From: Jason D. <ja...@in...> - 2003-05-16 05:27:15
|
Is it possible to configure one of the components in docutils to *not* treat the first two titles as the document title and subtitle? I've extended the html4css1.Writer class to not output them but then realized that I was doing this in the wrong place. I don't just want to omit them from the output, I want them to be treated like normal section titles. I started looking through the parser/statemachine code to see if that's what I'm looking for but it's going to take me a while to start digesting that. Thanks for any help or pointers in the right direction, Jason |
From: David G. <go...@py...> - 2003-05-16 22:24:14
|
Jason Diamond wrote: > Is it possible to configure one of the components in docutils to *not* > treat the first two titles as the document title and subtitle? The place to look is in the transforms. docutils.transforms.frontmatter.DocTitle to be precise. This has been in the to-do list for some time: Standalone Reader: Implement an option to turn off the DocTitle transform? A patch would be welcome. See the source code, <http://docutils.sf.net/spec/transforms.html>, and <http://docutils.sf.net/spec/rst/reStructuredText.html#document> for details. -- David Goodger http://starship.python.net/~goodger Programmer/sysadmin for hire: http://starship.python.net/~goodger/cv |
From: Mark N. <no...@so...> - 2003-05-19 14:46:40
|
David Goodger wrote: > > Jason Diamond wrote: > > Is it possible to configure one of the components in docutils to *not* > > treat the first two titles as the document title and subtitle? > > The place to look is in the transforms. > docutils.transforms.frontmatter.DocTitle to be precise. > > This has been in the to-do list for some time: > > Standalone Reader: Implement an option to turn off the DocTitle > transform? The Perl version of the reStructuredText parser has an option to bypass selected transforms (e.g., docutils.transforms.frontmatter.DocTitle). For compatibility, I gave the transforms the same names as in docutils. --Mark |
From: David G. <go...@py...> - 2003-05-19 15:30:03
|
Mark Nodine wrote: > The Perl version of the reStructuredText parser has an option to bypass > selected transforms (e.g., docutils.transforms.frontmatter.DocTitle). > For compatibility, I gave the transforms the same names as in docutils. What is the mechanism? Does each transform have its own command-line option, or is there a generic "--bypass-transform" option? When can we get access to this code? -- David Goodger |
From: Mark N. <no...@so...> - 2003-05-19 19:28:49
|
David Goodger wrote: > > Mark Nodine wrote: > > The Perl version of the reStructuredText parser has an option to bypass > > selected transforms (e.g., docutils.transforms.frontmatter.DocTitle). > > For compatibility, I gave the transforms the same names as in docutils. > > What is the mechanism? Does each transform have its own command-line > option, or is there a generic "--bypass-transform" option? The latter. -D xformoff=<regexp> Turns off default transforms matching regexp. (Used for internal testing.) > When can we get access to this code? The main barrier is getting permission from Motorola Legal to post it. The secondary barrier is that I noticed for some reason it does not pass all the regression tests on OS X, though it works on Solaris and Linux. We've been using it quite successfully internally, so I think we're about ready to approach Legal. --Mark |
From: <gr...@us...> - 2003-05-20 07:08:31
|
How to disable DocTitle transforming ==================================== :Author: Report from the FPI [#]_. :Usage: Internal only. Investigation ------------- Classes derived of readers.Reader can override the empty list (class variable) default_transforms. e.g. the standalone-reader class defines:: default_transforms = (references.Substitutions, frontmatter.DocTitle, frontmatter.DocInfo, references.ChainedTargets, references.AnonymousHyperlinks, references.IndirectHyperlinks, references.Footnotes, references.ExternalTargets, references.InternalTargets,) class Publisher calls apply_transforms after readers.read. apply_transforms calls:: document.transformer.populate_from_components( (self.source, self.reader, self.reader.parser, self.writer, self.destination)) which calls self.add_transforms(self.default_transforms), self being the Transformer class and for each of the entries in the passed list, self.source, self.reader, ... To disable a transform we must get in the way of this mechanism. How to ? -------- a. Disable/remove an entry from class.default_transforms. Might need to specify the class and the transform. b. Disable the transform itself, by a list settings.donot_transforms and let the classes check if they are listed. c. Or let Transformer.apply_transforms check settings.donot_transforms before calling a transform. Problems -------- * How to know the name of a transform ? Is the classname ok, or should one classify the transforms i.e. a transform has a role which could be filled by some python-classes. * How to a. needs more specification: class/role and transform, but is more specific. * b. might be acceptable if the transform class has __role__ set and a generic routine in the baseclass checks for ... but even then i dislike that transforms know about settings. Cheers .. [#] Fine Python Investigator -- BINGO: innovative solutions --- Engelbert Gruber -------+ SSG Fintl,Gruber,Lassnig / A6170 Zirl Innweg 5b / Tel. ++43-5238-93535 ---+ |
From: David G. <go...@py...> - 2003-05-23 02:51:21
|
gr...@us... wrote: > How to ? > -------- > > a. Disable/remove an entry from class.default_transforms. > Might need to specify the class and the transform. > > b. Disable the transform itself, by a list settings.donot_transforms > and let the classes check if they are listed. > > c. Or let Transformer.apply_transforms check > settings.donot_transforms before calling a transform. If we want to implement a general-purpose transform-suppression mechanism, I think something like (c) is the way to go. However, I don't know if we need such a general-purpose mechanism. In the meantime, it would be easier for each transform to check its own applicability. I'd suggest "--no-doc-title" and "--no-doc-info" options to start. (BTW, "donot" is not a word. "Don't" is a word, a contraction of the words "do not". "Donut" is a simplification of the word "doughnut". Whenever you write "donot", I first see "donut" before realizing you mean "do not". If you want to stay slim, do not be a donut eater. :-) > Problems > -------- > > * How to know the name of a transform ? Is the classname ok, or > should one classify the transforms i.e. a transform has a role > which could be filled by some python-classes. If a general-purpose mechanism is needed, I think the class itself, or the class name (perhaps 'module.Class') would be sufficient. Let's wait and see. I don't think such a mechanism is needed yet. -- David Goodger http://starship.python.net/~goodger Programmer/sysadmin for hire: http://starship.python.net/~goodger/cv |
From: <gr...@us...> - 2003-05-26 07:52:42
|
On Thu, 22 May 2003, David Goodger wrote: > gr...@us... wrote: > > How to ? > > -------- > > > > a. Disable/remove an entry from class.default_transforms. > > Might need to specify the class and the transform. > > > > b. Disable the transform itself, by a list settings.donot_transforms > > and let the classes check if they are listed. > > > > c. Or let Transformer.apply_transforms check > > settings.donot_transforms before calling a transform. > > If we want to implement a general-purpose transform-suppression > mechanism, I think something like (c) is the way to go. > > However, I don't know if we need such a general-purpose mechanism. In > the meantime, it would be easier for each transform to check its own > applicability. I'd suggest "--no-doc-title" and "--no-doc-info" > options to start. Problem ------- transforms have no settings_spec: Publisher.setup_option_parser calls OptionParser( and passes components(settings_spec, self.parser, self.reader, self.writer) OptionParser gets settings_spec from the passed components. I dunno like to pass every transform in components, because there is only one reader and one writer but there might be several transforms. -- BINGO: high-performance breakthrough --- Engelbert Gruber -------+ SSG Fintl,Gruber,Lassnig / A6170 Zirl Innweg 5b / Tel. ++43-5238-93535 ---+ |
From: David G. <go...@py...> - 2003-05-27 02:38:51
|
gr...@us... wrote: > Problem > ------- > > transforms have no settings_spec: True. Transforms may be chosen/specified late in processing, well after startup. Therefore they cannot be anticipated for command-line processing. The component that controls or specifies a transform should handle any transform-specific settings. > Publisher.setup_option_parser calls OptionParser( and passes > components(settings_spec, self.parser, self.reader, self.writer) > > OptionParser gets settings_spec from the passed components. > > I dunno like to pass every transform in components, because there > is only one reader and one writer but there might be several > transforms. I don't understand the last sentence. -- David Goodger |
From: <gr...@us...> - 2003-05-27 06:52:01
|
new commandline options --no-doc-info --no-doc-title, for the standalone reader. details below On Mon, 26 May 2003, David Goodger wrote: > gr...@us... wrote: > > Problem > > ------- > > > > transforms have no settings_spec: > > True. Transforms may be chosen/specified late in processing, well after > startup. Therefore they cannot be anticipated for command-line > processing. The component that controls or specifies a transform should > handle any transform-specific settings. > > > Publisher.setup_option_parser calls OptionParser( and passes > > components(settings_spec, self.parser, self.reader, self.writer) > > > > OptionParser gets settings_spec from the passed components. > > > > I dunno like to pass every transform in components, because there > > is only one reader and one writer but there might be several > > transforms. > > I don't understand the last sentence. In my understanding of the commandline options are specified to OptionParser in Publisher.setup_option_parser, by passing a list of components. The components currently consist of : * self.parser, self.reader, self.writer * and settings_spec are passed from the Publisher creation, means this could be done from the tool. Disabling the doctitle transform is a general option, so it makes no sense (to me) if it is defined in a tool. The transforms are defined in the list default_transforms e.g. class Reader:: default_transforms = (references.Substitutions, frontmatter.DocTitle, frontmatter.DocInfo, references.ChainedTargets, references.AnonymousHyperlinks, references.IndirectHyperlinks, references.Footnotes, references.ExternalTargets, references.InternalTargets,) i did put the option into readers/standalone.py BUT if one uses the transform without this reader the setting wont be defined and the transform would crahs on testing for the setting. so i test with getattr. and i had no success packing this into a test. how to pass the settings in tests ? -- BINGO: Testing! Testing! Testing! Testing! This is your nine o'clock alarm call! --- Engelbert Gruber -------+ SSG Fintl,Gruber,Lassnig / A6170 Zirl Innweg 5b / Tel. ++43-5238-93535 ---+ |
From: <u_s...@bl...> - 2003-05-27 17:05:21
|
Hi all, attached is my own quick hack at preventing the frontmatter transforms. I had the same need a few weeks ago; this is what I came up with [1]_. It works, but it's not pretty (I didn't invest much effort in trying to find a future-proof and extensible solution). Also, the code did not pass three of the unit tests (those are related to the latex writer -- I don't see a connection to my code, see attachment), and obviously any unit tests for the code are missing. Greetings, Ueli .. [1] David, Jason -- I sent an email similar to you about a week ago. As I had no echo at all, I assume it got lost somewhere, hence a new attempt. Sorry if I bother you for the second time! >-- Original-Nachricht -- >From: gr...@us... >To: docutils-develop <doc...@li...> >Cc: ja...@in... >Subject: Re: [Docutils-develop] Preventing Document Title and Subtitles >Date: Tue, 27 May 2003 08:57:34 +0200 (CEST) > > >new commandline options --no-doc-info --no-doc-title, for the standalone >reader. >details below > >On Mon, 26 May 2003, David Goodger wrote: > >> gr...@us... wrote: >> > Problem >> > ------- >> > >> > transforms have no settings_spec: >> >> True. Transforms may be chosen/specified late in processing, well after >> startup. Therefore they cannot be anticipated for command-line >> processing. The component that controls or specifies a transform should >> handle any transform-specific settings. >> >> > Publisher.setup_option_parser calls OptionParser( and passes >> > components(settings_spec, self.parser, self.reader, self.writer) >> > >> > OptionParser gets settings_spec from the passed components. >> > >> > I dunno like to pass every transform in components, because there >> > is only one reader and one writer but there might be several >> > transforms. >> >> I don't understand the last sentence. > >In my understanding of the commandline options are specified to OptionParser >in Publisher.setup_option_parser, by passing a list of components. The >components currently consist of : > >* self.parser, self.reader, self.writer >* and settings_spec are passed from the Publisher creation, means this could >be > done from the tool. > >Disabling the doctitle transform is a general option, so it makes no sense >(to me) if it is defined in a tool. > >The transforms are defined in the list default_transforms e.g. class Reader:: > > default_transforms = (references.Substitutions, > frontmatter.DocTitle, > frontmatter.DocInfo, > references.ChainedTargets, > references.AnonymousHyperlinks, > references.IndirectHyperlinks, > references.Footnotes, > references.ExternalTargets, > references.InternalTargets,) > >i did put the option into readers/standalone.py BUT if one uses the transform >without this reader the setting wont be defined and the transform would crahs >on testing for the setting. so i test with getattr. > >and i had no success packing this into a test. how to pass the settings in >tests ? > > > >-- > BINGO: Testing! Testing! Testing! Testing! This is your nine o'clock alarm >call! > --- Engelbert Gruber -------+ > SSG Fintl,Gruber,Lassnig / > A6170 Zirl Innweg 5b / > Tel. ++43-5238-93535 ---+ > > >------------------------------------------------------- >This SF.net email is sponsored by: ObjectStore. >If flattening out C++ or Java code to make your application fit in a >relational database is painful, don't do it! Check out ObjectStore. >Now part of Progress Software. http://www.objectstore.net/sourceforge >_______________________________________________ >Docutils-develop mailing list >Doc...@li... >https://lists.sourceforge.net/lists/listinfo/docutils-develop |
From: David G. <go...@py...> - 2003-05-27 18:35:09
|
Ueli Schlaepfer wrote: > attached is my own quick hack at preventing the frontmatter > transforms. Thanks. Engelbert's checkins to docutils/readers/standalone.py and docutils/transforms/frontmatter.py yesterday do a good job of it. > .. [1] David, Jason -- I sent an email similar to you about a week > ago. As I had no echo at all, I assume it got lost > somewhere, hence a new attempt. Not lost, just haven't had time to reply yet, sorry. I give higher priority to mailing list messages, since they're public. Public messages also generate discussion. Hint, hint. :-) > Also, the code did not pass three of the unit tests (those are > related to the latex writer -- I don't see a connection to my code, > see attachment), That was not related to your patch. From the Bugs list: Configuration files (~/.docutils or /etc/docutils.conf or test/docutils.conf) affect any test suites that use docutils.core.Publisher (test/test_writers). For example, setting the default language causes changes in the output. (Reported by Ludger Humbert.) -- <http://docutils.sf.net/spec/notes.html#bugs> The LaTeX Writer tests use the full Docutils Publisher mechanism, including configuration files. You must have a configuration file in your home directory or /etc that affects the test. -- David Goodger http://starship.python.net/~goodger Programmer/sysadmin for hire: http://starship.python.net/~goodger/cv |
From: <eng...@ss...> - 2003-05-28 07:51:39
|
On Tue, 27 May 2003, David Goodger wrote: > Ueli Schlaepfer wrote: > > attached is my own quick hack at preventing the frontmatter > > transforms. > > Thanks. Engelbert's checkins to docutils/readers/standalone.py and > docutils/transforms/frontmatter.py yesterday do a good job of it. But ueli's patch could be better, because it is not in the reader, but the frontend, so the option is available for all readers. is this correct ? by adding a enable_name = "doc_info" to transforms we could test generic in transform/__init__.py. BUT: then we might need to add the enabler/disabler to the option list ... needs more thinking > The LaTeX Writer tests use the full Docutils Publisher mechanism, > including configuration files. You must have a configuration file in > your home directory or /etc that affects the test. this needs a fix, but even my postings to the list (wink wink), about should the test test all or only the interface and how to test option combinations, never had any success, not even ignored i'd say :-) -- BINGO: Einpflegen --- Engelbert Gruber -------+ SSG Fintl,Gruber,Lassnig / A6170 Zirl Innweg 5b / Tel. ++43-5238-93535 ---+ |
From: David G. <go...@py...> - 2003-05-28 18:19:29
|
[David Goodger] >> Thanks. Engelbert's checkins to docutils/readers/standalone.py and >> docutils/transforms/frontmatter.py yesterday do a good job of it. [Engelbert Gruber] > But ueli's patch could be better, because it is not in the reader, > but the frontend, so the option is available for all readers. is > this correct ? Only the Standalone Reader applies the DocTitle and DocInfo transforms, so putting this setting in docutils.readers.standalone is correct. > by adding a enable_name = "doc_info" to transforms we could > test generic in transform/__init__.py. > > BUT: then we might need to add the enabler/disabler to the option > list ... > > needs more thinking I don't follow. *Please* give examples -- David Goodger |
From: David G. <go...@py...> - 2003-05-29 15:31:27
|
I have revised the internal implementation of the new --no-doc-title and --no-doc-info command line options. This affects config file settings (old: no_doc_title and no_doc_info; new: doctitle_xform and docinfo_xform). -- David Goodger |