jlaurens at users.sourceforge.net
Tue Feb 12 10:53:54 CET 2008
Le 12 févr. 08 à 09:26, Hans Hagen a écrit :
> LAURENS Jérôme wrote:
>> \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
> (btw, i then assume that there is also an implicit position
> insertion possible, like \injectsuchapositionhere or so)
The idea would be something like
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
and there will be more info in the output.
I guess the size of the node is not something publicly available in
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
And I am afraid it is difficult to avoid text files in that particular
situation because we have no control on viewers nor editors.
More information about the ntg-pdftex