Le 12 févr. 08 à 09:26, Hans Hagen a écrit :
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)
Actually, absolutely no new node is created, unlike srcltx, src- specials and pdfsync This is why there won't be compatibility problems with already existing macros.
(btw, i then assume that there is also an implicit position insertion possible, like \injectsuchapositionhere or so)
not yet. The idea would be something like \marksynctexposition{blah} or \synctexcomment{blah} where blah is something related to the content, but I do not know yet how it should be designed With synctex, you are absolutely sure that no new node has been created. This is what makes the difference with srcltx, src specials and pdfsync and this is what ensures that other packages won't break.
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.
No, this is not how the patch works. The purpose is not to create new nodes nor manipulate node lists, the purpose is only to observe existing nodes. If you extend the size of some whatsit nodes, they will become observable, and there will be more info in the output. I guess the size of the node is not something publicly available in luatex, otherwise there might be problems when changing the node size in the core of the engine.
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
All the problem lies into inter process communication. If lua is able to talk directly to the viewer, the editor or the external synctex controller, then truncation is useless. But as long as IPC is made through text files, then truncation is a real benefit. And I am afraid it is difficult to avoid text files in that particular situation because we have no control on viewers nor editors. JL