Well, HTML comes from SGML, so I guess the loop is closed.
Using Web Technologies to Print a Book
11–20 of 69 posts
Re: Using Web Technologies to Print a Book
#12This doesn't work for Linux, but for folks writing a novel, I can definitely recommend Scrivener (Mac and Windows). In addition to a powerful writing environment, it's "Compile" feature can output flexibly for print and ebooks. I generated hardcover, paperback, mobi, and epub, with enough customizability for me and no scripting required. Granted this is Hacker News and people here _like_ writing code (myself included…
Well, Mac and almost Windows. Windows is still stuck in version 1.x of Scrivener, which is a decent-enough writing environment (bar the now-quite-quaint UI), but it's nowhere near the version 3 that Mac users have access to, especially as regards compilation and output. (I've been waiting for a Windows version update for years and years.)
Re: Using Web Technologies to Print a Book
#13Re: Using Web Technologies to Print a Book
#14This doesn't work for Linux, but for folks writing a novel, I can definitely recommend Scrivener (Mac and Windows). In addition to a powerful writing environment, it's "Compile" feature can output flexibly for print and ebooks. I generated hardcover, paperback, mobi, and epub, with enough customizability for me and no scripting required. Granted this is Hacker News and people here _like_ writing code (myself included…
Re: Using Web Technologies to Print a Book
#15Glad the author shared his methods. If you're going to repeat this, I'd suggest you give it a try with the first 10 to 15 pages. Something like a small zine. Then use all the tools and make sure you get the output you're expecting. I've written several booklets that I sell on Amazon and my website. If you're interested in writing but not ready to commit to a full novel, try publishing a small zine or two. It's a lot…
Thanks for sharing this link. I've written a few simple art-making Javascripts as well ( http://richardmavis.info/squares , http://richardmavis.info/circles , http://richardmavis.info/stars , http://richardmavis.info/snow , http://richardmavis.info/malevich , http://richardmavis.info/whale-shark-skin ) but am definitely interested in other techniques.
Re: Using Web Technologies to Print a Book
#16This doesn't work for Linux, but for folks writing a novel, I can definitely recommend Scrivener (Mac and Windows). In addition to a powerful writing environment, it's "Compile" feature can output flexibly for print and ebooks. I generated hardcover, paperback, mobi, and epub, with enough customizability for me and no scripting required. Granted this is Hacker News and people here _like_ writing code (myself included…
Re: Using Web Technologies to Print a Book
#17Do HTML and CSS rendering engines implement Knuth paragraph layout yet? AIUI, they still use greedy line layout and justification, which can produce various artifacts (like whitespace rivers and orphan lines) that the Knuth-style linebreaking in TeX avoids. Right now, I still don't think I'd consider using anything but TeX or some heavyweight DTP package for printed material.
No CSS implementation "for the web" does.
Implementing CSS justification for printing as Knuth-Plass and implementing so in a web-compatible manner is somewhat very different task. I think the algorithm's interaction with CSS floats is unclear. As always, it's in the Firefox's bug tracker, no, it's not because browser vendors don't want to or are lazy. https://bugzilla.mozilla.org/show_bug.cgi?id=630181
Re: Using Web Technologies to Print a Book
#18Do HTML and CSS rendering engines implement Knuth paragraph layout yet? AIUI, they still use greedy line layout and justification, which can produce various artifacts (like whitespace rivers and orphan lines) that the Knuth-style linebreaking in TeX avoids. Right now, I still don't think I'd consider using anything but TeX or some heavyweight DTP package for printed material.
As always, Unicode is a problem.
1: https://xmlgraphics.apache.org/fop/
Re: Using Web Technologies to Print a Book
#19Do HTML and CSS rendering engines implement Knuth paragraph layout yet? AIUI, they still use greedy line layout and justification, which can produce various artifacts (like whitespace rivers and orphan lines) that the Knuth-style linebreaking in TeX avoids. Right now, I still don't think I'd consider using anything but TeX or some heavyweight DTP package for printed material.
Apache FOP[1] does[2] if you're willing to jump back in time to XHTML or use an HTML2FO converter. As always, Unicode is a problem. 1: https://xmlgraphics.apache.org/fop/ 2: https://xmlgraphics.apache.org/fop/0.95/hyphenation.html cf. https://wiki.apache.org/xmlgraphics-fop/HowTo/HtmlToPdf
Re: Using Web Technologies to Print a Book
#20• It completely mangled the kerning, like it was ignoring the font’s kerning and then making it even worse by only placing characters to 1pt precision (at 600dpi, one dot is 0.12pt). (To clarify: I never actually measured it; this is just my rough guess as to what may have caused it.)
• It was somewhere between agonisingly difficult and impossible to actually get precise sizes; print A4, for example, with your body carefully set up so the widths add to the right amount, and the appropriate “don’t zoom” command line argument, and it’d still mess it up (and subtle content changes could make it better or worse). A container of `width: 15cm` could end up 15cm wide if you were extremely fortunate, but was more likely to be 14cm, or 17cm, or something like that. And it might vary from page to page.
• Pages didn’t really exist, in layout terms, so that any sort of finesse of where things should appear was just impossible.
• Probably worse, you could end up with the descenders of the bottom line of text on a page at the top of the next page. I have a vague feeling I hit a situation where a line could even be split in half, rather than just the descenders, but that may have been printing from Chrome or Firefox at a similar time.
• Its header/footer stuff was mildly limiting and fairly annoying to get working properly (and made document sizing even more troublesome, too).
It was also very crummy for producing a PDF for screen use, as regards things like links and tables of contents and other annotations.
Had it been just one or two of these things, I would probably have filed bugs; but it didn’t look as though there was much interest in actually fixing things, and it was so very broken for any sort of precise, serious work, that I just gave up.
Have things improved for wkhtmltopdf since then? I’d be interested to hear.
I found the state of the art for web-to-PDF conversion to be Prince (https://www.princexml.com/) by an enormous margin, with it producing absolutely superb results. Nonetheless, it does have some limitations; most notably, in my opinion, CSSOM, so that the JavaScript doesn’t interact with the layout at all. There were various other CSS and JavaScript niggles that I hit too, but they’ve steadily been fixed over time too. Bear in mind that Prince is made by a small team and is the entire web engine.
I would really like a vector graphics pipeline for Servo: https://github.com/servo/servo/issues/3788