PDF is not an eBook format

[DawnFalcon]

Originally Posted by ahi

I refer you to my earlier remark.

Oh right, yes, when you admitted you were early teens. Sorry, that dosn't get you a pass from me, when you make authorative statements as you have, they get examined.

One side is trying to desperately defend the current broken state of the eBook market by pointing out the myriad possible workarounds and insisting that only formats that will forever continue to permit such workarounds are viable.

Well yes, the side of the argument is trying to insist that the only way to proceed is to shackle ebooks to the limits of print books, and the only workaround to multiple screen sizes is to have as many different, seperately proofed, documents for each of them.

The other side is trying to point out that the very need for workarounds is a sign of careless neglect on the part of publishers and will eventually need to be remedied, regardless of how it impacts people's ability to poorly tweak their eBooks.

Completely. The ADE renderer needs drastic improvement, or another switched to, and the ePuB standard needs to be driven fowards. Nice to see the agreement for once.

However if the pro-PDF crowd get its way, there's no reason to assume that technology would not develop to accommodate those who prefer dynamic layouts.

Quite right, there's no reason or need to assume, the history of the PDF format makes it quite clear that it has no real possibility whatsoever of it happening, and Abobe's effective abandonment of the development of the PDF in favour of ePuB is evident.

[EowynCarter]

Filesize need not be terrible, particularly if the zipping algorithm is able to recognize the similarity between the data contained in the various versions of the PDF.

But that would requiers some specific compressing. Thus, not readeable by someting else, and that's a bad idea. If it's normal zip, you can eventually get the one file you want, and be done. Unless you make some big changes to pdf so it deals with that all by itself. (but there, you might be bettter off getting rid of pdf and starting a new format altogether.)

It would be nice to have the reader go directly to the version we want. For ePub, it's easy, if preference say "ePub", you display ePub. If preference say pdf, 5" 12px, but the proposed versions are 11px and 13px, there you have a problem.
Then the reader should stores setting for all files. (easy, we're already storing last position and bookmark in an other file).

[ahi]

Originally Posted by DawnFalcon

Oh right, yes, when you admitted you were early teens. Sorry, that dosn't get you a pass from me, when you make authorative statements as you have, they get examined.

Well yes, your side of the argument is trying to insist that the only way to proceed is to shackle ebooks to the limits of print books, and the only workaround to multiple screen sizes is to have as many different, seperately proofed, documents for each of them.

You're deranged... on both counts.

Originally Posted by DawnFalcon

Completely. The ADE renderer needs drastic improvement, or another switched to, and the ePuB standard needs to be driven fowards. Nice to see the agreement for once.

An inability to understand is a sign of nothing more than plain ignorance. But yes, for the sake of the reflow-crowd those things should also be done.

Originally Posted by DawnFalcon

Quite right, there's no reason to assume, the history of the PDF format makes it quite clear that it has no real possibility whatsoever of it happening, and Abobe's effective abandonment of the development of the PDF in favour of ePuB is evident.

Frankly, judging by all the statements you made thus far, your understanding of technology in general is tenuous at best... and your predictions are mostly based on misconceptions.

- Ahi

[ahi]

Originally Posted by EowynCarter

But that would requiers some specific compressing. Thus, not readeable by someting else, and that's a bad idea. If it's normal zip, you can eventually get the one file you want, and be done.

It would be nice to have the reader go directly to the version we want. For ePub, it's easy, if preference say "ePub", you display ePub. If preference say pdf, 5" 12px, but the proposed versions are 11px and 13px, there you have a problem.
Then the reader should stores setting for all files. (easy, we're already storing last position and bookmark in an other file).

Oh, yes... if there's no easy way to "nudge" the ".zip" format to do this, I'd live with the size excess until (soon enough) it stops mattering or even being noticeable.

Your idea about preference matching is a good one. The eBook market is sorely in need of some smart people that are both programmers and bookmakers to sit down and come up with some clever ideas. I am certain though that it will happen sooner rather than later.



- Ahi

[EowynCarter]

An other (maybe better idea), would be do add an OPTIONAL layer on ePub for fixed page size and font size. (Mmm, there are actually loads of problem there, it like trying to relflow pdf, not the way to go because not meant for that)

[DawnFalcon]

Originally Posted by Sonist

Uhm, the general public doesn't really care, they stream stuff like Hulu, or Netflix, which in fact do use the same formats as TV broadcasts.

Really? Cite please where podcasters use ATSC or DVB please.

Nope, what Ahi wants may come to exist when Apple, or someone else, introduces a large-screen, color device, which will do for tablets/readears what the iPhone did for smart phones.

Introduce a marketplace in which it's almost impossible to get your product noticed and driving down prices to unsustainable levels? Oh, and let's not forget it's a single sales channel with moderately arbitrary censorship. It's really not easy to make money from an iPhone app unless it's at the very top.

And again, large-screen is not what an awful lot of people want from an e-reader.

But, what you want, already exists, and has existed from the most primitive times of desktop computing. It's called plain text. And no, it's not the future.

Really? Cite please where plain text standard has pop-up text support, support for US/UK spelling english differences, embedable bookmarks and remote text pushing, to name a few of the things I want and have previously mentioned in this thread.

'nuf said.... Do you even have experience with an ereader?

Yes, although I don't have one at the present time.

I bet, you don't get why people want Flash and Java too....

I understand why people use them. And quite often misuse them, too, creating sites which they call Web 2.0 but are actually just a mess to navigate.

As to apps and games, certainly, ActionScript is very useful. Java if you're looking at the mobile market certainly - except the iPhone, of course.

Uhm, PDF is one of the formats, from which you generally strip the DRM rather easily.

So as well as immoral (buying DRM'ed content) actions, you want me to take illegal ones too? No. Just no. I'd rather buy dead tree format, thanks (This is why most of my ebooks are from Baen, it's not because I don't read wisely, but because Baen has sensible standards and prices for ebooks).

I am not married to PDF, but I am worried, that another new format, like ePub, which is not really robust enough to support very complex layouts and is therefore destined to be another dead-end, will only confuse the market, and turn people off e-books.

So you're saying that XHTML, the base of ePuB, can't do complex formats? The standards committee would be very interested to hear that.


ahi - So I'm deranged for replying to your statements? Well them, I'll be general - again, you cannot ignore todays limitations in favour of some future utopic time, you have to deal with the situation as in the here and no and publisher's and adobe's actual actions.

[DawnFalcon]

Originally Posted by EowynCarter

An other (maybe better idea), would be do add an OPTIONAL layer on ePub for fixed page size and font size. (Mmm, there are actually loads of problem there, it like trying to relflow pdf, not the way to go because not meant for that)

My problem with that is the ePuB standard allready has too many "optional" elements, which threaten to fragment its support. I'd rather see a "layer" system for it which allowed you to insert manual formatting for some page, font and margin sizes, with reflowing for all other page, fonts and margins. Note that there would be no duplication of the base text, just of the formatting.

[EowynCarter]

So you're saying that XHTML, the base of ePuB, can't do complex formats? The standards committee would be very interested to hear that.

And there some nice stuff coming for css 3 too, like multiples columns. (But adobe needs to begin with supporting css 2 fully )

Hulu, or Netflix

I wish we had these in France !

My problem with that is the ePuB standard allready has too many "optional" elements, which threaten to fragment its support. I'd rather see a "layer" system for it which allowed you to insert manual formatting for some page, font and margin sizes, with reflowing for all other page, fonts and margins. Note that there would be no duplication of the base text, just of the formatting.

I'm not sure how that would work.

[DawnFalcon]

Well yes, I'm certainly not arguing that the progress on the ADE renderer dosn't need a rocket up its...er... backside.

[Alexander Turcic]

Ok, I am a bit late to this discussion, but may I make the friendly suggestion that we all agree that there are differing opinions in regard to the usefulness of the PDF format, and that we won't find a definite answer, at least for now?

There were a few unfortunate remarks that could easily be interpreted as personal attacks. I would like to remind everyone that this is a friendly community and that we don't condone personal attacks. Please respect this, or we cannot continue having this discussion.

Thank you.

[Kostas]

Originally Posted by ahi

Yes, today you are better off getting an ePub and either suffering the poor quality or fixing it yourself by turning it into PDF via LaTeX. Once publishers start doing their jobs with regards to eBooks: PDFs will look good. They will be designed for eBook reading device screen sizes. They will reflow suitably. End of story.
- Ahi

I really could live with this statement... At last...

[ahi]

Originally Posted by Kostas

I really could live with this statement... At last...

Good for you! I've probably said this a good few times before both in this thread and in others.

Frankly, Alex, this thread really should be closed down. At best it's a place where people are shouting at each other from mountaintops miles away... there being no chance of information or views being successfully exchanged. At worst... well, my less kind assessment of this thread is well known by those that have been reading it.

After about 30 pages of discussion, there has basically been no progress... despite the fact that we are not talking about subjective things, as much as people want to suggest otherwise.

I'll make another judicious attempt to resume ignoring this thread... perhaps for good, this time. It is as much a waste of my time as it is of everyone else's.

- Ahi

[PKFFW]

So much hate and rudeness.

[frabjous]

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!

[DawnFalcon]

Originally Posted by frabjous

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.

No, you don't need to use a DVI driver, but any other means of rendering is going to have higher overheads. It's what DVI is designed for, after all. In the meantime, you're saying that the PDF output works? Well yea, but that dosn't deal with my requirement, for instance, for multiple screen sizes without using different documents and losing my annotations.

(Also, as far as I know, there isn't a suitable DVI driver for the ARM architecture so one would have to be written)

(Probably with CSS tricks it could be emulated, but it would be a lot of work.)

Actually, while MathML isn't embedded into readers at present, it can be used in ePuB documents as an island, along with backup images, and in future renderers which support it, they'll render. You can even include a SVG and render that on platforms which support it as well.

And the next version of ePuB is very, very likely to mandate MathML (and there's no reason it can't be added in firmware, it's not a complex or large package).

And honestly, do you disagree that MathML is ideal for what you're trying to do? ePuB is a new format. It'll get there, and rapidly. I think your problem is more with the current version of ADE, which I'm not defending, and publisher lazyness* rather than ePuB.

(*I'm told darknet books often have better formatting than official ones)

(I'd note that modern TeX editors can convert to MathML, it's not like it's restricted to HTML-derived formats)