[NTG-pdftex] Synchronization

Hans Hagen pragma at wxs.nl
Tue Feb 12 09:26:07 CET 2008

```LAURENS Jérôme wrote:

> \tracesynctexpositions=0:disabled
> \tracesynctexpositions=1:math, kern, glue, hbox

so, variant 2 and 3 are influencing the node lists (I assume that this
does not influence the outout i.e. no inhibiting of the \last...
primitives etc (sometimes whatsits can get in the way)

(btw, i then assume that there is also an implicit position insertion
possible, like \injectsuchapositionhere or so)

> If someone plans to use point 1 for another tex extension, then it
> will be possible to use your \traceoutputpositions terminology if this
> is relevant.

in the case of luatex (as an example) >= 2 would not work out well
because then all the user code that operates on a node list should take
these extra nodes (whatsites) into acount (ignore them and such); so, in
the case of luatex we would end up with just case 1 (but then in all
nodes). If needed user code can inject additional nodes (like 2/3). At
the end the info needed for synchronization can be written to file by a
lua function that loops over the resulting lists (of a callback in the
backend that produces the output), totally under user control. Of course
then, someone can write a sync compatible format.

> Actually, the dimensions are available in full dimensions, but this is
> a deliberate choice of the controller to truncate them to a lower
> precision.

i assumed as much -)

> If the controller is implemented in lua, it will also decide to
> truncate simply because it is a matter of efficiency.

it depends ... a bit of caching and a few more bytes may be cheaper than
calculations

> The purpose of the lower precision in synctex end is simply to reduce
> the size of the auxiliary output file.
> If we use full resolution, then the size increases by 40%, which is -
> very- significant because I/O operations are involved.
> 8192 is the best choice for that purpose.

(i can even imagine that outputting base points is an alternative
because after all, viewers work in such dimensions)

> I hope this explanation will enlight the design of synctex, and make
> you understand how tex and synctex are tied together.

sure, but what we want to keep an eye on (at least for luatex) is that
new functionality is open, not interfering, under user control etc

anyhow, pdftex is a good testbed for the sync feature (i suppose that
xetex also needs some tweaking when method 2/3 comes inti play because
it may manipulate node lists differently from pdftex and has additional
node types)

Hans

-----------------------------------------------------------------