Quote:
Originally Posted by AlPe
Also, glyphIgo does not handle ligatures, if you mean whether it is able to detect them, collapse them and use the appropriate Unicode symbol. However, if a ligature is already specified as a single Unicode character, it is managed properly (as a single Unicode character).
|
Unicode characters only exist for a handful of ligatures (I mean stylistic ligatures such as "ffi", not letter-like ones like ß or æ), and they should not be used! They are only there for historical and compatibility reasons. Ligatures should be handled by the font alone.
It has already been discussed elsewhere, but it should be required for a font subsetter to properly consider ligatures, that is, at least not remove them if they are present in the original font... ideally, it should remove only unused ligatures (and "alternate" glyphs, etc., but that may be difficult to process).
Quote:
Originally Posted by JSWolf
Then glyphIgo needs to be fixed. ADE 2.0 and some versions between 1.7.2 and 2.0 do convert to ligatures and if glyphIgo says everything is good to go in the fonts and it's not, then there could be missing characters.
|
Missing ligatures would not result in missing characters. The only problem occurs if a font with ligatures is subset without taking them into account then at least two things could happen:
(a) The ligatures are completely removed. The original font may show, for instance, "ffi" or "Th" as ligatures, the subset font will simply show them as their individual characters, just like most renderers (which don't support ligatures) will do anyway.
(b) The subsetter is buggy, the ligatures are removed but their references are not. A renderer that does not support ligatures will not notice. A renderer that does, will show empty blocks or question marks where the ligatures would be.
But, assuming a given font is correct (i.e., it doesn't have references to non-existent characters), there's no way to know whether ligatures would have been used or not, and there's certainly nothing broken.