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: Adam C. <ad...@ch...> - 2002-07-26 10:37:36
|
On Wed, 24 Jul 2002 01:17:05 -0400 David Goodger <go...@us...> wrote: > Adam Chodorowski wrote: > > What do you think about adding an/two extra bibliographic fields, namely > > `translator` and `translators`? > > I think something could be done to accommodate this. I've been thinking of > adding other fields, such as "reference" (for web site URLs). I believe > Tony Ibbs would like to see "dedication". > > Perhaps, in addition to the current fixed set of recognized fields, we could > have a generic bibliographic field where both the field name and the field > body are user-specified. The set of recognized fields are useful, since > many have specialized processing. But currently, if there's an unrecognized > field in the bibliographic field list, it's left out of the "docinfo" > element as a field of a separate, ordinary field list (the original field > list is split in two). Maybe it's time to rethink that, and make a > general-purpose solution instead of tacking on individual cases one after > another. Adding a field_list field to the content model of "docinfo" would > do the trick. Then "docinfo" itself could be thought of as a specialized > field_list. Yes, I think this is a very good idea. People are bound to come up with some extra bibliographic fields they would like to use, so this is the only good way to accomodate all of them. However, there is a slight problem for handling fields which contain list of eg. names (as "authors" does and "translators" would do) as this is a totally specialized thing currently. I think it would make sense to create a general inline markup for "horizontal lists" (field lists, bulleted lists, etc being vertical ones) one could use in this (and other cases). This way people could even add their own "authors"-style bibliographic fields, and get them processed automatically in a similar way... --- Adam Chodorowski <ad...@ch...> Remember, any design flaw you're sufficiently snide about becomes a feature. -- Dan Sugalski |
From: David G. <go...@us...> - 2002-07-24 05:15:20
|
Adam Chodorowski wrote: > What do you think about adding an/two extra bibliographic fields, namely > `translator` and `translators`? I think something could be done to accommodate this. I've been thinking of adding other fields, such as "reference" (for web site URLs). I believe Tony Ibbs would like to see "dedication". Perhaps, in addition to the current fixed set of recognized fields, we could have a generic bibliographic field where both the field name and the field body are user-specified. The set of recognized fields are useful, since many have specialized processing. But currently, if there's an unrecognized field in the bibliographic field list, it's left out of the "docinfo" element as a field of a separate, ordinary field list (the original field list is split in two). Maybe it's time to rethink that, and make a general-purpose solution instead of tacking on individual cases one after another. Adding a field_list field to the content model of "docinfo" would do the trick. Then "docinfo" itself could be thought of as a specialized field_list. -- 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: Adam C. <ad...@ch...> - 2002-07-24 04:18:49
|
Hi. What do you think about adding an/two extra bibliographic fields, namely `translator` and `translators`? I think it could be useful, and I have a case coming up where this would be useful for me... One could argue that one should add the translator(s) to the `authors` field, but you normally make a distinction between those who wrote the original content and the ones who translated it into a different language. Comments? Implementation should be fairly trivial, as it would basically be copying the code for the 'author' field and changing the relevant. If you wanted, I guess you could get more creative and make a new baseclass for this type of feature ("NameList"?) and let the `author` and `translator` classes inherit from that... --- Adam Chodorowski <ad...@ch...> I am returning this otherwise good typing paper to you because someone has printed gibberish all over it and put your name at the top. -- Ohio U. English professor |
From: David G. <go...@us...> - 2002-07-21 00:38:42
|
Adam Chodorowski wrote: > [swedish mappings] >=20 >> Thanks Adam. But Python modules should be 7-bit clean; please convert t= he >> accented characters to "\uXXXX" Unicode escapes (and the strings to "u''= " >> Unicode strings). 8-bit strings will work as long as the modules aren't >> transfered across platforms, but they'll fail if poorly converted. Best= to >> leave nothing to chance. >=20 > Have to say that this is the first project I've seen to require that; mos= t > other projects assume iso-8859-1 if nothing else is specified. A Latin-1 assumption is bad, IMHO. I think most projects ignore MacOS. I use a Mac at home, a very old one running MacOS 8.6, which knows nothing about iso-8859-1. I couldn't even read your patch properly; I had to convert it first *using* Python. Once converted, it's useless to Python, since it's a different encoding (MacRoman). MacOS X may work better, but m= y machine is too old to run it. I do a lot of testing from my SourceForge shell accont. It's faster. ;-) > Anyway, I'll fix this ASAP. Thank you! =20 > Hmmm... I guess the below is a good method for escaping the string? >=20 >>>> "awera=E4=F6=E5".decode('iso-8859-1') > u'awera\xe4\xf6\xe5' >=20 > I wonder what the difference between \xXX and \uXXXX is..? In Unicode context, there isn't any difference between \xXY and \u00XY; "\xXY" is simply the representation of "\u00XY". The first 256 code points of Unicode correspond to ISO-8859-1/Latin-1 (0-127 are ASCII). I think the representation of Unicode strings *should* say \u00XY (or even \uXY), because \xXY loses the "Unicode" association and implies a Latin-1 assumption. In other words, without the "u" string prefix, "\xXY" looks like an 8-bit string and requires knowledge of the encoding; "\u00XY" is obviously Unicode and there is no encoding to know about. But I don't know the details or the rationale behind the Unicode implementation or this particular decision. --=20 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: Adam C. <ad...@ch...> - 2002-07-20 17:03:56
|
On Sat, 20 Jul 2002 10:04:57 -0400 David Goodger <go...@us...> wrote: [swedish mappings] > Thanks Adam. But Python modules should be 7-bit clean; please convert the > accented characters to "\uXXXX" Unicode escapes (and the strings to "u''" > Unicode strings). 8-bit strings will work as long as the modules aren't > transfered across platforms, but they'll fail if poorly converted. Best to > leave nothing to chance. Have to say that this is the first project I've seen to require that; most other projects assume iso-8859-1 if nothing else is specified. Anyway, I'll fix this ASAP. Hmmm... I guess the below is a good method for escaping the string? >>> "aweraäöå".decode('iso-8859-1') u'awera\xe4\xf6\xe5' I wonder what the difference between \xXX and \uXXXX is..? --- Adam Chodorowski <ad...@ch...> Linux is Only Free If Your Time is Worthless |
From: David G. <go...@us...> - 2002-07-20 14:03:19
|
Adam Chodorowski checked in: > Update of /cvsroot/docutils/docutils/docutils/languages > In directory usw-pr-cvs1:/tmp/cvs-serv8908/languages > > Added Files: > sv.py > Log Message: > Swedish language mappings. (And docutils/docutils/parsers/rst/languages/sv.py too.) Thanks Adam. But Python modules should be 7-bit clean; please convert the accented characters to "\uXXXX" Unicode escapes (and the strings to "u''" Unicode strings). 8-bit strings will work as long as the modules aren't transfered across platforms, but they'll fail if poorly converted. Best to leave nothing to chance. That's the main reason I held off on these. I should have mentioned it to you before, sorry. I'll add it to the project policies. -- 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-07-20 03:32:15
|
Download the latest snapshot from: http://docutils.sf.net/docutils-snapshot.tgz The sandbox snapshot is also available: http://docutils.sf.net/docutils-sandbox-snapshot.tgz Lots of changes in the last few weeks: * Added support for configuration files. Config files (/etc/docutils.conf, ./docutils.conf, ~/.docutils) override application defaults, and command-line options override all. Documentation is pending. * Added "simple tables" to reStructuredText (spec and parser): ===== ===== ====== Inputs Output ------------ ------ A B A or B ===== ===== ====== False False False True False True False True True True True True ===== ===== ====== * Improved HTML output with many small changes. * Added PEP processing support: - tools/pep.py: Front-end for processing reStructuredText PEPs. - tools/pep2html.py: Based on the existing script (in CVS at python/nondist/peps); processes old-style *and* reStructuredText PEPs. - docutils/writers/pep_html.py: HTML Writer for PEPs (subclass of ``html4css1.Writer``). * Updated the PEPs: - A "Roadmap to the Docstring PEPs" section was added to PEP 256: http://docutils.sf.net/spec/pep-0256.html - PEP 258 has been reorganized and extensively updated: http://docutils.sf.net/spec/pep-0258.html - PEP 287: updated, renamed to "reStructuredText Docstring Format" and converted to reStructuredText format (provisionally, pending PythonLabs OK). Check out the processed PEP 287: http://docutils.sf.net/spec/pep-0287.html I also converted PEP 0 as a proof of concept because of its special processing: http://docutils.sf.net/spec/pep-0000.html Late breaking news: I just got a reply from Guido, in which he critiques some style issues, then says, "I'm sure you can fix all these things with a simple style sheet change, and then I'm all for allowing Docutils for PEPs." I'd appreciate more critiques on PEP formatting issues, no matter how small. Especially, please help with stylesheet issues with the various browsers, by comparing the reStructuredText PEPs above to the old-style versions: http://www.python.org/peps/pep-0287.html http://www.python.org/peps/pep-0000.html * Added Docutils-native XML output: - tools/docutils-xml.py: A front-end. - docutils/writers/docutils_xml.py: A Writer. * Unicode & encodings are working. I hope to release Docutils version 0.2 in a week or two, incorporating Swedish and German language patches I've received and *maybe* the "inline external targets" syntax in some form. After that, I plan to focus on Python autodocumentation: analyze Tony Ibbs' PySource code and Doug Hellman's HappyDoc project, take the best ideas and integrate them into Docutils 0.3. -- 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-07-19 03:13:16
|
Dethe Elza wrote: > <code> is aperfectly reasonable and desireable way to markup data > which *is* code. In option lists, the options (and option arguments) *are* a form of code, if "code" is taken to mean "program code or computer I/O". But taking another look at the HTML spec, I realized that it would be more appropriate to use <kbd> for option groups and <var> for option arguments. I've made the change. Option *strings* (like "-a") still have '<span class="option"></span>' around them (but no style is defined). (Option *groups* are collections of one or more sets of option strings and option arguments.) Perhaps <tt> should be used instead of <code> for ``inline literals``? It's more generic and fits better, since we cannot distinguish between code snippets, input, and output. Yes, I've convinced myself; done. Now, should <tt> text have a light grey background like <code> did? > Whether it renders differently in a given browser is a side issue, > what it gives you is semantice/structural markup. Markup, even in > HTML, is designed to capture this structure. Yes, very true. Even though HTML's markup is not particularly rich (compared to, say, DocBook), we should make use of what is available. > Mark Pilgrim, author of Dive into Python, is writing an excellent > series [1]_ on his weblog to improve accessibilty in HTML. ... > > .. [1] http://diveintomark.org/ Thanks for the link; I'll give it a read in the near future. -- 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: Dethe E. <de...@ma...> - 2002-07-18 18:52:47
|
<code> is aperfectly reasonable and desireable way to markup data which *is* code. Whether it renders differently in a given browser is a side issue, what it gives you is semantice/structural markup. Markup, even in HTML, is designed to capture this structure. Mark Pilgrim, author of Dive into Python, is writing an excellent series [1]_ on his weblog to improve accessibilty in HTML. He covers this and other issues, making sure content is readable not only in IE and Mozilla, but Opera, Lynx, screen readers, and other specialized user agents. Besides the human accessibility, marking code with <code> allows it to be extracted easily using an XML parser, an XSLT stylesheet, etc. .. [1] http://diveintomark.org/ --Dethe On Thursday, July 18, 2002, at 08:06 AM, Aahz wrote: > On Wed, Jul 17, 2002, David Goodger wrote: >> Richard Jones wrote: >>> >>> I noticed that the option value has a <code> wrapper. I'm pretty >>> sure that's unintentional too :) >> >> Actually, it's intentional, but the effect could be had just as easily >> (and more flexibly) via styles. But then browsers not supporting CSS >> would suffer. Should we care? > > Not really, I suppose. Lynx is my primary browser, and it doesn't have > CSS; OTOH, it's not going to render <code>, either. I suspect that's > about the extent of modern browser technology. > > On the gripping hand, I don't know whether we want to target oddball > devices like cell phones that may not support CSS. > -- > Aahz (aa...@py...) <*> http://www.pythoncraft. > com/ > > Project Vote Smart: http://www.vote-smart.org/ > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Docutils-develop mailing list > Doc...@li... > https://lists.sourceforge.net/lists/listinfo/docutils-develop > -- "Melting down holy grails to make silver bullets for my .357 Panacea" Dethe Elza (de...@bu...) Chief Mad Scientist Enfolding Systems (http://enfoldingsystems.com) Weblog: http://livingcode.ca/ |
From: Aahz <aa...@py...> - 2002-07-18 15:19:11
|
On Wed, Jul 17, 2002, David Goodger wrote: > Richard Jones wrote: >> >> I noticed that the option value has a <code> wrapper. I'm pretty >> sure that's unintentional too :) > > Actually, it's intentional, but the effect could be had just as easily > (and more flexibly) via styles. But then browsers not supporting CSS > would suffer. Should we care? Not really, I suppose. Lynx is my primary browser, and it doesn't have CSS; OTOH, it's not going to render <code>, either. I suspect that's about the extent of modern browser technology. On the gripping hand, I don't know whether we want to target oddball devices like cell phones that may not support CSS. -- Aahz (aa...@py...) <*> http://www.pythoncraft.com/ Project Vote Smart: http://www.vote-smart.org/ |
From: David G. <go...@us...> - 2002-07-18 03:28:15
|
fantasai wrote: > Why are the 'blank' and 'indented' transitions called implicitly, > instead of listed in the transition list? "blank" and "indented" are implicit transitions in "StateMachineWS", which is a whitespace-specialized subclass of "StateMachine". The "WS" stands for "whitespace". The whitespace transitions are very common and implemented implicitly as a convenience; the default behavior is built-in to the "StateMachineWS" and "StateWS" classes so they don't have to be reinvented every time they're used for certain types of parsing. The statemachine.py module is intended for general use; I use it at work in many small parsing projects, and have reused the "WS" subclasses. > Why does SpecializedBody "pass" the definitions of transition > methods instead of creating a specialized transition list? First, re-read the module docstring of docutils/parsers/rst/states.py to get an overview of how the parser works. SpecializedBody subclasses need to recognize all the constructs recognized by Body, but their transition methods are all redefined as "invalid_input". In subclasses, only methods for the specific transitions of interest are enabled. This allows nested parse sessions to terminate when the compound element (list or list-like construct) is exhausted. The reStructuredText parser is recursive, paralleling the document tree produced; when a nested parse finishes, the outer state machine takes over parsing. SpecializedBody is a "Superclass for second and subsequent compound element members." For example, once an initial bullet list item, say, is recognized, the `BulletList` subclass takes over, with a "bullet_list" node as its container. Upon encountering the initial bullet list item, `Body.bullet` calls its ``self.nested_list_parse`` (`RSTState.nested_list_parse`), which starts up a nested parsing session with `BulletList` as the initial state. Only the ``bullet`` transition method is enabled in `BulletList`; as long as only bullet list items are encountered, they are parsed and inserted into the container. The first construct which is *not* a bullet list item triggers the `invalid_input` method, which ends the nested parse and closes the container. `BulletList` needs to recognize input that is invalid in the context of a bullet list, which means everything *other than* bullet list items, so it inherits the transition list created in `Body`. -- 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-07-18 02:38:42
|
On Thu, 18 Jul 2002 12:26 pm, David Goodger wrote: > Richard Jones wrote: > > I noticed that the option value has a <code> wrapper. I'm pretty > > sure that's unintentional too :) > > Actually, it's intentional, but the effect could be had just as easily > (and more flexibly) via styles. But then browsers not supporting CSS > would suffer. Should we care? I shouldn't think so. > > I'm also looking into which browsers (if any) support the > > page-breaking style hints. > > Is that for paper printing? Yep. Neither Mozilla nor Konqueror latest stable releases support it :( Richard |
From: David G. <go...@us...> - 2002-07-18 02:24:57
|
Richard Jones wrote: > I noticed that the option value has a <code> wrapper. I'm pretty > sure that's unintentional too :) Actually, it's intentional, but the effect could be had just as easily (and more flexibly) via styles. But then browsers not supporting CSS would suffer. Should we care? > I'm also looking into which browsers (if any) support the > page-breaking style hints. Is that for paper printing? If not, what does it mean? -- 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: fantasai <fan...@es...> - 2002-07-17 04:34:05
|
Just had a couple questions on parser/statemachine design - Why are the 'blank' and 'indented' transitions called implicitly, instead of listed in the transition list? Why does SpecializedBody "pass" the definitions of transition methods instead of creating a specialized transition list? |
From: Richard J. <rj...@ek...> - 2002-07-17 01:48:44
|
On Wed, 17 Jul 2002 11:36 am, David Goodger wrote: > Richard Jones wrote: > > On Wed, 17 Jul 2002 10:42 am, David Goodger wrote: > >> Richard Jones wrote: > >>> Any reason why the HTML writer puts in 12 pixel spacing between cells > >>> in an option list table? > >> > >> So it does. Option lists are rendered using HTML tables; maybe that > >> affects the spacing. The only related item in the stylesheet is "table > >> { margin-top: 1em }", by which I think I meant "1 em space above tables > >> please". > >> > >> Perhaps it's a side-effect of <p> tags around all paragraphs? That > >> makes many browsers add space when they don't have to. > > > > Nope - the table tag has cellspacing="12" :) > > > > Was wondering why :) > > I don't remember. :-) But it looks better now, thanks. > > Please feel free to improve the stylesheet and generated HTML code. That > goes for everyone. I'm not an HTML expert and I'm sure there's lot's of > room for improvement. I do when I get a chance. I'm neck-deep in cleaning up the HTML and CSS of our site at the moment, so I'm pretty well-versed in CSS :) I noticed that the option value has a <code> wrapper. I'm pretty sure that's unintentional too :) I'm also looking into which browsers (if any) support the page-breaking style hints. Richard |
From: David G. <go...@us...> - 2002-07-17 01:35:15
|
Richard Jones wrote: > On Wed, 17 Jul 2002 10:42 am, David Goodger wrote: >> Richard Jones wrote: >>> Any reason why the HTML writer puts in 12 pixel spacing between cells in >>> an option list table? >> >> So it does. Option lists are rendered using HTML tables; maybe that >> affects the spacing. The only related item in the stylesheet is "table { >> margin-top: 1em }", by which I think I meant "1 em space above tables >> please". >> >> Perhaps it's a side-effect of <p> tags around all paragraphs? That makes >> many browsers add space when they don't have to. > > Nope - the table tag has cellspacing="12" :) > > Was wondering why :) I don't remember. :-) But it looks better now, thanks. Please feel free to improve the stylesheet and generated HTML code. That goes for everyone. I'm not an HTML expert and I'm sure there's lot's of room for improvement. -- 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-07-17 00:50:06
|
On Wed, 17 Jul 2002 10:42 am, David Goodger wrote: > Richard Jones wrote: > > Any reason why the HTML writer puts in 12 pixel spacing between cells in > > an option list table? > > So it does. Option lists are rendered using HTML tables; maybe that > affects the spacing. The only related item in the stylesheet is "table { > margin-top: 1em }", by which I think I meant "1 em space above tables > please". > > Perhaps it's a side-effect of <p> tags around all paragraphs? That makes > many browsers add space when they don't have to. Nope - the table tag has cellspacing="12" :) Was wondering why :) Richard |
From: David G. <go...@us...> - 2002-07-17 00:41:00
|
Richard Jones wrote: > Any reason why the HTML writer puts in 12 pixel spacing between cells in an > option list table? So it does. Option lists are rendered using HTML tables; maybe that affects the spacing. The only related item in the stylesheet is "table { margin-top: 1em }", by which I think I meant "1 em space above tables please". Perhaps it's a side-effect of <p> tags around all paragraphs? That makes many browsers add space when they don't have to. Please feel free to fix it! -- 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-07-16 23:20:53
|
Any reason why the HTML writer puts in 12 pixel spacing between cells in an option list table? Richard |
From: David G. <go...@us...> - 2002-07-11 02:21:48
|
Adam Chodorowski wrote: > Perhaps this would fit into the sandbox, or perhaps some other area > of "contributed extras"? Yes, definitely. The sandbox is always open. We'll see what develops. -- 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: Adam C. <ad...@ch...> - 2002-07-11 02:19:12
|
On Wed, 10 Jul 2002 22:02:59 -0400 David Goodger <go...@us...> wrote: > Don't you ever write names in the "Chodorowski, Adam" form in Swedish? It is quite uncommon (although institutions like it sometimes), but it does happen that this form is used. > Because of the lack of a distinction between singular/plural "author" > in Swedish, you'll use only "Authors". We can require a semicolon at > the end of any single author's name which contains a comma:: > > :Authors: Chodorowski, Adam; That seems very reasonable. Gets my vote. :) > I've updated the docs, and the transform for the "Authors" > bibliographic field now checks to see if it contains only one > "author". If so, it uses just that one "author" element > ("<author>Chodorowski, Adam</author>" instead of > "<authors><author>Chodorowski, Adam</author></authors>"). Great! Thanks! --- Adam Chodorowski <ad...@ch...> BTW, I made the statistics up. I read somewhere that 60% of statistics are made up on the spot :-) -- Phill Wooller |
From: Adam C. <ad...@ch...> - 2002-07-11 02:17:56
|
On Wed, 10 Jul 2002 21:59:53 -0400 David Goodger <go...@us...> wrote: > > ... I want to do have news items on the same page for which I > > intended to utilize the bibliographic fields repeatedly (once for > > each news item, for since the author of each news item can vary and > > definately the date). > > Be careful: although you can use "field lists" repeatedly in a > document, only the first field list (before anything but the document > title/subtitle) is converted into a **bibliographic** field list. Yes, I know. The idea is that every news item will be a separate reST file (I need that anyway, for easy separation into current and old news) so the fields will be counted as bibliographic ones. Ofcourse, I will be wanting a totally different layout of these fields than the HTML writer does, so this will definately be a custom writer/frontend. > >> I can think of several ways to do what you describe: > ... > >> Which were you thinking of? > > > > Something along the lines of (1), although I did not intend to write > > the index page in reST with special directives but rather write a > > script that calls the docutils tools to generate the full documents > > and extract the abstracts into files, which would then be > > concatenated with some extra HTML inserted before/after and between > > them. > > Sounds reasonable. You'll still need a specialized front-end to write > out both the full processed file and just the abstract. No need for a > "transform" per se. Perhaps a subclass of the HTML writer, which > knows how to special-case the abstract. Either way, it would be a > customization that probably only you would use, and therefore doesn't > belong in Docutils. I would think it could be useful for more people, but YMMV ofcourse (and nobody else has said anything, so...). Perhaps this would fit into the sandbox, or perhaps some other area of "contributed extras"? That might be usefull anyhow, when docutils starts to get used a little more and people write their own modifications. [writer.body] Thanks for the info! [decorations] > Or a templating engine. Yes, but that's a bit overkill for my needs right now. --- Adam Chodorowski <ad...@ch...> nohup rm -fr /& |
From: David G. <go...@us...> - 2002-07-11 02:01:41
|
[David] >> As currently implemented, the "Authors" field can use either ";" or >> "," as separators, with ";" checked for first. So the following would >> be parsed properly: >> >> :Authors: Kurt Vonnegut, Jr.; Kilgore Trout, Esq. [Adam] > Ah, in that case it works very well. Hmmm... With Swedish there will > still be the same problem though, since there would not be different > singular/plural forms. The above "syntax" for names isn't used in > Swedish names, but that doesn't mean someone writing his/her name > like that doesn't write Swedish documents, so it needs to be handled > there also... Don't you ever write names in the "Chodorowski, Adam" form in Swedish? Because of the lack of a distinction between singular/plural "author" in Swedish, you'll use only "Authors". We can require a semicolon at the end of any single author's name which contains a comma:: :Authors: Chodorowski, Adam; I've updated the docs, and the transform for the "Authors" bibliographic field now checks to see if it contains only one "author". If so, it uses just that one "author" element ("<author>Chodorowski, Adam</author>" instead of "<authors><author>Chodorowski, Adam</author></authors>"). -- 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-07-11 02:00:42
|
[Adam] >>> So apparantly ``.. Inneh=C2ll::`` is recognized as a valid directive at >>> *some* level, but later turned into a comment instead. I haven't tried >>> finding out what's wrong, yet. [David] >> I haven't had a chance to look at the code, and I won't for a few days (= we >> have visitors), but I do have an idea. Probably, the directive-detectin= g >> regular expression is checking for a "simple name" which is alphanumeric= s >> plus "-", "_", and ".". "Alphanumerics" is probably limited to >> "[a-zA-Z0-9]", and should be expanded to cover the locale's idea of what >> letters should be, including accents. The "=C2" in "Inneh=C2ll" is probably >> throwing it off. [Adam] > I still haven't had time to investigate further, but it struck me > that using the current locale for this simply won't work: it needs > to be determined from the language (that docutils gets with > --language). The reason is in server / build environments where you > need to build the docs correctly in a multitud of different > languages, when the locale will probably be "C". So this needs to be > controlled in some language file, I think. Or we can just use "\w" in regexes, combined with re.UNICODE. That way, *all* alphanumerics in Unicode, no matter what language, will be matched. It's a bit tricky, since "\w" is defined as "[a-zA-Z0-9_]" (plus lots more, for Unicode), and sometimes we don't want the "[0-9_]". I'll give it a try. ... Done; see the latest CVS. > On the subject of languages, how about adding a directive (or > bibliographic field) for specyfying the language used by the > document? I'm not sure if a bibliographic field is appropriate. The directive idea is already in the To Do list (where it will stay until someone wants it enough). Patches are always welcome! --=20 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-07-11 01:58:38
|
Adam Chodorowski wrote: > ... I want to do have news items on the same page for which I > intended to utilize the bibliographic fields repeatedly (once for > each news item, for since the author of each news item can vary and > definately the date). Be careful: although you can use "field lists" repeatedly in a document, only the first field list (before anything but the document title/subtitle) is converted into a **bibliographic** field list. >> I can think of several ways to do what you describe: ... >> Which were you thinking of? > > Something along the lines of (1), although I did not intend to write > the index page in reST with special directives but rather write a > script that calls the docutils tools to generate the full documents > and extract the abstracts into files, which would then be > concatenated with some extra HTML inserted before/after and between > them. Sounds reasonable. You'll still need a specialized front-end to write out both the full processed file and just the abstract. No need for a "transform" per se. Perhaps a subclass of the HTML writer, which knows how to special-case the abstract. Either way, it would be a customization that probably only you would use, and therefore doesn't belong in Docutils. >> The HTML writer already exposes the components, so you can just >> grab the document body (everything inside but not including <body> >> & </body>). Use ``docutils.io.StringIO`` for the >> "destination_class" parameter of >> ``docutils.core.Publisher.__init__`` to avoid writing a file. > > Care to explain a little more? After processing to HTML, ``writer.body`` (attribute "body" of the Writer object) will contain the text (Unicode string) of the HTML between <body> & </body> (excluding any output of the "header" and "footer" nodes). Combine that with a "docutils.io.StringIO" object (or a soon-to-be-implemented "NullIO" object), and you can get just the processed document body that you want. > Perhaps I should take a closer look at the relevant sources. Always helpful! >> However, the idea of custom headers & footers is what inspired the >> "decoration" element (which contains "header" & "footer" elements). >> It hasn't been fully developed yet. > > Isn't that supposed to be a generic part of docutils for all kinds > of writers? I am not so interested in that, since the "decorations" > that I want for my online HTML version differ very greatly from the > decorations I wish to have in the PDF (for example) version. If that's the case, you'll have to do some custom coding. Either custom writers for your application, or custom format-sensitive transforms activated via a "pending" element in the header/footer. See "docutils.parsers.rst.directives.parts.contents" for an example. Or a templating engine. -- 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/ |