View Single Post
Old 08-31-2009, 02:17 PM   #430
ahi
Wizard
ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.
 
Posts: 1,790
Karma: 507333
Join Date: May 2009
Device: none
Quote:
Originally Posted by DawnFalcon View Post
....
I refer you to my earlier remark.

Quote:
Originally Posted by Jellby View Post
Oh... then there's no reason why ePUB readers can get those trivial enhancements

The fact is good typography is not trivial, as you know, and it is only inexpensive because it can largely be done with free tools, but it takes time, knowledge and expertise.

Getting typography a whole lot better that it is now (for HTML renderers) would be trivial, just use proper justification and ligatures. But that does not make it "right". You have to manually check every end of sentence to make the spacing a bit wider there (in English typography), for instance, you have to manually check every hyphenation to make sure it's right, you have to manually check every pagebreak looking for widows, orphans or too much whitespace (and rivers, and stacks...), you have to check every floating figure/table, you have to be careful with undesired linebreaks (it's better not to split "Mr. Smith" if possible, for example), etc. And many of those things have to be checked again if you change the font size, or the page size.

In short, the sort of things that "can only be done with PDF" are not easy or trivial, but the things that are easy or trivial "can be implemented in ebook renderers", and that would already be a big improvement.
I'm sorry... but most of this, Jellby, is so close to being right that it would be too painstaking for me to point out the myriad places/reasons where it is slightly but significantly off.

Long story short--certainly a lot of easy and trivial typography cannot be implemented in eBook renderers on account of being impossible to correctly handle at display time.

Quote:
Originally Posted by Xenophon View Post
And I find that both (?all?) sides in this discussion are showing an utter willful deafness to the quite legitimate preferences and desires of the other posters!
You people value different things, darn it!
I hear what your saying... but the two positions are not on equal footing.

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.

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.

The use of fixed layouts (to avoid using the dirty word "PDF") needs in no way be a barrier to reflow on less common devices or for less common font-size preferences.

The carte-blanche use of dynamic layouts however does make achieving the typographic quality of even mediocre quality fixed layout eBooks literally impossible, because the task is not software automatable, and certainly not possible to correctly handle at display-time via software-automation.

In other words: if reflow-crowd gets their way, typography goes to crap and the pro-PDF crowd will forever be stuck typesetting their own books.

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.

- Ahi
ahi is offline   Reply With Quote