Ligature not triggered before dash about eb-garamond HOT 12 CLOSED

This is tricky. Dash is too ambiguous a character to make such definitive statement. On the one hand it’s used to join separte words, on the other it’s the character that’s inserted automatically at hyphenation points in the middle of words. In the latter case I wouldn’t want an end-of-word ligature.
The current mechanism looks one place after the s. If there is a lowercase letter or a hyphen, the substitution gets suppressed.
Would it make sense to have it look one place after the hyphen? So if after the s there is a hyphen followed by a letter (LC or UC), it is save to assume that the s is at the end of a word and can get replaced?

from eb-garamond.

@georgd I think this is an acceptable solution.

from eb-garamond.

I thought the hyphen that is inserted by automatic hyphenation is a different glyph from the one you type on the keyboard (“soft hyphen”, U+00AD, vs. “hard hyphen”, U+002D). If this is the case, then you would want to adjust the mechanism so that ligature substitution is suppressed before a soft hyphen, but not a hard one.

Siva

Siva Kalyan (♂)
Sent with Sparrow (http://bit.ly/sigsprw)

On Tuesday, 1 January 2013 at 03:32, Gregory Beauregard wrote:

@georgd (https://github.com/georgd) I think this is an acceptable solution.

—
Reply to this email directly or view it on GitHub (#25 (comment)).

from eb-garamond.

The soft hyphen is a control character for manually indicating possible hyphenation point and should have no visible rendering at all, the automatically inserted hyphen is either hyphen minus (U+002D) or hyphen (U+2010). But I also don’t think there will be any OpenType layout interaction with automatically inserted hyphen, but this needs to be tested.

from eb-garamond.

@Gnintendo: The implementation of this solution is currently blocked by a bug in Fontforge.

@khaledhosny: there is OT layout interaction with automatically inserted hyphen (at least in XeLaTeX) and I’m glad there is, else application of kerning etc. would be quite difficult with this character.

from eb-garamond.

The implementation of this solution is currently blocked by a bug in Fontforge.

If you mean this, it is has been fixed in Sortsmill FontForge (I’m not subscribed to FF mailing lists, so it is better to report such issues in our tracker to be notified when they are fixed).

there is OT layout interaction with automatically inserted hyphen (at least in XeLaTeX)

Nice. Hyphenation in XeTeX is something I need to look into.

from eb-garamond.

Khaled, I’ve seen your patch and I’m currently trying to backport it to FF – that means I looked for the corresponding line in featurefile.c and replaced it, hoping that this does the trick. Now building.

from eb-garamond.

This is fixed now, however, XeLaTeX seems to have problems understanding the rules.

from eb-garamond.

The current XeTeX release uses ICU LayoutEngine which is known to have issues with contextual rules. The development version have been ported to HarfBuzz, so if the rules work with other HarfBuzz based applications (e.g. Firefox), it should be OK, but I don’t mind testing it if you have some test files.

from eb-garamond.

I’m really looking forward to your new XeTeX! I always test with Firefox (currently v17.0.1) to check for HarfBuzz, it’s fine there. This is a minimal example to test this feature with Xe/LuaLaTeX:

\documentclass{article}
\usepackage{fontspec}
\setmainfont[Ligatures=Contextual]{EB Garamond}
\begin{document}
\textit{vis-à-vis Kreis- und Ellipsenberechnungen}
\footnotesize \textit{vis-à-vis Kreis- und Ellipsenberechnungen}
\end{document}

from eb-garamond.

Seems to work fine with next XeTeX.

from eb-garamond.

Great, thanks! I close this now.

from eb-garamond.