From: Guenter M. <mi...@us...> - 2012-11-22 13:43:16
|
On 2012-11-22, Kirill Smelkov wrote: > On Wed, Nov 21, 2012 at 03:49:29PM +0000, Guenter Milde wrote: Dear Kirill, >> >> I agree that support for class arguments in LaTeX can/should be extended >> >> to include more useful cases. Docutils already adds a mechanism with the >> >> ``DUrole`` command, which could be employed here. >> >> Suggestion: handle class arguments for bullet lists similar to >> >> block-quotes: >> >> +1 simple, >> >> +1 applicable to other elements without inflating latex2e/__init__.py >> >> nor the generated LaTeX source. >> ... >> > Thanks for thorough reply. However I feel that reusing DUrole for >> > handling classes would be inflexible, because when DUrole<class> is in >> > effect we already are in an environment (itemize in your example) and in >> > general case one may want to use different environments for different >> > classes. That is not artificial - I've already had to use my own >> > environment instead of description for customized fieldlists. >> This could be remedied by wrapping \DUrole around the environment:: >> \DUrole{compact}{ >> \begin{itemize} >> \item item 1 >> \item item 2 >> \item item 3 >> \end{itemize} >> } > Imho no, this won't work. ... > This is related to how latex environments work - either you set > it's settings inside, or you should know the nesting level and set > itemsep<level> and parskip<level> etc, which is not elegantly possible > for general wrapper ... I recommend the very nice enumitem_ package for list customization. It's comprehensive documentation reveals that the example problem could be solved via "global settings" where the level-argument is optional :: \documentclass[]{article} \usepackage{lmodern} \usepackage[T1]{fontenc} \usepackage{enumitem} \begin{document} Compact: { \setlist[itemize]{noitemsep} \small% \begin{itemize} \item item 1 \item item 2 \end{itemize} } Back to normal: \begin{itemize} \item item 1 \item item 2 \end{itemize} \end{document} .. _enumitem: http://mirror.ctan.org/help/Catalogue/entries/enumitem.html > Besides, we are hardcoding used environment in stone. Yes, if there is a matching standard environment (or macro), we are using it. IMO this is "the right thing". It provides widely compatible, clean LaTeX files and allows styling with the established LaTeX tools. A stylesheet can even save the original environment or macro to an alias and overwrite the definition with a custom version. > I think the consensus here could be as follows: > 1. \DUenv[class] looks for \DUenvclass, and uses it if found. > 2. if not, fallback environment is used (itemize for DUitemize) with > your \DUclass[class] inside it (sorry, I've missed it in a hurry > on the first read), e.g. ... > What do you think? -1 too complicated. -1 inflating latex2e/__init__.py and the generated LaTeX source. -1 custom macros are cumbersome when hand-editing the LaTeX source or converting it to other source formats. > ( And also, using DUrole for styling classes could come into confilict > with using roles in the document itself, e.g. as in :compact:`text` ) It would be up to the user to ensure that "DUrole..." macros do not interfere. Class arguments and custom styles are advanced stuff, so, IMO, we are not demanding too much. Considering that "compact" is already established in the HTML writer, a different name could be used for the role. In other cases, a class argument like "compactlist" or similar can be used. Also mind, that, e.g. :: \newcommand{\DUrolesmall}[1]{% {\setlist[itemize]{noitemsep}\small#1}% } would work as expected in both, a "small" bullet-list and a :small:`role`. >> > I'm also proposing we next convert all direct usage of TeX environments >> > to DUsomething classed dispatch step-by-step. >> This blows up the latex source and makes it hard to convert to anything >> except DVI or PDF. (Think about import to LyX or OpenOffice, e.g.) as well >> as working on Docutils-generated LaTeX source. > This blows up only preamble, which we are maybe better move to separate > static file, and add an option for rst2latex to whether embed it or not > into generated tex source, just like html writer does with > --embed-stylesheet. This is a separate TODO item: Move the preamble code to a LaTeX package (which should also be uploaded to CTAN) and provide an "embed-stylesheet" setting with possible values: yes, no, and subset (where subset is basically the current behaviour). > The document text itself is not blown up, and still remains structured. > I see no problem importing it to anywhere, without embedded preamble. > Yes, importers should be taught about what used DUenv means, but we > already have to do it, because for example we already use > \begin{DUfieldlist} ... \end{DUfiledlist}. I'd rather get rid of DUfieldlist... Thanks, Günter |