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
___________________________________________________________________________________
