Le 11 févr. 08 à 19:47, Hans Hagen a écrit :
LAURENS Jérôme wrote:
Couldn't we adopt an intermediate position? \tracesynctexpositions
i see no reason for 'tex' in the name, after all, we are running tex; also, nowadays there is no need to have short names (many new primitives have verbose names)
where you consider synctex as a whole word, just like mutex, cortex, vortex, vertex and of course latex In fact, due to performance reasons, only approximate output positions are traced, the output position unit is tex sp, but the synctex position unit is 8192 sp. I would expect a \traceoutputpositions to really report the output position, not just something approximate.
well, i'm more thinking along the line ...
\traceoutputpositions = 0 : disabled \traceoutputpositions = 1 : low resolution \traceoutputpositions = 2 : medium resolution (8192 resolution) \traceoutputpositions = 3 : high resolution
Unfortunately, this is not what synctex is designed for. It is more like \tracesynctexpositions=0:disabled \tracesynctexpositions=1:math, kern, glue, hbox \tracesynctexpositions=2:add noads \tracesynctexpositions=3:add some whatsits All this is dedicated to the Editor/Viewer synchronization, and it is not advisable to use it for something else. Roughly speaking, here is how synctex works: 1 - some nodes have been extended to -always- store synchronization information 2 - if some flag is enabled, this information is used to help synchronization. Point 1 belongs to the data model, it is public and can be used by any other tex extension. Point 2 is a controller, which means a piece of code that uses the data; it is -private- to synctex. The \synctex (or \tracesynctexpositions) primitive controls the behaviour of this synctex controller. So it is dedicated to point 2 and this is why it must be named accordingly. 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.
although position are always approximations (take for instance complex ligatures orgenerated code) i wonder if we should divert from the full sp resolution; i'd say: output the full number (no devision) and provide resolution in the amount of sync points
ok, the question is about precision
(if this feature also ends up in luatex, then it will be full resolution if only because all dimensions accessible at the lua end are in scaled points)
no, you are confusing the data and the controller. Actually, the dimensions are available in full dimensions, but this is a deliberate choice of the controller to truncate them to a lower precision. If the controller is implemented in lua, it will also decide to truncate simply because it is a matter of efficiency. 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 hope this explanation will enlight the design of synctex, and make you understand how tex and synctex are tied together. JL