Internet Explorer 9 does not diſplay any ligatures until they are manually triggered by layout control characters (ZWNJ or ZWJ). Of courſe, this pretty much defies the very purpoſe ſmart ligatures. Ligatures may be called for by uſing a ZWJ. The following ſample will be diſplayed correctly in Internet Explorer 9:
| Sample | Code |
|---|---|
| beſchütze | beſ‍c‍hüt‍ze |
Additionally, Internet Explorer 9 will ſometimes (when?) diſplay the rlig ligatures if they are followed ſoon (how ſoon?) by a layout control character (ZWNJ or ZWJ). I have been unable to find out how this works exactly.
On Windows and Mac OS, Opera does not diſplay any ligatures until they are manually triggered by layout control characters (ZWNJ or ZWJ). Of courſe, this pretty much defies the very purpoſe ſmart ligatures. Ligatures may be called for by uſing a ZWJ. The following ſample will be diſplayed correctly in Opera:
| Sample | Code |
|---|---|
| beſchütze | beſ‍c‍hüt‍ze |
Additionally, Opera will diſplay the ligatures in any word that has a layout control character (ZWNJ or ZWJ). When letterſpacing is increaſed, all ligatures are retained. This cannot be fixed with a ZWNJ, becauſe a ZWNJ will cauſe double letterſpace.
Safari does not diſplay any ligatures unleſs two requirements are met: (a) There muſt be an additional CSS definition; (b) there muſt be no intervening non-printing characters. Since theſe two requirements may be ſet globally, they allow for a workaround. However, even if both requirements are met, ligature diſplay in text with increaſed letterſpacing is ſtill not correct.
-
Safari requires the following additional non-ſtandard CSS definition:
text-rendering: optimizeLegibility;
Since this definition is non-ſtandard, your CSS will fail to validate when you uſe it.
This is what the above browser test looks like if that additional CSS-Definition is included:
- OpenType
- beſchütze/Zeitzone – beſchütze/Zeitzone
- AAT
- beſchütze/Zeitzone – beſchütze/Zeitzone
- Graphite
- beſchütze/Zeitzone – beſchütze/Zeitzone
- Reference image
This yields better reſults in Safari. However, when letterſpacing is increaſed, the required ligatures are not diſtinguiſhed from the other ligatures; inſtead, either kind of ligatures is retained. This error can be ſeen in the following ſcreenſhot from Safari:
-
Safari will fail to diſplay the ligatures if there are any non-printing characters ſuch as a ſoft hyphen or – ironcally! – a ZWJ., ſee the following two ſamples where Safari fails to diſplay the required ‹tz› ligature (in ſpite of
text-rendering: optimizeLegibility):Sample Code Soft hyphen beſchütze beſchüt­zeZWJ beſchütze beſchüt‍ze
Google Chrome will not diſplay any ligatures until three requirements are met: (a) There muſt be – like in Safari – an additional CSS definition; (b) there muſt be – like in Safari – no intervening non-printable characters; and (c) the font muſt be locally inſtalled. Of courſe, this pretty much defies the very purpoſe of font embedding. On Windows and Linux, there is at leaſt one additional requirement, but I have not been able to pin it down.
In TextEdit, LibreOffice and Gimp, ligatures are diſplayed, but when letterſpacing is increaſed, the required ligatures are not diſtinguiſhed from the other ligatures; inſtead, either kind of ligatures is retained. Additionally, the ZWNJ cauſes double letterſpace when letterſpacing is increaſed. Both errors can be ſeen in the following incorrect ſcreenſhot (from TextEdit.app):
Compare that to a ſcreenſhot of the correct diſplay in Firefox:
For letterſpacing in XeLaTeX to work correctly, I uſe the packages fontspec and xspace to renew the command \emph ſo it produces text with increaſed letterſpacing:
\usepackage{fontspec,xspace}
\renewcommand\emshape{\xspace\addfontfeature{LetterSpace=20.0,WordSpace=1.5,Ligatures={NoCommon}}}