[nabsltd]

Originally Posted by HarryT

I would have thought that any decent rendering engine would have the sense not to use a ligature if the two letters of the pair had different styles applied to them.

The HTML rendering engine merely enables the TrueType/OpenType "liga" feature with it's font-renderer. It has no effect if that table isn't in the font, and only does what the table says it should do, which means it displays ligatures only for pairs that map to a ligature glyph.

Here's the entire ligature substitution table from one Adobe font:

  sub T h -> T_h;
  sub f f b -> f_f_b;
  sub f f h -> f_f_h;
  sub f f i -> f_f_i;
  sub f f j -> f_f_j;
  sub f f k -> f_f_k;
  sub f f l -> f_f_l;
  sub f f t -> f_f_t;
  sub f b -> f_b;
  sub f f -> f_f;
  sub f h -> f_h;
  sub f i -> f_i;
  sub f j -> f_j;
  sub f k -> f_k;
  sub f l -> f_l;
  sub f t -> f_t;
  sub f f_t.alt -> f_f_t;
  sub Tcedilla h -> Tcommaaccent_h;
  sub Tcaron h -> Tcaron_h;
  sub longs longs i -> longs_longs_i;
  sub longs longs l -> longs_longs_l;
  sub longs b -> longs_b;
  sub longs h -> longs_h;
  sub longs i -> longs_i;
  sub longs k -> longs_k;
  sub longs l -> longs_l;
  sub longs t -> longs_t;
  sub longs longs -> longs_longs;
  sub gamma gamma -> gamma_gamma;
  sub lambda lambda -> lambda_lambda;

CSS is just starting to support OpenType features, which should allow an author to override the renderer defaults for ligatures, etc., in a compliant system. OpenType features also allow fonts to do many things that make for much simpler code. The following renders like the attached image, if your renderer supports the CSS, and you have a font that has the feature (Adobe's New Century Schoolbook does):

<style>
.myfraction {
font-variant-numeric: diagonal-fractions;
}
</style>

<p><span class="myfraction">1/2 1/4 3/4 11/32</span></p>

Originally Posted by pdurrant

I'm all for people trying designs and asking whether it can be done. It helps to show either that the ePub spec is good for a wide variety of ebook design, or that it is not.

Personally, I think it's vastly over complicated for 90% of books. And that the complications don't actually help very much with complex page layout, as HTML/CSS wasn't designed from the point of view of high quality typography/page layout.

One thing that should have been added to the spec is that anything that is considered "body text" (i.e., the text of the book needed to read and understand the story, that in a print book is all set in the same typeface and size) should have been required to be marked as such in some way (e.g., adding another item to the "class" attribute, adding an "epub:" attribute of some kind, etc.).

That way, body font changes, font resizing, and line spacing changes by the reader software would only affect those parts of the text. This would solve a lot of the problems we have with the "runaway font size" for initial caps, chapter headings, etc., since there reader software could have an option to only resize them if they are smaller than the chosen body text size.

Basically, the semantic tags currently in EPUB (like epub:section) are useless to 99% of reader software, while ones that would really help with many of the problems don't exist.