I’m pretty excited for this to be added to ereaders, which notoriously (among people who care about this kind of thing) have terrible layout engines.
Better ways of laying out digital text have existed since before ereaders existed. Even this one CSS directive has already been supported by Chrome for two years. What's missing is Amazon & co. giving a shit about it. That needle shows no signs of moving.
> Even this one CSS directive has already been supported by Chrome for two years
The article says what chrome does is only support the “no super short lines” bit.
So while you won’t end up with one word on its own line at the end of a paragraph, it’s not trying to prevent rivers of text or keep a relatively clean ragged right or anything else.
That’s allowed by spec, but it’s not quite the same thing.
I was about to ask about that, how are / were traditional paper books lined out to prevent this? Surely not by hand. Proprietary software maybe?
Well, before desktop publishing, by phototypesetting [1], before that by hot-metal typesetting [2], before that, by hand. Nowadays, with software like Adobe InDesign, of if you happen to be a CS/math/physics nerd, with LaTeX, which has a famously high-quality layouting engine that utilizes the Knuth–Plass line-breaking algorithm [3]. Indeed it's fairly well known that Donald Knuth created TeX because he wasn't happy with the phototypeset proofs he received in 1977 for the second edition of The Art of Computer Programming, finding them inferior compared to the hot-metal typeset first edition.
[1] https://en.wikipedia.org/wiki/Phototypesetting
[2] https://en.wikipedia.org/wiki/Hot_metal_typesetting
[3] https://en.wikipedia.org/wiki/Knuth%E2%80%93Plass_line-break...
The old linotype machines had visual indicators of minimum and maximum line width, and the operator would make a judgement call with each line. Spacers would then automatically justify the letters. It was all mechanical and amazing.
See http://widespacer.blogspot.com/2014/01/two-spaces-old-typist... for many details.
Books were produced before computers, and with very good typesetting. One difference between websites and books is that theee is a feedback loop with books where somebody ia at looking at the layout and either adjusting the spacing subtly, or even editing the text to avoid problems. Sometimes this is just to ensure that left justified text isn’t too ragged on the right edge, sometimes it’s to avoid river of space rubbing through a paragraph, and sometimes it’s editing or typesetting to avoid orphans.
But text on a page is set for a set layout, and that’s where the web really differs.
In ye olde dayes, indeed by hand. That's why there was often extra space after punctuation. In more mechanized times, the operator has to watch for it. Proofreaders are trained to watch for loose lines, rivers, widows, hyphenation errors, and other spacing problems. Those things will be marked as errors in proof. Even with modern DTP tools, typesetters still have to make a lot of manual corrections. Of course, for print, you're setting for a fixed format. You can do a lot of fine-tuning that a browser can't do on the fly.
The idea of extra space after punctuation (especially periods) being a result of printing technology is a myth. Extra space is present in handwritten documents: go look at the US Declaration of Independence or Constitution for well-known examples. People only started shortening the space between sentences to match the space between words very recently.
Nowdays basically any professionally produced book is made in Indesign. And text wrapping is semi-automated. It's automated but checked for issues and fixed manually. Indesign has two text wrapping algorithms paragraph composer that tries to balance whole paragraphs and line composer that only checks line by line.
Surprisingly in the high-end the less automated line composer is used a lot more. It requires more work but human decisions lead to best results if done properly.
Currently on Android i use Moon+ reader that has hyphenation + hanging punctuation. Before that (2008-2013) I used eInk reader that came with CoolReader (its layout engine "crengine" is the base for KOReader) that also had good hyphenation and hanging punctuation and nice footnotes.
So in my experience ereaders have had great layout engines.
Note that it’s up to the browser to do whatever it thinks is best. They didn’t lay down specific rules.
So unless the e-reader uses an engine that already has good rules there will be no real change unless the manufacturer does what it should have already.
Is this where folks will get it for ereaders? Naively, I hadn't realized ereaders were glorified webkit displays.
EPUB is HTML.
I knew it was related, but I had assumed it did not rely on CSS. Again, I noted it was a naive view.
Granted, I probably view CSS with far more disdain than I should.
CSS is your friend
The cascading aspect is mostly a big L. As is the dream of user style sheets. All the more so from the obfuscated style names so many tools saddle us with.
Don't get me wrong, there are smart people working on css. That we decided, as an industry, to treat layout as a Rube Goldberg machination of interacting rules on a growing number of elements is not something you can easily overcome.
Sometimes I like to think Knuth may have intrusive violent thoughts about how shit programmers make text look.
yeah, I agree, sometimes reading an ebook feels very off b/c of the lines just looking way too justified