PDF is not an eBook format

[frabjous]

Sounds great to me. Actually, if I spent a little less time on forums like MobileRead, and a little more time honing my currently very amateuresque programming skills, I think I might even be able to contribute towards such an end. Something perhaps not quite (2), but rather a script that took .tex source and simply made the adjustments for digital readers by adding a line for the geometry package with the appropriate settings (determined at run-time if you like, perhaps even with a GUI), perhaps adding \sloppy if the page size chosen was small enough, and then processed it by calling pdflatex already on the system, wouldn't actually be that difficult. The trickiest thing would be removing any calls to packages (or other formatting) incompatible with geometry.

With the way PDF renderers on our devices work (or at least on the Sony--I assume others), choosing a page size smaller than the native dimensions of the reader is basically the same thing as choosing a larger font size.

[ahi]

Originally Posted by frabjous

Sounds great to me. Actually, if I spent a little less time on forums like MobileRead, and a little more time honing my currently very amateuresque programming skills, I think I might even be able to contribute towards such an end.

He he.

Alas, I have not yet managed to wrap my mind around GUI programming sufficiently that I'd be competent to do #2, and in too many ways TeX file structures and correspondences remain a mind-boggling mystery enough to me that I'd almost certainly be useless to work on #1 as well.

However, the idea of single source TeX files for multiple output versions continues to intrigue me ever more, and I might do some playing around with that concept. If I come up with anything of consequence... perhaps a useful set of "macros", I might try to figure out how to put it together into a proper package for everyone's benefit.

- Ahi

[ahi]

Originally Posted by frabjous

Something perhaps not quite (2), but rather a script that took .tex source and simply made the adjustments for digital readers by adding a line for the geometry package with the appropriate settings (determined at run-time if you like, perhaps even with a GUI), perhaps adding \sloppy if the page size chosen was small enough, and then processed it by calling pdflatex already on the system, wouldn't actually be that difficult. The trickiest thing would be removing any calls to packages (or other formatting) incompatible with geometry.

Yes. The main difference here is that it sounds like it would attempt to "domesticate" wild TeX source files. Whereas my conception of #2 would work with files specifically intended to be used by it (and/or other similar programs).

Simplest way is to have there be a simple set of variables defined as basically the first thing in the source, and have everything use those (instead of hard-coded values) thereafter. #2 could alter the values of those variables, and would basically expect the output to change accordingly because the TeX source is (supposed to be) setup in such a way.

Originally Posted by frabjous

With the way PDF renderers on our devices work (or at least on the Sony--I assume others), choosing a page size smaller than the native dimensions of the reader is basically the same thing as choosing a larger font size.

True. Although if there is any raster content (that is large enough that it should be downsized/resampled to whatever smaller page size) it would benefit from the correct page size being used.

- Ahi

[DawnFalcon]

Ahi;

Why should there need to be firmware support for specific hyphenation dictionaries? The smart way to do it is to support plug-in dictionaries in the file format...

Thing is, there's no reason that a custom DVI format for ebooks couldn't contain the markup for multiple screen sizes without needing to duplicate the base data, but there's also no reason why ePub couldn't be extended to do that either.

Except that Publishers, well, won't.

[ahi]

I'll just pretend you are aware that there are typesetting and layout issues between different languages that are not related to hyphenation.

- Ahi

[DawnFalcon]

I'll just pretend that you're aware that it was one example, and mysteriously enough, you can use different interacting systems to create a complete typographical layout.

Strange, that.

[ahi]

Ah, yes! Technology will magically save the day.

We cannot quite say how, nor are we even aware what obstacles there are to overcome--but we are confident beyond any doubt that it will triumph, and very soon at that.

Good show!

- Ahi

[DawnFalcon]

Yea, that is precisely your line, that there will only be a few fixed sized screens and publishers will be willing to provide PDF's for each of them.

Wait...

(There's a difference between actively working to take ePuB in a plausable direction and bland assertion that a few screen sizes will become standard)

[sanders]

For "normal prose", I suppose automatic layout would be feasible. However, for complicated (scientific) documents, I'm not very hopeful that this can happen without human intervention.

For my book (shameless plug) I made a specially formatted version for 8" ebook readers (I have an iRex iLiad myself) and that was a lot more work than just changing some parameters of the geometry package. I had to move illustrations around, and even re-word some of the paragraphs to fit. Fortunately, I did manage to include both versions in the same source file, so I can select at "compile time" which format I want. But doing this again for a 6" version or perhaps a separate 10" version would be getting progressively more difficult, and I'm not sure the extra sales would warrant the effort.

I do think that extending PDF as a "container" which has multiple pre-rendered versions is a pretty good idea, and much more elegant than having to keep different files around.

[EowynCarter]

Originally Posted by sanders

For "normal prose", I suppose automatic layout would be feasible. However, for complicated (scientific) documents, I'm not very hopeful that this can happen without human intervention.

Can do.
The real problem there is that some stuff just won't render "as is" on 6" or 5", no mater the format.

[jackau]

I agree, pdf is not an Ebook format, maybe in 18 months time, certainly NOT NOW!

E-readers' software need catches up, their hardware is more capable. Then ADOBE is kind enough to give us a FREE software that converts the pdf to a form support by most devices (all ebook makers need is upgrade software to support this new format...)

[ahi]

Originally Posted by EowynCarter

Can do.
The real problem there is that some stuff just won't render "as is" on 6" or 5", no mater the format.

Stuff also won't render as is on a 6x9 paper book size page. It will require human intervention still. Perhaps less of it, or of different sorts... but still.

Edit: Though I see you wrote "some stuff". Well, naturally. But most books, technical and scientific ones among them ought to be convertible with relatively few (and even fewer drastic/fundamental) changes into a 6" (or better yet a 8") eBook format using PDF. But more likely, if it is beyond simple prose, only down-converted into HTML or HTML+images.

Originally Posted by jackau

I agree, pdf is not an Ebook format, maybe in 18 months time, certainly NOT NOW!

E-readers' software need catches up, their hardware is more capable. Then ADOBE is kind enough to give us a FREE software that converts the pdf to a form support by most devices (all ebook makers need is upgrade software to support this new format...)

Darn! Almost 40 pages of sometimes nuanced discussion when the truth was in front of our noses all along.

Originally Posted by sanders

I do think that extending PDF as a "container" which has multiple pre-rendered versions is a pretty good idea, and much more elegant than having to keep different files around.

Any chance you are a GUI programmer extraordinaire?

- Ahi

[frabjous]

Originally Posted by sanders

For my book (shameless plug) I made a specially formatted version for 8" ebook readers (I have an iRex iLiad myself) and that was a lot more work than just changing some parameters of the geometry package. I had to move illustrations around, and even re-word some of the paragraphs to fit. Fortunately, I did manage to include both versions in the same source file, so I can select at "compile time" which format I want. But doing this again for a 6" version or perhaps a separate 10" version would be getting progressively more difficult, and I'm not sure the extra sales would warrant the effort.

I don't doubt it in your case. To be fair, however, the book I've been working on typsetting is a technical work in the philosophy of mathematics, and has things like equations, graphs and matrices in it -- though probably only a fraction of what your book does. I'll admit that I definitely did do more than just change the settings for the geometry package and let 'er rip. I did move some figures, and introduce different break points in long displays, etc.

What we'd need is a number of people--not necessarily the author--who are especially trained at writing code in a way that uses ifthen or, better, some new LaTeX packages especially for the purpose, to make the necessary conditional adjustments -- you've done it for a couple sizes; I've done it for a couple more. When people get more experience with this, and new packages are created, I imagine it could get easier to do this, and even more towards arbitrary sizes.

Mentioning something that would take the code and insert some geometry package options was just something I had in mind as something I might even be able to script with my very limited skills, which would work on many documents, including nearly all nontechnical ones, and even some technical ones, though not all.

Is it worth the effort? With the current market for digital books, probably not. But digital publishing is already becoming more and more common, and I don't think the trajectory is going to slow down anytime soon. Already, most academic libraries have moved towards having most of their journal subscriptions being electronic only. As long as they're doing this, why force a fixed format on the end-user, as you must with paper? And this is just the tip of the iceberg.

Congrats on your book, by the way.

[ahi]

Originally Posted by sanders

But doing this again for a 6" version or perhaps a separate 10" version would be getting progressively more difficult, and I'm not sure the extra sales would warrant the effort.

Hmmm... might not the sales of a 6" version warrant the extra effort well over even the combined potential sales of an 8" and a 10" version? (What with most eBook reading devices having 6" displays.)

Also, (admittedly less complicated) all of these took me less than a full day's worth of work.

- Ahi

[DawnFalcon]

"What with most eBook reading devices having 6" displays."

It's a convenient size. Actually, a fair few have 5" screens as well these days. Smaller readers for novel reading... sure, they're going to typically munge technical books and the like horribly, but they're not really intended for such!

Although again I'd note that very hopefully the next ePub standard will support MathML natively...