Re: Possible bug in \definefontfallback with check=yes

Hans,

No problem at all!

There’s no hurry, as I’m also in the middle of something else. I just 
wanted to let you know. It can certainly wait a few days.

JP


Le 13/08/2026 à 09:51, Hans Hagen via ntg-context a écrit :
> On 8/13/2026 9:15 AM, Jean-Pierre Delange via ntg-context wrote:
>> Hi Hans,
>>
>> While testing Semitic languages for multilingual bibliography support
>> (in this case Aramaic/Syriac), I came across a reproducible problem with
>> `check=yes` in `\definefontfallback`.
>
> hopefully Wolfgang can have a look at it as I'm in the middle of 
> something else so switching to font mode ... otherwise it has to wait 
> a couple of days.
>> The tests were made with:
>>
>>      ConTeXt 2026.07.29 11:46 LMTX
>>      LuaMetaTeX 2.11.09
>>      functionality level 20260727
>>
>> The issue first appeared in a bibliography test using Libertinus 
>> Serif as
>> the main text font and Estrangelo Edessa as a Syriac fallback. I then
>> reduced it to the font fallback mechanism itself, without BTX/SBL or 
>> bidi.
>>
>> I also repeated the test with SBL BibLit as the main font in order to 
>> rule
>> out a Libertinus-specific interaction. The same result occurs with both
>> main fonts:
>>
>>                     check=yes,force=yes        force=yes
>>                           ------------------- ---------
>> Libertinus Serif             FAIL                   WORKS
>> SBL BibLit                      FAIL                    WORKS
>>
>> In all cases the Edessa fallback font is found and loaded. With
>> `check=yes`, however, the Syriac characters are not taken from the
>> fallback font. Removing only `check=yes` makes the fallback work.
>>
>> I found an earlier related report by Alan Bowen on the list in 2021
>> ("rtl fontfallback family issue?"), also involving Syriac, Estrangelo
>> Edessa, and font fallback under LMTX. That example used
>> `\definefallbackfamily` and seems to concern a different issue, but I
>> mention it because of the closely related Syriac/fallback context.
>>
>> Here is a MWE using SBL BibLit:
>>
>> ------------------------------------------------------------
>>
>> \definefontfallback
>>    [testfallback]
>> [file:/usr/share/fonts/opentype/xfree86-nonfree-syriac/SyrCOMEdessa.otf]
>>    [0x0700-0x074F]
>>    [check=yes,force=yes]
>>
>> \definefontsynonym
>>    [TestSerif]
>>    [file:SBL_BLit.ttf]
>>    [fallbacks=testfallback]
>>
>> \definefont
>>    [TestFont]
>>    [TestSerif at 12pt]
>>
>> \starttext
>>
>> \TestFont
>>
>> Latin: Test
>>
>> Greek: λόγος
>>
>> Hebrew: שלום
>>
>> Syriac: ܟܬܒܐ
>>
>> \stoptext
>>
>> ------------------------------------------------------------
>>
>> With
>>
>>      [check=yes,force=yes]
>>
>> SBL BibLit and SyrCOMEdessa are both loaded, but the Syriac characters
>> are reported as missing from SBL BibLit and are not rendered.
>>
>> If I change only
>>
>>      [check=yes,force=yes]
>>
>> to
>>
>>      [force=yes]
>>
>> the Syriac fallback is used and the characters are rendered.
>>
>> The same A/B behaviour is reproducible with Libertinus Serif as the main
>> font.
>>
>> This led me to look at `font-col.lmt`, in
>> `collections.clonevector()`.
>>
>> In the `check` branch, when `target` is not set, I find:
>>
>>      elseif check then
>>          ...
>>          else
>>              for unicode = start, stop do
>>                  local unic = unicode + offset - start
>>                  if isprivate(unic) or isprivate(unicode) then
>>                      -- ignore
>>                  elseif not newchars[target] then
>>                      -- not in font
>>                  elseif force or (not vector[unic] and not 
>> oldchars[unic]) then
>>                      vector[unic] = cloneid
>>                      ...
>>                  end
>>              end
>>
>> This is the `else` branch of
>>
>>      if target then
>>          ...
>>      else
>>          ...
>>      end
>>
>> so `target` appears to be nil at this point.
>>
>> Consequently,
>>
>>      newchars[target]
>>
>> does not seem to test whether the Unicode character currently being
>> processed is present in the fallback font.
>>
>> This matches the observed behaviour closely: when `check=yes` is active,
>> no useful fallback vector is produced for the Syriac range; when
>> `check=yes` is removed, the same font, range, and fallback work.
>>
>> Would the test here perhaps need to use
>>
>>      newchars[unicode]
>>
>> or
>>
>>      newchars[unic]
>>
>> depending on the intended handling of `offset`?
>>
>> I first encountered this while testing Syriac font coverage for
>> multilingual bibliography support, but the reduced example above is
>> independent of the bibliography and bidi mechanisms.
>>
>> Best,
>> JP
>>
>> ___________________________________________________________________________________ 
>>
>> If your question is of interest to others as well, please add an 
>> entry to the Wiki!
>>
>> maillist : [email protected] / 
>> https://mailman.ntg.nl/mailman3/lists/ ntg-context.ntg.nl
>> webpage  : https://www.pragma-ade.nl / https://context.aanhet.net 
>> (mirror)
>> archive  : https://github.com/contextgarden/context
>> wiki     : https://wiki.contextgarden.net
>> ___________________________________________________________________________________ 
>>
>
>
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : [email protected] / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage  : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive  : https://github.com/contextgarden/context
wiki     : https://wiki.contextgarden.net
___________________________________________________________________________________