You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
(15) |
Oct
(21) |
Nov
(18) |
Dec
(59) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(43) |
Feb
(35) |
Mar
(78) |
Apr
(65) |
May
(163) |
Jun
(169) |
Jul
(137) |
Aug
(77) |
Sep
(47) |
Oct
(27) |
Nov
(43) |
Dec
(68) |
2004 |
Jan
(61) |
Feb
(39) |
Mar
(11) |
Apr
(42) |
May
(86) |
Jun
(82) |
Jul
(24) |
Aug
(26) |
Sep
(37) |
Oct
(62) |
Nov
(131) |
Dec
(43) |
2005 |
Jan
(31) |
Feb
(56) |
Mar
(65) |
Apr
(165) |
May
(106) |
Jun
(97) |
Jul
(65) |
Aug
(150) |
Sep
(78) |
Oct
(115) |
Nov
(41) |
Dec
(26) |
2006 |
Jan
(50) |
Feb
(39) |
Mar
(56) |
Apr
(67) |
May
(89) |
Jun
(68) |
Jul
(116) |
Aug
(65) |
Sep
(58) |
Oct
(103) |
Nov
(28) |
Dec
(52) |
2007 |
Jan
(92) |
Feb
(60) |
Mar
(124) |
Apr
(96) |
May
(69) |
Jun
(79) |
Jul
(25) |
Aug
(22) |
Sep
(7) |
Oct
(17) |
Nov
(27) |
Dec
(32) |
2008 |
Jan
(57) |
Feb
(87) |
Mar
(51) |
Apr
(43) |
May
(56) |
Jun
(62) |
Jul
(25) |
Aug
(82) |
Sep
(58) |
Oct
(42) |
Nov
(38) |
Dec
(86) |
2009 |
Jan
(50) |
Feb
(33) |
Mar
(84) |
Apr
(90) |
May
(109) |
Jun
(37) |
Jul
(22) |
Aug
(51) |
Sep
(93) |
Oct
(86) |
Nov
(31) |
Dec
(62) |
2010 |
Jan
(33) |
Feb
(57) |
Mar
(62) |
Apr
(43) |
May
(30) |
Jun
(49) |
Jul
(20) |
Aug
(40) |
Sep
(152) |
Oct
(38) |
Nov
(15) |
Dec
(32) |
2011 |
Jan
(29) |
Feb
(25) |
Mar
(65) |
Apr
(45) |
May
(27) |
Jun
(11) |
Jul
(14) |
Aug
(8) |
Sep
(13) |
Oct
(117) |
Nov
(60) |
Dec
(19) |
2012 |
Jan
(23) |
Feb
(32) |
Mar
(24) |
Apr
(41) |
May
(56) |
Jun
(24) |
Jul
(15) |
Aug
(11) |
Sep
(26) |
Oct
(21) |
Nov
(12) |
Dec
(31) |
2013 |
Jan
(32) |
Feb
(24) |
Mar
(39) |
Apr
(44) |
May
(44) |
Jun
(8) |
Jul
(9) |
Aug
(12) |
Sep
(34) |
Oct
(19) |
Nov
(5) |
Dec
(9) |
2014 |
Jan
(22) |
Feb
(12) |
Mar
(7) |
Apr
(2) |
May
(13) |
Jun
(17) |
Jul
(8) |
Aug
(10) |
Sep
(7) |
Oct
(4) |
Nov
|
Dec
(39) |
2015 |
Jan
(13) |
Feb
(12) |
Mar
(12) |
Apr
(40) |
May
(5) |
Jun
(22) |
Jul
(3) |
Aug
(42) |
Sep
(5) |
Oct
(10) |
Nov
|
Dec
(10) |
2016 |
Jan
(9) |
Feb
(43) |
Mar
(5) |
Apr
(14) |
May
(17) |
Jun
(5) |
Jul
(5) |
Aug
(22) |
Sep
(5) |
Oct
|
Nov
(4) |
Dec
(18) |
2017 |
Jan
(28) |
Feb
(29) |
Mar
(9) |
Apr
(23) |
May
(48) |
Jun
(5) |
Jul
(32) |
Aug
(9) |
Sep
(13) |
Oct
(13) |
Nov
(6) |
Dec
(4) |
2018 |
Jan
(6) |
Feb
(5) |
Mar
(1) |
Apr
(2) |
May
(5) |
Jun
(17) |
Jul
(12) |
Aug
(15) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
2019 |
Jan
|
Feb
(6) |
Mar
(3) |
Apr
(5) |
May
(10) |
Jun
(6) |
Jul
(6) |
Aug
|
Sep
(11) |
Oct
(18) |
Nov
(10) |
Dec
(7) |
2020 |
Jan
(3) |
Feb
(14) |
Mar
(2) |
Apr
(1) |
May
(5) |
Jun
|
Jul
(1) |
Aug
(11) |
Sep
(8) |
Oct
|
Nov
(1) |
Dec
(14) |
2021 |
Jan
(7) |
Feb
(2) |
Mar
(1) |
Apr
(8) |
May
(23) |
Jun
(7) |
Jul
(10) |
Aug
(1) |
Sep
|
Oct
(7) |
Nov
(10) |
Dec
(2) |
2022 |
Jan
|
Feb
(21) |
Mar
|
Apr
(3) |
May
(7) |
Jun
(4) |
Jul
(1) |
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
2023 |
Jan
(18) |
Feb
|
Mar
(1) |
Apr
|
May
(9) |
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
(2) |
Mar
(3) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
(2) |
2025 |
Jan
(4) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(3) |
Jun
(6) |
Jul
(21) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: David G. <go...@py...> - 2002-12-15 05:26:18
|
Stephan R.A. Deibel wrote: > If this looks like something potentially useful for the docutils project, > please let me know and I can clean it up and contribute it. Haven't looked at the code yet, but it sounds very cool. Yes, please, and thank you! -- David Goodger go...@py... |
From: David G. <go...@py...> - 2002-12-15 05:24:20
|
David Abrahams wrote: > Thanks for your reply. When I try your workaround I still get a > grammatically incorrect apostrophe in the word "lists". Would it > break anything if you added the backslash to the list of "certain > punctuation characters"? That way, I could write ``list``\s and get > exactly the effect I want. Interesting idea. May work. I'll have to think it through. There may be adverse side-effects due to the way backslash-escapes are handled internally (they're converted to \x00 null bytes, which I've always thought was a bit of a kludge, but it's worked thus far). -- David Goodger go...@py... |
From: David A. <da...@bo...> - 2002-12-15 03:15:20
|
David Goodger <go...@py...> writes: > David Abrahams wrote: >> The following line doesn't seem to format as expected: >> >> Those bracketed expressions are Python ``list``s. A ``list`` is >> >> I just wanted the word "list" to appear twice as an inline literal, >> with the 's' following in a normal font. Is there a way to do this? > > reStructuredText's inline markup is designed to work at the phrase-level, > not at the character level. So no, you can't do it, at least not directly. > However, there is a work-around; certain punctuation characters *are* > allowed adjacent to inline markup end-strings, such as apostrophes. So you > could write it like this: > > Those bracketed expressions are Python ``list``'s. A ``list`` is > (^ note the apostrophe) > > This rule allows for text like "Use double backquotes ("``") for inline > literals." For all the gory details, see > > http://docutils.sf.net/spec/rst/reStructuredText.html#inline-markup David, Thanks for your reply. When I try your workaround I still get a grammatically incorrect apostrophe in the word "lists". Would it break anything if you added the backslash to the list of "certain punctuation characters"? That way, I could write ``list``\s and get exactly the effect I want. -- David Abrahams da...@bo... * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution |
From: Stephan R.A. D. <sd...@wi...> - 2002-12-15 02:43:15
|
From: "Patrick K. O'Brien" <po...@or...>: > I'm wondering how hard it is to create a custom writer. In particular, > one that produces a particular type of xml file. I've read all the > docutils documentation and most of the emphasis seems to be on how to > write text using RST, or what kind of HTML it produces. What I haven't > seen much of is how to use RST for a particular application. In case it helps, I managed to write my own custom writer in about a day and a half of effort without any prior knowledge of docutils. Might be useful as an example of the minimum needed to glom onto the docutils framework: ftp://wingide.com/pub/outgoing/rest_writer.tgz (http also works) This and outputs plain text (often of course close to reStructuredText) plus a list of link locations and targets. This is used to feed into a custom documentation viewer and besides is useful in outputting text that's suitable to show to people that get freaked out by __ after words and stuff like that. It works on all the examples I've tried although the tables code isn't done yet so outputs junk. If this looks like something potentially useful for the docutils project, please let me know and I can clean it up and contribute it. - Stephan ------------------------------------------------------------------------ Wing IDE for Python Archaeopteryx Software, Inc www.wingide.com Take Flight! |
From: David G. <go...@py...> - 2002-12-15 02:21:58
|
David Abrahams wrote: > The following line doesn't seem to format as expected: > > Those bracketed expressions are Python ``list``s. A ``list`` is > > I just wanted the word "list" to appear twice as an inline literal, > with the 's' following in a normal font. Is there a way to do this? reStructuredText's inline markup is designed to work at the phrase-level, not at the character level. So no, you can't do it, at least not directly. However, there is a work-around; certain punctuation characters *are* allowed adjacent to inline markup end-strings, such as apostrophes. So you could write it like this: Those bracketed expressions are Python ``list``'s. A ``list`` is (^ note the apostrophe) This rule allows for text like "Use double backquotes ("``") for inline literals." For all the gory details, see http://docutils.sf.net/spec/rst/reStructuredText.html#inline-markup -- David Goodger <go...@py...> Open-source projects: - Python Docutils: http://docutils.sourceforge.net/ (includes reStructuredText: http://docutils.sf.net/rst.html) - The Go Tools Project: http://gotools.sourceforge.net/ |
From: David A. <da...@bo...> - 2002-12-15 01:10:21
|
The following line doesn't seem to format as expected: Those bracketed expressions are Python ``list``s. A ``list`` is I just wanted the word "list" to appear twice as an inline literal, with the 's' following in a normal font. Is there a way to do this? -- David Abrahams da...@bo... * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution |
From: Patrick K. O'B. <po...@or...> - 2002-12-14 20:29:41
|
On Saturday 14 December 2002 02:14 pm, Aahz wrote: > On Sat, Dec 14, 2002, Patrick K. O'Brien wrote: > > Is it possible (within reason, not just theoretically) to reverse > > the reST publish process such that you could input an xml file and > > output a reST marked-up plaintext file? > > There is currently no mechanism to do this. As David would say, > contributions welcome. And I suppose it might not make sense to do this using Docutils, as other tools (like XSL, perhaps) are designed for this kind of thing. I just think it would be cool to take existing material and turn it into reST plaintext. But I don't have the time or energy to do this myself. -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." ----------------------------------------------- |
From: Aahz <aa...@py...> - 2002-12-14 20:14:26
|
On Sat, Dec 14, 2002, Patrick K. O'Brien wrote: > > Is it possible (within reason, not just theoretically) to reverse the > reST publish process such that you could input an xml file and output a > reST marked-up plaintext file? There is currently no mechanism to do this. As David would say, contributions welcome. -- Aahz (aa...@py...) <*> http://www.pythoncraft.com/ "To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it." --...@li... |
From: Patrick K. O'B. <po...@or...> - 2002-12-14 20:09:05
|
Is it possible (within reason, not just theoretically) to reverse the reST publish process such that you could input an xml file and output a reST marked-up plaintext file? -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." ----------------------------------------------- |
From: Patrick K. O'B. <po...@or...> - 2002-12-14 16:18:06
|
On Saturday 14 December 2002 10:10 am, David Goodger wrote: > Patrick K. O'Brien wrote: > > I'm wondering how hard it is to create a custom writer. In > > particular, one that produces a particular type of xml file. I've > > read all the docutils documentation and most of the emphasis seems > > to be on how to write text using RST, or what kind of HTML it > > produces. What I haven't seen much of is how to use RST for a > > particular application. > > A void waiting to be filled! What an opportunity for you! ;) I'm taking notes. I was going to see if I could make an article out of this effort. > There is some other information available: Thank you for all the tips and links. Looks like just what I needed. -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." ----------------------------------------------- |
From: David G. <go...@py...> - 2002-12-14 16:09:58
|
Patrick K. O'Brien wrote: > I'm wondering how hard it is to create a custom writer. In > particular, one that produces a particular type of xml file. I've > read all the docutils documentation and most of the emphasis seems > to be on how to write text using RST, or what kind of HTML it > produces. What I haven't seen much of is how to use RST for a > particular application. A void waiting to be filled! What an opportunity for you! ;) There is some other information available: * PEP 258 gives an overview of the architecture: <http://docutils.sf.net/spec/pep-0258.html> * The DTD gives the schema for the internal data structure (which is what a Writer component translates from): <http://docutils.sf.net/spec/docutils.dtd> * "The Docutils Document Tree" describes the DTD: <http://docutils.sf.net/spec/doctree.html> The DTD and doctree doc only describe part of the internal data structure, the part that is exposed as XML using the docutils-xml.py front-end (which uses the writers/docutils_xml.py module). The rest of the details (keeping track of hyperlinks and other bookkeeping) is documented inside the docutils/nodes.py module in docstrings. I'm sure it's not complete though. Take a look at the existing writers to see how they work. In the main distribution, see docutils/writers/html4css1.py. In the sandbox, see sandbox/aahz/OO/ (OpenOffice.org writer) and sandbox/oliverr/docbook/, both of which produce XML. For anything that's not clear, please ask (doc...@li... is probably more appropriate), and I will endeavour to answer. These answers will undoubtedly find their way back into the documentation. > What I'd like to do next is be able to create tutorials in structured > text and have a tool that produces a valid IBM tutorial xml file. Can > anyone tell me if this is a sensible application of RST? Sure, sounds fine. > One of the constraints is that it would have to limit the structured > text to the features that are supported by the IBM tutorial xml spec. Feasible, by code reinforced by documentation. I don't have time to look up the references you've given; I will next week. > The current tools seem to me (and I could be wrong) to expect to be > able to handle the full range of RST conventions. In all cases, the final output format doesn't match exactly with the Docutils doctree. Usually the solution is to map Docutils constructs onto one or more target primitives. The HTML writer does that a lot. > The other issue is whether the IBM format expects certain things > that RST doesn't currently allow. That may be a more immediate issue. Worse comes to worst, you can always create custom directives for the specialized data. The "raw" directive may be a useful stop-gap. [later...] > Thanks. Having looked at your code, as well as the other sandboxes, I > think what I want to do isn't too crazy. Not crazy at all. > Has anyone ever written a quick overview of how to go about a custom > application of reST? Engelbert Gruber has collected some notes in <http://docutils.sf.net/sandbox/grubert/making_a_writer.html>. It needs a lot of fleshing out though. You may get some pointers from Oliver Rutherfurd's <http://www.rutherfurd.net/articles/rst-ht2html.html>. -- David Goodger <go...@py...> Open-source projects: - Python Docutils: http://docutils.sourceforge.net/ (includes reStructuredText: http://docutils.sf.net/rst.html) - The Go Tools Project: http://gotools.sourceforge.net/ |
From: Patrick K. O'B. <po...@or...> - 2002-12-14 07:21:43
|
On Saturday 14 December 2002 12:44 am, Aahz wrote: > If you look in sandbox/aahz, you'll see what I've hacked up to > produce OpenOffice.org XML. Thanks. Having looked at your code, as well as the other sandboxes, I think what I want to do isn't too crazy. Has anyone ever written a quick overview of how to go about a custom application of reST? -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." ----------------------------------------------- |
From: Aahz <aa...@py...> - 2002-12-14 06:44:41
|
On Fri, Dec 13, 2002, Patrick K. O'Brien wrote: > > I'm wondering how hard it is to create a custom writer. In particular, > one that produces a particular type of xml file. I've read all the > docutils documentation and most of the emphasis seems to be on how to > write text using RST, or what kind of HTML it produces. What I haven't > seen much of is how to use RST for a particular application. If you look in sandbox/aahz, you'll see what I've hacked up to produce OpenOffice.org XML. -- Aahz (aa...@py...) <*> http://www.pythoncraft.com/ "To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it." --...@li... |
From: Patrick K. O'B. <po...@or...> - 2002-12-14 05:24:35
|
I'm wondering how hard it is to create a custom writer. In particular, one that produces a particular type of xml file. I've read all the docutils documentation and most of the emphasis seems to be on how to write text using RST, or what kind of HTML it produces. What I haven't seen much of is how to use RST for a particular application. Here is what I have in mind. IBM has a custom xml specification for tutorial files. When you create a tutorial in their xml format, they have a bunch of tools that transform that xml into several html files (with the IBM headers, footers, etc.), a US letter size PDF, an A4 size PDF, a zip file, etc. I just did my first tutorial for them and I used my own xml-generating Python utility to do so. It worked, but it wasn't exactly pretty and it was too much work, compared to a structured text approach. What I'd like to do next is be able to create tutorials in structured text and have a tool that produces a valid IBM tutorial xml file. Can anyone tell me if this is a sensible application of RST? One of the constraints is that it would have to limit the structured text to the features that are supported by the IBM tutorial xml spec. The current tools seem to me (and I could be wrong) to expect to be able to handle the full range of RST conventions. The other issue is whether the IBM format expects certain things that RST doesn't currently allow. The IBM tutorial stuff is called Toot-O-Matic (no joke) and is available at https://www6.software.ibm.com/dl/devworks/dw-tootomatic-p. It's mostly Java and XSL stuff. An article about it is at http://www-106.ibm.com/developerworks/xml/library/x-toot/index.html Any suggestions or advice would be greatly appreciated. -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." ----------------------------------------------- |
From: David G. <go...@py...> - 2002-12-12 02:59:01
|
[Beni Cherniavsky] > [New to the list, rST rocks :] Welcome, and thanks! [David Ascher] >> Is there an option I don't know about to let docutils barrel >> through and never raise an exception when processing a >> document? [Beni Cherniavsky] > I don't think that skipping errors is the right approach since it > can guess wrongly what you meant. DWIMs are known to make people > sorry for using them :-). I agree, which is why the defaults are set up as they are. I do not recommend changing them permanently. Suppressing errors and warnings is treating the symptom, not the cause. In this case, the cause was a bug; suppressing the errors would just mask the bug. Posting bug reports on SourceForge or this list gives much better results. > However the cycle of running docutils and fixing the source is not > very convenient when you are in a hurry. TeX's approach of stopping > and suggesting interactive fix possibilities could be more effecient > (if the messages are less criptic ;-) but doesn't save the > corrections in any way. So how about a ``--halt=edit`` mode that > will spawn your text editor on the line where the first error > happened and after you exit the editor, it will restart from the > beginning (or maybe continue if the input file's timestamp hasn't > changed)? I think the complexity of such a feature would outweigh its usefulness. Docutils' error output ("filename:lineno: message") is already designed to be compatible with the output of many GNU tools, which have support in Emacs and probably in other tools as well. -- David Goodger <go...@py...> Open-source projects: - Python Docutils: http://docutils.sourceforge.net/ (includes reStructuredText: http://docutils.sf.net/rst.html) - The Go Tools Project: http://gotools.sourceforge.net/ |
From: David G. <go...@py...> - 2002-12-12 02:56:46
|
I wrote: > But then I tried your example, in which the "..." is indented in a > block quote. You've discovered a bug in the parser. Expect a fix > in a day or two. This was an easy one; I just had to move a conditional. Bug fixed in CVS and snapshot: http://docutils.sf.net/docutils-snapshot.tgz -- David Goodger <go...@py...> Open-source projects: - Python Docutils: http://docutils.sourceforge.net/ (includes reStructuredText: http://docutils.sf.net/rst.html) - The Go Tools Project: http://gotools.sourceforge.net/ |
From: Beni C. <cb...@te...> - 2002-12-11 21:43:03
|
On 2002-12-11, David Ascher wrote: > Beni Cherniavsky wrote: > > > I don't think that skipping errors is the right approach since it can > > guess wrongly what you meant. DWIMs are known to make people sorry for > > using them :-).However the cycle of running docutils and fixing the > > source is not very convenient when you are in a hurry.TeX's approach of > > stopping and suggesting interactive fix possibilities could be more > > effecient (if the messages are less criptic ;-) but doesn't save the > > corrections in any way.So how about a ``--halt=edit`` mode that will > > spawn your text editor on the line where the first error happened and > > after you exit the editor, it will restart from the beginning (or maybe > > continue if the input file's timestamp hasn't changed)? > > None of this helps me, as the docutils phase is run by a cron job at 4 in the > morning.Trust me, I know what I'm doing =). > Oh, now I understand =). But I could use an edit mode in any case, maybe I'll write one. -- Beni Cherniavsky <cb...@tx...> What's lower level than machine code? A spreadsheet: not only addresses are numeric and hand-allocated but also all loops are hand-unrolled and all calls hand-inlined... (and macros are unheard of, of course). |
From: David A. <Da...@Ac...> - 2002-12-11 17:53:15
|
Beni Cherniavsky wrote: > I don't think that skipping errors is the right approach since it can > guess wrongly what you meant. DWIMs are known to make people sorry for > using them :-). However the cycle of running docutils and fixing the > source is not very convenient when you are in a hurry. TeX's approach of > stopping and suggesting interactive fix possibilities could be more > effecient (if the messages are less criptic ;-) but doesn't save the > corrections in any way. So how about a ``--halt=edit`` mode that will > spawn your text editor on the line where the first error happened and > after you exit the editor, it will restart from the beginning (or maybe > continue if the input file's timestamp hasn't changed)? None of this helps me, as the docutils phase is run by a cron job at 4 in the morning. Trust me, I know what I'm doing =). --david |
From: Beni C. <cb...@te...> - 2002-12-11 09:22:01
|
[New to the list, rST rocks :] On 2002-12-10, David Ascher wrote: > Is there an option I don't know about to let docutils barrel through and never > raise an exception when processing a document?I'm all for strictness in > formatting in 99% of cases, but I'd like to use docutils to convert old > documents written in "vague structured text" into HTML, in cases where there > is no reason to go back to the original texts to make them conform. > I don't think that skipping errors is the right approach since it can guess wrongly what you meant. DWIMs are known to make people sorry for using them :-). However the cycle of running docutils and fixing the source is not very convenient when you are in a hurry. TeX's approach of stopping and suggesting interactive fix possibilities could be more effecient (if the messages are less criptic ;-) but doesn't save the corrections in any way. So how about a ``--halt=edit`` mode that will spawn your text editor on the line where the first error happened and after you exit the editor, it will restart from the beginning (or maybe continue if the input file's timestamp hasn't changed)? -- Beni Cherniavsky <cb...@tx...> What's lower level than machine code? A spreadsheet: not only addresses are numeric and hand-allocated but also all loops are hand-unrolled and all calls hand-inlined... (and macros are unheard of, of course). |
From: David G. <go...@py...> - 2002-12-11 01:24:40
|
David Ascher wrote: > Is there an option I don't know about to let docutils barrel through > and never raise an exception when processing a document? "Never" may not be possible, but "almost never" is. Use the "--halt none" option or ``settings.halt_level = 5``. Similarly for "--report" if you don't even want to *see* the warnings (which I don't recommend). > Where the ... is interpreted as a heading marker -- if I change the > "."'s to "1"'s, docutils has no problems. > > Note that while this is from an old PEP, I have other documents > which have the same idiom: > > # if unknown message -> do mime parsing, regex rules, eval tests, etc. > ... > > Maybe we could make ... a special case? It is already a special case, actually. A line of punctuation marks is recognized as a title underline if it is flush left and as long as the title text or longer. If the line of punctuation marks is shorter than the title text, but at least 4 characters long, it will be recognized as an underline but a warning is generated. If it is 3 characters long or shorter, it is *not* recognized as a title underline, and an info-level system message is generated. Info-level messages are normally filtered out of final output (use "--report" to adjust). To illustrate:: $ tools/publish.py << EOF > blahblah > ... > EOF <document source="<stdin>"> <system_message level="1" line="2" source="<stdin>" type="INFO"> <paragraph> Possible title underline, too short for the title. Treating it as ordinary text because it's so short. <paragraph> blahblah ... But then I tried your example, in which the "..." is indented in a block quote. You've discovered a bug in the parser. Expect a fix in a day or two. -- David Goodger <go...@py...> Open-source projects: - Python Docutils: http://docutils.sourceforge.net/ (includes reStructuredText: http://docutils.sf.net/rst.html) - The Go Tools Project: http://gotools.sourceforge.net/ |
From: David A. <Da...@Ac...> - 2002-12-10 23:55:55
|
Is there an option I don't know about to let docutils barrel through and never raise an exception when processing a document? I'm all for strictness in formatting in 99% of cases, but I'd like to use docutils to convert old documents written in "vague structured text" into HTML, in cases where there is no reason to go back to the original texts to make them conform. It appears that the failures i'm encountering in these old corpora are things like: When referencing an external web page in the body of a SPEC, you should include the title of the page in the text, with a footnote reference to the URL. Do not include the URL in the body text of the SPEC. E.g. Refer to the Python Language web site [1] for more details. ... [1] http://www.python.org Where the ... is interpreted as a heading marker -- if I change the "."'s to "1"'s, docutils has no problems. Note that while this is from an old PEP, I have other documents which have the same idiom: # if unknown message -> do mime parsing, regex rules, eval tests, etc. ... Maybe we could make ... a special case? Thoughts? --david |
From: Greg W. <gw...@me...> - 2002-12-09 15:01:49
|
On 06 December 2002, David Abrahams said: > in the tools directory. It had lots of complaints, many of which look > serious, though it only flagged them as warnings. In particular, I > notice lots of characters which appear to be invalid (possibly > nuls). I'm not an HTML expert, which is why I use Tidy. Are these > worth doing something about? I've been using nsgmls for validating HTML -- it understands XML just fine, which is important because Docutils generates XHTML. I haven't tried it lately, but the last time I did (ie. after David G. fixed an error in the DTD line output), Docutils-generated HTML was just fine. Greg -- Greg Ward - software developer gw...@me... MEMS Exchange http://www.mems-exchange.org |
From: David A. <da...@bo...> - 2002-12-07 14:06:32
|
David Goodger <go...@py...> writes: > Warnings mean "I'm not sure, but I think something may be wrong here" > and it's left to the user to judge. Of course I knew that. > Many of these cases are not really problems, just HTMLTidy being > overly critical. > >> In particular, I notice lots of characters which appear to be >> invalid (possibly nuls). > ... > | Character codes 128 to 159 (U+0080 to U+009F) are not allowed in HTML > > That's because test.html is encoded in UTF-8. Oh, how novel! I hadn't noticed it was using utf-8. I normally deal with handwritten HTML, so I've never seen utf-8 encoding in an HTML document before. > Looks like HTMLTidy doesn't understand the ``<?xml version="1.0" > encoding="utf-8" ?>`` processing instruction at the beginning of the > file. Try the "-utf8" option. OK. >> I'm not an HTML expert, which is why I use Tidy. Are these >> worth doing something about? > > Some are, some aren't. > > | : Doctype given is "-//W3C//DTD XHTML 1.0 Transitional//EN" > | : Document content looks like XHTML 1.0 Strict > > HTMLTidy doesn't understand the transitional DTD? Seems odd. I think it does. I think it's saying that you didn't seemt to use any transitional features... but as I said I'm a non-expert. > | test.html:16:1: Warning: <meta> element not empty or not closed > | :17:1: Warning: <meta> element not empty or not closed > > These are real errors, now corrected. As I thought. > | :23:1: Warning: <table> lacks "summary" attribute > ... > | The table summary attribute should be used to describe > | the table structure. It is very helpful for people using > | non-visual browsers. The scope and headers attributes for > | table cells are useful for specifying which headers apply > | to each table cell, enabling non-visual browsers to provide > | a meaningful context for each cell. > > The "summary" attribute is not required by the HTML 4 spec, just > recommended. I know. Tidy's warnings about this get boring. > | :85:24: Warning: <a> Anchor "table-of-contents" already defined This one worried me, but I guess it's not much of an issue. > This seems to be because both the "id" attribute of the container > element and the "name" attribute of "<a>" elements are set to the same > thing (as specified in Appendix C of the XHTML spec, > http://www.w3.org/TR/xhtml1). HTML 4 and XHTML want elements to use > the "id" attribute, but Netscape 4 only works with the "name" > attribute on "<a>" tags. Perhaps the id and name attributes ought to > be on the same element though... HTML is a mishmash; can't win. > Unless there's a problem with a real browser (not just a tool like > tidy), I don't see the need to fix this. > > Thanks for taking the time to run HTMLTidy and bring these to our > attention. No problem. -- David Abrahams da...@bo... * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution |
From: David G. <go...@py...> - 2002-12-07 03:32:01
|
David Abrahams wrote: > I just ran HTMLTidy over the output of > > python html.py test.txt test.html > > in the tools directory. It had lots of complaints, many of which > look serious, though it only flagged them as warnings. ... | 67 warnings, 0 errors were found! Warnings mean "I'm not sure, but I think something may be wrong here" and it's left to the user to judge. Many of these cases are not really problems, just HTMLTidy being overly critical. > In particular, I notice lots of characters which appear to be > invalid (possibly nuls). ... | Character codes 128 to 159 (U+0080 to U+009F) are not allowed in HTML That's because test.html is encoded in UTF-8. Looks like HTMLTidy doesn't understand the ``<?xml version="1.0" encoding="utf-8" ?>`` processing instruction at the beginning of the file. Try the "-utf8" option. | even if they were, they would likely be unprintable control | characters. Tidy assumed you wanted to refer to a character with the | same byte value in the Windows-1252 encoding and replaced that | reference with the Unicode equivalent. Dangerous assumption. > I'm not an HTML expert, which is why I use Tidy. Are these > worth doing something about? Some are, some aren't. | : Doctype given is "-//W3C//DTD XHTML 1.0 Transitional//EN" | : Document content looks like XHTML 1.0 Strict HTMLTidy doesn't understand the transitional DTD? Seems odd. | test.html:16:1: Warning: <meta> element not empty or not closed | :17:1: Warning: <meta> element not empty or not closed These are real errors, now corrected. | :23:1: Warning: <table> lacks "summary" attribute ... | The table summary attribute should be used to describe | the table structure. It is very helpful for people using | non-visual browsers. The scope and headers attributes for | table cells are useful for specifying which headers apply | to each table cell, enabling non-visual browsers to provide | a meaningful context for each cell. The "summary" attribute is not required by the HTML 4 spec, just recommended. While I sympathize with its aim, I don't know of any way to automatically generate a summary of a table. Eventually a formal "table" directive may be written, and it could have a "summary" option. | :85:24: Warning: <a> Anchor "table-of-contents" already defined This seems to be because both the "id" attribute of the container element and the "name" attribute of "<a>" elements are set to the same thing (as specified in Appendix C of the XHTML spec, http://www.w3.org/TR/xhtml1). HTML 4 and XHTML want elements to use the "id" attribute, but Netscape 4 only works with the "name" attribute on "<a>" tags. Perhaps the id and name attributes ought to be on the same element though... HTML is a mishmash; can't win. Unless there's a problem with a real browser (not just a tool like tidy), I don't see the need to fix this. Thanks for taking the time to run HTMLTidy and bring these to our attention. -- David Goodger <go...@py...> Open-source projects: - Python Docutils: http://docutils.sourceforge.net/ (includes reStructuredText: http://docutils.sf.net/rst.html) - The Go Tools Project: http://gotools.sourceforge.net/ |
From: David G. <go...@py...> - 2002-12-07 00:43:44
|
David Abrahams wrote: > I'm just getting started with ReST, and finding it to be natural > and a lot of fun to use. Glad to hear it! > I did find one behavior that violated my > expectations, using the html.py standalone processor. > > I was writing along and somewhere in the middle of my text I decided > to turn a parenthesized section into a footnote: ... > When I processed this into HTML, I was surprised to find that the > footnote appeared exactly where I had placed it, instead of near the > bottom of the page. Docutils doesn't guess where you want the footnotes to be. Look at PEPs, for example; footnotes are in a section called "References" or "References & Footnotes". The author might want to add a transition (horizontal rule in HTML) before the footnotes, or some other decoration. There are directives planned for gathering footnotes & citations at an author-specified point in the document, perhaps "footnotes" and "citations" to keep things simple. They haven't been implemented yet though. If you'd like to try, see http://docutils.sf.net/spec/howto/rst-directives.html for instructions. -- David Goodger <go...@py...> Open-source projects: - Python Docutils: http://docutils.sourceforge.net/ (includes reStructuredText: http://docutils.sf.net/rst.html) - The Go Tools Project: http://gotools.sourceforge.net/ |