[NTG-pdftex] Synchronization

LAURENS Jérôme jlaurens at users.sourceforge.net
Sat Feb 9 02:47:46 CET 2008


Le 8 févr. 08 à 13:52, Taco Hoekwater a écrit :

> LAURENS Jérôme wrote:
>> Hi,
>> I'd like to know the opinion of the developer team about   
>> synchronization and the patch I sent.
>
> I looked at Synchronize4.zip a while back and liked the general idea
> well enough, but somehow never got around to writing up my feelings.
>
> Here are a few remarks and questions:
>
> * how does this patch relate to the --src-specials switch from web2c,

No common code
better design
stronger design
better result

>
> and what editor/previewer combinations understand your files format?
> (and/or are likely to start doing that in the future)

I understand your question: you are wondering if this feature would be  
used by a viewer or an editor.
Anyone who ever used synchronization does not ask this question  
because he knows that such a synchronization is a "must have".

But let me give more technical answers.

- editors/viewers currently supporting .pdfsync files will most  
certainly support this new file format,
because from the editor/viewer developer point of view, supporting  
this new format is much easier than supporting the old pdfsync.
- Integrated TeX environments like iTeXMac2 or TeXShop on Mac OS X  
will support this feature because they want to provide the user a  
really efficient experience.
- this new synchronization scheme is conceptually well designed, and  
won't break where src-ltx, src-specials and pdfsync would break
- this synchronization scheme works the same for dvi or pdf

Next question is: how hard is it to support this new feature?

There are 2 possibilities, first, we can let things evolve according  
to nature's law and see what happens.
Second, we can help things go the right way. More precisely, I see 2  
possible designs, both relying on a synchronization controller, named  
"synchronizer"
Consider

1 - editor
2 - synchronizer
3 - viewer

forwards sync:

design 1:
- given a source file and a line number,  editor asks the synchronizer  
to display the output for that location in the source
- The synchronizer then parses the .sync file, finds out the real page  
and location to display, then asks the viewer to display it

design 2:
given a source file and a line number,  editor asks the synchronizer  
for the corresponding page number and location
The synchronizer then parses the .sync file, finds out the real page  
and location to display, and returns the result to the editor
Then the editor asks the viewer to display the result

backwards sync:

design 1:
given a pdf/dvi page and location, the viewer asks the synchronizer to  
display the intput for that location
The synchronizer then parses the .sync file, finds out the real line  
number and input source file to edit, then asks the editor to edit it

design 2:
given a pdf page and location, the viewer asks the synchronizer for  
the intput corresponding to that location
The synchronizer then parses the .sync file, finds out the real line  
number and input source file to edit, tand returns the result to the  
viewer
Then the viewer asks the editor to edit the result

The question is: where does the synchronizer live?

For integrated TeX environments, this controller should be integrated,  
just like the editor and the viewer are integrated.
But in general, the controller should be an external component(I vote  
for a ruby script)
to which the viewer and the editor would send messages. And this  
controller would be the same for all editors and viewers!

This is nothing but a MVC design: the model is the .sync file, the  
view is either the viewer or the editor, and both don't care about  
what is really inside the .sync file.

Once the synchronization controller is available as an external  
script, xpdf (forthcoming 3.0.3) would support synchronization with an  
appropriate config file.
I guess that auctex support would take just a few minutes.


>
>
> * I consider the |if s>3| test in get_node() pretty bad style. There
> may very well be a conflicting extension in the future, and then it
> may turn out that your code suddenly needs rewriting. It is better
> to adjust the node-specific functions like new_null_box() etc.
>
>
> This will result in more lines of web changes, but it will be easier
> to maintain the code by someone that is not you.

If you are talking about code design, I would follow you if you could  
explain what kind of extensions you are thinking of.

The actual synchronization rules are simple
- only nodes with size>3 are used for synchronization
- when a node is used for synchronization, the last 2 words are  
reserved for synchronization
- medium_node_size'd and box_node_size'd nodes are synchronized
- every type of node is a potential candidate for forthcoming  
enhancements in synchronization

By spreding initialization to many different places, you propose to  
create a set of rules and code for each type of node, mutliplying the  
synchronization hook points.
I have the impression that maintaining such a code would be a pain,  
even for the programmer!

However, if we want to initialize the nodes properly, we can do so in  
the node-specific function.
Unfortunately, those functions are not always used to create new nodes  
and one must take care of other routines.
But, how can we be sure that all the locations where initialization  
should take place are found? Any clue?

Another important problem concerns memory management.
I would not swear there is no memory leak.

>
>
> * the web glue code in synchronize.c is not very pretty, but I doubt
> there is a nice solution to that, so just let it be.

yes, this is not a strong design. I guess that everything could be  
made in web
but I don't know how (I don't want to;!), and I think it would have a  
non negligible computational cost when typesetting.

>
>
> * you should use actual C comments, though. Not the C++ // things.
> (Martin may have something more to say about C indentation style)
>
>
> * you licensed the C file as GPL2, yes?

Open source, whether GPL2 or something else, I don't know for sure  
because I was not given any hint about pdftex development rules.

>
>
> * the attachments seem missing in sarovar.org at the moment

All the attachments have been removed, there might be a good reason,  
should I upload once again?

>
>
> Best wishes,
> Taco
>



More information about the ntg-pdftex mailing list