LAURENS Jérôme wrote:
\tracesynctexpositions=0:disabled \tracesynctexpositions=1:math, kern, glue, hbox \tracesynctexpositions=2:add noads \tracesynctexpositions=3:add some whatsits
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 ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------