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
|
Nov
|
Dec
|
From: <ms...@ma...> - 2002-11-12 10:18:13
|
On Mon, Nov 11, 2002 at 08:53:01PM -0500, David Goodger wrote: > > It looks like I cannot get only the body of the text (what is located > > between <body> ... </body>) without some addtional programming, >=20 > Correct. You'll need a specialized Writer component. Take a look at > the files in http://docutils.sf.net/sandbox/oliverr/ht/ . This seems > to be a common requirement for people, so a custom HTML-body-only > Writer could be useful. I don't know what to do about the DocTitle > transform in this case though (in docutils/transforms/frontmatter.py). I believe, the best approach is to just ignore it. :) Those who really need it, could access it through the document instance. > > nor it's possible to get rid of use stylesheets at all. >=20 > I'm not sure what you mean by this or what you want. Please > elaborate. The current code does produce HTML elements with classes referencing to a stylesheet. I'd say that the rendering without a stylesheet seems to be OK for me, so I'd like to specify None as the stylesheet name, and in this case I'd expect to get html text without class references in html elements. > The html4css1.py Writer is designed to use a stylesheet, as > recommended by the latest HTML specs. If you want HTML that doesn't > require a stylesheet at all, a new Writer would be needed. Such a behaviour does not seem to be very complicated, so maybe it could be possible to add this functionality in the current code? > [ URLs with spaces ] >=20 > According to RFC 2396 "Uniform Resource Identifiers (URI): Generic > Syntax", spaces are not valid URI/URL characters. It does say this: >=20 > In some cases, extra whitespace (spaces, linebreaks, tabs, etc.) > may need to be added to break long URI across lines. The whitespace > should be ignored when extracting the URI. > ... > Using <> angle brackets around each URI is especially recommended > as a delimiting style for URI that contain whitespace. >=20 > The syntax you propose would conflict with this, especially if the > MS-style URL were to break across lines: >=20 > <http://www.example.com/a/very/long/ > path/broken/across/lines> >=20 > Is the whitespace after "long/" significant or not? The RFC says it's > not. The reStructuredText parser also joins long multi-line URLs in > targets. I wouldn't mind adding the ability to join broken URLs in > free text as well, if surrounded by brackets. >=20 > So the answer to your question is, I think I'd say no thanks. > Whitespace in URLs is a pain; I think it's better just to avoid it. Hmm. The current code does not seem to follow the quoted RFC 2396 then. I did specify <http://www.example.com/an url with spaces> (which seems to be correct according to this RFC) and as result got <<a href=3D"http://www.example.com/an">http://www.example.com/an</a> url with spaces> which seems to be incorrect, right? -- Misha |
From: David G. <go...@py...> - 2002-11-12 01:52:24
|
Mikhail Sobolev wrote: > Having downloaded the 0.2 version, I tried to write a simple program > to convert from text to HTML. It turned to out to be not that easy. > Fortunately, in mailing list archives I found a suggestion to > download the snapshot and proceed with publish_string helper. This > works great, thank you. Thank you for checking the archives! > I have two questions, however. > > It looks like I cannot get only the body of the text (what is located > between <body> ... </body>) without some addtional programming, Correct. You'll need a specialized Writer component. Take a look at the files in http://docutils.sf.net/sandbox/oliverr/ht/ . This seems to be a common requirement for people, so a custom HTML-body-only Writer could be useful. I don't know what to do about the DocTitle transform in this case though (in docutils/transforms/frontmatter.py). > nor it's possible to get rid of use stylesheets at all. I'm not sure what you mean by this or what you want. Please elaborate. The html4css1.py Writer is designed to use a stylesheet, as recommended by the latest HTML specs. If you want HTML that doesn't require a stylesheet at all, a new Writer would be needed. > The second comes from my rather extensive use of Outlook (yes, a > Microsoft product) "highlighting". In cases, when the path or the > file name contain spaces, it's very convenient to just enclose the > whole consruction in angle brackets (like, <schema://some > path/with/spaces/and a file>), and you do not really have to worry > about converting those in %20. What would you say about such a > feature? According to RFC 2396 "Uniform Resource Identifiers (URI): Generic Syntax", spaces are not valid URI/URL characters. It does say this: In some cases, extra whitespace (spaces, linebreaks, tabs, etc.) may need to be added to break long URI across lines. The whitespace should be ignored when extracting the URI. ... Using <> angle brackets around each URI is especially recommended as a delimiting style for URI that contain whitespace. The syntax you propose would conflict with this, especially if the MS-style URL were to break across lines: <http://www.example.com/a/very/long/ path/broken/across/lines> Is the whitespace after "long/" significant or not? The RFC says it's not. The reStructuredText parser also joins long multi-line URLs in targets. I wouldn't mind adding the ability to join broken URLs in free text as well, if surrounded by brackets. So the answer to your question is, I think I'd say no thanks. Whitespace in URLs is a pain; I think it's better just to avoid it. -- 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: <ms...@ma...> - 2002-11-11 17:29:17
|
Hi I need to convert plain text (with some formatting) to HTML format, and, fortunately, this module provide this functionality (among other). :) Having downloaded the 0.2 version, I tried to write a simple program to convert from text to HTML. It turned to out to be not that easy. Fortunately, in mailing list archives I found a suggestion to download the snapshot and proceed with publish_string helper. This works great, thank you. I have two questions, however. It looks like I cannot get only the body of the text (what is located between <body> ... </body>) without some addtional programming, nor it's possible to get rid of use stylesheets at all. What would be the best way to accomplish this? The second comes from my rather extensive use of Outlook (yes, a Microsoft product) "highlighting". In cases, when the path or the file name contain spaces, it's very convenient to just enclose the whole consruction in angle brackets (like, <schema://some path/with/spaces/and a file>), and you do not really have to worry about converting those in %20. What would you say about such a feature? Best Regards, -- Misha |
From: <ek...@in...> - 2002-11-01 19:33:34
|
Greetings from Bali... Beyond the immediate victims, the terrorist acts of 12 Oct 2002 in Bali send chilling shivers to the islands tourism industry, the very lifeblood of the island. Tourism industry in Bali employs hundreds of thousands of people, feeding around 3 million people in the island. If tourists stop coming, there will be a lot more victims... We are calling for Backpackers around the world to help revive tourism to Bali! To help do this, we have created a portal for Backpackers to visit Bali: http://www.budgetbali.com Please kindly visit the site. You can book online over 100 bed-and-breakfasts at heavily discounted prices. Long stays deals, homestays and rental homes are coming soon. We will also be putting in a forum and continue to improve the site. Inputs and suggestions are most welcome, as well as other resources that would be useful and links exchanges with other backpacking resources on the net. Sincerely, --Eka Ginting Enter your text here. ----------------------------------------------------------------------- *** indo.com CRM - Mailing List Management *** indo.com - the leading internet company in indonesia <br> http://www.indo.com & http://www.orientmagix.com : great deals for traveling to Indonesia & ASEAN <br> http://www.paketrupiah.com : instant travel in comfort and good time for Indonesian residents <br> http://www.rajacraft.com : buy quality indonesian crafts at wholesale prices <br> http://www.siliconbali.com : deploy internet technology for your business <br> Sent using http://www.turbocustomer.com - guaranteed lower costs to send your email, SMS, and international faxes!<p>click <a href="http://www.turbocustomer.com/unsub.php3?op=unsub&email=doc...@li...&coid=3">UNSUBSCRIBE</a> to unsubscribe</p> |
From: David G. <go...@us...> - 2002-11-01 02:27:13
|
Brett g Porter wrote: > I'm trying to document a C struct that's like: > > :: > { > int field1; > int field2; > } > > by keeping the code in literal blocks (in reality, it's a rather > large struct, and not every member needs annotation, something like: > > :: > { > int field1; > > This is a clever note about field1 > > :: > > int field2; > > this is another witticism > > :: > } > > ...but the indentation for the literal ``int field2;`` is not > consistent (because it doesn't have the curly braces to give it that > indentation context any more. > > Suggestions for how to accomplish what I'm trying? First, don't forget that you need a blank line after the "::" (it must be alone or at the end of a paragraph). The simplest way I can think of is to use some text to mark the left edge of your literal block. I'd choose ellipsis ("..."), since it indicates "continuing...": :: ... int field2; this is another witticism :: ... } Or the entire thing could be bordered on the left: :: | { | int field1; | int field2; | } (When splitting up the block, preserve the border bars.) Or even line numbers: :: 13: { 14: int field1; 15: int field2; 16: } Another way would be to use the "parsed-literal" directive: .. parsed-literal:: \ int field2; The backslash establishes the left edge but disappears after parsing. You have to be careful with parsed-literals though, becuase any inline markup *is* parsed. Finally, a runtime setting (set via directives and/or command-line options) could be introduced to establish fixed indentation levels. The parser could then assume, for example, that Literal blocks always begin 4 spaces to the right of the surrounding text. This would require implementation of course. The quickest way to implementation is to submit a patch! -- David Goodger <go...@us...> 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: Brett g P. <bgp...@ac...> - 2002-10-31 20:30:59
|
Okay, here's what I'm trying to do -- I understand why I'm getting th= e output I'm getting, but I don't like it <g>. I'm trying to document a C struct that's like: :: { int field1; int field2; } by keeping the code in literal blocks (in reality, it's a rather larg= e struct, and not every member needs annotation, something like: :: { int field1; This is a clever note about field1 :: int field2; this is another witticism :: } =2E..but the indentation for the literal ``int field2;`` is not consi= stent (because it doesn't have the curly braces to give it that indentation context any more. Suggestions for how to accomplish what I'm trying? thx... -- // Today's Oblique Strategy (=A9 Brian Eno/Peter Schmidt): // Do nothing for as long as possible // Brett g Porter * BgP...@ac... |
From: David G. <go...@us...> - 2002-10-31 02:46:26
|
[David] >> From http://docutils.sf.net/spec/doctree.html#transitions: >> >> A transition may not begin or end a section or document, nor >> may two transitions be immediately adjacent. >> >> The transitions were between sections (easy to see if you use the >> tools/publish.py front end). The parser isn't enforcing that rule, >> which is a bug that should be fixed. Fixed. The parser now enforces the structure; transitions aren't allowed at the beginning or end of sections or the document itself. >> Removing the transitions turns up a much more serious bug though, >> generating a traceback. *This* could be an "include" directive >> bug. I'll look into it. [Brett] > ...that's why I put the transitions in -- I found that sequential > "include"s with no intervening text stopped all the processing You should have reported *that* as a bug! ;) > putting transitions inbetween stopped the complaints. That will work as a temporary work-around, until the "include" directive problem is fixed. I don't know *why* it works (or why it's needed) yet. It turns out that part the problem is quite deep. The "include" directive starts a nested parse, which means that a section in the included file must be complete (it can't start in the included file and finish in the master file). This isn't very useful, so the implementation of the "include" directive has to be rethought. Unfortunately, to fix "include" it may be necessary to rework a very low-level aspect of the parser. If you're interested, I'll be following up on this on the docutils-develop list (http://lists.sf.net/lists/listinfo/docutils-develop). > Unfortunately I've been in the position of needing to convert an > existing doc over to reStructuredText in a hurry, and haven't had > much time to study the spec or the code closely. Understandable :) > Kudos again on building a system that let me get as far as I did in > a few hours! Thanks. -- David Goodger <go...@us...> 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: Brett g P. <bgp...@ac...> - 2002-10-30 02:00:08
|
----- Original Message ----- From: "David Goodger" <go...@us...> To: "Brett g Porter" <bgp...@ac...>; <doc...@li...> Sent: Tuesday, October 29, 2002 7:55 PM Subject: Re: [Docutils-users] problems with .. include:: ? > Brett g Porter wrote: > > I'm really enjoying Restructured Text. > > Glad to hear it! (No space though: reStructuredText.) Sorry -- as someone who insists that the world honor my request to lowercase my middle initial, I guarantee that I'll get it right from now on. > > I grabbed the cvs snapshot yesterday > > and everything was working as documented and as expected until I started > > dividing a very large document up into chapters and using the > > .. include:: > > > > directive to pull the chapters into the 'real' output document. Chapters > > that are pulled in via the include directive are omitted from the generated > > table of contents. Well, on closer examination, the very last chapter pulled > > in is included, but none of the others are. > > That actually had nothing to do with the "include" directive. It was > because of the transitions (lines of dashes in a.txt) between sections. The > table of contents is compiled in reverse from the end of the document, > stopping at the first non-section; in this case a transition. Thus only the > last section got in. > > From http://docutils.sf.net/spec/doctree.html#transitions: > > A transition may not begin or end a section or document, nor may > two transitions be immediately adjacent. > > The transitions were between sections (easy to see if you use the > tools/publish.py front end). The parser isn't enforcing that rule, which is > a bug that should be fixed. Removing the transitions turns up a much more > serious bug though, generating a traceback. *This* could be an "include" > directive bug. I'll look into it. > ...that's why I put the transitions in -- I found that sequential "include"s with no intervening text stopped all the processing and (through guessing and blind luck) that putting transitions inbetween stopped the complaints. Unfortunately I've been in the position of needing to convert an existing doc over to reStructuredText in a hurry, and haven't had much time to study the spec or the code closely. Kudos again on building a system that let me get as far as I did in a few hours! BgP |
From: David G. <go...@us...> - 2002-10-30 00:55:33
|
Brett g Porter wrote: > I'm really enjoying Restructured Text. Glad to hear it! (No space though: reStructuredText.) > I grabbed the cvs snapshot yesterday > and everything was working as documented and as expected until I started > dividing a very large document up into chapters and using the > .. include:: > > directive to pull the chapters into the 'real' output document. Chapters > that are pulled in via the include directive are omitted from the generated > table of contents. Well, on closer examination, the very last chapter pulled > in is included, but none of the others are. That actually had nothing to do with the "include" directive. It was because of the transitions (lines of dashes in a.txt) between sections. The table of contents is compiled in reverse from the end of the document, stopping at the first non-section; in this case a transition. Thus only the last section got in. From http://docutils.sf.net/spec/doctree.html#transitions: A transition may not begin or end a section or document, nor may two transitions be immediately adjacent. The transitions were between sections (easy to see if you use the tools/publish.py front end). The parser isn't enforcing that rule, which is a bug that should be fixed. Removing the transitions turns up a much more serious bug though, generating a traceback. *This* could be an "include" directive bug. I'll look into it. > Is this a known limitation? Something that will be fixed? Or is this one of > those "push up your sleeves and fix it, pal" things? Not a known problem until now; thanks for the bug report. It ought to be fixed at some point, when someone considers it important enought to fix. If it's important to *you*, you should definitely attempt a fix or at least a diagnosis. Bug-fix patches are *always* welcome! The docutils-develop list is the best place to discuss bugs in the code. -- David Goodger <go...@us...> 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: Brett g P. <bgp...@ac...> - 2002-10-29 22:16:52
|
Hi -- I'm really enjoying Restructured Text. I grabbed the cvs snapshot yes= terday and everything was working as documented and as expected until I star= ted dividing a very large document up into chapters and using the =2E. include:: directive to pull the chapters into the 'real' output document. Chapt= ers that are pulled in via the include directive are omitted from the gen= erated table of contents. Well, on closer examination, the very last chapter= pulled in is included, but none of the others are. For example, I've created the following 4 files a.txt ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A Restructured Text include Test =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =2E. contents:: -------------- =2E. include:: b.txt -------------- =2E. include:: c.txt -------------- =2E. include:: d.txt b.txt~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This is b.txt! =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Some body text here... c.txt ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This is C dot text =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D and also some body text in here! d.txt~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ D . txt reporting for duty! =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D complete with a body! end~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~` This generates the following HTML (note that only the last one appear= s in the TOC)... <?xml version=3D"1.0" encoding=3D"utf-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html lang=3D"en"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf= -8" /> <meta name=3D"generator" content=3D"Docutils 0.2.7: http://docutils.sourceforge.net/" /> <title>A Restructured Text include Test</title> <link rel=3D"stylesheet" href=3D"default.css" type=3D"text/css" /> </head> <body> <div class=3D"document" id=3D"a-restructured-text-include-test"> <h1 class=3D"title">A Restructured Text include Test</h1> <div class=3D"contents topic" id=3D"contents"> <p class=3D"topic-title"><a name=3D"contents">Contents</a></p> <ul class=3D"simple"> <li><a class=3D"reference" href=3D"#d-txt-reporting-for-duty" id=3D"i= d1" name=3D"id1"> D . txt reporting for duty!</a></li> </ul> </div> <hr /> <p>text here?</p> <div class=3D"section" id=3D"this-is-b-txt"> <h1><a name=3D"this-is-b-txt">This is b.txt!</a></h1> <p>Some body text here...</p> </div> <hr /> <div class=3D"section" id=3D"this-is-c-dot-text"> <h1><a name=3D"this-is-c-dot-text">This is C dot text</a></h1> <p>and also some body text in here!</p> </div> <hr /> <div class=3D"section" id=3D"d-txt-reporting-for-duty"> <h1><a class=3D"toc-backref" href=3D"#id1" name=3D"d-txt-reporting-fo= r-duty">D . txt reporting for duty!</a></h1> <p>complete with a body!</p> </div> </div> </body> </html> Is this a known limitation? Something that will be fixed? Or is this = one of those "push up your sleeves and fix it, pal" things? -- // Today's Oblique Strategy (=A9 Brian Eno/Peter Schmidt): // Ask your body // Brett g Porter * BgP...@ac... // http://mywebpages.comcast.net/bgporter/ |
From: David G. <go...@us...> - 2002-10-29 03:40:06
|
These questions are more suitable for the docutils-develop list; cross-posting. Ian Bicking wrote: > To serve as an instructional sample I'm making a very simply Wiki -- > I'd like to use reST as the markup, since it's not an example in > parsing (and I like the reST markup more than most Wiki markups to > boot). Great! Please share the results if you can. I know that some intregration with MoinMoin has been done, although incomplete I believe. See http://twistedmatrix.com/users/jh.twistd/moin/moin.cgi/RestSample > So, to do this I need to convert reST to HTML. I looked around in > buildhtml.py to get an idea, but I found it surprisingly difficult > to figure out just what I would need to do. buildhtml.py is a complicated beast, trying to be a kind of "make", recursively building HTML for regular and PEP files with integrated local config file support. It's not a good example to begin with. > Could someone perhaps tell me what the easiest way to do this is? First, make sure you're using the latest code from CVS or from the snapshot: <http://docutils.sf.net/docutils-snapshot.tgz>. Look in the docutils/core.py file at the "publish_string" convenience function. It is probably what you want. Beyond the docstrings, there is no related developer documentation yet. Contributions are, of course, most welcome! Perhaps the tools/pep2html.py module is a better example, function "fix_rst_pep". Docutils is called in one (logical) line of code:: output = core.publish_string( source=''.join(input_lines), source_path=inpath, destination_path=outfile.name, reader_name='pep', parser_name='restructuredtext', writer_name='pep_html', settings=docutils_settings) > I'm not sure of the relevance of the options, the importance of > FileIO, or some of the other abstractions involved in this > operation. I've since renamed "options" to "settings": they're runtime configuration settings (see http://docutils.sf.net/docs/tools.html#configuration-file-entries). For now, just use a convenience function with no explicit settings; the defaults should be fine. FileIO is an implementation detail; use strings with "publish_string" or file-like objects with "publish_file". Be sure to read the docstrings. > Also -- is there a good hook in reST that I can use for Wiki links? > The linking mechanism reST has is fine for internal and external > links, but doesn't fit right for Wiki links (which fall somewhere in > between). If I could capture failed internal links and turn them > into inter-wiki-page links, that would be perfect. Failing that, if > there was some way I could introduce another markup easily that > would be great. There's mention of Wikis as an example potential Reader component in PEP 258 (http://docutils.sf.net/spec/pep-0258.html#readers). A Wiki Reader could subclass the standard parser, or we could build in hooks if they prove general enough. The PEP Reader (docutils/readers/pep.py) first subclassed the parser (still does, minimally: the "Inliner" class), but most of the code was moved into the parser proper for other client code to use. I would suggest that Wiki links retain the trailing "_" of regular reStructuredText links, and a mechanism be added to do some kind of lookup from a Wiki target database. The extra syntax (trailing "_") removes ambiguity inherent in CamelCase WikiLinks (such as anything written by Angus MacDuff). > If there isn't an easy way, I'll probably just look for WikiNames in > the generated HTML, and do the substitution then. I'll have to do > some dynamic fixup anyway, to distinguish between existent Wiki > pages and to-be-created links. A proper integrated approach would be best IMO, and welcome. Please subscribe to docutils-develop (http://lists.sf.net/lists/listinfo/docutils-develop) and discuss it there. I'll be happy to help. -- David Goodger <go...@us...> 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: Ian B. <ia...@co...> - 2002-10-29 00:09:42
|
To serve as an instructional sample I'm making a very simply Wiki -- I'd like to use reST as the markup, since it's not an example in parsing (and I like the reST markup more than most Wiki markups to boot). So, to do this I need to convert reST to HTML. I looked around in buildhtml.py to get an idea, but I found it surprisingly difficult to figure out just what I would need to do. This is the (not working) code I came up with: pub = core.Publisher() pub.set_reader(reader_name='standalone', parser_name='restructuredtext', parser=None) pub.set_writer(writer_name='html') pub.source = io.FileIO(None, source_path=sourceFile) pub.destination = io.FileIO( None, destination_path=destFile) Could someone perhaps tell me what the easiest way to do this is? I'm not sure of the relevance of the options, the importance of FileIO, or some of the other abstractions involved in this operation. Also -- is there a good hook in reST that I can use for Wiki links? The linking mechanism reST has is fine for internal and external links, but doesn't fit right for Wiki links (which fall somewhere in between). If I could capture failed internal links and turn them into inter-wiki-page links, that would be perfect. Failing that, if there was some way I could introduce another markup easily that would be great. If there isn't an easy way, I'll probably just look for WikiNames in the generated HTML, and do the substitution then. I'll have to do some dynamic fixup anyway, to distinguish between existent Wiki pages and to-be-created links. Thanks, Ian |
From: David G. <go...@us...> - 2002-10-11 01:51:26
|
Mark McEahern wrote: > Forgive me if this is a FAQ. Well, since up to now there hasn't *been* an official FAQ, you're forgiven. ;-) > In StructuredText, you can do: > > 1. a > > 1. b > > 1. c > > and you'll get an ordered list (<ol><li>a</li><li>b</li><li>c</li>). > The advantage of this approach is that I don't need to manage the > numbers (e.g., if I move c between a and b, I don't have to > "renumber" them). > > With reStructuredText, OTOH, the above generates three ordered > lists: ... omitted ... > There's probably a good reason for this. I realize this is part of > the specification: > > http://docutils.sf.net/spec/rst/reStructuredText.html#enumerated-lists > > Any insight on why the implicit sequence approach is avoided (which > seems usable at least in isolation) is greatly appreciated. There's a discussion here: http://docutils.sf.net/spec/rst/alternatives.html#auto-enumerated-lists It's lingering there, awaiting a champion. I introduced a colleague to Docutils recently, let him loose, and his first suggestion was exactly this extension; the evidence is mounting that this would be a good change. I'm partial to alternative 2, since it establishes the enumeration sequence (arabic numerals, letters, etc.), and reduces the "line noise". > Perhaps the answer is simply: > > Explicit is better than implicit. That's a big part of it! I put auto-enumerated lists on to the to-do list (with a "?"), so it won't be forgotten, but it's not my priority right now. If you're interested, patches are gratefully accepted! -- David Goodger <go...@us...> 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...@us...> - 2002-10-11 01:48:25
|
Mark McEahern wrote: > If I were to try to express the wherefore of it myself, I'd say, ... Thanks, Mark, well put. This was enough to put the FAQ I've slowly been working on over the top. See it in all its glory here: http://docutils.sf.net/FAQ.html I invite questions and suggestions for more FAQ entries. -- David Goodger <go...@us...> 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: Mark M. <ma...@mc...> - 2002-10-10 15:47:17
|
Forgive me if this is a FAQ. In StructuredText, you can do: 1. a 1. b 1. c and you'll get an ordered list (<ol><li>a</li><li>b</li><li>c</li>). The advantage of this approach is that I don't need to manage the numbers (e.g., if I move c between a and b, I don't have to "renumber" them). With reStructuredText, OTOH, the above generates three ordered lists: <ol> <li>a</li> </ol> <ol> <li>b</li> </ol> <ol> <li>c</li> </ol> There's probably a good reason for this. I realize this is part of the specification: http://docutils.sourceforge.net/spec/rst/reStructuredText.html#enumerated-li sts Any insight on why the implicit sequence approach is avoided (which seems usable at least in isolation) is greatly appreciated. Perhaps the answer is simply: Explicit is better than implicit. Thanks, // mark - |
From: Mark M. <mar...@mc...> - 2002-10-10 15:29:22
|
[David Goodger [mailto:go...@us...]] > Check the "class" attribute on the "h1" tags, and you will see a > difference. It took a while for this to sink in. I mean, I saw the class="title". I know how to use CSS. But I just didn't get it. The aha moment came when I saw Greg Ward's reply. I think I just needed to know someone else had struggled with this too. And then I got over it, just like that. If I were to try to express the wherefore of it myself, I'd say, "The first section is special--there's only one of those. Rather than use a plain H1 for that, we use <H1 class="title"/> so that we can use H1 again within the document. The reason we do this? HTML only has H1-H6, so by making H1 do double duty, we effectively reserve these tags to provide 6 levels of heading beyond the single document title." Cheers, // mark - |
From: Greg W. <gw...@me...> - 2002-10-10 13:19:12
|
On 09 October 2002, David Goodger said: > Mark McEahern wrote: > > When I run it through tools/html.py, I get unexpected results (below). I > > was expecting H1, H2, then H3; instead, I get H1, H1, H2. > > Check the "class" attribute on the "h1" tags, and you will see a difference. > > The first title becomes the document title. From the markup specification: For the record, I thought the duelling <h1>s was kind of bogus at first too. But then I put default.css in place, and it all made sense. In fact, I think I like the Docutils way so much -- duplicate the title as a centred <h1>, with regular <h1>s below it -- that I might just start using it myself. Greg -- Greg Ward - software developer gw...@me... MEMS Exchange http://www.mems-exchange.org |
From: David G. <go...@us...> - 2002-10-10 00:29:23
|
Mark McEahern wrote: > When I run it through tools/html.py, I get unexpected results (below). I > was expecting H1, H2, then H3; instead, I get H1, H1, H2. Check the "class" attribute on the "h1" tags, and you will see a difference. The first title becomes the document title. From the markup specification: Specifically, there is no way to specify a document title and subtitle explicitly in reStructuredText. Instead, a lone top-level section title (see Sections_ below) can be treated as the document title. Similarly, a lone second-level section title immediately after the "document title" can become the document subtitle. See the `DocTitle transform`_ for details. (http://docutils.sf.net/spec/rst/reStructuredText.html#document) HTML is being used for dumb formatting; it isn't meant for anything but final display. A stylesheet *is* required, and you're welcome to roll your own. HTML is limited with only H1..H6, so we need to use them sparingly. The HTML Writer uses H1 for document title and H2 for document subtitle, and starts over at H1 for section titles. This will definitely go into the FAQ, being the most frequently asked question so far. -- David Goodger <go...@us...> 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: Mark M. <mar...@mc...> - 2002-10-09 21:04:36
|
Hi, I have this text: <text> Heading 1 ========= All my life, I wanted to be H1. Heading 1.1 ----------- But along came H1, and so now I must be H2. Heading 1.1.1 ************* Yeah, imagine me, I'm stuck at H3! </text> (excluding the <text> start and end tags.) When I run it through tools/html.py, I get unexpected results (below). I was expecting H1, H2, then H3; instead, I get H1, H1, H2. Thanks, // mark <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html lang="en"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <meta name="generator" content="Docutils 0.2.5: http://docutils.sourceforge.net/" /> <title>Heading 1</title> <link rel="stylesheet" href="default.css" type="text/css" /> </head> <body> <div class="document" id="heading-1"> <h1 class="title">Heading 1</h1> <p>All my life, I wanted to be H1.</p> <div class="section" id="heading-1-1"> <h1><a name="heading-1-1">Heading 1.1</a></h1> <p>But along came H1, and so now I must be H2.</p> <div class="section" id="heading-1-1-1"> <h2><a name="heading-1-1-1">Heading 1.1.1</a></h2> <p>Yeah, imagine me, I'm stuck at H3!</p> </div> </div> </div> </body> </html> - |
From: David G. <go...@us...> - 2002-10-03 22:29:44
|
Greg Ward wrote: > I like to start playing with stable code. ;-) Isn't "stable" just a euphemism for "fixed/unchanging"? :-) The current CVS is at 0.2.4 and continually improving. I try to keep bugs from creeping in. Have you tried running the test suite? http://docutils.sf.net/README.html#running-the-test-suite > Please lemme know when I can put my lovely precious whitespace back! Try it now. -- David Goodger <go...@us...> 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: Greg W. <gw...@me...> - 2002-10-03 14:07:39
|
On 02 October 2002, David Goodger said: > It looks like your Docutils installation is out of date. Reporter output > doesn't look like that any more. Get the latest snapshot here: > http://docutils.sf.net/docutils-snapshot.tgz Yeah, that was the 0.2 release. I like to start playing with stable code. ;-) I'm using the latest CVS now. > Perhaps the entire term line should be checked for inline markup first, and > only then split on a top-level " : "? The terms in the cases given won't be > split because the " : " would already be inside an inline literal element, > and thus not at the top level. This will have to be thought through to see > if there are any hidden gotchas. That sounds sensible to me. The error message I get -- namely, "Inline literal start-string without end-string" -- and the place where it comes from (at the end of the definition paragraph) make it sound like something is out of order. I suspect looking for " : " should come later in the game, but that's all I can say without looking at the code or making a fool of myself. > In the interim, how about this? > > set_name(name \: string) > use this to change the widget... I settled for this: ``set_name(name:string)`` use this to change the ... instead. Please lemme know when I can put my lovely precious whitespace back! ;-) Greg -- Greg Ward - software developer gw...@me... MEMS Exchange http://www.mems-exchange.org |
From: David G. <go...@us...> - 2002-10-03 00:11:32
|
Greg Ward wrote: > I'm trying to document a collection of methods like this: ... > ``set_name(name : string)`` > use this to change the widget name supplied to the constructor. ... > but Docutils doesn't seem to like my notation for argument types: > > Reporter: WARNING (2) Inline literal start-string without end-string at line > 10. > Reporter: WARNING (2) Inline literal start-string without end-string at line > 15. It looks like your Docutils installation is out of date. Reporter output doesn't look like that any more. Get the latest snapshot here: http://docutils.sf.net/docutils-snapshot.tgz > If I remove the whitespace around the colons, it doesn't complain. > > Oh... bugger... I seem to have run afoul of the "classifier" feature of > definition lists. Yes, it seems so. The " : " structural markup (delimiting the term line into "term" and "classifier" elements) is picked up before the "``" inline markup. That's a tricky case, one I hadn't anticipated. I think this is the only case of structural markup in the middle of text; in every other case, the markup is either at the beginning or at the end of a text block. > (Have I mentioned how nice it is that reST has a semi-formal spec?) Glad you like it. It certainly helps to be able to occasionally say "RTFM!" and have a "fine manual" to refer to. > This would be only slightly annoying if it weren't > for the fact that that feature appears to have been at least vaguely > inspired by the type syntax that I invented for Grouch. That raises it > from "slightly annoying" to "richly ironic", I think. More than vaguely. Grouch is mentioned in the spec. Ironic indeed! :-) > So is there a way to work around that feature? I tried backslashing the > colons, and they just came out backslashed in the HTML output. Backslash-escaping the colons does indeed prevent the term/classifier split, but then the inline literals take over and the backslashes stay in. Dilemma. Perhaps the entire term line should be checked for inline markup first, and only then split on a top-level " : "? The terms in the cases given won't be split because the " : " would already be inside an inline literal element, and thus not at the top level. This will have to be thought through to see if there are any hidden gotchas. In the interim, how about this? set_name(name \: string) use this to change the widget... You don't get the inline literal effect, but it's better than nothing. -- David Goodger <go...@us...> 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...@us...> - 2002-10-02 23:45:31
|
Greg Ward wrote: > Just doing my first mass restructuredtextification (is that the > appropriate terminology?) If you like. :-) > of some docs, and I noticed that Konqueror 2.2.2 formats HTML > documents slightly differently if they have > > <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> > > -- in particular, the vertical line spacing is too much. If I edit > out the "charset=utf-8", then it looks perfectly ordinary. Ditto if > I s/utf-8/us-ascii/ -- that looks fine. > > Anyone else seen this? Guess I'll just use "-o us-ascii" for now. I haven't seen it myself, but it sounds like Konqueror may be using a different font for Unicode text, with different whitespace metrics. If your documents are exclusively ASCII, and you don't use symbol footnotes (which may produce Unicode symbols; references look like this: [*]_), you should be fine. You could use "-o latin-1" to allow a little more latitude. You could even put "output-encoding: latin-1" in your config file and be done with it; see http://docutils.sf.net/docs/tools.html#configuration-files . -- David Goodger <go...@us...> 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: Greg W. <gw...@me...> - 2002-10-02 16:16:04
|
I'm trying to document a collection of methods like this: """ Common widget methods --------------------- The Widget base class also provides a couple of useful methods: ``set_name(name : string)`` use this to change the widget name supplied to the constructor. Unless you know what you're doing, you should do this before rendering or parsing the widget. ``set_value(value : any)`` use this to set the widget value; this is the same as supplying a value to the constructor (and the same type rules apply, ie. the type of 'value' depends on the widget class). ``clear()`` clear the widget's current value. Equivalent to ``widget.set_value(None)``. """ but Docutils doesn't seem to like my notation for argument types: Reporter: WARNING (2) Inline literal start-string without end-string at line 10. Reporter: WARNING (2) Inline literal start-string without end-string at line 15. If I remove the whitespace around the colons, it doesn't complain. Oh... bugger... I seem to have run afoul of the "classifier" feature of definition lists. (Have I mentioned how nice it is that reST has a semi-formal spec?) This would be only slightly annoying if it weren't for the fact that that feature appears to have been at least vaguely inspired by the type syntax that I invented for Grouch. That raises it from "slightly annoying" to "richly ironic", I think. So is there a way to work around that feature? I tried backslashing the colons, and they just came out backslashed in the HTML output. Greg -- Greg Ward - software developer gw...@me... MEMS Exchange http://www.mems-exchange.org |
From: Greg W. <gw...@me...> - 2002-10-01 21:13:25
|
Just doing my first mass restructuredtextification (is that the appropriate terminology?) of some docs, and I noticed that Konqueror 2.2.2 formats HTML documents slightly differently if they have <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> -- in particular, the vertical line spacing is too much. If I edit out the "charset=utf-8", then it looks perfectly ordinary. Ditto if I s/utf-8/us-ascii/ -- that looks fine. Anyone else seen this? Guess I'll just use "-o us-ascii" for now. Greg |