Re: Bug with ligatures (EBGaramond) and \mainlanguage[es]

[Hans Hagen <pragma@wxs.nl>]

On 3/26/2015 7:10 AM, Pablo Rodriguez wrote:
> On 03/26/2015 06:23 AM, Andrés Conrado wrote:
>> Hello, list. When I try to use the EBGaramond font
>> (http://www.georgduffner.at/ebgaramond/) in spanish (using
>> \mainlanguage[es]), ligatures disappear. But they only disappear when
>> they belong to a word (when alone, they look fine). See MWE, if you
>> remove the comment in the \mainlanguage command, ligatures get screwed up:
>
> Hi Andrés,
>
> I’m afraid this is a proper bug.
>
> It isn’t related to Spanish as language. The bug is triggered when a the
> ligature has a hyphenation point at the end.
>
> Here is another mininmal example with German as main language:
>
>      \mainlanguage[de]
>
>      \loadtypescriptfile[ebgaramond]
>
>      \setupbodyfont[ebgaramond,24pt]
>
>      \starttext
>      \hsize\zeropoint
>      figura afigura
>
>      \es figura afigura
>
>      \en figura afigura
>      \stoptext
>
> German only inserts a hyphenation point after three characters (and
> before other three characters). This is why the first word has the
> ligature and the second word doesn’t have it.
>
> English doesn’t show the bug, because it doesn’t find any hyphenation
> point in the words.
>
> Until this is fixed, you may use the new hyphenator. You need a fairly
> new beta. Add the following lines at the top of your preamble:
>
>      \setuphyphenation[method=traditional]
>      \sethyphenationfeatures[strict]
>
> I hope it helps,

It's not a bug actually but a side effect. The way fonts implement 
ligatures is rather diverse (and even not always recognizable as 
ligature). This can interact with hyphenation especially because we not 
only have to take replacements into account but also relative 
positioning, because 1-1 replacement, many-1 replacements and 
positioning are all used in combination.

Because it makes no sense to expand a node list into all possible 
permutations of (combinations) of hyphenation points, the current 
mechanism has some assumptions. One problem with that is that in 
traditional tex a discretionary comes in several disguises and at some 
point it doesn't even have specific hyphenation characters it its 
sublists which in turn interacts with whatever-hyphen replacements and 
kerning.

So, the context reality is that there are a few strategies uses and the 
results depends on the combination of these strategies. Currently the 
defaults result in a limited analysis. Then we can have this:

\setuphyphenation[method=expanded]

which indeed in this example gives the results as expected. Because that 
method is also used in the alternative hyphenator that one also works.

In a future version I will change some defaults or maybe even switch to 
the alternative hyphenator as it offers some advantages. Pablo has been 
testing it for a while and it seems to work ok. The only drawback is 
that I need to keep the old methods as benchmark.

When multiple side-by-side hyphenation points are used the font builder 
can discard some but this is normally no big issue for tex.

Hans

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
                                              | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________