Quote:
Originally Posted by DawnFalcon
Until? Please link any movement whatsoever in PDF towards this (and not the 2002 effort for PDF, either). LaTeX has some fairly broken support for this which is incompatible with most DVI drivers.
|
1) For the
fourth time, LaTeX does not need to use a DVI driver, and
even if it did, 2) It support for differ font sizes and different page sizes/styles, and putting in commands that are only activated when certain font or page sizes works whether it's using the DVI driver or a PDF driver. On what basis do you say it's support is broken? It works flawlessly when I've done it, and yes, I've done it. In fact, I'll demonstrate in just a moment.
All right, the eBook I'm working on is a public domain title,
Introduction to Mathematical Philosophy by Bertrand Russell. I first made an HTML version of this, which I converted to .mobi and .ePub. Here's how my
first attempt at a mobi looked like as a screenshot on a Kindle:
Things to note: it looks like crap generally, and the overlining (which you'll see below) doesn't even work since mobi doesn't support it. (I've since had to modify the original notation there... I hate mobi files.)
ePub is an improvement, since you can at least overline. Here's a screenshot from ADE from the ePub version:
This looks better than on my Sony, where I can't get full justification, but it still looks pretty bad. The variables are not in true italics, but a slanted roman, and hence run into the Sheffer strokes next to them, since ePub has no knowledge of mathematical spacing. (Probably with CSS tricks it could be emulated, but it would be a lot of work.) The Sheffer strokes have to either be full upright, or rendered as slashes, with no in between. Nothing is hyphenated, so there is too much space on some lines, such as the one under the first display.
I took my HTML source and converted it to TeX by running a bunch of regular expression finds and replaces. I then made several different PDFs, originally one for letter paper, but also (from the same source), one of them sized for my Sony. Here's a screenshot of the relevant page:
I think this looks good--maybe not as good as trained professional could do, but not so bad as a amateur. I can indicate original pagination in the margins the way I want it to appear (not forced on me by ADE). Not only is there overlining, but it is done dynamically: higher when what is overlined is higher. The Sheffer strokes are defined as operators, and so there is extra space put between them and the true italics variables next to them. (The space is not in the code; it's done because of their mathematical semantic category.) The narrow scope ones are slanted, but not as far as a slash, so they don't look like fractions. Words are hyphenated at syllable breaks when need be. There are ligatures, kerning, etc. There is extra space between sentences as opposed to between words.
Can this be "reflowed"? It could be if our readers came with LaTeX interpreting software... Wanna make a minor change to the font size? I change literally one character in my .tex source and click a button...
The font is larger. Different words are hypenated. I didn't pick these spots; it did. Could what it picked be tweaked? Maybe... it's not clear to me how it should be, though. We now have a footnote on the page, since after reflow the footnote from slightly above is visible.
Yes, there is an widow, but I chose to allow it to do that. I could have made it impossible with again, just one simple change that could be automated.
Want a bigger change? Let's change the font to Utopia. This time I have to change one line of code in the premable (which could of course be automated), and click a button:
Again, different words hyphenated, etc., but still looks good, IMHO. (This time the footnote is on the previous page but runs over to this one... yes, I guess this is a relic from paper publisher, but it still beats endnotes, which no one reads.)
Want another radical change? Let's change the page size to that of a iphone and eliminate the right margin. Again, I change one line of code, and get:
Still looks good, or at least as good one could expect from that font size on that screen size.
All such changes could be done using variables and precisely the same code. Better yet, it could be programmed to alter its badness weightings according to the variable (this could be programmed into the reader software--I didn't do anything like that at all to get the above.)
Is the above perfect? No. But it sure beats what we're getting with ePub.
I think people are overreacting the problems involved with such things as manually checking widows and orphans, etc. LaTeX automatically puts in extra space after sentences (as I'm sure Jellby knows); it can be programmed to do widow and orphan control up to a point, but not do it when it would result in too much whitespace, etc. Could you improve the results with some manual checking and tweaking? Sure! But once again, having something that is programmed to
try to get these things right the first time is surely an improvement over something that doesn't do it at all.
And I don't see why either LaTeX, or a similar renderer, even one for HTML/ePub source, couldn't be created and improved until it does it
almost as well as a competent typesetter would do... maybe not the best typesetter, but a competent one. It's just a defeatist attitude to think we have to choose between completely fixed page layout, and lousy reflow. We can, and should, have both reflow and decent typography!