From: Alan G I. <ai...@am...> - 2005-10-05 15:46:06
|
1. Citation keys are broken. If a citation reference has an underscore, [like_this], then with --use-latex-citations the LaTeX writer will produce \bibitem[like{\_}this]{like{\_}this} That places forbidden characters in the citekey. It should produce \bibitem[like{\_}this]{like_this} 2. It would be very nice to be able to --use-bibtex-for-citations --bibliographystyle=mystyle.bst --bibliography=mybib.bib - suppress the citations - \usepackage{natbib} - produce citation references \cite{like_this} - add \bibliographystyle{mystyle} \bibliography{mybib} 3. Just a comment on rst2latex vs. rst2newlatex: the movement here is exactly the opposite of my preference, if I understand it. Of course I am not presumptuously claiming it is "wrong": forcing LaTeX that way may be what most users want. (Is it?) What I want out of a LaTeX writer is the heaviest possible reliance on LaTeX with the fewest "tricks". I really hope that rst2newlatex is not destined to *replace* rst2latex but rather to "surpass" it for needs of some users (not me). fwiw, Alan Isaac |
From: Alan G I. <ai...@am...> - 2005-10-10 02:09:41
|
On Wed, 5 Oct 2005, Alan G Isaac apparently wrote: > 1. Citation keys are broken. > If a citation reference has an underscore, [like_this], > then with --use-latex-citations the LaTeX writer will > produce > \bibitem[like{\_}this]{like{\_}this} > That places forbidden characters in the citekey. > It should produce > \bibitem[like{\_}this]{like_this} Since I posted the above bug report along with some enhancement requests, I just want to be sure the bug report was seen. Cheers, Alan Isaac |
From: <gr...@us...> - 2005-10-10 07:59:46
|
On Sun, 9 Oct 2005, Alan G Isaac wrote: > On Wed, 5 Oct 2005, Alan G Isaac apparently wrote: > > 1. Citation keys are broken. > > If a citation reference has an underscore, [like_this], > > then with --use-latex-citations the LaTeX writer will > > produce > > \bibitem[like{\_}this]{like{\_}this} > > That places forbidden characters in the citekey. > > It should produce > > \bibitem[like{\_}this]{like_this} > > > Since I posted the above bug report along with some > enhancement requests, I just want to be sure the bug report > was seen. committed to svn -- BINGO: significantly improved cost structure |
From: David G. <go...@py...> - 2005-10-14 14:07:34
Attachments:
signature.asc
|
[Alan G Isaac] > 3. Just a comment on rst2latex vs. rst2newlatex: the > movement here is exactly the opposite of my preference, > if I understand it. What, specifically, are you referring to? -- David Goodger <http://python.net/~goodger> |
From: Alan G I. <ai...@am...> - 2005-10-15 05:47:04
|
> [Alan G Isaac] >> 3. Just a comment on rst2latex vs. rst2newlatex: the >> movement here is exactly the opposite of my preference, >> if I understand it. On Fri, 14 Oct 2005, David Goodger apparently wrote: > What, specifically, are you referring to? The movement away from friendly reliance on LaTeX towards a heavy handed "forcing" of LaTeX. I append a very simple on paragraph example below: I would always want the old output not the new output. Recall that I offered no criticism of the new approach, for the simply reason that I do not understand its motivation. I only expressed my hope that it will not be the only development. I hope we will see the old approach continue and indeed be elaborated to an *even greater* reliance on LaTeX to do what is right. I want to lean on LaTeX, not wrestle with it. I also want my LaTeX to be usable as a LaTeX document, since sometimes I have to leave reST for LaTeX (e.g., when a document's math requirements become too much for reST to handle nicely). The output of the new writer is not suitable for that. Here is another way to put it: LaTeX fully supports "styles". My view is that you should no more force LaTeX this way than you would force HTML this way (rather than relying on CSS). Cheers, Alan Isaac ------------------------------------------------------------ Old Output:: The open-databank format enhances the original databank specification for the comment lines and adds a couple details. It retains all of the advantages of the microTSP databank format for fixed-frequency time series data. (That is, it is easily human readable, almost self documenting, easily parsed, and terse.) Any correctly formatted microTSP databank file is an open-databank file. New Output:: \renewcommand{\Dparagraphindented}{false}% \renewcommand{\Dparent}{section}% \DNparagraph{% The{ }open{-}databank{ }format{ }enhances{ }the{ }original{ }databank{ }specification{ }for{ }the{ }comment{ }lines{ }and{ }adds{ }a{ }couple{ }details.{ }It{ }retains{ }all{ }of{ }the{ }advantages{ }of{ }the{ }microTSP{ }databank{ }format{ }for{ }fixed{-}frequency{ }time{ }series{ }data.{ }(That{ }is{,}{ }it{ }is{ }easily{ }human{ }readable{,}{ }almost{ }self{ }documenting{,}{ }easily{ }parsed{,}{ }and{ }terse.){ }Any{ }correctly{ }formatted{ }microTSP{ }databank{ }file{ }is{ }an{ }open{-}databank{ }file.% }% |
From: <gr...@us...> - 2005-10-15 10:26:46
|
On Sat, 15 Oct 2005, Alan G Isaac wrote: > > [Alan G Isaac] > >> 3. Just a comment on rst2latex vs. rst2newlatex: the > >> movement here is exactly the opposite of my preference, > >> if I understand it. > > On Fri, 14 Oct 2005, David Goodger apparently wrote: > > What, specifically, are you referring to? the question came up years ago: should the latexwriter use latex as a backend that produces ps or pdf or whatever or should real latex code be produced. without a real answer. my opinion would be to produce real latex code and maybe make a texwriter or a pswriter or a roffbackend, because i work with latex because i want to reuse the typsetting knowledge of it's creators and always have the impression that goning against the rules in latex is hard (latex coding is real easy if you can live with the rules). but then there are two latexwriters, that is fine with me. > The movement away from friendly reliance on LaTeX towards > a heavy handed "forcing" of LaTeX. I append a very simple > on paragraph example below: I would always want the old > output not the new output. > > Recall that I offered no criticism of the new approach, for > the simply reason that I do not understand its motivation. > I only expressed my hope that it will not be the only > development. I hope we will see the old approach continue > and indeed be elaborated to an *even greater* reliance on > LaTeX to do what is right. I want to lean on LaTeX, not > wrestle with it. > > I also want my LaTeX to be usable as a LaTeX document, since > sometimes I have to leave reST for LaTeX (e.g., when > a document's math requirements become too much for reST to > handle nicely). The output of the new writer is not > suitable for that. > > Here is another way to put it: LaTeX fully supports "styles". > My view is that you should no more force LaTeX this way than > you would force HTML this way (rather than relying on CSS). > ------------------------------------------------------------ > > Old Output:: > > The open-databank format enhances the original databank specification > for the comment lines and adds a couple details. It retains > all of the advantages of the microTSP databank format for fixed-frequency > time series data. (That is, it is easily human readable, almost self > documenting, easily parsed, and terse.) Any correctly formatted microTSP > databank file is an open-databank file. > > New Output:: > > \renewcommand{\Dparagraphindented}{false}% > \renewcommand{\Dparent}{section}% > \DNparagraph{% > The{ }open{-}databank{ }format{ }enhances{ }the{ }original{ }databank{ }specification{ }for{ }the{ }comment{ }lines{ }and{ }adds{ }a{ }couple{ }details.{ }It{ }retains{ }all{ }of{ }the{ }advantages{ }of{ }the{ }microTSP{ }databank{ }format{ }for{ }fixed{-}frequency{ }time{ }series{ }data.{ }(That{ }is{,}{ }it{ }is{ }easily{ }human{ }readable{,}{ }almost{ }self{ }documenting{,}{ }easily{ }parsed{,}{ }and{ }terse.){ }Any{ }correctly{ }formatted{ }microTSP{ }databank{ }file{ }is{ }an{ }open{-}databank{ }file.% > }% -- BINGO: collaboratively initiate competitive deliverables |
From: Alan G I. <ai...@am...> - 2005-10-15 18:23:22
|
On Sat, 15 Oct 2005, T) gr...@us... apparently wrote: > there are two latexwriters, that is fine with me. We agree on that. And we agree that the old writer is the one we want, not the new writer. I am largely expressing the hope that the old writer be seen as the focus for *LaTeX* writer development, and the other as essentially misnamed and serving other purpose (e.g., PDF creation) via LaTeX. [1] Cheers, Alan Isaac .. [1] Even so, I'd like to hear more discussion of why such a heavy handed approach is seen as desirable. My gut instinct is that this can be done in a more LaTeX friendly way (e.g., with a default.sty and appropriate environments). |
From: Felix W. <Fel...@gm...> - 2005-10-24 20:41:38
|
Alan G Isaac wrote: [Re-ordered the quoting a bit.] > Recall that I offered no criticism of the new approach, for the simply > reason that I do not understand its motivation. So let me elaborate a bit: The policy of the new LaTeX writer is to do the safest thing possible, that I'm confident of to work *always*. I'm not always sure if logic in the old LaTeX writer will work always, whereas for the new LaTeX, I usually am. So this results in fewer bugs (just as the one you just discovered). Furthermore, the new LaTeX writer should enable to user to tweak the behavior of LaTeX as much as possible through re-defining of macros. You may have noticed that much of the writer logic has been moved to the standard LaTeX stylesheet. (Quite some documentation needs to be written yet to enable users to actually make use of that flexibity.) > I only expressed my hope that it will not be the only development. I will carefully listen to all use cases and objections. However, I do not think that in the long term it is either desirable or viable to maintain two LaTeX writers in parallel. I must admit that even now I feel unable to wrestle with all bugs in the old LaTeX writer and make sure it works probably -- which is why I started a rewrite with a different design, learning from the problems of the old LaTeX writer. > [About newlatex2e, I don't like] The movement away from friendly > reliance on LaTeX towards a heavy handed "forcing" of LaTeX. > > [...] I hope we will see the old approach continue and indeed be > elaborated to an *even greater* reliance on LaTeX to do what is right. I think this is a major misunderstanding: What you see in the output of the new writer (and what looks admittedly ugly) is only the result of the writer paranoidly escaping anything that could possibly break. It lets LaTeX do the job of typesetting and "doing the right thing". In fact it relies heavily on LaTeX's typesetting capabilities. > I also want my LaTeX to be usable as a LaTeX document, since sometimes > I have to leave reST for LaTeX (e.g., when a document's math > requirements become too much for reST to handle nicely). The output > of the new writer is not suitable for that. Hmm. Yes, that's true. > Here is another way to put it: LaTeX fully supports "styles". I found lack of customizability (esp. given that LaTeX is a macro language) one of the major annoyances with the old LaTeX writer. The new writer lets the user apply arbitrary styles to most elements. > My view is that you should no more force LaTeX this way than you would > force HTML this way (rather than relying on CSS). Rest assured that the new LaTeX writer does just that. :-) -- For private mail please ensure that the header contains 'Felix Wiemann'. "the number of contributors [...] is strongly and inversely correlated with the number of hoops each project makes a contributing user go through." -- ESR |
From: Alan G I. <ai...@am...> - 2005-10-24 21:19:28
|
On Mon, 24 Oct 2005, Felix Wiemann apparently wrote: > new writer lets the user apply arbitrary styles to most elements. OK, I am understanding a bit more I think. Most of the "intervention" I commented on is oriented to designating a variety of elements for purposes of styling, using the new macro names. Of course I do not really hope you have time enough to educate me, but if you are inclined to share some motivation, I have two questions. 1. Core question: What is an example of markup supported by reST but not in your opinon adequately supported by existing LaTeX constructs? 2. Suppose we make a distinction between inline elements and block level elements. Why is it desirable to style block level elements with a macro (say, \DNparagraph) rather than with an environment (which might have the same name)? Thanks, Alan |
From: Alan G I. <ai...@am...> - 2005-10-24 21:24:15
|
On Mon, 24 Oct 2005, Alan G Isaac apparently wrote: > What is an example of markup supported by reST but not in > your opinon adequately supported by existing LaTeX > constructs? Actually I should anticipate slightly here. I am going to guess that one answer is: nested elements. But an environment can set variables to indicate nesting. (You do something related to this already; and obviously LaTeX's list environments keep track of nesting.) Cheers, Alan |
From: Felix W. <Fel...@gm...> - 2005-10-29 21:03:58
|
Alan G Isaac wrote: > 1. Core question: What is an example of markup supported by reST but > not in your opinon adequately supported by existing LaTeX > constructs? E.g. field lists, option lists, definition lists, tables, topics, sidebars, footnotes, ... LaTeX usually provides environments that are intended to be used for such purposes (e.g. definition lists, or tables) but break for a lot of cases that are supported by Docutils (mostly having to do with nested block-level elements). Consider tables inside of footnotes, field lists inside of tables, bullet lists inside of definition lists, etc. > 2. Suppose we make a distinction between inline elements and block > level elements. Why is it desirable to style block level elements > with a macro (say, \DNparagraph) rather than with an environment > (which might have the same name)? Sometimes it's necessary to pass the contents of a block-level element to a macro. You can't do that if you are using an environment. So I followed the simple rule that the contents of all elements are automatically passed to LaTeX as macro calls, with the exception of "document" and "section", because then LaTeX would run out of memory for big documents. -- For private mail please ensure that the header contains 'Felix Wiemann'. "the number of contributors [...] is strongly and inversely correlated with the number of hoops each project makes a contributing user go through." -- ESR |
From: Alan G I. <ai...@am...> - 2005-10-29 23:25:00
|
> Alan G Isaac wrote: >> 1. Core question: What is an example of markup supported by reST but >> not in your opinon adequately supported by existing LaTeX >> constructs? On Sat, 29 Oct 2005, Felix Wiemann apparently wrote: > E.g. field lists, option lists, definition lists, tables, topics, > sidebars, footnotes, ... > LaTeX usually provides environments that are intended to be used for > such purposes (e.g. definition lists, or tables) but break for a lot of > cases that are supported by Docutils (mostly having to do with nested > block-level elements). Consider tables inside of footnotes, field lists > inside of tables, bullet lists inside of definition lists, etc. OK, this is a narrower interpretation of "LaTeX constructs" than I had in mind. LaTeX of course allows you to define environments to meet your needs. Tables inside of footnotes: you mean *tabular* environments? I do not see the problem. Of course anything that can float arbitrarily will be a problem, so the *table* (float) environment would not be appropriate. Field lists inside of tables: you mean inside of *tabular* environments. This can be done. Just put the "fieldlist" environment inside a cell, or multiple cells if that is appropriate. Bullet lists inside of defintion lists: again I do not see the problem. E.g., \begin{description} \item[label] \begin{minipage}[t]{\textwidth} \begin{itemize} \item item 1 \item item 2 \item item 3 \end{itemize} \end{minipage} \item[label] Second item \end{description} Of course none of this addresses your claim that you would need sometimes to both put content in an environment and pass that same content to a macro. I'd be interested in an example of that necessity. Thank you, Alan Isaac |
From: Mikolaj M. <mi...@wp...> - 2005-10-29 23:21:19
|
Felix Wiemann scripsit: > Alan G Isaac wrote: > >> 1. Core question: What is an example of markup supported by reST but >> not in your opinon adequately supported by existing LaTeX >> constructs? > > E.g. field lists, option lists, definition lists, tables, topics, > sidebars, footnotes, ... > > LaTeX usually provides environments that are intended to be used for > such purposes (e.g. definition lists, or tables) but break for a lot of > cases that are supported by Docutils (mostly having to do with nested > block-level elements). What do you mean by "not adequately supported"? > Consider tables inside of footnotes, > field lists inside of tables, > bullet lists inside of definition lists, etc. All those things are working for me, eg. page 4 of http://skawina.eu.org/mikolaj/vst.pdf Point "4.2.1 User CSS". Source http://skawina.eu.org/mikolaj/vst.tex m. -- LaTeX + Vim = http://vim-latex.sourceforge.net/ Vim Universal Templates: http://vim.sf.net/script.php?script_id=1078 vim.pl - http://skawina.eu.org/mikolaj CLEWN - http://clewn.sf.net |
From: Felix W. <Fel...@gm...> - 2005-10-24 21:07:08
|
Alan G Isaac wrote: > I am largely expressing the hope that the old writer be seen as the > focus for *LaTeX* writer development, and the other as essentially > misnamed and serving other purpose (e.g., PDF creation) via LaTeX. [1] Nope. The new LaTeX writer is generating true LaTeX. It makes heavy use of LaTeX built-in functionality and it is largely customizable via LaTeX macros. > .. [1] Even so, I'd like to hear more discussion of why such a heavy > handed approach is seen as desirable. My gut instinct is that this > can be done in a more LaTeX friendly way (e.g., with a default.sty > and appropriate environments). Possibly it can be done. That requires significant knowledge of LaTeX's inner workings, though, which I don't possess. Also, only a part of Docutils' functionality can be mapped to LaTeX's standard macros and environments. The new writer uses a rather simply structured way to pass the document tree to LaTeX and call macros, which avoids a lot of headaches and gives me confidence that I can work around most of LaTeX's deficiencies -- LaTeX is not particularly clean in its inner workings, unfortunately. -- For private mail please ensure that the header contains 'Felix Wiemann'. "the number of contributors [...] is strongly and inversely correlated with the number of hoops each project makes a contributing user go through." -- ESR |
From: Felix W. <Fel...@gm...> - 2005-10-30 15:31:10
|
Mikolaj Machowski wrote: > Felix Wiemann scripsit: > >> LaTeX usually provides environments that are intended to be used for >> such purposes (e.g. definition lists, or tables) but break for a lot of >> cases that are supported by Docutils (mostly having to do with nested >> block-level elements). > > What do you mean by "not adequately supported"? I didn't write "not adequately supported"... What I mean with the above paragraph is that when you nest the standard constructs, you often get broken margins or the document won't be processable by LaTeX at all. >> Consider tables inside of footnotes, field lists inside of tables, >> bullet lists inside of definition lists, etc. > > All those things are working for me, eg. page 4 of > http://skawina.eu.org/mikolaj/vst.pdf, point "4.2.1 User CSS". No, I'm sorry I have to say, they don't work. (Except for tables inside of footnotes, which I was wrong about.) You have some problematic cases in this very document: E.g. "5.15 Tables" and "5.16 Simple Tables" where the nested lists have too much vertical margin, and the last row in the calendar table is too high. And bullet lists inside of definition lists become a problem when the first element of the definition is a bullet list: This is the term. * Definition * is * a * bullet * list. The old LaTeX writer relies on LaTeX's description environment and suffers from broken rendering whereas the new LaTeX writer builds its own environment that works even in cases like this one. (Didn't test with VST's LaTeX writer.) -- For private mail please ensure that the header contains 'Felix Wiemann'. "the number of contributors [...] is strongly and inversely correlated with the number of hoops each project makes a contributing user go through." -- ESR |
From: Felix W. <Fel...@gm...> - 2005-10-30 16:17:56
|
Alan G Isaac wrote: > LaTeX of course allows you to define environments to meet your needs. Yes, and I'm doing that, except that I'm using macros instead of environments for greater flexibility. But please don't expect either the macro definitions or the macro calls to be readable. They are designed to work around LaTeX's deficiencies, so they are *ugly* because they do a lot of hacking. > Tables inside of footnotes: you mean *tabular* environments? Yes. (I'm always using Docutils terminology on this list to avoid confusion.) > I do not see the problem. Sorry, I was wrong about that case. > Field lists inside of tables: you mean inside of *tabular* > environments. This can be done. Just put the "fieldlist" environment > inside a cell, or multiple cells if that is appropriate. Why don't you test it? +--------------------+ | :Name: | | Paragraph. | | | | Paragraph. | | :Name: | | Paragraph. | | | | Paragraph. | +--------------------+ Now render this with the old LaTeX writer which uses LaTeX's standard description environment for field lists: Both vertical and horizontal margins around the field list are much too large. Test it with the new LaTeX writer, and it works. (There's not enough space between the fields of the field list, but that's another issue, and it's gonna be fixed, of course.) > Bullet lists inside of defintion lists: again I do not see the > problem. E.g., > > \begin{description} > \item[label] > \begin{minipage}[t]{\textwidth} > \begin{itemize} > \item item 1 > \item item 2 > \item item 3 > \end{itemize} > \end{minipage} > \item[label] Second item > \end{description} In this example you start doing something that's absolutely natural for someone who writes LaTeX code manually: You notice that you can't put the itemize environment directly into the description environment, so you just surround it with a minipage. *You are hacking around LaTeX's deficiencies right here.* What I'm doing is to put this hack-around logic into the writer. It's not that easy because a human can just write the document, render it, see where it breaks, and fix it, but the writer must know in advance where the document could break. E.g. you cannot always surround itemize environments with minipages because that would break page-breaking. And consider what happens if the label of your description list gets very wide -- it shouldn't push the itemize environment to the right. Now solve some spacing problems (which in this case happen with wide labels or if we add a paragraph after the minipage) and you end up with a really complicated macro. By the way, since we are using minipages here, I have to make sure that *all* elements also work inside of minipages. So these are the nice and interesting edge cases that are a pain for the developer but that make, on the other hand, a fully functional LaTeX writer so attractive, because it allows you to write structurally complex documents that will render flawlessly without you having to get into the depths of LaTeX to fix the spacing. > Of course none of this addresses your claim that you would need > sometimes to both put content in an environment and pass that same > content to a macro. I'd be interested in an example of that > necessity. For example a footnote is a block-level element (because it contains block-level elements), but you have to pass the contents of the footnote to a macro (\insert\footins or or \footnotetext). So an environment would fail here. Instead of making a mess by mixing environments and macros (and, as you can see from the footnote example, it's quite difficult to decide what should be an environment and what a macro), I just go the easiest and most fail-safe way "make everything a macro." -- For private mail please ensure that the header contains 'Felix Wiemann'. "the number of contributors [...] is strongly and inversely correlated with the number of hoops each project makes a contributing user go through." -- ESR |
From: Felix W. <Fel...@gm...> - 2005-10-24 19:54:45
|
Alan G Isaac wrote: > 1. Citation keys are broken. > > If a citation reference has an underscore, [like_this], then with > --use-latex-citations the LaTeX writer will produce > \bibitem[like{\_}this]{like{\_}this} That places forbidden > characters in the citekey. It should produce > \bibitem[like{\_}this]{like_this} Thanks for the feedback. Engelbert fixed that for the latex2e writer. For newlatex2e, that feature isn't implemented at the moment. I added passing raw text to the to-do list though. > 2. It would be very nice to be able to > --use-bibtex-for-citations > --bibliographystyle=mystyle.bst > --bibliography=mybib.bib > > - suppress the citations > - [...] Suppressing the citations is a really ugly hack. You can do that if you like (with newlatex2e, you won't even need to touch the Python code; just adjust the stylesheet), but I wouldn't like to see such an option in the core. > 3. Just a comment on rst2latex vs. rst2newlatex: the > movement here is exactly the opposite of my preference, > if I understand it. Of course I am not presumptuously > claiming it is "wrong": forcing LaTeX that way may be > what most users want. (Is it?) If they want flexibility, power, and robustness, it is. If they want well-readable LaTeX output, it's not. > What I want out of a LaTeX writer is the heaviest possible reliance > on LaTeX with the fewest "tricks". That's what newlatex2e does. > I really hope that rst2newlatex is not destined to *replace* > rst2latex but rather to "surpass" it for needs of some users (not > me). Well, I'm actually planning to replace latex2e with newlatex2e, but that's still a bit in the future and will be discussed beforehand. Of course I'm always open to hearing people's use cases that may let them prefer latex2e. -- For private mail please ensure that the header contains 'Felix Wiemann'. "the number of contributors [...] is strongly and inversely correlated with the number of hoops each project makes a contributing user go through." -- ESR |
From: Alan G I. <ai...@am...> - 2005-10-24 21:19:21
|
On Mon, 24 Oct 2005, Felix Wiemann apparently wrote: > If they want flexibility, power, and robustness, it is. > If they want well-readable LaTeX output, it's not. I hope you will say something that will help me understand this. I have a couple decades of experience as a LaTeX user, and I have never seen these two aspects to be in conflict. (Just the opposite, usually: the appropriate use of environments enables almost any desired formatting with essentially no impact on readability.) Out of curiosity, I wonder if the underlying goal is really a TeX writer rather than a LaTeX writer. (Compare e.g. the goals of qatex.) In my opinion as a user (admittedly unaware of your design goals), a *LaTeX* writer should rely to the greatest extent possible on the robust accumulation of knowledge present in the existing packages (or possibly rely on implementing and new package). To take but one concrete example, it should be able to rely on natbib for citation handling. Cheers, Alan |
From: Felix W. <Fel...@gm...> - 2005-10-25 22:56:03
|
Alan G Isaac wrote: > Felix Wiemann wrote: > >> If they want flexibility, power, and robustness, it is. >> If they want well-readable LaTeX output, it's not. > > I hope you will say something that will help me understand this. I > have a couple decades of experience as a LaTeX user, and I have never > seen these two aspects to be in conflict. These aren't in conflict when you write LaTeX code manually because you immediately see it when you did something wrong and can just fix it. However, for software generating LaTeX code it is necessary to include escaping mechanisms for a lot of cases. As a simple example, the LaTeX writer must make sure that consecutive dashes ("--") aren't interpreted as en or em dash. The old LaTeX writer protects such dashes by inserting empty braces ("-{}-"). The new LaTeX writer uses a catch-all approach by brace-surrounding *any* character that could possibly interact with its environment, thus leading to "{-}{-}" in this case. This means that I'm *sure* that no character will interact with any other character. For the old LaTeX writer, we've had several character-related problems (like "[" at beginning of line), and I'm by no means able to verify that there aren't any other problems. Also the new writer mostly relies on LaTeX macros to implement its functionality, and you can easily overwrite these macros and thus tweak the behavior for any element of the document tree. This is only possible because the writer "dumps" the tree to LaTeX, passing in all information that's possibly relevant to the macros. That's why you get such long winded LaTeX output. > Out of curiosity, I wonder if the underlying goal is really > a TeX writer rather than a LaTeX writer. No. I considered limiting myself to pure TeX (to make the output usable in other TeX-based systems), but I've found that, besides my own lack of knowledge about pure TeX, we actually need a lot of the functionality of LaTeX, technically and in terms of do-the-right-thing typesetting knowledge. > In my opinion as a user (admittedly unaware of your design goals), a > *LaTeX* writer should rely to the greatest extent possible on the > robust accumulation of knowledge present in the existing packages (or > possibly rely on implementing and new package). It does. :-) > To take but one concrete example, it should be able to rely on natbib > for citation handling. I'm not sure if it should use natbib by default (didn't look at it closely), but in any case you'll be able to write your own stylesheet so that it uses natbib for citation handling. -- For private mail please ensure that the header contains 'Felix Wiemann'. "the number of contributors [...] is strongly and inversely correlated with the number of hoops each project makes a contributing user go through." -- ESR |
From: Alan G I. <ai...@am...> - 2005-10-25 23:37:10
|
On Wed, 26 Oct 2005, Felix Wiemann apparently wrote: > the new writer mostly relies on LaTeX macros to implement its > functionality, and you can easily overwrite these macros and thus tweak > the behavior for any element of the document tree. This could also be done with environments, right? > This is only possible because the writer "dumps" the tree > to LaTeX, passing in all information that's possibly > relevant to the macros. That's why you get such long > winded LaTeX output. I wonder again whether appropriately designed environments might not prove more elegant for handling this. Anyway, thank you for the explanations. I am understanding better the considerations. Cheers, Alan Isaac |
From: Mikolaj M. <mi...@wp...> - 2005-10-26 07:14:26
|
Felix Wiemann scripsit: > Alan G Isaac wrote: > >> Felix Wiemann wrote: >> >>> If they want flexibility, power, and robustness, it is. >>> If they want well-readable LaTeX output, it's not. >> >> I hope you will say something that will help me understand this. I >> have a couple decades of experience as a LaTeX user, and I have never >> seen these two aspects to be in conflict. > > These aren't in conflict when you write LaTeX code manually because you > immediately see it when you did something wrong and can just fix it. > However, for software generating LaTeX code it is necessary to include > escaping mechanisms for a lot of cases. > > As a simple example, the LaTeX writer must make sure that consecutive > dashes ("--") aren't interpreted as en or em dash. The old LaTeX writer > protects such dashes by inserting empty braces ("-{}-"). The new LaTeX > writer uses a catch-all approach by brace-surrounding *any* character > that could possibly interact with its environment, thus leading to > "{-}{-}" in this case. This means that I'm *sure* that no character > will interact with any other character. For the old LaTeX writer, we've > had several character-related problems (like "[" at beginning of line), > and I'm by no means able to verify that there aren't any other problems. For this particular thing (and few other) better solution would be use of another newcommand. In that way user could easily redefine how -- will be treated:: \newcommand{\dhyph}{{-}{-}} m. -- LaTeX + Vim = http://vim-latex.sourceforge.net/ Vim Universal Templates: http://vim.sf.net/script.php?script_id=1078 vim.pl - http://skawina.eu.org/mikolaj CLEWN - http://clewn.sf.net |
From: Marc 'B. R. <ma...@ri...> - 2005-10-27 21:10:36
|
On Wednesday 26 October 2005 00:52, Felix Wiemann wrote: > As a simple example, the LaTeX writer must make sure that consecutive > dashes ("--") aren't interpreted as en or em dash. The old LaTeX > writer protects such dashes by inserting empty braces ("-{}-"). The > new LaTeX writer uses a catch-all approach by brace-surrounding *any* > character that could possibly interact with its environment, thus > leading to "{-}{-}" in this case. This means that I'm *sure* that no > character will interact with any other character. While I understand the motivation I still think it's a pity to loose=20 "free" ligatures this way. And I'm not sure what impact the difference between "a word" and "a=20 bunch of characters" makes for the layout engine. Does LaTeX still=20 know that "{f}{i}{s}{h}" is a word, or is it just a bunch of characters=20 with no spaces inbetween? Ciao, Marc 'BlackJack' Rintsch =2D-=20 I'm not a complete idiot - several parts are missing. |
From: Alan G I. <ai...@am...> - 2005-10-28 00:23:41
|
On Thu, 27 Oct 2005, Marc 'BlackJack' Rintsch apparently wrote:=20 > While I understand the motivation I still think it's=20 > a pity to loose "free" ligatures this way.=20 I agree for -- and ---, but the developers have never agreed. Their advice: use real en and em dashes. > And I'm not sure what impact the difference between "a=20 > word" and "a bunch of characters" makes for the layout=20 > engine. Does LaTeX still know that "{f}{i}{s}{h}" is=20 > a word, or is it just a bunch of characters with no spaces=20 > inbetween?=20 It's a word: ligatures arrive. But {-}{-} is different from -- In any case, the writer is not giving us {f}{i}{s}{h}. Cheers, Alan Isaac |
From: Marc 'B. R. <ma...@ri...> - 2005-10-29 19:29:26
|
On Friday 28 October 2005 02:27, Alan G Isaac wrote: > > And I'm not sure what impact the difference between "a > > word" and "a bunch of characters" makes for the layout > > engine. Does LaTeX still know that "{f}{i}{s}{h}" is > > a word, or is it just a bunch of characters with no spaces > > inbetween? > > It's a word: ligatures arrive. > But {-}{-} is different from -- With "{f}{i}{s}{h}" I get *fish* instead of *=EF=AC=81sh* from LaTeX. > In any case, the writer is not giving us {f}{i}{s}{h}. Ah, I missed the post with the example of `{}` just around spaces and=20 non-word characters. Sorry for the noise. Ciao, Marc 'BlackJack' Rintsch =2D-=20 =E2=80=9CA man should never be ashamed to own he has been in the wrong, which is saying, in other words, that he is wiser today than he was yesterday.=E2=80=9D -- Jonathan Swift |
From: Alan G. I. <ala...@gm...> - 2005-10-29 22:29:45
|
Marc 'BlackJack' Rintsch wrote: > With "{f}{i}{s}{h}" I get *fish* instead of *fish* from LaTeX. My eyes are clearly aging: you are quite right. Alan Isaac |