Preferred Font Size in eBooks

[ahi]

Originally Posted by HarryT

I take the opposite viewpoint: why cling to the outmoded idea of a fixed-layout page simply because that is what paper books have? Electronic devices offer the potential for reflowable content, user selection of text size, margins, etc, which paper books cannot, all of which goes to enhance the reading experience.

At the expense of degrading the reading experience on a far more fundamental level.

The myriad enthusiastic suggestions on this board that considerations about proper typography should be thrown to the wind are proposing something that really is just fundamentally unthinkable. Not for a marginalized niche market perhaps, but certainly unthinkable for a market that is meant to be a serious alternative to print books.

Relegating typography to a secondary concern in making books is akin to relegating proper design principles to a secondary concern in making clothes. Conceivable, but not anything that could or should ever become the rule instead of the exception.

And also what Hajo said.

[JSWolf]

I disagree with Hajo. Take a look at the ePub from the following link and you'll see this is just not always so that you need to know the screen size ahead of time. However, it does help if you have a guess of the possible minimum size of the screen. So if we use a 6" eink screen as that marker, then good reflowing content with a complex layout can be made to look good.

https://www.mobileread.com/forums/att...6&d=1241731327

[ahi]

Originally Posted by JSWolf

I disagree with Hajo. Take a look at the ePub from the following link and you'll see this is just not always so that you need to know the screen size ahead of time. However, it does help if you have a guess of the possible minimum size of the screen. So if we use a 6" eink screen as that marker, then good reflowing content with a complex layout can be made to look good.

https://www.mobileread.com/forums/att...6&d=1241731327

Yes, it can be made to look good, even very good given the right content and right restraints. But it cannot be made to match the quality of a paper book--the same way that websites also cannot.

Do we agree on this much?

- Ahi

[HarryT]

Perhaps an illustration will show what I mean, Ahi. Attached is a photograph of my CyBook Gen3 (very slightly blurred, I'm afraid - the light is rather poor in my room, but it's good enough, I think). I'm sure that to a typographer, there are all sorts of things wrong with it, but all I need for a novel (which is what I use my Gen3 for reading) there are only a few basic features I need: centred titles, indented paragraphs, and reasonable justification, and the Mobi file format gives me all that. A 6" screen is just too small for "complex" formats, and Mobi is "good enough" for my needs.

[=X=]

Originally Posted by ahi

The horse is starting to decay,

Here let me help you out this is what your looking for ===>

Originally Posted by ahi

Sensibly enough, if they have a genuine need for font resizing--but less great a trade-off, if they simply cling to font resizing out habit because early eBook offerings were/are so poor that they can only be made readable by the use thereof.

Actually this is due to the poor contrast quality eInk devices have. A gray/green background and black text is no where near as sharp as a white backgrond and black text that is found on paper books.

So under low ambient lighting it is easier on the eyes to increase the font size. When I read on my PRS-505 I find I do this often, but when I'm reading on my phone I never increase my font size.

=X=

[ahi]

Originally Posted by HarryT

Perhaps an illustration will show what I mean, Ahi. Attached is a photograph of my CyBook Gen3 (very slightly blurred, I'm afraid - the light is rather poor in my room, but it's good enough, I think). I'm sure that to a typographer, there are all sorts of things wrong with it, but all I need for a novel (which is what I use my Gen3 for reading) there are only a few basic features I need: centred titles, indented paragraphs, and reasonable justification, and the Mobi file format gives me all that. A 6" screen is just too small for "complex" formats, and Mobi is "good enough" for my needs.

I see what you mean, and I was assuming something around these lines even unseen.

It's not terrible, but it does look distinctly and immediately like something typeset by a computer in real-time. In other words: worse than a paper book that could be purchased for far less than what an eBook device costs. I don't think that will fly with the average person.

And yes, 6" is probably too small for more complex typography; but 8" is probably not, and 10" is pretty much fine for any general book, textbook, or magazine, so long as it is thoughtfully prepared for that size.

Not to mention that if a format--whether it's ePub's descendant, or ADE--can encapsulate multiple PDF files, you could have both font resizing and pristine typography. This suggestion of mine doesn't seem to be taken seriously, but it's true. It is trivial to create additional PDF versions for slightly different display and different font sizes--the only problem is with the user interface that does not presently give a way to make use of this in a way that isn't a drag to the user.

My 8 PDFs of "The Art of War" cover a pretty decent range at about 3 MB in size (with 8 copies of the cover, 7 of which would not be there to take up space in a consolidated format)... it's entirely feasible, and it is a far more meritorious way to offer a choice of font sizes than by taking the the easy and low quality way out and stick to device-managed reflow of text.

What is wrong with that idea? Particularly since future eBook devices are bound to standardize their display sizes at something between 8" and 10", down the road reducing the number of different display sizes that need to be supported. (With the caveat that random-sized cell phone displays are not eBook devices, even if eBook software is usable with them.)

- Ahi

[ahi]

Originally Posted by =X=

Here let me help you out this is what your looking for ===>


Actually this is due to the poor contrast quality eInk devices have. A gray/green background and black text is no where near as sharp as a white backgrond and black text that is found on paper books.

So under low ambient lighting it is easier on the eyes to increase the font size. When I read on my PRS-505 I find I do this often, but when I'm reading on my phone I never increase my font size.

=X=

Ok, that is certainly food for thought. However I should point out that material intended for leisurely reading should generally not use white paper, but rather a more creme colour.

Actual white paper with black text is too harsh on the eyes for prolonged reading, and is more often seen in textbooks and other similar types of books/genres. So we don't need to totally reach white, before the contrast becomes as good as it is with your average paperback novel.

- Ahi

Ps.: Notice where even on this page white is used and where "creme" colour is used?

[Jellby]

Originally Posted by ahi

It's not terrible, but it does look distinctly and immediately like something typeset by a computer in real-time. In other words: worse than a paper book that could be purchased for far less than what an eBook device costs. I don't think that will fly with the average person.

Note that there is still room for improvement with purely automatic typesetting. The ebook readers could use a paragraph-breaking algorithm similar to the one in TeX instead of simplistic Word-like they're using now, and hyphenation could be greatly improved, and some automatic ligatures used... There are some things that are not possible and would need human intervention, but still without that a much more pleasant typesetting can be achived without sacrificing flexibility.

[ahi]

Originally Posted by Jellby

Note that there is still room for improvement with purely automatic typesetting. The ebook readers could use a paragraph-breaking algorithm similar to the one in TeX instead of simplistic Word-like they're using now, and hyphenation could be greatly improved, and some automatic ligatures used... There are some things that are not possible and would need human intervention, but still without that a much more pleasant typesetting can be achived without sacrificing flexibility.

LaTeX makes (not quantitatively but qualitatively) considerable use of hyphenation for paragraph breaking and related tasks, but it still trips up on words I would expect to long have made it into the hyphenation dictionaries, not to mention proper names... and let me not even imagine the horrors that my Hungarian books would be subjected to via any sort of real-time LaTeX style hyphenation on a device with only a (relatively neglected or non-existent) Hungarian hyphenation dictionary.

Even in the best of times, this is one of the big things in LaTeX based typesetting that doesn't work well without human intervention.

But I grant you, progress is certainly possible. I'm just not convinced the best that can be achieved via this methodology is going to make me any less regretful that I am not reading a PDF customized for my device and font-size preference.

- Ahi

[Jellby]

Originally Posted by ahi

LaTeX makes (not quantitatively but qualitatively) considerable use of hyphenation for paragraph breaking and related tasks, but it still trips up on words I would expect to long have made it into the hyphenation dictionaries, not to mention proper names...

As far as I know, LaTeX does not use hyphenation dictionaries, but patterns, that is, algorithms that try to predict where each word can be hyphenated without having to store hyphenation points for every word. In my experience, it often works pretty well, at least in Spanish (which is relatively easy, anyway). But there's no reason why reading devices or software could not include more sophisticated hyphenation schemes, patterns, dictionaries or whatever, which should depend on the language of the book and be disable-able.

[ahi]

Originally Posted by Jellby

But there's no reason why reading devices or software could not include more sophisticated hyphenation schemes, patterns, dictionaries or whatever, which should depend on the language of the book and be disable-able.

Overly optimistic faith in progress on problems that are very simple to identify and define but difficult (arguably impossible) to get right 100% of the time is always suspicious to me.

You might be right... but, on the other hand, I think whatever progress in any given language there is to be made in non-dictionary based hyphenation is already likely to have been made.

But I could always be wrong. And either way, I do agree with your point on a general level, regardless of specifics.

- Ahi

[HarryT]

Originally Posted by ahi

It's not terrible, but it does look distinctly and immediately like something typeset by a computer in real-time. In other words: worse than a paper book that could be purchased for far less than what an eBook device costs. I don't think that will fly with the average person.

I'm afraid we're just going to have to agree to differ on that point . I honestly think that it's perfectly adequate for novels.

And yes, 6" is probably too small for more complex typography; but 8" is probably not, and 10" is pretty much fine for any general book, textbook, or magazine, so long as it is thoughtfully prepared for that size.

I totally agree with you about that. For large screen devices, there is absolutely a need for "real" typography. ePub seems to be a pretty good job in those circumstances.

[Jellby]

Originally Posted by ahi

Overly optimistic faith in progress on problems that are very simple to identify and define but difficult (arguably impossible) to get right 100% of the time is always suspicious to me.

Yes, I'm an idealist I would like to think some future device might allow the user to tag a word as wrongly-hyphenated and add it to some hyphenation exceptions dictionary (which could then be exported and shared).

Anyway, the hyphenation system does not need to be perfect to be useful. Not every valid hyphenation point has to be identified, but if enough valid points (and few invalid ones) are, the typographic quality of the text can significantly improve from the non-hyphenated text. This would be the first goal.

Another possibility would be to have each book carry its own list of hard words to hyphenate. The reader would then know how to deal with them. Wrong hyphenations would be the fault of the book creator, not of the format or the reading software... exactly the case of PDFs.

[JSWolf]

Originally Posted by ahi

LaTeX makes (not quantitatively but qualitatively) considerable use of hyphenation for paragraph breaking and related tasks, but it still trips up on words I would expect to long have made it into the hyphenation dictionaries, not to mention proper names... and let me not even imagine the horrors that my Hungarian books would be subjected to via any sort of real-time LaTeX style hyphenation on a device with only a (relatively neglected or non-existent) Hungarian hyphenation dictionary.

Even in the best of times, this is one of the big things in LaTeX based typesetting that doesn't work well without human intervention.

But I grant you, progress is certainly possible. I'm just not convinced the best that can be achieved via this methodology is going to make me any less regretful that I am not reading a PDF customized for my device and font-size preference.

- Ahi

But if we has LaTex hyphenation support and kerning, that sample that Harry posted would look better. It would look less computerish. I know the only way to get proper hyphens is with a dictionary, but I think the LaTex way will be good enough.

[HarryT]

Originally Posted by Jellby

Yes, I'm an idealist I would like to think some future device might allow the user to tag a word as wrongly-hyphenated and add it to some hyphenation exceptions dictionary (which could then be exported and shared).

The hyphenation on the Gen3 seems to be reasonably good - it gets it "right" more often than it gets it wrong - but it's far from perfect. One particularly irritating feature of it is that it doesn't consider a dash to be a point at which it is "allowed" to break a line, but will instead add a hyphen to the dash.