[NTG-pdftex] Synchronization

LAURENS Jérôme 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=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
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  
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.


More information about the ntg-pdftex mailing list