Hans,

Thank you for the clarifications, this makes perfect sense. In particular, the point about variable fonts and instances sharing the same internal names is likely key here, and it explains well why name-based lookup can lead to unexpected results. The outline step indeed acts as a magnifier, making such differences visible. Using a single, stable font variant and relying on well-defined font locations (e.g. |texmf-fonts|) seems the right approach for a reliable long-term workflow.

Best//JP


Le 17/02/2026 à 00:42, Hans Hagen via ntg-context a écrit :
On 2/16/2026 10:45 PM, Jean-Pierre Delange via ntg-context wrote:
Hi Dalyoung,

This is a very interesting situation, because it highlights how crucial it is to work with stable, well-sourced font files, and to run tests on different machines using exactly the same font binaries, in order to properly isolate the source of the problem.

If all is the same there should be no differences.

In particular, forcing fonts via explicit |file:| paths and clearing/ rebuilding the font cache seems essential here, given the potential collisions between /Noto KR/ and /Noto CJK KR/ variants (TTF vs OTF/CFF, variable vs static instances).

Indeed, there can be diferences between ttf and otf (which is also why we sometimes made choices wrt to what to put in the distribution).

Another problem is that variable fonts often have the same internal names which makes for clashes in lookup by name. So, never put both a variable font and instance in the tree. (Anyway, variable fonts are mainly there to save transmission on the web so I actually never use them.)

For a stable workflow (long term) one can best put copies in texmf-fonts and use filenames for lookups.

It might also be worth checking whether this behaviour is already documented somewhere in ConTeXt Garden, or whether it should be added as a note, since this kind of issue is likely to confuse users working with CJK fonts and outlines.

Normally, when you update a font the cache will be refreshed as we keep track of the timestamp, but it might be that cached outlines (or mp) goes unnoticed.

    /Stale or mixed font cache/: even after updating font files, older
    font metadata may still be used unless the cache is fully cleared
    and rebuilt.

an occasional cleanup doesn't hurt

    /Font technology differences/: the KR fonts (TrueType / quadratic
    outlines, often variable + instances) and the CJK KR fonts (OTF
    PostScript / CFF outlines) are technically different, and this may
    affect outline extraction in borderline cases.

also, when using variable fonts or extreme (small or large) scales one can sometimes see artifacts ... these go unnoticed in print but blown up on the screen then can stand out (also happens with vector graphics with inaccurate snapping or low res coordinates)

    /Different binaries despite identical names/: using |name:| instead
    of |file:| can hide the fact that different font files are actually
    being loaded.

It doesn't hurt to check the log on that.

This should make it clear whether the overlap is caused by font resolution/cache issues or by a platform- or font-specific problem.

or by design .. for instance cmr fonts had such effects and these were sorted out in lmr

a quick and dirty test can be:

\effect[outer]{An outline}

although there are side effects and such due to the fact that pdf is somewhat limited and/or viewers differ a bit it shows the same "multiple elements that overlap" issues

On macOS, font lookup can easily be affected by system fonts, duplicates, and cached metadata. To isolate whether the issue comes from font resolution or from the font files themselves, it may help to run a strictly controlled local test.

aghain a reason for using copies in the tree

|oepsmp/oepsmp.texfonts/NotoSerifCJKkr-Regular.otfNotoSerifCJKkr- Bold.otfNotoSerifKR-Regular.ttfNotoSerifKR-Bold.ttf|

better use texmf-fonts/fonts/data as it is there for a reason

Hans


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

Reply via email to