Quote:
Originally Posted by jbjb
What about the per-book effort to produce these fixed layouts? I'd rather that was spent on better proof reading of content. That makes much more of a difference to me than perfect hyphenation etc.
|
What makes you think that it's an either-or proposition? It seems a counter-intuitive assumption to me. And, to be frank, any time the publisher decides to save on getting typography or even just the hyphenation part right will not be time re-allotted to additional proofreading.
There is, I'm rather sure, no chance of improving the content accuracy of eBooks by arguing for relaxing the typographic standards thereof.
And as I've noted a good few times though, good quality typography is not difficult or time-consuming to do with the right tools and technologies, and even great typography is not prohibitively so, even for a small publisher.
Quote:
Originally Posted by Ankh
But why use hyphenation on the reader, when it can be pre-hyphenated in advance?
Build a hyphenation database, and let automated engine insert soft hyphens EVERYWHERE. When there is ambiguity or a word that is not in the dictionary/database, ask user for intervention.
If the reader has a correct handling of soft-hyphens (ADE, even 1.71, doesn't), isn't this a solution for hyphenation of the reflowable formats?
|
Do you really consider feasible a hyphenation database that contains all actual words it addresses, along with all their compounded, conjugated/declined (and apostrophe-laden?) forms? Even for languages unlike English, where prefixes, suffices, conjugations, and declensions can create over a 100 valid and sensible words from a 3 letter root word?
Given how utterly technically simple this is, you'd think all word processors would be using it by now. (Though "present" in English, and many words in other languages would continue to be incorrectly auto-hyphenated.)
- Ahi