From: David A. <da...@bo...> - 2004-08-19 15:46:54
|
I have text in my documents naming a special kind of component; that text needs to be formatted sans-serif. Seems to me that I should make a curstom "special-component" interpreted text role. IIUC, I can give it an appropriate :class: option and, for HTML, set that class' formatting in the CSS (right?) What about LaTeX? Is there any way to put something in the stylesheet that will govern the formatting of a particular role? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com |
From: David G. <go...@py...> - 2004-09-05 23:19:35
Attachments:
signature.asc
|
[David Abrahams] > I have text in my documents naming a special kind of component; that > text needs to be formatted sans-serif. Seems to me that I should > make a curstom "special-component" interpreted text role. IIUC, I > can give it an appropriate :class: option and, for HTML, set that > class' formatting in the CSS (right?) Yes, correct. > What about LaTeX? Is there any way to put something in the > stylesheet that will govern the formatting of a particular role? I don't think there is, currently. It would be great if somebody added that functionality. I don't know enough about LaTeX to know how that could be done, or even *if* it could be done. -- David Goodger <http://python.net/~goodger> |
From: <eng...@ss...> - 2004-09-06 07:15:51
|
On Sun, 5 Sep 2004, David Goodger wrote: > [David Abrahams] > > I have text in my documents naming a special kind of component; that > > text needs to be formatted sans-serif. Seems to me that I should > > make a curstom "special-component" interpreted text role. IIUC, I > > can give it an appropriate :class: option and, for HTML, set that > > class' formatting in the CSS (right?) > > Yes, correct. > > > What about LaTeX? Is there any way to put something in the > > stylesheet that will govern the formatting of a particular role? > > I don't think there is, currently. It would be great if somebody > added that functionality. I don't know enough about LaTeX to know how > that could be done, or even *if* it could be done. i dont know who did it :: def visit_inline(self, node): # titlereference self.body.append( '\\docutilsrole%s{' % node.get('class')) def depart_inline(self, node): self.body.append( '}' ) this looks like some role treatment ? -- BINGO: Wie gehts Ihnen mit ...? --- Engelbert Gruber -------+ SSG Fintl,Gruber,Lassnig / A6170 Zirl Innweg 5b / Tel. ++43-5238-93535 ---+ |
From: David A. <da...@bo...> - 2004-09-07 00:27:02
|
eng...@ss... writes: > On Sun, 5 Sep 2004, David Goodger wrote: > >> [David Abrahams] >> > I have text in my documents naming a special kind of component; that >> > text needs to be formatted sans-serif. Seems to me that I should >> > make a curstom "special-component" interpreted text role. IIUC, I >> > can give it an appropriate :class: option and, for HTML, set that >> > class' formatting in the CSS (right?) >> >> Yes, correct. >> >> > What about LaTeX? Is there any way to put something in the >> > stylesheet that will govern the formatting of a particular role? >> >> I don't think there is, currently. It would be great if somebody >> added that functionality. I don't know enough about LaTeX to know how >> that could be done, or even *if* it could be done. > > i dont know who did it :: > > def visit_inline(self, node): # titlereference > self.body.append( '\\docutilsrole%s{' % node.get('class')) > > def depart_inline(self, node): > self.body.append( '}' ) > > this looks like some role treatment ? 'twas I, with your permission. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com |
From: David G. <go...@py...> - 2004-09-06 12:49:23
Attachments:
signature.asc
|
[eng...@ss...] > i dont know who did it :: > > def visit_inline(self, node): # titlereference > self.body.append( '\\docutilsrole%s{' % node.get('class')) > > def depart_inline(self, node): > self.body.append( '}' ) > > this looks like some role treatment ? Right, I remember now. That's what I get for neglecting email for so long. Sorry for the confusion. That works for custom interpreted text roles that don't modify an existing inline element, but it doesn't help in the general case, such as:: .. class:: special This is an ordinary paragraph, which will now have a ``class="special"`` attribute. That's still a worthwhile goal to aspire to. -- David Goodger <http://python.net/~goodger> |
From: <eng...@ss...> - 2004-09-06 14:16:44
|
On Mon, 6 Sep 2004, David Goodger wrote: > [eng...@ss...] > > i dont know who did it :: > > > > def visit_inline(self, node): # titlereference > > self.body.append( '\\docutilsrole%s{' % node.get('class')) > > > > def depart_inline(self, node): > > self.body.append( '}' ) > > > > this looks like some role treatment ? > > Right, I remember now. That's what I get for neglecting email for > so long. Sorry for the confusion. > > That works for custom interpreted text roles that don't modify an > existing inline element, but it doesn't help in the general case, > such as:: but for the customroles in pythondoc generator we need a way to specify the names i.e. now we would get \docutilsrolemethod for role (class) "method" but the python documentation would need \method. > .. class:: special > > This is an ordinary paragraph, which will now > have a ``class="special"`` attribute. > > That's still a worthwhile goal to aspire to. but it would mean to check on every construct if the class is set or does not have the default value, would be something like xml to latex converter. although i would add support for special cases if need arises, the general solution for some future problem is not for me. -- BINGO: conveniently integrate economically sound technology --- Engelbert Gruber -------+ SSG Fintl,Gruber,Lassnig / A6170 Zirl Innweg 5b / Tel. ++43-5238-93535 ---+ |
From: Felix W. <Fel...@gm...> - 2004-09-11 22:57:31
|
David Abrahams wrote: > What about LaTeX? Is there any way to put something in the > stylesheet that will govern the formatting of a particular role? I just added --call-class-command: ------------------------------------------------------------------------ ~/tmp $ cat stylesheet.tex \renewcommand{\docutilsclass}[2]{% \ifthenelse{\equal{#1}{method}}% {<METHOD>#2</METHOD>}% {#2}% } ~/tmp $ cat roles.txt .. role:: method(literal) This is an example: :method:`foo(x, y, z)`. ~/tmp $ rst2latex.py --call-class-command --stylesheet=stylesheet.tex roles.txt roles.tex ------------------------------------------------------------------------ If you render roles.tex, you see that "foo(x, y, z)" appears as "<METHOD>foo(x, y, z)</METHOD>". Please don't rely on the existence of --call-class-command and \docutilsclass yet. It hasn't been discussed and it is untested and undocumented. It's just there for testing and can be removed or changed at any time. I'd appreciate some feedback about this option. David Goodger, do you think the dispatch_ methods in nodes.py are OK? If yes, I'll update the docstrings. Cc to Greg Ward, because it's probably of some interest for his Python-documentation writer. -- When replying to my email address, please ensure that the mail header contains 'Felix Wiemann'. http://www.ososo.de/ |
From: David G. <go...@py...> - 2004-09-12 04:19:34
Attachments:
signature.asc
|
[Felix Wiemann] > David Goodger, do you think the dispatch_ methods in nodes.py are > OK? No, I don't. I don't understand why they were added or what they're for. Why is the logic of the tree traversal being downloaded into the Visitor class? They're separate on purpose. Plus, the dispatch_* methods add an extra layer of method calls, slowing things down for the general case. Not that Docutils cares much about speed, but this seems to penalize every Visitor for the sake of one. Also, the debug output is much less useful now (it no longer says which of visit_x or unknown_visit is called). I think I see your intent now (a brief explanation would have helped). Was it to add a hook so the LaTeX writer could perform work on every visit_* and depart_* call? You should be able to do that with a GenericNodeVisitor (or a variation), without having to modify nodes.py at all. I don't think nodes.py should have been modified in this case, at least not without some discussion first. The tree traversal logic should not have been moved. Please revert the change. -- David Goodger <http://python.net/~goodger> |
From: Felix W. <Fel...@gm...> - 2004-09-12 14:54:01
|
David Goodger wrote: > Felix Wiemann wrote: > >> David Goodger, do you think the dispatch_ methods in nodes.py are OK? > > No, I don't. > > I don't understand why they were added or what they're for. Oh, sorry. Lack of communication again. I added them in order to be able to plug in arbitrary hooks on node-visiting and node-departing (see below). > Why is the logic of the tree traversal being downloaded into the > Visitor class? It's not the traversal logic which has been moved but just the mapping of node-class-name to the method to be called. The implementation of the dispatch methods is two lines each, so there's indeed not very much logic. > Plus, the dispatch_* methods add an extra layer of method calls, > slowing things down for the general case. No, not really: ~/source/docutils/docutils/docutils $ cvs up -j HEAD -j 1.56 nodes.py RCS file: /cvsroot/docutils/docutils/docutils/nodes.py,v retrieving revision 1.58 retrieving revision 1.56 Merging differences between 1.58 and 1.56 into nodes.py ~/source/docutils/docutils/docutils $ time rst2html.py ~/source/docutils/docutils/docs/user/rst/demo.txt &> /dev/null real 0m4.658s user 0m4.640s sys 0m0.020s ~/source/docutils/docutils/docutils $ cvs up -j 1.56 -j HEAD nodes.py M nodes.py RCS file: /cvsroot/docutils/docutils/docutils/nodes.py,v retrieving revision 1.56 retrieving revision 1.58 Merging differences between 1.56 and 1.58 into nodes.py ~/source/docutils/docutils/docutils $ time rst2html.py ~/source/docutils/docutils/docs/user/rst/demo.txt &> /dev/null real 0m4.700s user 0m4.650s sys 0m0.040s So it's approx. 1% difference. > Also, the debug output is much less useful now (it no longer says > which of visit_x or unknown_visit is called). In rev. 1.57 it didn't say which one of visit_* or depart_* was called, which I just fixed (rev. 1.58). However, it didn't say before if visit_x or unknown_visit is called, if I'm not misinterpreting the lines of rev. 1.56:: name = 'visit_' + self.__class__.__name__ method = getattr(visitor, name, visitor.unknown_visit) visitor.document.reporter.debug(name, category='nodes.Node.walk') So name == 'visit_x', regardless of whether visit_x exists or if unknown_visit is chosen. > I think I see your intent now (a brief explanation would have helped). Yes, sorry. > Was it to add a hook so the LaTeX writer could perform work on every > visit_* and depart_* call? Exactly. > You should be able to do that with a GenericNodeVisitor (or a > variation), without having to modify nodes.py at all. I don't see any elegant way to implement the same functionality using the GenericNodeVisitor. The problem is that default_visit and default_departure are only called if the node-class specific visit/depart method does *not* exist. However, for all(?) nodes, there are according visit/depart methods in the LaTeX translator. So what would have to be done is writing a GenericNodeVisitor which wraps around the normal LaTeX-visitor, just in order to implement the \docutilsclass functionality. This isn't elegant at all, IMO. On the other hand, I don't find it illogical for a visitor class to resolve names (i.e. strings) to methods on its own. > I don't think nodes.py should have been modified in this case, at > least not without some discussion first. I just modified it because it didn't change Docutils' behavior, and it's easier to discuss if there is an existing implementation. And I needed it for an example implementation of \docutilsclass. > Please revert the change. I didn't do that yet, because I think you might be convinced after reading my explanations on logic-move/speed/debug-output. If you aren't, feel free to revert nodes.py to revision 1.56. -- When replying to my email address, please ensure that the mail header contains 'Felix Wiemann'. http://www.ososo.de/ |
From: Felix W. <Fel...@gm...> - 2004-09-15 18:48:10
|
Felix Wiemann wrote: > I just added --call-class-command: Does anyone have any use for this? If yes, I'd add docs and tests. If not, I'd just rip it out and re-add it if there is some real demand. Do you think the way it's realized (naming and such) is all right? Or should something be changed? -- When replying to my email address, please ensure that the mail header contains 'Felix Wiemann'. http://www.ososo.de/ |
From: David G. <go...@py...> - 2004-09-12 21:45:03
Attachments:
signature.asc
|
[David Goodger] >> Plus, the dispatch_* methods add an extra layer of method calls, >> slowing things down for the general case. [Felix Wiemann] > No, not really: ... > So it's approx. 1% difference. Yes, if that. My timing tests were inconclusive; any difference was less than experimental error. >> Also, the debug output is much less useful now (it no longer says >> which of visit_x or unknown_visit is called). > > In rev. 1.57 it didn't say which one of visit_* or depart_* was > called, which I just fixed (rev. 1.58). Thanks. > However, it didn't say before if visit_x or unknown_visit is called, > if I'm not misinterpreting the lines of rev. 1.56:: ... > So name == 'visit_x', regardless of whether visit_x exists or if > unknown_visit is chosen. You weren't misinterpreting. I've fixed that now. >> You should be able to do that with a GenericNodeVisitor (or a >> variation), without having to modify nodes.py at all. > > I don't see any elegant way to implement the same functionality > using the GenericNodeVisitor. The problem is that default_visit and > default_departure are only called if the node-class specific > visit/depart method does *not* exist. However, for all(?) nodes, > there are according visit/depart methods in the LaTeX translator. > So what would have to be done is writing a GenericNodeVisitor which > wraps around the normal LaTeX-visitor, just in order to implement > the \docutilsclass functionality. Yes, that's what I was thinking. When I saw the checkin messages, it seemed to be splitting up the algorithm and adding a lot of work for a special case. But now I see that I was mistaken. Thanks for your explanation. > This isn't elegant at all, IMO. I can see how the hook may be generally useful, so I agree. I've cleaned up the debugging and parameters a bit. -- David Goodger <http://python.net/~goodger> |