Hacker News Reader

Comment by JackeJR | Hacker News Reader

There are many reasons this comparison is not made. I will just touch on one. The target medium is different. For html, you have monitors of different sizes as well as windows that can be resized. For latex, you choose your target at the start: A4 paper? Screen presentation? A0 poster?

With a fixed medium in mind, you can be extremely particular on where on this canvas you want a piece of text/graphic or whatever.

Without a fixed medium, you have to have logic to address the different mediums and compromises have to be made.

View on HN

That seems contradictory, when Latex is rather famously imprecise at placing figures and such. Weren't both languages (at least at some point) intended to take layouting control away from the writer?

But regardless, I think that, in addition to moving away from Latex we should also reconsider the primary output format. Documents are rarely printed anymore, and inaccessible, fixed-size A4 pdfs are annoying to read on anything but an iPad Pro.

LaTeX isn't intended to take layout control away from the author so much as it is intended to automatically produce a good-enough layout allowing a single author to produce a very large document without employing a designer.

HTML by contrast explicitly does remove control over layout from the author and place it in the hands of the user (and their chosen user agent).

Both languages have mechanisms to (somewhat) separate the content from the formatting rules.

Both claims are incorrect.

LaTeX would rather produce a bad document if it cannot produce a good one. Example: overfull hbox. A designer is still required who creates the documentclass, it is just that LaTeX comes with some predefined ones intended for scientific publishing.

HTML+CSS require pixel-perfect rendering. Example: ACID2 test. While it might have been the idea of plain HTML at some point (<em> instead of <i>), control has never been taken away from the author thanks to CSS.

You're badly mischaracterizing tests like ACID2. The test definition includes a long list of things that invalidate the test, including things like changing the zoom level. So it's wrong to construe that test as requiring pixel-perfect rendering when it explicitly doesn't cover exactly the kind of user agent controls I'm talking about.

Your comments about LaTeX do not seem to contradict anything I said.

Well, maybe they’re not printed by yourself. But many academics, often young people included, still print papers.

Which they can still do. Printed HTML is perfectly serviceable (definitely better than non-printed PDF).

Or are you arguing that there are somehow more people reading printed papers than digital?

HTML+CSS has facilities to target a page format (CSS @page rule, cm and in dimension units). Not to say that it's on the same level as LaTeX, but it's pretty impressive by its own right.

Note that this won't prevent the page from being displayed in other sizes, where it will most likely have a broken layout instead.

True, but with CSS you define one layout for the web format alongside a different layout for the print format, using the @page rule.

If I want only the print format this will require double the effort though.

No it doesn't? If you only want the print format, just do the print format layout, ignore the web format. Why do you care that it's broken there?

Are there good deep dives on how far you can practically this? Especially in combination with headless browser pdf generation?

Last time I looked into it, a while ago, my impression was that it would get rickety too soon. It’d be a good place to be, I think, if web and “document” tech stacks could have nice and practical convergence.

We use CSS paged media to create e-books and invoices (using weasyprint [0]). One of the most helpful resources for me was print-css.rocks [1], they cover a lot of what’s possible and include which tools support which parts of it (tools targeting paged media, browser support is essentially non-existent and outside using JS to fake it with paged.js, not relevant). The expensive tools tend to support more features, but thanks to some donations/sponsorships, weasyprint has really caught up and now supports a very large part of the spec.

> Especially in combination with headless browser pdf generation

I have no idea why you’d want to do that. Browsers are bad at it, dedicated tools are great at it.

[0]: https://weasyprint.org/

[1]: https://print-css.rocks/

[2]: https://pagedjs.org/

> I have no idea why you’d want to do that. Browsers are bad at it, dedicated tools are great at it.

Fair! I was just aspiring to a place where web pages and documents converge more.

Thanks for the recommendations!

I'd say it's already there. See for example the https://pagedjs.org/ project which allows advanced typesetting (including for printing) using web technologies. It is already used in production by at least one book publisher (C&F editions)

I've used it for my own such production, perfect binding with a hand guillotine and screw clamps in my attic - nothing remotely professional, but you still have to start by making a book block, and Paged.js is a solid call there. Unless beauty of typography (more than TTF/OTF hinting can handle) is of particular merit, it's usually my preferred first typesetting option.

As an old hand with PDF-in-browser production, I expected much worse of Paged.js than I found. It's powerful and mostly enjoyable to use! Oh, you end up with a large set of CSS rules, and it is not without bugs and gotchas (failing to specify a bleed rule somewhere at least once in every @page context subtly breaks layout; footnote layout is functional but automatic call numbering isn't always perfect, etc.)

You should definitely not expect to take Paged.js out of the box, slap a theme on it, and go; it comes as a box of parts with a mostly complete machine inside, and if it breaks you get to keep all the pieces. I imagine the publisher who uses it must have some prior interest in web technologies, for example.

Nor is Paged.js remotely as capable or flexible as InDesign or a comparable tool, especially for the deeply rudimentary condition of web typography overall - something even as elaborate a tool as this can't really approach fixing.

But Paged.js is also unlike InDesign in having a much shallower (days vs months) learning curve for folks like us with prior web experience, and however equivocal a review I may now be giving of its technical merits, I do actually like working with Paged.js quite a lot.

I've also used pagedjs for a relatively complex booklet with bidirectional text in different languages, images and long footnotes. The result was great but there were some annoying bugs, some of them seeming to be possible underlying bugs in chrome and Firefox. Still, latex would have been even more frustrating.

Coincidentally, I've also used pagedjs for a project recently (125K novel) and encountered some bugs/minor issues. Overall though, I would say I had an immensely positive experience (because even when stuff broke, it was still just HTML, CSS, and JS--so I, like any other web developer, could fix it).

That said, it's a shame that the relevant W3C specs (see https://pagedjs.org/about/) still aren't fully supported by browsers (but perhaps such is the fate of niche features), but with that being the case, I'm infinitely thankful that pagedjs exists as a polyfill.

Oh, I certainly don't doubt that. And as I said, I haven't really found Paged.js all that frustrating! I have extensive though not recent Pagemaker experience; I expected InDesign to be easier, and now I rue the day when that's where I'm forced to resort.

In my experience Paged.js is at its best when building to PDF, but then that's always my intermediate format when working to paper, because that's where PDF's inflexibility shines. The source of a book block, everything that builds to that PDF, partakes of all the infelicities of the JS ecosystem. But to remake the book itself again, all I need do to start is print the PDF.

I pay for a tool to convert HTML/CSS into PDFs https://www.princexml.com/ and it seems to work well. I don't have the best idea of how it compares to the various free options though.

> For latex, you choose your target at the start

Yes, sometimes, but I would say that one of the benefits of latex is how easy you can switch to another layout. But I guess the point is that you typically render to a set of outputs with fixed dimensions (pdf)

> For latex, you choose your target at the start: A4 paper? Screen presentation? A0 poster?

You can change that as you go along.

> You can change that as you go along.

that's not the point they were trying to make. you may need to change the display target for every viewer.

That's an interesting point.

HTML is usually distributed 'as source'. TeX (or LaTeX) is usually compiled to some other format first, before being distributed.

Yeah, I wonder how good TeX renderers would have gotten if page rendering happened client side in a browser.

TeX worked (and works) in batch mode on ancient hardware. Today's computers are so much faster, that this should actually be fast enough to run interactively without having to change or optimise too much.

Why does TeX take so long to render documents today, then?

Reply on news.ycombinator.com