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