Hello, I've started a prototype for a TeX module. At this time it handles not so badly some Python documentation files. Can anybody point me some TeX presentations, articles or books templates (or documents)? I don't think a lot of new commands are defined in the Python documentation files (there are some .sty). So I probably won't need to handle the definition of new commands for this format. There is still a lot to do in order to implement all the Martin's proposals, but it may probably be used as a basis. My next step will be to separate what is generic TeX and what is PythonDoc specific. My current implementation is attached. -- Nekral

On Sun, 5 Dec 2004 20:46:53 +0100, Martin Quinson wrote please go on so that I can follow this discussion. THank you to you, Martin and François for what you did already. Just some notes. I am now completely unable to program in perl so I just cannot help with the programming. But i can well test and comment. The document I am now translating from English to French, that could serve as a test (and this would help me a lot) is http://lightandmatter.com/bk2.tar.gz if you uncompress this file, please try and process file ch01/ch01.tex or ch02/ch02.tex We (the author of the original ENglish document and myself) have a proposal: we are ready to adapt the sources (if this is simple enough) in order to help with the use of po4a, aka for example include some simple complementary formatting of the original text file in order to simplify the parsing done by po4a and therefore the use of translation tools like kbabel and gtranslator. Much thanks in advance, Nicolas -- Nicolas Pettiaux

On Mon, 6 Dec 2004 00:19:33 +0100, Nicolas François wrote definitively LaTeX. It is more flexible. I don't think so ... provided \newlines is accepted by LaTex (which I don't remember and can"t find now). > Some TeX questions: > * Does a line starting by a command has a special meaning when > inside a paragraph? > For example, I've seen: > Who > {}\code{are} > you? I do not remember that I had seen such a syntax. > but also: > Who > \code{are} > you? > Are those paragraphs different? > * Is there any problem if a space is added at the end of lines? no > * Any idea on how to test the results? (diffing dvi?) human reading could work ? Nicolas -- Nicolas Pettiaux

On Mon, Dec 06, 2004 at 07:50:25PM +0100, Nicolas François wrote: Go for TeX, please. If we manage to derive a TeXinfo from this module, it will make clear that it's not LaTeX only. Yeah, that's exactly what I wanted to say. Don't do this convertion. I'm not so sure. If you have: toto% tutu then adding spaces after toto do change things. But it's not really an end of line. On real end of line, I guess it's ok to add spaces. Thanks, Mt.

El día Tue, Dec 14, 2004 at 10:28:09PM +0100, Nicolas François <nicolas.francois(a)centraliens.net&gt; escribió: It protects the space after the word (`Question:' or `Answer:'). -- jr <juanrafael.fernandez at hispalinux.es> # gpg --keyserver wwwkeys.pgp.net --recv-keys 0D709914

Hello, Based on my reading on LaTeX and Nicolas' book, I will change a little bit the implementation. It is much more formalized than the previous prototype. If it works, the content of this mail may be used as a documentation for this module. 1) The functions: parse: * The parse function will only separate paragraphs. The separator is an empty line or a line beginning by a comment. What I'm calling here a "paragraph" is not a paragraph in the output document, but a bloc of code separated by one of these separators. * The parse function will also remove the comments from this paragraph and keep them in a buffer (to be pushed as PO comments if there is a string to translate in this paragraph, or ignored otherwise). The comments will be ignored in the localized document. (This doesn't concern lines beginning by a comment, which will just be pushed, like empty lines) * Once a paragraph is found, the translation of the paragraph (built by translate_buffer) is pushed. translate_buffer: return the translation of a buffer (typically a paragraph or a subset of a paragraph) 1) call get_leading_command, to handle a leading command If the paragraph begins by a command, call this command's subroutine with the paragraph in argument and append this translation to the translated buffer. Loop until there is no more leading command. 2) call get_trailing_command, to handle trailing command (loop) while there is some trailing commands, call these commands, and build a translated buffer to push at the end of the current paragraph. 3) append the translation of the remaining paragraph (if any) 4) append the translation of the trailing commands * it should be possible to keep the separator between the commands (could be none, a space or a newline). One question: Is this separator important? For example, can I re-wrap: \inputprotcode \makeindex \debing{document} \myeqnspacing into: \inputprotcode \makeindex \begin{document} \myeqnspacing or even \inputprotcode\makeindex\begin{document}\myeqnspacing parse_command: A subroutine for the commands subroutine and get_leading_command / get_trailing_command * take a paragraph/buffer in argument * output the command name, an optional * (for \chapter*{foo}), an array of optional argument (between []), an array of argument (between {}), and the remaining paragraph/buffer. Another question: Are optional arguments always before regular arguments? get_leading_command: Is probably the same as parse_command. get_trailing_command: If the given paragraph ends by a command, then extract this command and return the command name, etc. and the remaining paragraph. The parameter of a command can contain a command, so a simple regular expression won't be sufficient. To be understood as a trailing command, the command will have to end by an argument (could be optional), or should not have any argument. I've read that a command is a \ followed by a string of lower and/or uppercase letters or a \ followed by a single nonletter. I will probably only support the first case, but not the latter (with some exception) command subroutines: * commands is a hash of subroutines with the command name as a key. * One command subroutine takes in argument the paragraph/buffer (and $self,...). The arguments may have been separated by parse_command before and provided as arguments. outputs are: a translated string, the remaining paragraph/buffer * to translate the content of a parameter, translate_buffer could be called. This way, I'm dealing with \chapter{foo\label{bar}} 2) environments * when a \begin is encountered, push the environment name in a stack. This should permit to embed environments Do you think this may be useful to have a full stack of the environment? It may be better than always handling the paragraph (and shifting lines) in a separated subroutine * when a \end is encountered, pop this environment (some verifications could be done) * The translate_buffer should ensure that if the environment stack contains a verbatim, then the no-wrap flag is set, and other things like this (e.g. setting the type) * some environment may be particular, and a more complicated subroutine could handle the current paragraph, and possibly shift some lines. * the environments subroutines could be separated from the commands hash. Do you think they should be separated? 3) Some questions: * Is there some commands that need to be translated? For example, somebody may want to change \noindent into a \localized_noindent. * Does a line containing only spaces breaks a paragraph? 4) \newcommand I had a look at Nicolas' book. I think the parser explained above can do the trick for it. The parser could receive in argument the class file (lm.cls), or the file name could be deduced from the \documentclass{lm} command. Every lines of this document is ignored, but lines beginning by: "% po4a:" (In fact, these lines could also be specified in another file, but it may be easier to have the definitions of the commands and the definition of how they should be dealt with by po4a) Here is my proposal for the format of these lines: % po4a: new_command alias other_command or % po4a: new_command x y z t where * x is the number of optional arguments (between []) 0 - no optional argument -1 - variable (can it be?) n - maximum number of optional argument (maybe -1 will be easier to use) * y is the number of arguments maybe x and y are not needed * z array of indexes of the optional arguments that have to be translated -1 - all optional argument should be translated 0 - none 1,3,7 - the 1st, 3rd and 7th arguments should be translated * t array of indexes of the arguments that have to be translated 5) User point of view (my goals) Nicolas should only have to provide the bk2.tex file to the parser (and a class file). When the \include{ch01/ch01} will be encountered, this file will be parsed. No file should require a modification (except the class file or a file containing only the "% po4a: " commands 6) Conclusion So, it virtually works in my dreams and everything seems rather clear and simple;) Some points were masked/forgotten here (notably the reference, at this time I only plan to keep one reference for a paragraph, but this can certainly be fixed latter). Lets start coding, -- Nekral

On Fri, 10 Dec 2004 23:34:32 +0100, Denis Barbier wrote THank you to contribute. I have recently came accross several active people who will be very happy with this tools tat will allow to ease the translation of Latex documents, but that will also, ans thiscan even be more important, simplify greatly the maintenance of the transaltions with respect to their respective originals. I am forwarding the discussion so far to the original author of the latex documents I am translating to see if he has some comments. THanks again to all Nicolas -- Nicolas Pettiaux

On Sat, Dec 11, 2004 at 12:15:29PM +0100, Nicolas François wrote: [...] But this is wrong, in LaTeX this comment is ignored and there is only one paragraph in your example above. [...] Okay, I see, but I wonder whether this is the right way to go. IMO you should first try to have a working implementation, then people use it in ways you did not imagine, and you then have to fix/extend it. Sometimes authors put \label at the beginning of paragraphs, maybe it is similar with \index. Denis

On Sat, Dec 11, 2004 at 06:14:13PM +0100, Nicolas François wrote: [...] Sounds more logical, yes. I do not know what to do with the first two because typographic rules depend on languages, so they should not be automatically written into translated documents. It seems indeed logical to write \index argument into its own msgid. \label argument should not be translated. About \footnote, I do not understand how you can put it into a separate msgid, because footnotes can appear anywhere in a sequence and you then need a marker to tell where to insert them. Denis

On Sat, Dec 11, 2004 at 06:14:13PM +0100, Nicolas François wrote: Actually, % also comments the end of line in LaTeX. In addition, white chars at the begining of the line are not taken into account. As a result, those two forms are strictly equivalent. toto% tutu <<< tototutu <<< This becomes important when you do some TeX coding: \def\interfbuild#1#2{\mathrel{\mathop{% \rlap{% \raise .6ex% \hbox{\ensuremath{#1}}% }% \raise -.2ex% \hbox{\ensuremath{#2}}% }}} Those beasts become hairly when not indented, and extra spaces are not welcome around those definitions. I know that your goal is not to eat documents defining such beasts for now, but maybe one day ? Mt. PS: Sorry for the delay...

On Wed, Dec 15, 2004 at 11:27:22PM +0100, Nicolas François wrote: Only the class file? What if I define new macros in the file ? o:-) This *is* the right way to go. It is so clumsy in sgml because we do not really do the parsing ourselves there. nsgml does the parsing and then run some callbacks of ours. this solution seemed simple at the first glance when I begun working on Sgml.pm, but it brings a bunch of issues, such as this one. Please keep avoiding Sgml.pm braindead design while working on TeX.pm :) This is quite problematic. Did you a nice way to find the '}' matching a given '{' ? (yeah, I have to confess I didn't find the time to read your code) It would solve such issues, wouldn't it? This is related to #300874 (Included files should be searched in the path of the master) https://alioth.debian.org/tracker/index.php?func=detail&aid=300874&am... I should rewrite a bit the sgml module to get rid of this clumsy nsgml, and then we could work on a generic inclusion mecanism solving such issues. Jordi was interested in such a mecanism for Xml, too, but we failed to find a nice interface last time we spoke about it. You mean that it adds a second new line along the first one sometimes? It may be fixed by recompiling the document once again. Welcome in LaTeX cumbersome world :) Diffing the pdf does reveals changes? What about the ps? All your work is very impressive. I was already more than impressed when you played with Man.pm, but this time, I'm thrilled. Thanks for your time and sorry for not being able to help you more. Mt.