You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
(27) |
Jun
(22) |
Jul
(72) |
Aug
(82) |
Sep
(86) |
Oct
(138) |
Nov
(100) |
Dec
(62) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(122) |
Feb
(147) |
Mar
(92) |
Apr
(82) |
May
(101) |
Jun
(153) |
Jul
(37) |
Aug
(34) |
Sep
(46) |
Oct
(46) |
Nov
(6) |
Dec
(38) |
2004 |
Jan
(64) |
Feb
(81) |
Mar
(36) |
Apr
(194) |
May
(329) |
Jun
(272) |
Jul
(68) |
Aug
(74) |
Sep
(150) |
Oct
(57) |
Nov
(62) |
Dec
(63) |
2005 |
Jan
(78) |
Feb
(30) |
Mar
(137) |
Apr
(78) |
May
(54) |
Jun
(122) |
Jul
(72) |
Aug
(110) |
Sep
(80) |
Oct
(75) |
Nov
(125) |
Dec
(79) |
2006 |
Jan
(100) |
Feb
(15) |
Mar
(41) |
Apr
(67) |
May
(30) |
Jun
(11) |
Jul
(14) |
Aug
(22) |
Sep
(20) |
Oct
(14) |
Nov
(11) |
Dec
(15) |
2007 |
Jan
(17) |
Feb
(16) |
Mar
(35) |
Apr
(21) |
May
(33) |
Jun
(50) |
Jul
(12) |
Aug
(7) |
Sep
(2) |
Oct
(6) |
Nov
(5) |
Dec
(2) |
2008 |
Jan
(14) |
Feb
(20) |
Mar
(35) |
Apr
(9) |
May
(57) |
Jun
(21) |
Jul
(42) |
Aug
(4) |
Sep
(13) |
Oct
(76) |
Nov
(40) |
Dec
(55) |
2009 |
Jan
(26) |
Feb
(15) |
Mar
(3) |
Apr
(67) |
May
(32) |
Jun
(39) |
Jul
(59) |
Aug
(31) |
Sep
(59) |
Oct
(64) |
Nov
(21) |
Dec
(10) |
2010 |
Jan
(21) |
Feb
(3) |
Mar
(116) |
Apr
(33) |
May
(9) |
Jun
(28) |
Jul
(21) |
Aug
(23) |
Sep
(146) |
Oct
(70) |
Nov
(31) |
Dec
(57) |
2011 |
Jan
(33) |
Feb
(22) |
Mar
(11) |
Apr
(21) |
May
(51) |
Jun
(47) |
Jul
(35) |
Aug
(26) |
Sep
(25) |
Oct
(34) |
Nov
(61) |
Dec
(51) |
2012 |
Jan
(75) |
Feb
(31) |
Mar
(26) |
Apr
(16) |
May
(24) |
Jun
(24) |
Jul
(31) |
Aug
(46) |
Sep
(36) |
Oct
(28) |
Nov
(37) |
Dec
(21) |
2013 |
Jan
(16) |
Feb
(56) |
Mar
(31) |
Apr
(44) |
May
(45) |
Jun
(29) |
Jul
(38) |
Aug
(18) |
Sep
(12) |
Oct
(16) |
Nov
(21) |
Dec
(11) |
2014 |
Jan
(13) |
Feb
(14) |
Mar
(28) |
Apr
(7) |
May
(72) |
Jun
(33) |
Jul
(21) |
Aug
(1) |
Sep
(6) |
Oct
(14) |
Nov
(18) |
Dec
(22) |
2015 |
Jan
(23) |
Feb
(108) |
Mar
(76) |
Apr
(114) |
May
(60) |
Jun
(9) |
Jul
(8) |
Aug
(9) |
Sep
(42) |
Oct
(9) |
Nov
|
Dec
(7) |
2016 |
Jan
(6) |
Feb
(15) |
Mar
(7) |
Apr
|
May
(33) |
Jun
(3) |
Jul
(19) |
Aug
(12) |
Sep
(6) |
Oct
(16) |
Nov
(17) |
Dec
(125) |
2017 |
Jan
(66) |
Feb
(98) |
Mar
(29) |
Apr
(32) |
May
(63) |
Jun
(98) |
Jul
(26) |
Aug
(33) |
Sep
(19) |
Oct
(77) |
Nov
(31) |
Dec
(27) |
2018 |
Jan
(32) |
Feb
(11) |
Mar
(5) |
Apr
(12) |
May
(4) |
Jun
(9) |
Jul
(9) |
Aug
(13) |
Sep
(11) |
Oct
(6) |
Nov
(23) |
Dec
(2) |
2019 |
Jan
(26) |
Feb
(12) |
Mar
(20) |
Apr
(18) |
May
(7) |
Jun
(22) |
Jul
(81) |
Aug
(129) |
Sep
(32) |
Oct
(18) |
Nov
(11) |
Dec
(44) |
2020 |
Jan
(19) |
Feb
(10) |
Mar
(38) |
Apr
(4) |
May
(9) |
Jun
(15) |
Jul
(29) |
Aug
(79) |
Sep
(12) |
Oct
(22) |
Nov
(10) |
Dec
(37) |
2021 |
Jan
(16) |
Feb
(14) |
Mar
(20) |
Apr
(100) |
May
(21) |
Jun
(19) |
Jul
(13) |
Aug
(13) |
Sep
(37) |
Oct
(112) |
Nov
(64) |
Dec
(22) |
2022 |
Jan
(209) |
Feb
(38) |
Mar
(11) |
Apr
(10) |
May
(55) |
Jun
(104) |
Jul
(35) |
Aug
(10) |
Sep
(21) |
Oct
(21) |
Nov
(50) |
Dec
(12) |
2023 |
Jan
(6) |
Feb
|
Mar
(3) |
Apr
(41) |
May
(48) |
Jun
(9) |
Jul
(6) |
Aug
(25) |
Sep
(3) |
Oct
(22) |
Nov
(56) |
Dec
(12) |
2024 |
Jan
(5) |
Feb
(5) |
Mar
(38) |
Apr
(62) |
May
(12) |
Jun
(10) |
Jul
(3) |
Aug
(59) |
Sep
(2) |
Oct
(36) |
Nov
(14) |
Dec
(3) |
2025 |
Jan
(5) |
Feb
(19) |
Mar
(7) |
Apr
(65) |
May
(11) |
Jun
(13) |
Jul
(46) |
Aug
(27) |
Sep
(33) |
Oct
(1) |
Nov
|
Dec
|
From: Tony J I. (Tibs) <to...@ls...> - 2002-05-09 09:01:11
|
David Goodger wrote: > I've added a "Project Policies" section to the notes: > > http://docutils.sf.net/spec/notes.html#project-policies > > Please take a look; I'd like to hear opinions. Is it > reasonable? Anything objectionable? Thanks. Looking at Coding Conventions... Well, pysource is a big offender on the naming conventions for non-classes, but I am aware of that and have intended to fix it (camelCase method names for the visitor methods used to wander over the Python are indicated by the visitor mechanism [you'll need to add an allowable exception for cases like this, I'm afraid], and that rather propagated, even though it is not normally the convention I use). As I said, something I intend strongly to fix at some point. The "single quote for string literals" is a problem to me - I have never been aware of this preference - indeed, I thought the "standard" Python preference was the other way round (for no reason I can think of). I have a lot of existing code that would need changing to match that, and *personally* am not very motivated, since I find 'string' harder to see than "string" (unless colour coded). On the other hand, following a consistent set of rules is a good thing. On the other other hand, I am actually surprised there *is* a policy on this, since Python itself doesn't care... Hmm - not sure where I stand on that - obviously I'd prefer not to change my ways, but also I prefer to code to standards if they exist. Can you point to where this is documented outwith your text? (fighting whilst not sure he should!) The CVS part looks good, and I like the explanation of how to use the sandbox. Tibs -- Tony J Ibbs (Tibs) http://www.tibsnjoan.co.uk/ Give a pedant an inch and they'll take 25.4mm (once they've established you're talking a post-1959 inch, of course) My views! Mine! Mine! (Unless Laser-Scan ask nicely to borrow them.) |
From: David G. <go...@us...> - 2002-05-09 05:07:29
|
Richard Jones wrote: > Looks good to me. Might want to mention the line-continuation > indentation policy. You noticed my fiddling :-). I just use the Python standard, as implemented in the Emacs python-mode. Should I spell out the details, or is that too anal-retentive? -- 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: Richard J. <rj...@ek...> - 2002-05-09 04:34:25
|
On Thu, 9 May 2002 14:26, David Goodger wrote: > I've added a "Project Policies" section to the notes: > > http://docutils.sf.net/spec/notes.html#project-policies > > Please take a look; I'd like to hear opinions. Is it reasonable? Anything > objectionable? Thanks. Looks good to me. Might want to mention the line-continuation indentation policy. Richard |
From: David G. <go...@us...> - 2002-05-09 04:24:46
|
I've added a "Project Policies" section to the notes: http://docutils.sf.net/spec/notes.html#project-policies Please take a look; I'd like to hear opinions. Is it reasonable? Anything objectionable? 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: David G. <go...@us...> - 2002-05-07 17:24:12
|
[moving to Doc-SIG for greater exposure] David Goodger wrote: >> However, a literal block isn't really the ideal way to represent an >> address block, is it? I've been mulling over an idea for a "verse" >> directive which seems to apply here. See >> http://docutils.sf.net/spec/notes.html#body-verse. What do you >> think? How about that ';;' syntax? Tony J Ibbs (Tibs) wrote: > As you say, the outstanding question is interpretation of inline markup > within a verse - i.e., in HTML terms, is it <pre> or not... Literal blocks use <pre> exclusively and treat all whitespace and line breaks as significant; no inline markup is recognized. In "verse blocks" (semi-literal blocks; anybody have a better name?) only line breaks and indentation are treated differently from a regular paragraph; inline markup like *emphasis* is recognized normally. > Thinking *about* verses, I'd obviously argue for allowing inline markup, > but am unfussed about lists I don't think lists or anything else are necessary. Verse blocks can be thought of as variations of paragraphs, which don't have nested constructs in the Docutils model. > I'm not *too* keen on the use of ";;", but it does have a clear analogy > with "::", and it's unlikely to be used "by mistake". I assume the rules > of how it appears are identical to those for "::"? (i.e., precede with a > space to suppress a colon in the output?) Perhaps, although I don't think people will want to end a paragraph with a semicolon. -- 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: Tony J I. (Tibs) <to...@ls...> - 2002-05-07 09:03:37
|
David Goodger wrote: > However, a literal block isn't really the ideal way to represent an > address block, is it? I've been mulling over an idea for a "verse" > directive which seems to apply here. See > http://docutils.sf.net/spec/notes.html#body-verse. What do you > think? How about that ';;' syntax? Hmm - a useful thing to be able to do. I suspect that this *allows* me to handle (although not necessarily in the way I'd like best) the majority of cases where I might want forced line breaks - in the same way that "::" allows me to handle most places where I want to escape a character. As you say, the outstanding question is interpretation of inline markup within a verse - i.e., in HTML terms, is it <pre> or not... Thinking *about* verses, I'd obviously argue for allowing inline markup, but am unfussed about lists (I don't have any examples *I can think of* of poetry that uses them, for instance). But I trust you to work out the details here, I think. I'm not *too* keen on the use of ";;", but it does have a clear analogy with "::", and it's unlikely to be used "by mistake". I assume the rules of how it appears are identical to those for "::"? (i.e., precede with a space to suppress a colon in the output?) (personally, a "..verse" (or even "..sing"!) directive would be OK by me as well...) Tibs ..pedant:: In the second poem, should "stint" be "skint"? -- Tony J Ibbs (Tibs) http://www.tibsnjoan.co.uk/ "How fleeting are all human passions compared with the massive continuity of ducks." - Dorothy L. Sayers, "Gaudy Night" My views! Mine! Mine! (Unless Laser-Scan ask nicely to borrow them.) |
From: David G. <go...@us...> - 2002-05-07 04:24:46
|
Richard Jones wrote: > > I've hit another error in a definition list... note the line > > number the error is reported at, and the line that is actually > > erroneous (the last one). I replied: > I see it. I'll see about fixing the error reporting. It may take a > bit of thought though, so don't hold your breath. Fixed it: the truly erroneous line's line number is now reported. The fix was much easier than I thought it would be. Turns out there were several tests that also had wrong line numbers in their system messages; fixed them too. -- 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-05-06 04:51:49
|
Richard Jones wrote: >>> Reporter: WARNING (2) Literal block expected at line 2; none found. >> >> This is a tricky one. Because field list field names can be quite >> long, the spec allows for arbitrary minimum indentation of the second >> and subsequent lines [#]_, without inferring any significance. In >> other words, the address block is not seen as being indented at all, >> but just as a second paragraph. So as far as the parser is concerned, >> there *is* no literal block to be found! > > Sorry, I read the spec wrong Perhaps so, but it shows up a weakness in the spec that ought to be corrected, one way or another. This fails the "unsurprising" test. I'll up the priority of that particular to-do item. -- 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: Richard J. <rj...@ek...> - 2002-05-06 04:33:54
|
On Mon, 6 May 2002 14:26, David Goodger wrote: > Richard Jones wrote: > > I've got some problems in parsing a document. The following biblio > > > > element results in errors: > > >>>>> snip > > : > > :Organization: Computer and Information Sciences:: > > > > New Jersey Institute of Technology > > University Heights > > Newark, NJ, 07102 > > (address obsolescent). > > <<<<< snip > > I'll take the warnings in reverse order. > > > Reporter: WARNING (2) Cannot extract compound bibliographic field > > "Organization". > > This is by design of the document model. The "organization" element > currently may only contain text, not body elements. It was intended > to only contain the organization's name. You present a good example > of why the status quo perhaps ought to change. Requires thought. I figured that that's the problem - yes, it needs a solution :) > However, a literal block isn't really the ideal way to represent an > address block, is it? I've been mulling over an idea for a "verse" > directive which seems to apply here. See > http://docutils.sf.net/spec/notes.html#body-verse [#]_. What do you > think? How about that ';;' syntax? Yes, just noticed those checkins. I like the idea. there's a lot of situations where a hard newline would be really nice. I'm pretty sure this proposal takes care of all the ones I have run into so far. > .. [#] Just updated. Especially note the examples; I love having > *Monty Python's Flying Circus: Just The Words* and *The Fairly > Incomplete & Rather Badly Illustrated Monty Python Songbook* on my > reference shelf, and I refer to them frequently (can you tell?). > Makes programming fun! Thank Guido for Python! Made me chuckle ;) > > Reporter: WARNING (2) Literal block expected at line 2; none found. > > This is a tricky one. Because field list field names can be quite > long, the spec allows for arbitrary minimum indentation of the second > and subsequent lines [#]_, without inferring any significance. In > other words, the address block is not seen as being indented at all, > but just as a second paragraph. So as far as the parser is concerned, > there *is* no literal block to be found! Sorry, I read the spec wrong - I corrected it soon after sending the email. Richard |
From: David G. <go...@us...> - 2002-05-06 04:25:05
|
Richard Jones wrote: > I've got some problems in parsing a document. The following biblio > element results in errors: > > >>>>> snip > :Organization: Computer and Information Sciences:: > > New Jersey Institute of Technology > University Heights > Newark, NJ, 07102 > (address obsolescent). > <<<<< snip I'll take the warnings in reverse order. > Reporter: WARNING (2) Cannot extract compound bibliographic field > "Organization". This is by design of the document model. The "organization" element currently may only contain text, not body elements. It was intended to only contain the organization's name. You present a good example of why the status quo perhaps ought to change. Requires thought. However, a literal block isn't really the ideal way to represent an address block, is it? I've been mulling over an idea for a "verse" directive which seems to apply here. See http://docutils.sf.net/spec/notes.html#body-verse [#]_. What do you think? How about that ';;' syntax? .. [#] Just updated. Especially note the examples; I love having *Monty Python's Flying Circus: Just The Words* and *The Fairly Incomplete & Rather Badly Illustrated Monty Python Songbook* on my reference shelf, and I refer to them frequently (can you tell?). Makes programming fun! Thank Guido for Python! > Reporter: WARNING (2) Literal block expected at line 2; none found. This is a tricky one. Because field list field names can be quite long, the spec allows for arbitrary minimum indentation of the second and subsequent lines [#]_, without inferring any significance. In other words, the address block is not seen as being indented at all, but just as a second paragraph. So as far as the parser is concerned, there *is* no literal block to be found! I think this is correct behavior; perhaps the docs need some clarification. I invite counter-arguments, to either of the preceding statements. ;-) .. [#] See http://docutils.sf.net/spec/rst/reStructuredText.html#field-lists, end of third paragraph, and http://docutils.sf.net/spec/rst/reStructuredText.html#indentation, last paragraph before the literal block. To rectify this problem, just rewrite that field list item as follows:: :Organization: Computer and Information Sciences:: New Jersey Institute of Technology University Heights Newark, NJ, 07102 (address obsolescent). Now the indentation of the literal block *is* significant (it's different from the indentation of the second line). However, you'll either have to wait for a change to the document model (not guaranteed!), or rewrite the field list item, either as a single paragraph, or something like this:: :Organization: Computer and Information Sciences, New Jersey Institute of Technology [#]_ .. [#] :: University Heights Newark, NJ, 07102 (address obsolescent). Note that the '::' has to be on the second line of the footnote, for the same reason as given above for the field list item. This behavior may change, however (there's a to-do list entry that begins with "Fix the parser's indentation handling" in http://docutils.sf.net/spec/notes.html#restructuredtext-parser). > I've hit another error in a definition list... note the line number > the error is reported at, and the line that is actually erroneous > (the last one). I see it. I'll see about fixing the error reporting. It may take a bit of thought though, so don't hold your breath. As always, thanks for the feedback. It will make its way into the code and/or the docs, anon. -- 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: Richard J. <rj...@ek...> - 2002-05-06 01:11:47
|
I've got some problems in parsing a document. The following biblio element results in errors: >>>>> snip :Organization: Computer and Information Sciences:: New Jersey Institute of Technology University Heights Newark, NJ, 07102 (address obsolescent). <<<<< snip Reporter: WARNING (2) Literal block expected at line 2; none found. Reporter: WARNING (2) Cannot extract compound bibliographic field "Organization". I've hit another error in a definition list... note the line number the error is reported at, and the line that is actually erroneous (the last one). >>>>> snip S.member(ob), D.member(arg,map), G.member(src,dst) respectively are membership tests for the types. Each returns 1 if the object or pair are members of the structure or 0 otherwise. S.add(ob), D.add(arg,map), G.add(src,dst) respectively add new members to the object. These are equivalent to G[src]=dst, D[arg]=map, S[ob]=1 but the former may be preferrable for graphs and sets since they are less misleading. This is an "in place" mutation operation -- it will raise an error if the object has been hashed. X.items() returns a list of the members of the structure. For example:: >>> X = kjSet([0, 1, 2, 0, 1]) >>> X.items() [1, 0, 2] >>> X = kjGraph([(3, 0), (2, 2), (1, 2), (2, 0), (2, 0), (3, 0)]) >>> X.items() [(1, 2), (3, 0), (2, 2), (2, 0)] G.keys(), G.values() return the left members and right members of pairs in the graph G respectively. For example:: >>> G = kjGraph([(4, 8), (0, 9), (1, 10), (4, 9), (3, 7), (3, 8), (2, >>> 7)]) >>> G.keys() [4, 0, 1, 3, 2] >>> G.values() [8, 9, 10, 9, 7, 8, 7] Note that keys eliminates redundancies, whereas values does not. These functions are also defined for dictionaries but are not defined for sets. <<<<< snip Reporter: WARNING (2) Definition list ends without a blank line; unexpected unindent at line 5. Richard |
From: David G. <go...@us...> - 2002-05-05 17:36:40
|
I've just finished a major round of checkins (subscribe at http://lists.sourceforge.net/lists/listinfo/docutils-checkins). Here's a summary of the changes I made: - Changed a lot of 'longnamesthatlooklikethis' into 'long_names_that_look_like_this'. Improves readability methinks. This will break most docutils-dependent code out there. Check in your code to the CVS tree and I'll help bring it up to date. (Tony, do you have any changes for pysource? Please send them if you can't CVS.) - Added a PEP reader. This provides support for RFC 2822 headers and recognizes 'PEP ####' and 'RFC ####' in the text as hyperlinks. I'm still working on a directive and a front-end, then I'll convert PEP 287 as a proof of concept. - Extracted the inline markup parsing code into a class of its own, docutils.parsers.rst.states.Inliner. This allows for easy subclassing (already in use by the PEP reader). - Made the html4css1.py writer XHTML-compatible: switched to lowercase element & attribute names; empty tag format. More may be required for full compatibility; I'll wait for bug reports. For more details, see http://docutils.sf.net/HISTORY.html. -- 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: Tony J I. (Tibs) <to...@ls...> - 2002-04-29 08:59:48
|
Engelbert Gruber wrote: > is anyone working on writers and when on which one ? David Goodger replied: > I've written a simple HTML writer, but I'm now working on other > components. No definite plans for additional writers yet. I've also got a simple HTML writer (one that doesn't use CSS) in pysource - at some stage that's likely to become more like David's in API - so getting ideas from David's Writer on how to do such things is still a good idea. I'd hope that someone will work on PDF at some point - I've still got an outstanding promise to Andy Robinson to push that idea around a bit at people. Tibs -- Tony J Ibbs (Tibs) http://www.tibsnjoan.co.uk/ .. "equal" really means "in some sense the same, but maybe not .. the sense you were hoping for", or, more succinctly, "is .. confused with". (Gordon McMillan, Python list, Apr 1998) My views! Mine! Mine! (Unless Laser-Scan ask nicely to borrow them.) |
From: David G. <go...@us...> - 2002-04-27 04:30:56
|
Engelbert Gruber wrote: > is anyone working on writers and when on which one ? I've written a simple HTML writer, but I'm now working on other components. No definite plans for additional writers yet. > any hints on a latex or rtf backend ? If you're volunteering to write one or both and are asking for help, great! I'll be happy to answer any questions you have. As Richard said, please take a look at the HTML writer for a start. If you're asking when LaTeX and RTF writers will be ready, I couldn't say. I don't know of anyone working on them yet. They're not a priority on my list. If they're important to you, please consider writing one and contributing it back to the project! Richard Jones wrote: > I'd say start with the HTML writer and work from there. It > implements formatting for most (all?) of the DOM. The docutils.writers.html4css1 module should support all elements; that's one if its goals. If it doesn't, that's a bug. -- David Goodger <go...@us...> Open-source projects: - Python Docutils: http://docutils.sourceforge.net/ - The Go Tools Project: http://gotools.sourceforge.net/ |
From: Richard J. <rj...@ek...> - 2002-04-26 12:09:37
|
On Fri, 26 Apr 2002 20:35, eng...@ss... wrote: > is anyone working on writers and when on which one ? > > any hints on a latex or rtf backend ? I'd say start with the HTML writer and work from there. It implements formatting for most (all?) of the DOM. Richard |
From: <eng...@ss...> - 2002-04-26 10:37:43
|
is anyone working on writers and when on which one ? any hints on a latex or rtf backend ? cheers -- --- Engelbert Gruber ----+ SSG Fintl,Gruber,Lassnig | A6410 Telfs Untermarkt 9 | Tel. ++43-5262-64727 ----+ |
From: David G. <go...@us...> - 2002-04-20 19:09:19
|
The purpose of the Docutils project is to create a set of tools for processing plaintext documentation into useful formats, such as HTML, XML, and TeX. It is the subject of PEPs 256 & 258. Docutils currently supports input from standalone files; soon it will process PEPs, and eventually it will support inline documentation from Python modules and packages. Docutils uses the reStructuredText markup, the subject of PEP 287; other markups are possible. It produces simple HTML for CSS; other formats will become available in time. Quick link to the download: http://prdownloads.sf.net/docutils/docutils-0.1.tar.gz Docutils home page: http://docutils.sourceforge.net/ To subscribe to the mailing lists: - Development discussions (doc...@li...): http://lists.sourceforge.net/lists/listinfo/docutils-develop - CVS checkin messages: http://lists.sourceforge.net/lists/listinfo/docutils-checkins High-level discussions take place on the Python Doc-SIG mailing list: http://mail.python.org/mailman/listinfo/doc-sig, mailto:Do...@py... A ReStructuredText Primer (gentle introduction): http://docutils.sf.net/docs/rst/quickstart.html Quick reStructuredText (user reference): http://docutils.sf.net/docs/rst/quickref.html There has been a lot of progress lately. The reStructuredText parser is feature-complete, there's a standalone input file reader, and a simple HTML/CSS writer. The web site's HTML files are generated from reStructuredText source (the quickref being the only exception). There are a few simple front-ends in docutils/tools; see the README: http://docutils.sf.net/README.html. There is still much work to be done. Contributors are welcome! Release 0.1 (2002-04-20) ======================== This is the first release of Docutils, merged from the now inactive reStructuredText_ and `Docstring Processing System`_ projects. For the pre-Docutils history, see the `reStructuredText HISTORY`_ and `DPS HISTORY`_ files. .. _reStructuredText: http://structuredtext.sf.net/ .. _Docstring Processing System: http://docstring.sf.net/ .. _reStructuredText HISTORY: http://structuredtext.sf.net/HISTORY.html .. _DPS HISTORY: http://docstring.sf.net/HISTORY.html General changes: renamed 'dps' package to 'docutils'; renamed 'restructuredtext' subpackage to 'rst'; merged the codebases; merged the test suites (reStructuredText's test/test_states renamed to test/test_rst); and many modifications required to make it all work. -- David Goodger <go...@us...> Open-source projects: - Python Docutils: http://docutils.sourceforge.net/ - The Go Tools Project: http://gotools.sourceforge.net/ |