[Tex2002ans]

Originally Posted by AliceWonder

I'm curious as to how many devices have built-in glyphs for those commonly used fractions?

Again, it's a very bad idea to use Vulgar Fractions.

I just wrote about all the pros/cons a few weeks ago:

https://www.mobileread.com/forums/sh...08#post3882608

Those characters were only included in Unicode for backwards compatibility with some legacy encodings.

Use normal numbers: "25/26 or 2/3" and then rely on CSS for OpenType Fractions.

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.

[...]

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.

Yes, but ereaders are extremely long-term devices. There are still millions of 8+ year old devices out there that are still chugging along and being used to read.

Originally Posted by JSWolf

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

Exactly. The shelflife of e-ink readers is immense. Like my Nook (1st generation) is still kicking around. Battery life is still pretty great.

And there are millions of others just like it, and they won't ever be patched.

EPUB

And like JSWolf said, older versions of ADE (like v2.0.1) is an okay approximation for many of these older devices. That version of RMSDK was used in many of the EPUB readers.

Newer versions of ADE renders with newer RMSDK (and Readium for EPUB3)... so ADE 4+ will show support for things that many older ereaders just won't ever support (like more advanced CSS3, WOFF, etc.).

Kindles / MOBI

It's kind of like using Kindle Previewer 2 to emulate what an older Kindle would look like... instead of relying on Kindle Previewer 3 (which ONLY shows newer KF8 format). But there are still MILLIONS of older Kindles out there that only support KF7 ("old MOBI").

Originally Posted by AliceWonder

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.

But the reality is soft hyphens do interfere with Search. They also interfere with Dictionary lookup, and things such as Auto-Translation too (think Google Translate).

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.

If you read a lot of that soft hyphen posts I linked to... "Hyphenate This!" is a Calibre plugin that already does this.

It might be okay for personal copies... but I would never use it for an ebook for sale.

Originally Posted by AliceWonder

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

Don't include Soft Hyphens ever. Again, the disadvantages are immense.

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.

There's no such thing in CSS.

In LaTeX, you can then manually create lists of words to adjust hyphenation manually if needed:

\hyphenation{man-u-al}

In Word Processors, you usually have a way to add manual user-dictionaries with hard-coded hyphenations in there.

In the web/ebooks/CSS... no.

* * *

Side Note: See a lot of my previous Hyphenation discussion from 2014, especially Post #20:

Using regex for more elegant hyphenation and word wrap

Side Note #2: For bleeding edge hyphenation info, see:

http://www.hyphenation.org/tex

Also see "Hyphenation in TeX and elsewhere, past and future" by Mojca Miklavec and Arthur Reutenauer in TUGboat Volume 37 (2016) No. 2 (PDF) for some of the discussion on licensing issues + growing pains (updating the patterns for UTF-8, getting patterns into browsers+other programs/devices).

* * *

LaTeX

Hyphenation is based completely on hyphenation patterns (I'll call this "Algorithm-based").

A giant list of pre-hyphenated words is fed, and this creates the pattern for each language.

From what I can gather, this is where much of the hyphenation patterns/research comes from, and then the web browsers sort of adopt solutions from here.

Patterns get updated every so often, and there are people who keep track of hyphenation exceptions that the patterns get wrong, such as the ushyphex (US Hyphenation Exceptions) package:

https://ctan.org/tex-archive/info/di...phenex?lang=en

In LaTeX, you also have full control over things like:

• Characters to the left/right of hyphen

and because you have full access to the renderer, you can also do more complicated language-specific typography.

(There's very complicated hyphenation in some languages: Letters/spelling changes, double hyphens, duplicated letters, dealing with single letter words, etc... it's why it's usually best to just use babel/polyglossia, assign your document the correct language, and leave it up to the experts.)

* * *

Web Standards

Miles behind LaTeX, but they're slowly playing catchup.

CSS3

You pretty much just have hyphens:

https://developer.mozilla.org/en-US/...eb/CSS/hyphens

You specify document language, and hope the support is there (and that it's good). Sadly, Polish isn't one of the better ones... yet.

CSS4

They're adding a few more advanced things to deal with hyphenation:

https://www.w3.org/TR/css-text-4/#hyphenation

You'll get access to a few more LaTeX-type things such as:

• (hyphenate-limit-chars) # Chars allowed to the left/right of hyphens
• (hyphenate-limit-lines) # Multiple hyphen line-endings in a row.
• (hyphenate-limit-last) Hyphen at the very end of page/column, etc.

Ebooks

Like JSWolf said, some of the better devices (like Kobo) actually let you replace with your own Hyphenation Dictionaries.

On Kobo, you can also adjust # of chars to the left/right of hyphens.

Devices that support hyphens usually embedded their own patterns (and most likely applying English hyphenation rules to languages like Polish... which is why it's usually abysmal).

But many of the older devices out there don't support hyphenation at all. Again, it's best to just leave it that way. Don't muddle your ebooks with Soft Hyphens, because they introduce much worse problems than poorer justification.

Side Note: Many programs also apply very bad/wrong left/right hyphens... like Microsoft Word has right-hyphen-chars as 2... so you get atrocious hyphenation at the 2-letter "-ly". Proper English typography has 3 (which is what LaTeX sets it to).