Font Best Practices

[Tex2002ans]

Originally Posted by AliceWonder

Not if the reader does fonts the right way.

When the CSS specified font does not have the glyph, then the readers should attempt to get the glyph from the font type specified.

[...]

If the Euro is used, since the font does not have that code-point, it would be fetched from the default sans-serif font if it has the code point.

But that's not the reality... again, it's what the standards say SHOULD happen, but not what DOES happen.

Reality is, don't use soft hyphens. They'll come to bite you in the ass.

[Hitch]

Originally Posted by AliceWonder

Not if the reader does fonts the right way.

Yeah, but as you may have noticed from all our discussions here, that's not what happens in the real world.


Hitch

[JSWolf]

Originally Posted by AliceWonder

They break searching because of bugs in the reader.

And a lot of readers support automated hyphenation *IN WESTERN LATIN* but seriously get it wrong or do not support it at all in other languages. As such, readers *should* support soft hyphens so ePub in those languages will work right.

But even if they don't, the glyph then would be a zero-width glyph if their default fonts had U+00AD but it seems there isn't something like WGL4 was to Windows --- not even for western Latin glyphs --- that ePub authors can know the readers all support, so embedding their own fonts is the only way to know the glyphs they need are there.

With a Kobo Reader, you can get hyphenation for the language you want if you have a hyphenation dictionary for that language.

As for should, the reality is they don't all support soft hyphens. So you just have to go with what is instead of what should be. Even if the current version of ADE (RMSDK) works properly with soft hyphens.

I prefer to have the reading software do the hyphenation as adding soft hyphens change the page number for ADE type page numbers.

[AliceWonder]

Originally Posted by Hitch

Yeah, but as you may have noticed from all our discussions here, that's not what happens in the real world.


Hitch

Then bug reports need to be filed - even if for the time being we have to work around the bugs - because they are bugs, and bugs should be fixed.

Satisfaction with mediocrity is a weakness.

[AliceWonder]

Just to be clear I'm not a fan of manually using soft hyphens - they make the code hard to read and should only be used when automated hyphenation gets it wrong.

But they should not interfere with search and when an author needs to use them, the glyph should be there even on systems that don't use it. Which means the author has to embed a font because many devices seem to have a bug where that codepoint isn't available. Guess it would have made their system fonts a few bytes bigger...

Really fonts on devices probably should at least support all codepoints used in Windows-1252 if not WGL4. But they clear don't. So there is a need to embed.

[JSWolf]

Originally Posted by AliceWonder

Then bug reports need to be filed - even if for the time being we have to work around the bugs - because they are bugs, and bugs should be fixed.

Satisfaction with mediocrity is a weakness.

The problem is that yes, proper soft hyphen support can be added. But there are going to be devices and people using older software versions. So it's never going to be fixed in a way that soft hyphens will work for everyone.

For example, anyone still using a Sony Reader will not have working soft hyphens and there's no way at all to fix this.

[theducks]

Originally Posted by AliceWonder

Then bug reports need to be filed - even if for the time being we have to work around the bugs - because they are bugs, and bugs should be fixed.

Satisfaction with mediocrity is a weakness.

You missed: 'They don't CARE' to fix the current product. (it would snafu the upgrade path)

You want a fix...Just maybe...it will be in next years model (but don't hold you breath).

[AliceWonder]

Originally Posted by JSWolf

The problem is that yes, proper soft hyphen support can be added. But there are going to be devices and people using older software versions. So it's never going to be fixed in a way that soft hyphens will work for everyone.

For example, anyone still using a Sony Reader will not have working soft hyphens and there's no way at all to fix this.

Right - but there are readers now that do not have automated hyphenation but do properly support soft hyphenation.

The calibre reader I use on Linux - maybe there is a plugin that does it, but when I right click on an ePub and choose "Open with E-Book Viewer" there is no automated hyphenation, but if I add soft-hyphens they are used.

So should I refrain from fixing the display of ePub documents on readers that *do* support soft hyphens just because some readers do not have U+00AD or should I go ahead and include the soft hyphens for the benefit of those using compatible readers and also include a font that has U+00AD so that users of devices w/o that glyph will at least get the proper zero width glyph instead of a ? glyph?

And yes, I know soft hyphens break search on some devices. Users of those devices should complain to the manufacturer, they paid money for an ePub reader and they got one with a very nasty bug. If I cater to that bug, then I can not deliver as good of a product to those using devices / software without a bug.

And while searching for info on ePub hyphenation, it seems the automated hyphenation for Polish is often extremely bad - Polish books should either disable hyphenation all together or only use soft hyphenation until the automated hyphenation is fixed.

When we develop to bugs instead of the standard, the consumer loses.

Bugs are reality and have to be worked around, but not at the expense of producing an inferior product for those without blatantly defective readers.

In my opinion.

[JSWolf]

Originally Posted by AliceWonder

Right - but there are readers now that do not have automated hyphenation but do properly support soft hyphenation.

The calibre reader I use on Linux - maybe there is a plugin that does it, but when I right click on an ePub and choose "Open with E-Book Viewer" there is no automated hyphenation, but if I add soft-hyphens they are used.

So should I refrain from fixing the display of ePub documents on readers that *do* support soft hyphens just because some readers do not have U+00AD or should I go ahead and include the soft hyphens for the benefit of those using compatible readers and also include a font that has U+00AD so that users of devices w/o that glyph will at least get the proper zero width glyph instead of a ? glyph?

And yes, I know soft hyphens break search on some devices. Users of those devices should complain to the manufacturer, they paid money for an ePub reader and they got one with a very nasty bug. If I cater to that bug, then I can not deliver as good of a product to those using devices / software without a bug.

And while searching for info on ePub hyphenation, it seems the automated hyphenation for Polish is often extremely bad - Polish books should either disable hyphenation all together or only use soft hyphenation until the automated hyphenation is fixed.

When we develop to bugs instead of the standard, the consumer loses.

Bugs are reality and have to be worked around, but not at the expense of producing an inferior product for those without blatantly defective readers.

In my opinion.

But if you did use soft hyphens, you'd piss off a lot of people. It's not worth the hassle. Don't do it. It doesn't work well enough and never will.

[AliceWonder]

A CSS solution would be better - as in a CSS solution that lets you define hyphenation for words that automated hyphenation get wrong.

I get the don't do it, only brought it up because it is a clear cut example of why embedding fonts are a good thing.

Unless our book is completely 7-bit ASCII we really have no way to know whether every glyph we use is supported by the device fonts. There is no "ePub glyph list" like Windows had with WGL4. Embedding the font is the only way to know that a font with the glyphs we use is there.

[BetterRed]

Originally Posted by AliceWonder

The calibre reader I use on Linux - maybe there is a plugin that does it, but when I right click on an ePub and choose "Open with E-Book Viewer" there is no automated hyphenation, but if I add soft-hyphens they are used.

I wouldn't use the calibre viewer as a yardstick for standards compliance, it's author has never claimed it was an EPUB, DOCX, MOBI... or anything else, standards compliant viewer. Almost the opposite in fact. It's a pragmatic solution to viewing books in just about any format.

BR

[AliceWonder]

It's handling of soft-hyphens is standard, standard HTML that predates ePub.

I'm not using soft hyphens. I do use them sometimes in websites, there I use a bullet in the source so I can read the page and see where they are and the use a php wrapper to preg_replace them with the actual glyph when served, so that view source is readable. Can't really do that in ePub and several entities in words is just horrible to work with in a text editor.

-=-

http://unicodefractions.com/

I'm curious as to how many devices have built-in glyphs for those commonly used fractions?
I'm guessing some have them but I'm also guessing many don't. There's really know way to know, hence why I want to embed fonts.

I suppose for authors who never use fractions maybe that doesn't matter, but the artist drawn glyphs really do look better than using n/m.

[ps67]

Originally Posted by AliceWonder

The calibre reader I use on Linux - maybe there is a plugin that does it, but when I right click on an ePub and choose "Open with E-Book Viewer" there is no automated hyphenation, but if I add soft-hyphens they are used.

calibre reader, if You set it in preferences (of the reader itself) will show hyphenation.

[JSWolf]

Originally Posted by AliceWonder

A CSS solution would be better - as in a CSS solution that lets you define hyphenation for words that automated hyphenation get wrong.

I get the don't do it, only brought it up because it is a clear cut example of why embedding fonts are a good thing.

Unless our book is completely 7-bit ASCII we really have no way to know whether every glyph we use is supported by the device fonts. There is no "ePub glyph list" like Windows had with WGL4. Embedding the font is the only way to know that a font with the glyphs we use is there.

The way to know if you need to embed is to test your ePub in ADE 2.0.1. I know the default font used there doesn't have all the glyphs.

You can download ADE 2.0.1 for Windows or OS X (as long as you are not using the version OS X that's 64-bit only) at https://www.adobe.com/support/digita...downloads.html

[AliceWonder]

So every user uses the same fonts as ADE 2.0.1 ?
I find that hard to believe.