Hacker News Reader

Comment by lazyeye | Hacker News Reader

Why you would use anything other than a HTML -> PDF rendering engine is beyond me.

Because styling semi-complicated PDFs with CSS is a layer of hell right above e-mails & old browsers. I say this as someone who enjoys CSS & in the .NET world has used this method over things like Crystal Reports (even before they dropped their .NET support).

I havent found this at all. Ive been rendering very complex html to pdf (complex svg charts, headers, footers etc) and its been fine. Just a matter of getting the element heights/widths correct. Once you've got the basic page template done its not much effort at all to tweak as required

Have you heard of Paged.js ?

There's a good matrix of feature support at https://print-css.rocks/lessons for all the things HTML-to-PDF engines can (and can't) do.

The CSS3 Paged Media spec was born broken on some fundamental things like counter resets, then effectively abandoned in 2013, so some complex print-specific requirements like fully customizable page numbering just don't happen without additional tooling. Accessible tagged PDFs are still a struggle, and I think only Weasyprint readily supports them among free or open-source options (and only since around September).

Here's some PHP code to handle page numbering :-

<?php

$pagenum = 1;

$pagenum++;

print("Page: $pagenum");

That prints "Page: 2". It doesn't appear anything related to pagination or layout.

Well obviously you'd have that code on each page. So thats the incredibly complex and challenging page numbering problem solved.

As far as pagination is concerned I wrap each page in this tag

   <page size="A4">  </page>

with this css:-

page[size = 'A4'] { height: 29.7cm; width: 21cm; page-break-before: always; }

    page[size = 'A4'][layout = 'portrait'] {
        height: 21cm;
        width: 29.7cm;
    }

So that's the incredibly complex and challenging problem of pagination solved.

And fortunately html does layout too.

You're just pushing complexity around. Now you have to figure out how much content you can put on each page before you have to make a new one. The reason it seemed so easy is that you just deferred the hard part.

Nope. What you call the "hard part" is

if (rowcount > 100) newpage();

But lets use an entirely new, esoteric PDF specific layout language instead and we wont call that the "hard part".

Actually to be fair it obviously depends on the situation. If you are churning out large volumes of PDFs then it might make sense to get the efficiency with a PDF-specific language. But HTML -> PDF definitely has its place too and is not as hard to work with as people are claiming.

You did it again. What's a row? Are you telling me that 100 of them will fit on any page, regardless of font size or margins?

Why would you be randomly changing the font-size or margin? Surely that would be known in advance?

Sometimes they might be. But even if you know the font size of the headers, the contents, and the bulleted lists, you still won't know where the paragraphs wrap, unless you also require a fixed-width font, and don't allow any of the word lengths to change. But then we probably wouldn't be calling it a "modern library for PDF generation".

For a proper page numbering, consistent word wrapping, pixel-perfect font rendering and document outline support.

You cant do page numbering in html? Seriously? I haven't had an issue with any of these things rendering html to pdf.

The Paged Media spec on counters and counter-resets paints implementations into a corner. They can't both comply with the spec and implement page count resets on page breaks. This has been a known issue with the spec since 2013[1][2] and been a thorn in implementations since.[3]

1: https://www.w3.org/Style/CSS/Tracker/issues/334

2: https://github.com/w3c/csswg-drafts/issues/4760

3: https://github.com/Kozea/WeasyPrint/issues/93#issuecomment-4...

Here's some PHP code to handle page numbering (page breaks are no problem at all rendering html to pdf) :-

<?php

$pagenum = 1;

$pagenum++;

print("Page: $pagenum");

I’ve had trouble with html -> pdf when it comes to tables. Most of the packages out there don’t have a way to say “if only the first few rows of the table will render before a page-break, then put the page-break before the table”. Or getting a table to not break at row X when that row has a cell that spans more than one row. Or getting table headings to repeat on the next page when a page-break mid-table is unavoidable.

These are all things that good page layout software can deal with easily.

HTML to pdf is also pretty slow and unreliable when you want a table of contents or an index with page numbers. On a fast machine, a 200 page PDF can take several minutes to generate. PrinceXML is the only software I’ve tried that does a good job of it. For very simple documents (no CSS, limited Unicode) HTMLDoc is pretty good and very fast.

I agree with html you have to manage the pagebreak within the code but honestly its not that complicated to insert a pagebreak based on rowcount.

Row count is not the only condition for how much can fit on a page.

Content matters for row height, as does fonts, styling, etc. Footers, too. The number of footnotes (thus the height of the footer) can depend on the page content, too.

Maybe there's an image in there, or some sort of specially styled content that makes the line height larger than normal.

You have to be able to render the row to know the final dimensions, to be able to make a call whether it should go on that page or the next. If you don't, then you end up with one page actually rendering over into a second page.

Is there an open source pure-.NET library that implements this?

I've heard good things about https://github.com/Kozea/WeasyPrint in Python.

Filling a fillable PDF programmatically?

Reply on news.ycombinator.com