Hi Pablo,
sorry for the earlier noise ! To avoid relying on viewer behaviour, I
tried to objectify the issue by inspecting the PDF objects directly. The
method is simply to compare the |/Subtype /Link| annotations written
into the PDF by each engine, in particular their |/Rect| values.
Specifically, I proceeded as you yourself indicated: compiling the
source file with lmtx and with luatex :
*
context --engine=luatex --result=border-luatex border-pablo.tex
*
context --engine=luametatex --result=border-lmtx border-pablo.tex
Then, extract the |/Rect [x0 y0 x1 y1]| values of the |/Link|
annotations from the resulting PDFs (e.g. via PyPDF2 or mutool) . To
achieve this (and to make the comparison independent of any PDF viewer),
I used a very small inspection script on the PDF files themselves. The
idea is simply to parse the PDF structure and list the annotations of
type |/Subtype /Link|, then read their |/Rect [x0 y0 x1 y1]|entries. A
minimal Python script using a standard PDF library (e.g. PyPDF2) is
sufficient for this: it opens the PDF, iterates over |/Annots|on a given
page, and prints the |/Rect|values for each link. Comparing these
numeric rectangles between the LuaTeX and LMTX outputs makes it possible
to identify whether the clickable area is already misplaced at
PDF-generation level, independently of how viewers render it. Here below
the two different values which show some issue in PDF production by LMTX :
border-luatex.pdf
Link #1: /Rect [14.593437, 6.648379, 20.46615, 21.112035]
Link #2: /Rect [24.361358, 6.660722, 30.216172, 21.080296]
border-lmtx.pdf
Link #1: /Rect [14.677078, 6.638355, 20.660645, 21.080296]
Link #2: /Rect [24.639551, 6.660722, 30.613851, 21.080296]
Doing so shows that (again), for the same source, the |/Rect| values
differ between LuaTeX and LMTX, which explains the consistently
misplaced clickable areas observed across viewers. Thanks for pointing
this out, and sorry again for the confusion earlier. I hope this
explanation sheds some light on the problem you encountered (although it
doesn't explain why LMTX produces this difference!). As Hans has
mentioned before, LMTX is not “LuaTeX with options” but a different
engine, with its own backend and internal pipeline. I’ll leave it to him
to explain whether this behaviour is expected, or if it can be improved.
Best//JP
Le 20/02/2026 à 09:10, Pablo Rodriguez via ntg-context a écrit :
On 2/19/26 19:52, Jean-Pierre Delange via ntg-context wrote:
Hi Pablo,
I think I understand the issue you are pointing out. In your MWE, the
visual content produced by |\at[æb]| is correctly scaled, but the
clickable area (and the border drawn with |references.border|) no longer
matches the scaled text in LMTX. In other words, the visual
transformation seems to be applied, but the geometry of the link
annotation does not seem to follow in the same way. What makes this
particularly noticeable is that it already happens with very small
scaling factors, and only in LMTX: with LuaTeX the link area still
appears to be placed correctly. This suggests that the problem is not
with |\at| itself, but with how link annotations interact with
transformations such as |\scale| in the LMTX backend — possibly the
annotation rectangle is computed before the transformation is applied,
or is not transformed along with the box.
For reference, I am testing this with a ConTeXt version from July 2025.
I haven’t yet checked whether different PDF viewers (e.g. Firefox /
PDF.js versus native viewers) affect how the link borders are displayed,
so that may also play a role. This is just my current reading of the
behavior; I’d be interested to know whether this matches what others
observe, or if I’m missing something.
Sorry, Jean-Pierre, but would it be to much to as as confirmation either
of these brief replies?
1. Yes, I can reproduce the issue.
2. No, I cannot reproduce your issue.
Excuse me, but I don’t need a (machine-generated?) explanation (or
something virtually indistinguishable from it) from the issue I’m just
providing a sample. I think I know what I see on screen.
From your reply, I guess that you may have reproduced the issue.
I’m testing this with both 2026.02.12 13:41 and 2026.02.19 11:49 (both
Linux64). In both cases, LMTX draws the wrong link area and LuaTeX draws
it right.
Results of misplaced link area are consistent with current (as packaged
[and updated as of today] for “Fedora 43”) “Evince”/“Okular”, “MuPDF-GL”
and “XpdfReader”.
I think I might have hit a bug, asked for confirmation, so I’m not
missing something and it could be fixed.
Many thanks for your help,
Pablo
___________________________________________________________________________________
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
___________________________________________________________________________________
