Re: Possible bug in \definefontfallback with check=yes

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
> ___________________________________________________________________________________


-- 

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
        tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
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
___________________________________________________________________________________