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: Beni C. <cb...@te...> - 2002-12-11 21:43:03
|
On 2002-12-11, David Ascher wrote: > Beni Cherniavsky wrote: > > > I don't think that skipping errors is the right approach since it can > > guess wrongly what you meant. DWIMs are known to make people sorry for > > using them :-).However the cycle of running docutils and fixing the > > source is not very convenient when you are in a hurry.TeX's approach of > > stopping and suggesting interactive fix possibilities could be more > > effecient (if the messages are less criptic ;-) but doesn't save the > > corrections in any way.So how about a ``--halt=edit`` mode that will > > spawn your text editor on the line where the first error happened and > > after you exit the editor, it will restart from the beginning (or maybe > > continue if the input file's timestamp hasn't changed)? > > None of this helps me, as the docutils phase is run by a cron job at 4 in the > morning.Trust me, I know what I'm doing =). > Oh, now I understand =). But I could use an edit mode in any case, maybe I'll write one. -- Beni Cherniavsky <cb...@tx...> What's lower level than machine code? A spreadsheet: not only addresses are numeric and hand-allocated but also all loops are hand-unrolled and all calls hand-inlined... (and macros are unheard of, of course). |
From: David A. <DavidA@ActiveState.com> - 2002-12-11 17:53:15
|
Beni Cherniavsky wrote: > I don't think that skipping errors is the right approach since it can > guess wrongly what you meant. DWIMs are known to make people sorry for > using them :-). However the cycle of running docutils and fixing the > source is not very convenient when you are in a hurry. TeX's approach of > stopping and suggesting interactive fix possibilities could be more > effecient (if the messages are less criptic ;-) but doesn't save the > corrections in any way. So how about a ``--halt=edit`` mode that will > spawn your text editor on the line where the first error happened and > after you exit the editor, it will restart from the beginning (or maybe > continue if the input file's timestamp hasn't changed)? None of this helps me, as the docutils phase is run by a cron job at 4 in the morning. Trust me, I know what I'm doing =). --david |
From: Beni C. <cb...@te...> - 2002-12-11 09:22:01
|
[New to the list, rST rocks :] On 2002-12-10, David Ascher wrote: > Is there an option I don't know about to let docutils barrel through and never > raise an exception when processing a document?I'm all for strictness in > formatting in 99% of cases, but I'd like to use docutils to convert old > documents written in "vague structured text" into HTML, in cases where there > is no reason to go back to the original texts to make them conform. > I don't think that skipping errors is the right approach since it can guess wrongly what you meant. DWIMs are known to make people sorry for using them :-). However the cycle of running docutils and fixing the source is not very convenient when you are in a hurry. TeX's approach of stopping and suggesting interactive fix possibilities could be more effecient (if the messages are less criptic ;-) but doesn't save the corrections in any way. So how about a ``--halt=edit`` mode that will spawn your text editor on the line where the first error happened and after you exit the editor, it will restart from the beginning (or maybe continue if the input file's timestamp hasn't changed)? -- Beni Cherniavsky <cb...@tx...> What's lower level than machine code? A spreadsheet: not only addresses are numeric and hand-allocated but also all loops are hand-unrolled and all calls hand-inlined... (and macros are unheard of, of course). |
From: David G. <go...@py...> - 2002-12-11 01:24:40
|
David Ascher wrote: > Is there an option I don't know about to let docutils barrel through > and never raise an exception when processing a document? "Never" may not be possible, but "almost never" is. Use the "--halt none" option or ``settings.halt_level = 5``. Similarly for "--report" if you don't even want to *see* the warnings (which I don't recommend). > Where the ... is interpreted as a heading marker -- if I change the > "."'s to "1"'s, docutils has no problems. > > Note that while this is from an old PEP, I have other documents > which have the same idiom: > > # if unknown message -> do mime parsing, regex rules, eval tests, etc. > ... > > Maybe we could make ... a special case? It is already a special case, actually. A line of punctuation marks is recognized as a title underline if it is flush left and as long as the title text or longer. If the line of punctuation marks is shorter than the title text, but at least 4 characters long, it will be recognized as an underline but a warning is generated. If it is 3 characters long or shorter, it is *not* recognized as a title underline, and an info-level system message is generated. Info-level messages are normally filtered out of final output (use "--report" to adjust). To illustrate:: $ tools/publish.py << EOF > blahblah > ... > EOF <document source="<stdin>"> <system_message level="1" line="2" source="<stdin>" type="INFO"> <paragraph> Possible title underline, too short for the title. Treating it as ordinary text because it's so short. <paragraph> blahblah ... But then I tried your example, in which the "..." is indented in a block quote. You've discovered a bug in the parser. Expect a fix in a day or two. -- David Goodger <go...@py...> Open-source projects: - Python Docutils: http://docutils.sourceforge.net/ (includes reStructuredText: http://docutils.sf.net/rst.html) - The Go Tools Project: http://gotools.sourceforge.net/ |
From: David A. <DavidA@ActiveState.com> - 2002-12-10 23:55:55
|
Is there an option I don't know about to let docutils barrel through and never raise an exception when processing a document? I'm all for strictness in formatting in 99% of cases, but I'd like to use docutils to convert old documents written in "vague structured text" into HTML, in cases where there is no reason to go back to the original texts to make them conform. It appears that the failures i'm encountering in these old corpora are things like: When referencing an external web page in the body of a SPEC, you should include the title of the page in the text, with a footnote reference to the URL. Do not include the URL in the body text of the SPEC. E.g. Refer to the Python Language web site [1] for more details. ... [1] http://www.python.org Where the ... is interpreted as a heading marker -- if I change the "."'s to "1"'s, docutils has no problems. Note that while this is from an old PEP, I have other documents which have the same idiom: # if unknown message -> do mime parsing, regex rules, eval tests, etc. ... Maybe we could make ... a special case? Thoughts? --david |
From: Greg W. <gw...@me...> - 2002-12-09 15:01:49
|
On 06 December 2002, David Abrahams said: > in the tools directory. It had lots of complaints, many of which look > serious, though it only flagged them as warnings. In particular, I > notice lots of characters which appear to be invalid (possibly > nuls). I'm not an HTML expert, which is why I use Tidy. Are these > worth doing something about? I've been using nsgmls for validating HTML -- it understands XML just fine, which is important because Docutils generates XHTML. I haven't tried it lately, but the last time I did (ie. after David G. fixed an error in the DTD line output), Docutils-generated HTML was just fine. Greg -- Greg Ward - software developer gw...@me... MEMS Exchange http://www.mems-exchange.org |
From: David A. <da...@bo...> - 2002-12-07 14:06:32
|
David Goodger <go...@py...> writes: > Warnings mean "I'm not sure, but I think something may be wrong here" > and it's left to the user to judge. Of course I knew that. > Many of these cases are not really problems, just HTMLTidy being > overly critical. > >> In particular, I notice lots of characters which appear to be >> invalid (possibly nuls). > ... > | Character codes 128 to 159 (U+0080 to U+009F) are not allowed in HTML > > That's because test.html is encoded in UTF-8. Oh, how novel! I hadn't noticed it was using utf-8. I normally deal with handwritten HTML, so I've never seen utf-8 encoding in an HTML document before. > Looks like HTMLTidy doesn't understand the ``<?xml version="1.0" > encoding="utf-8" ?>`` processing instruction at the beginning of the > file. Try the "-utf8" option. OK. >> I'm not an HTML expert, which is why I use Tidy. Are these >> worth doing something about? > > Some are, some aren't. > > | : Doctype given is "-//W3C//DTD XHTML 1.0 Transitional//EN" > | : Document content looks like XHTML 1.0 Strict > > HTMLTidy doesn't understand the transitional DTD? Seems odd. I think it does. I think it's saying that you didn't seemt to use any transitional features... but as I said I'm a non-expert. > | test.html:16:1: Warning: <meta> element not empty or not closed > | :17:1: Warning: <meta> element not empty or not closed > > These are real errors, now corrected. As I thought. > | :23:1: Warning: <table> lacks "summary" attribute > ... > | The table summary attribute should be used to describe > | the table structure. It is very helpful for people using > | non-visual browsers. The scope and headers attributes for > | table cells are useful for specifying which headers apply > | to each table cell, enabling non-visual browsers to provide > | a meaningful context for each cell. > > The "summary" attribute is not required by the HTML 4 spec, just > recommended. I know. Tidy's warnings about this get boring. > | :85:24: Warning: <a> Anchor "table-of-contents" already defined This one worried me, but I guess it's not much of an issue. > This seems to be because both the "id" attribute of the container > element and the "name" attribute of "<a>" elements are set to the same > thing (as specified in Appendix C of the XHTML spec, > http://www.w3.org/TR/xhtml1). HTML 4 and XHTML want elements to use > the "id" attribute, but Netscape 4 only works with the "name" > attribute on "<a>" tags. Perhaps the id and name attributes ought to > be on the same element though... HTML is a mishmash; can't win. > Unless there's a problem with a real browser (not just a tool like > tidy), I don't see the need to fix this. > > Thanks for taking the time to run HTMLTidy and bring these to our > attention. No problem. -- David Abrahams da...@bo... * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution |
From: David G. <go...@py...> - 2002-12-07 03:32:01
|
David Abrahams wrote: > I just ran HTMLTidy over the output of > > python html.py test.txt test.html > > in the tools directory. It had lots of complaints, many of which > look serious, though it only flagged them as warnings. ... | 67 warnings, 0 errors were found! Warnings mean "I'm not sure, but I think something may be wrong here" and it's left to the user to judge. Many of these cases are not really problems, just HTMLTidy being overly critical. > In particular, I notice lots of characters which appear to be > invalid (possibly nuls). ... | Character codes 128 to 159 (U+0080 to U+009F) are not allowed in HTML That's because test.html is encoded in UTF-8. Looks like HTMLTidy doesn't understand the ``<?xml version="1.0" encoding="utf-8" ?>`` processing instruction at the beginning of the file. Try the "-utf8" option. | even if they were, they would likely be unprintable control | characters. Tidy assumed you wanted to refer to a character with the | same byte value in the Windows-1252 encoding and replaced that | reference with the Unicode equivalent. Dangerous assumption. > I'm not an HTML expert, which is why I use Tidy. Are these > worth doing something about? Some are, some aren't. | : Doctype given is "-//W3C//DTD XHTML 1.0 Transitional//EN" | : Document content looks like XHTML 1.0 Strict HTMLTidy doesn't understand the transitional DTD? Seems odd. | test.html:16:1: Warning: <meta> element not empty or not closed | :17:1: Warning: <meta> element not empty or not closed These are real errors, now corrected. | :23:1: Warning: <table> lacks "summary" attribute ... | The table summary attribute should be used to describe | the table structure. It is very helpful for people using | non-visual browsers. The scope and headers attributes for | table cells are useful for specifying which headers apply | to each table cell, enabling non-visual browsers to provide | a meaningful context for each cell. The "summary" attribute is not required by the HTML 4 spec, just recommended. While I sympathize with its aim, I don't know of any way to automatically generate a summary of a table. Eventually a formal "table" directive may be written, and it could have a "summary" option. | :85:24: Warning: <a> Anchor "table-of-contents" already defined This seems to be because both the "id" attribute of the container element and the "name" attribute of "<a>" elements are set to the same thing (as specified in Appendix C of the XHTML spec, http://www.w3.org/TR/xhtml1). HTML 4 and XHTML want elements to use the "id" attribute, but Netscape 4 only works with the "name" attribute on "<a>" tags. Perhaps the id and name attributes ought to be on the same element though... HTML is a mishmash; can't win. Unless there's a problem with a real browser (not just a tool like tidy), I don't see the need to fix this. Thanks for taking the time to run HTMLTidy and bring these to our attention. -- David Goodger <go...@py...> Open-source projects: - Python Docutils: http://docutils.sourceforge.net/ (includes reStructuredText: http://docutils.sf.net/rst.html) - The Go Tools Project: http://gotools.sourceforge.net/ |
From: David G. <go...@py...> - 2002-12-07 00:43:44
|
David Abrahams wrote: > I'm just getting started with ReST, and finding it to be natural > and a lot of fun to use. Glad to hear it! > I did find one behavior that violated my > expectations, using the html.py standalone processor. > > I was writing along and somewhere in the middle of my text I decided > to turn a parenthesized section into a footnote: ... > When I processed this into HTML, I was surprised to find that the > footnote appeared exactly where I had placed it, instead of near the > bottom of the page. Docutils doesn't guess where you want the footnotes to be. Look at PEPs, for example; footnotes are in a section called "References" or "References & Footnotes". The author might want to add a transition (horizontal rule in HTML) before the footnotes, or some other decoration. There are directives planned for gathering footnotes & citations at an author-specified point in the document, perhaps "footnotes" and "citations" to keep things simple. They haven't been implemented yet though. If you'd like to try, see http://docutils.sf.net/spec/howto/rst-directives.html for instructions. -- David Goodger <go...@py...> Open-source projects: - Python Docutils: http://docutils.sourceforge.net/ (includes reStructuredText: http://docutils.sf.net/rst.html) - The Go Tools Project: http://gotools.sourceforge.net/ |
From: David A. <da...@bo...> - 2002-12-06 23:58:18
|
I just ran HTMLTidy over the output of python html.py test.txt test.html in the tools directory. It had lots of complaints, many of which look serious, though it only flagged them as warnings. In particular, I notice lots of characters which appear to be invalid (possibly nuls). I'm not an HTML expert, which is why I use Tidy. Are these worth doing something about? c:/src/docutils/tools/test.html:16:1: Warning: <meta> element not empty or not closed c:/src/docutils/tools/test.html:17:1: Warning: <meta> element not empty or not closed c:/src/docutils/tools/test.html:23:1: Warning: <table> lacks "summary" attribute c:/src/docutils/tools/test.html:85:24: Warning: <a> Anchor "table-of-contents" already defined c:/src/docutils/tools/test.html:130:5: Warning: <a> Anchor "structural-elements" already defined c:/src/docutils/tools/test.html:132:5: Warning: <a> Anchor "section-title" already defined c:/src/docutils/tools/test.html:136:5: Warning: <a> Anchor "transitions" already defined c:/src/docutils/tools/test.html:143:5: Warning: <a> Anchor "body-elements" already defined c:/src/docutils/tools/test.html:145:5: Warning: <a> Anchor "paragraphs" already defined c:/src/docutils/tools/test.html:148:5: Warning: <a> Anchor "inline-markup" already defined c:/src/docutils/tools/test.html:158:66: Warning: <span> Anchor "id20" already defined c:/src/docutils/tools/test.html:172:5: Warning: <a> Anchor "bullet-lists" already defined c:/src/docutils/tools/test.html:195:5: Warning: <a> Anchor "enumerated-lists" already defined c:/src/docutils/tools/test.html:228:5: Warning: <a> Anchor "definition-lists" already defined c:/src/docutils/tools/test.html:241:5: Warning: <a> Anchor "field-lists" already defined c:/src/docutils/tools/test.html:242:1: Warning: <table> lacks "summary" attribute c:/src/docutils/tools/test.html:259:5: Warning: <a> Anchor "option-lists" already defined c:/src/docutils/tools/test.html:261:1: Warning: <table> lacks "summary" attribute c:/src/docutils/tools/test.html:305:5: Warning: <a> Anchor "literal-blocks" already defined c:/src/docutils/tools/test.html:316:5: Warning: <a> Anchor "block-quotes" already defined c:/src/docutils/tools/test.html:324:5: Warning: <a> Anchor "doctest-blocks" already defined c:/src/docutils/tools/test.html:333:5: Warning: <a> Anchor "tables" already defined c:/src/docutils/tools/test.html:335:1: Warning: <table> lacks "summary" attribute c:/src/docutils/tools/test.html:378:1: Warning: <table> lacks "summary" attribute c:/src/docutils/tools/test.html:414:5: Warning: <a> Anchor "footnotes" already defined c:/src/docutils/tools/test.html:415:1: Warning: <table> lacks "summary" attribute c:/src/docutils/tools/test.html:418:23: Warning: <a> Anchor "id6" already defined c:/src/docutils/tools/test.html:424:1: Warning: <table> lacks "summary" attribute c:/src/docutils/tools/test.html:427:23: Warning: <a> Anchor "label" already defined c:/src/docutils/tools/test.html:434:1: Warning: <table> lacks "summary" attribute c:/src/docutils/tools/test.html:437:23: Warning: <a> Anchor "id9" already defined c:/src/docutils/tools/test.html:441:1: Warning: <table> lacks "summary" attribute c:/src/docutils/tools/test.html:444:23: Warning: <a> Anchor "id10" already defined c:/src/docutils/tools/test.html:445:113: Warning: replacing invalid character code 128 c:/src/docutils/tools/test.html:448:1: Warning: <table> lacks "summary" attribute c:/src/docutils/tools/test.html:451:23: Warning: <a> Anchor "id12" already defined c:/src/docutils/tools/test.html:451:72: Warning: replacing invalid character code 128 c:/src/docutils/tools/test.html:454:1: Warning: <table> lacks "summary" attribute c:/src/docutils/tools/test.html:457:23: Warning: <a> Anchor "id13" already defined c:/src/docutils/tools/test.html:458:51: Warning: <span> Anchor "id62" already defined c:/src/docutils/tools/test.html:463:5: Warning: <a> Anchor "citations" already defined c:/src/docutils/tools/test.html:464:1: Warning: <table> lacks "summary" attribute c:/src/docutils/tools/test.html:468:23: Warning: <a> Anchor "cit2002" already defined c:/src/docutils/tools/test.html:472:154: Warning: <span> Anchor "id64" already defined c:/src/docutils/tools/test.html:476:5: Warning: <a> Anchor "targets" already defined c:/src/docutils/tools/test.html:486:41: Warning: <span> Anchor "id66" already defined c:/src/docutils/tools/test.html:489:5: Warning: <a> Anchor "duplicate-target-names" already defined c:/src/docutils/tools/test.html:495:5: Warning: <a> Anchor "id18" already defined c:/src/docutils/tools/test.html:498:35: Warning: <span> Anchor "id68" already defined c:/src/docutils/tools/test.html:502:5: Warning: <a> Anchor "directives" already defined c:/src/docutils/tools/test.html:516:5: Warning: <a> Anchor "document-parts" already defined c:/src/docutils/tools/test.html:522:5: Warning: <a> Anchor "images" already defined c:/src/docutils/tools/test.html:530:1: Warning: <table> lacks "summary" attribute c:/src/docutils/tools/test.html:552:5: Warning: <a> Anchor "admonitions" already defined c:/src/docutils/tools/test.html:589:5: Warning: <a> Anchor "target-footnotes" already defined c:/src/docutils/tools/test.html:590:1: Warning: <table> lacks "summary" attribute c:/src/docutils/tools/test.html:593:23: Warning: <a> Anchor "id21" already defined c:/src/docutils/tools/test.html:598:5: Warning: <a> Anchor "line-blocks" already defined c:/src/docutils/tools/test.html:617:5: Warning: <a> Anchor "replacement-text" already defined c:/src/docutils/tools/test.html:622:5: Warning: <a> Anchor "substitution-definitions" already defined c:/src/docutils/tools/test.html:627:5: Warning: <a> Anchor "comments" already defined c:/src/docutils/tools/test.html:638:5: Warning: <a> Anchor "error-handling" already defined c:/src/docutils/tools/test.html:647:50: Warning: <a> Anchor "id19" already defined c:/src/docutils/tools/test.html:650:50: Warning: <a> Anchor "id61" already defined c:/src/docutils/tools/test.html:653:50: Warning: <a> Anchor "id63" already defined c:/src/docutils/tools/test.html:656:50: Warning: <a> Anchor "id65" already defined c:/src/docutils/tools/test.html:659:50: Warning: <a> Anchor "id67" already defined c:/src/docutils/tools/test.html: Doctype given is "-//W3C//DTD XHTML 1.0 Transitional//EN" c:/src/docutils/tools/test.html: Document content looks like XHTML 1.0 Strict 67 warnings, 0 errors were found! Character codes 128 to 159 (U+0080 to U+009F) are not allowed in HTML; even if they were, they would likely be unprintable control characters. Tidy assumed you wanted to refer to a character with the same byte value in the Windows-1252 encoding and replaced that reference with the Unicode equivalent. The table summary attribute should be used to describe the table structure. It is very helpful for people using non-visual browsers. The scope and headers attributes for table cells are useful for specifying which headers apply to each table cell, enabling non-visual browsers to provide a meaningful context for each cell. For further advice on how to make your pages accessible see "http://www.w3.org/WAI/GL". You may also want to try "http://www.cast.org/bobby/" which is a free Web-based service for checking URLs for accessibility. To learn more about HTML Tidy see http://tidy.sourceforge.net -- David Abrahams da...@bo... * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution |
From: David A. <da...@bo...> - 2002-12-06 23:20:28
|
I'm just getting started with ReST, and finding it to be natural and a lot of fun to use. I did find one behavior that violated my expectations, using the html.py standalone processor. I was writing along and somewhere in the middle of my text I decided to turn a parenthesized section into a footnote: Here's the main sentence I was writing [#]_. .. [#] And here's the remark that used to parenthesized. Here's some more text in the article When I processed this into HTML, I was surprised to find that the footnote appeared exactly where I had placed it, instead of near the bottom of the page. In an output medium like HTML, with hyperlinks, I expect to jump around to see the footnote. Or if it's a "paged medium", like PDF, I expect to see the footnote at the bottom of the physical page or the end of the chapter, depending on some preference. However, the ReST text file has none of these properties, and I find it natural and convenient to locate the footnote very close to its reference. I also note that TeX works the way I expect, for what that's worth (I generally hate using TeX, but this is one thing I do like about it). -Dave -- David Abrahams da...@bo... * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution |
From:
<yt...@li...> - 2002-12-02 13:18:48
|
<事業者>ジュエリーノン 2度と配信いたしませんので配信不要の方はこのままご返信くださいtak...@ni... <送信者>mcco taketu yosihttp://www6.plala.or.jp/taketu 拒否tak...@ni... <内容>無料プレゼント ●リニューアルオープン記念につきシルバーリングまたは18金ピアスを500名様にプレゼントいたします。応募方法はこちらからどうぞ http://www.paw.hi-ho.ne.jp/taketu/ |
From: Ray L. <ra...@es...> - 2002-11-26 15:39:54
|
I'd be more than happy to contribute. Right now though it requires libxml2, libxslt and their respective python bindings for this to work. I don't know if you're interested in something like that. Actually I can contribute the xsl stylesheets I'll be generating right from the start. A few questions: 1) The docutils-xml.py has some none functioning commandline options, is that known? I can document if it hasn't already. 2) Can there be a command line option to remove the <!DOCTYPE ... directive from the XML file created by docutils xml? I know it's a minidom, but I don't understand the cmdline classes well enought to add this option yet. The reason I want to remove it is for offline processing with libxml2 ... it's a validating parser, and when I go to transform the docutils-xml file it first tries to validate. That's no issue when connected, but when offline it can get a bit annoying. 3) Is there a single test document that uses everything in rst ( section indentation, tables, etc ... )? Thanks for your feedback, and I'll definitely be contributing the Xsl stylesheets. I've got one that works throught he sections / title / paragraphs. I'm trying to work out the rest as I go along. That's why a good sample that uses *everything* would be great. Ray |
From: David G. <go...@py...> - 2002-11-26 01:00:39
|
Ray Leyva wrote: > Just wondering if anybody has begun working on an DocUtils-Xml -> Xsl to > multi-target ( Html w/Css | Html no CSS | PDF ) transformation project > yet. Not as such, no. > So the question is, has anybody started to work on any Xsl for > DocUtils-XML? If they have can they share what they've worked on? I've > looked in the sandbox but have found nothing ... maybe I'm looking in > the wrong place? Back in April I merged the former reStructuredText and DPS projects into Docutils, and some of the old sandbox projects got left behind. Several XSL examples were there: * http://cvs.sf.net/cgi-bin/viewcvs.cgi/structuredtext/sandbox/alanj (Alan Jaffray) * http://cvs.sf.net/cgi-bin/viewcvs.cgi/structuredtext/sandbox/paulw (Paul Wright) * http://cvs.sf.net/cgi-bin/viewcvs.cgi/structuredtext/sandbox/rtxt2html (Remi Bertholet) They haven't been updated for some time, but they may help you get started. If you can, please contribute your results back to Docutils! -- 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: Ray L. <ra...@es...> - 2002-11-25 20:14:31
|
Hi, Just wondering if anybody has begun working on an DocUtils-Xml -> Xsl to multi-target ( Html w/Css | Html no CSS | PDF ) transformation project yet. I've spent the last few months working on just such a thing, but my initial documents are my own grammar of Xml, and well ... after much working with it I've definitely come to the decision that while great for transformation, and computerized transformations it sucks to have to write so many < blah blah > just to get a basic webpage up. In comes DocUtils, and it's ability to create an Xml representation of reST. So I started reading the code on Sunday afternoon ( yesterday ), and have decided I *really* want to start using reST, as my standard static content creation language. Non-static stuff, might move to generate reST, but I've already built it to generate my Xml grammar so I really don't see the need at this time. Maybe if somebody creates a better presentation layer than mine I'll move it, but for now I think mines better than most out there. So the question is, has anybody started to work on any Xsl for DocUtils-XML? If they have can they share what they've worked on? I've looked in the sandbox but have found nothing ... maybe I'm looking in the wrong place? Anyways thanks for your time. Ray PS : Sorry for the cross post, but I thought it would be easier if I sent this out as widely as possible, and I *know* that sometimes people in dev are not in users, and vice-versa. |
From: Brett g P. <bgp...@ac...> - 2002-11-19 14:05:34
|
----- Original Message ----- From: "David Goodger" <go...@py...> To: "Brett g Porter" <bgp...@ac...>; <doc...@li...> Sent: Monday, November 18, 2002 9:47 PM Subject: Re: [Docutils-users] Re: More include woes > This was a path manipulation bug. The wrong base path was being used. > Should be corrected now. Excellent -- thanks! > Looks like a data encoding error. Are there any non-US-ASCII > characters in your included document? The "include" directive wasn't > decoding new files properly, but that's corrected now. That's exactly what it was -- should have been corrected before now, but a few instances slipped through. > > Never mind on this one -- once I actually bothered to think about the > > traceback, I found the error in my source and fixed it. Still curious > > that this problem only happens when this file was being included. > > I'm curious too. When you say "error in my source", are you talking > about source code or source text? Sorry -- my text. Guess that I shouldn't use the word 'source' to refer to everything in the whole world, hm? > This "include" directive seemed like such a simple beast at the > beginning, but it has displayed unexpected complexity. Hopefully it's > been tamed now; time will tell. > > You'll have to update Docutils directly from CVS. SourceForge has been > doing some maintenance since yesterday, and the group directories are > read-only. The cron job that updates the snapshot files can't run > until they're done. > > Thanks for the report, and for exercising Docutils in interesting ways! You bet -- thanks for your speedy response. Today, I'm going to make a stab at bringing the rlpdf writer in the sandbox up to snuff (it's missing a ton of {visit|depart}_XXXX() handlers) or perhaps a rewrite. Wish me luck. |
From: David G. <go...@py...> - 2002-11-19 02:47:31
|
Brett g Porter wrote: > I've stumbled on one thing that looks like a real problem, and one > that's just making me scratch my head. > > 1) Directory problems: > > I am assembling a master document that pulls in some source from a > subdirectory, ... > Then I got the bright idea that the ref_intro doc should live down > in the reference_dir directory, so I moved it, and tried patching > the paths so it was including refch*.txt as if they were in the > current directory. > > That didn't work This was a path manipulation bug. The wrong base path was being used. Should be corrected now. > 2) Problems including a file. > > I have a file that works fine when rendered on its own. If I copy > its body into my master document at the point where I would like to > .. include:: it, the resulting master doc renders fine. However, any > attempt to include this file in another (even an otherwise empty > file that just includes it) gives me this error: ... > I've tried narrowing down the problem by whittling the problematic > file down, but can't reproduce the problem or locate the source. I'm > hoping that the traceback will give you a clue as to what the > problem is. Looks like a data encoding error. Are there any non-US-ASCII characters in your included document? The "include" directive wasn't decoding new files properly, but that's corrected now. > Never mind on this one -- once I actually bothered to think about the > traceback, I found the error in my source and fixed it. Still curious > that this problem only happens when this file was being included. I'm curious too. When you say "error in my source", are you talking about source code or source text? This "include" directive seemed like such a simple beast at the beginning, but it has displayed unexpected complexity. Hopefully it's been tamed now; time will tell. You'll have to update Docutils directly from CVS. SourceForge has been doing some maintenance since yesterday, and the group directories are read-only. The cron job that updates the snapshot files can't run until they're done. Thanks for the report, and for exercising Docutils in interesting ways! -- 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: Brett g P. <bgp...@ac...> - 2002-11-18 16:07:22
|
----- Original Message ----- From: "Brett g Porter" <bgp...@ac...> To: <doc...@li...> Sent: Monday, November 18, 2002 11:00 AM Subject: More include woes > 2) Problems including a file. > > I have a file that works fine when rendered on its own. If I copy its body > into my master document at the point where I would like to .. include:: it, > the resulting master doc renders fine. However, any attempt to include this > file in another (even an otherwise empty file that just includes it) gives > me this error: Never mind on this one -- once I actually bothered to think about the traceback, I found the error in my source and fixed it. Still curious that this problem only happens when this file was being included. |
From: Brett g P. <bgp...@ac...> - 2002-11-18 16:00:52
|
I've stumbled on one thing that looks like a real problem, and one th= at's just making me scratch my head. 1) Directory problems: I am assembling a master document that pulls in some source from a subdirectory, like: /main_dir masterdoc.txt ch1.txt <<etc.>> /reference_dir refch1.txt refch2.txt <<etc.>> The reference chapter begins with some introductory text, then brings= in each of the functions that are being documented. My first pass at thi= s had that intro file in the main_dir directory, and then included the ref = files like: <<ref_intro.txt>> text here, etc. =2E. include:: reference_dir/refch1.txt =2E. include:: reference_dir/refch2.txt Then I got the bright idea that the ref_intro doc should live down in= the reference_dir directory, so I moved it, and tried patching the paths = so it was including refch*.txt as if they were in the current directory. That didn't work (error was that there was no file `refch1.txt') so I restored the paths as if the current working directory at the context= of the include was still the top-level /main_dir -- then the error was even = odder, that there was no file `reference_dir/reference_dir/refch1.txt' On the one hand, directories are doubly-expanded, but on the other ha= nd they dont' seem to be exapnded at all. This isn't a killer for me (because it works fine with the intro text= in the /main_dir directory), but I wanted to report it nonetheless. 2) Problems including a file. I have a file that works fine when rendered on its own. If I copy its= body into my master document at the point where I would like to .. include= :: it, the resulting master doc renders fine. However, any attempt to includ= e this file in another (even an otherwise empty file that just includes it) = gives me this error: Traceback (most recent call last): File "c:\bin\docutils\tools\html.py", line 25, in ? publish_cmdline(writer_name=3D'html', description=3Ddescription) File "C:\bin\Python22\Lib\site-packages\docutils\core.py", line 230= , in publish_cmdline pub.publish(argv, usage, description, settings_spec, settings_ove= rrides) File "C:\bin\Python22\Lib\site-packages\docutils\core.py", line 173= , in publish output =3D self.writer.write(document, self.destination) File "C:\bin\Python22\Lib\site-packages\docutils\writers\__init__.p= y", line 52 , in write output =3D self.destination.write(self.output) File "C:\bin\Python22\Lib\site-packages\docutils\io.py", line 208, = in write output =3D self.encode(data) File "C:\bin\Python22\Lib\site-packages\docutils\io.py", line 126, = in encode return data.encode(self.settings.output_encoding or '') UnicodeError: ASCII decoding error: ordinal not in range(128) I've tried narrowing down the problem by whittling the problematic fi= le down, but can't reproduce the problem or locate the source. I'm hopin= g that the traceback will give you a clue as to what the problem is. thx -- // Today's Oblique Strategy (=A9 Brian Eno/Peter Schmidt): // Do nothing for as long as possible // Brett g Porter * BgP...@ac... // http://mywebpages.comcast.net/bgporter/ |
From: Brett C. <bac@OCF.Berkeley.EDU> - 2002-11-16 08:31:04
|
[David Goodger] > After a great deal of thought and much input from users, I've decided > that there are reasonable use cases for such a construct, and we've > settled on a reasonable syntax. The following syntax will be used:: > > See the `Python home page <http://www.python.org>`_ for info. > And it is already being used in the python-dev Summary! I just sent the rough draft to pyt...@py... . If anyone is curious to see the notation in action the rough draft should be in the Maiilman archives shortly. Otherwise you can wait until I get the summary up and online since I am planning on putting the original text versions up on python.org along with the HTML version in hopes of getting more people into using reST. -Brett |
From: David G. <go...@py...> - 2002-11-16 02:56:14
|
As always, the latest CVS snapshot can be had from http://docutils.sf.net/docutils-snapshot.tgz Embedded URIs in Hyperlink References ===================================== Back in June, Simon Budig proposed a new syntax for reStructuredText hyperlinks, to allow target URIs/URLs to be specified inline with the reference in the text. I was initially ambivalent/against the proposal (a similar mechanism was one of the flaws I found in my analysis of StructuredText!). One of the core values of reStructuredText is its readability, and although the proposed syntax offers convenience, I wasn't sure if the convenience was worth the cost. After a great deal of thought and much input from users, I've decided that there are reasonable use cases for such a construct, and we've settled on a reasonable syntax. The following syntax will be used:: See the `Python home page <http://www.python.org>`_ for info. This is exactly equivalent to:: See the `Python home page`_ for info. .. _Python home page: http://www.python.org As with the non-embedded reference forms, a single trailing underscore means "named", and you can use the same name to reference the same target URI again. Two trailing underscores means "anonymous"; the target URI cannot be referenced again. Full details can be found in the spec: http://docutils.sf.net/spec/rst/reStructuredText.html#embedded-uris Details of the issues considered and alternatives weighed can be found here: http://docutils.sf.net/spec/rst/alternatives.html#inline-external-targets Recognition of Schemeless Email Addresses in Targets ==================================================== The parser has always recognized bare standalone email addresses in text, like "Send email to jd...@ex...", automatically prefixing a "mailto:" URI scheme. I noticed some cases of schemeless email addresses in explicit targets, like this:: .. _mail me: me...@ex... Such targets were *not* getting a "mailto:" scheme prefix, resulting in bad hyperlinks. That's been fixed now, in explicit targets and in the new embedded URIs. French & Slovak Language Support ================================ New language modules have been contributed to Docutils: Slovak from Miroslav Vasko, and French from Stefane Fermigier. Already supported are German, Swedish, and English. New language modules are always welcome. They're easy to make; they're just translations of a couple dozen terms. See the newly expanded "Docutils Internationalization" for instructions: http://docutils.sf.net/spec/howto/i18n.html -- David Goodger <go...@py...> Open-source projects: - Python Docutils: http://docutils.sourceforge.net/ (includes reStructuredText: http://docutils.sf.net/rst.html) - The Go Tools Project: http://gotools.sourceforge.net/ |
From: <ms...@ma...> - 2002-11-13 03:07:20
|
On Tue, Nov 12, 2002 at 08:29:35PM -0500, David Goodger wrote: [ stylesheet / class usage discussion skipped ] I believe, the question I raised comes from my desire to use the generated HTML code as a part of a bigger document. So as I may not know what stylesheet is used in the "parent" document, this "unnecessary" references to a non-existant stylesheet may lead to problems. However I got your point and will try to supply the code which implements the this behaviour. > > Hmm. The current code does not seem to follow the quoted RFC 2396 > > then. I did specify > >=20 > > <http://www.example.com/an url with spaces> > >=20 > > (which seems to be correct according to this RFC) and as result got > >=20 > > <<a href=3D"http://www.example.com/an" > > >http://www.example.com/an</a> url with spaces> > >=20 > > which seems to be incorrect, right? >=20 > Note that according to the RFC, your example should be interpreted as: >=20 > http://www.example.com/anurlwithspaces >=20 > Which is *not* what you asked for. Which I _originally_ asked for. I understood your explanation and the reference to the RFC, and the way the RFC suggests these whitespace characters are interpreted. > >> The reStructuredText parser also joins long multi-line URLs in > >> targets. >=20 > This applies to the "target" construct only:: >=20 > .. _target: http://www.example.com/a/very/long/ > path/broken/across/lines >=20 > My comment does not apply to standalone URLs in text, with or without > angle brackets (which have no special meaning now). I see. I missed the word "targets", which actually has a special meaning. > This is the first time this issue has come up. If this feature is > important to you, I would be pleased to accept a patch that implements > it. But the patch should implement the behavior described in the RFC, > *not* the ad-hoc behavior witnessed in MS Outlook. The ambiguous and > non-standard MS Outlook behavior will *not* be supported. That I understand and I have no intention to insist on any non-standard behaviour whatsoever. -- Misha |
From: David G. <go...@py...> - 2002-11-13 01:28:49
|
[Mikhail] >>> nor it's possible to get rid of use stylesheets at all. [David] >> I'm not sure what you mean by this or what you want. Please >> elaborate. [Mikhail] > The current code does produce HTML elements with classes referencing > to a stylesheet. Actually, it's the other way around. The HTML file does reference a stylesheet in its <link rel="stylesheet" ... /> element, but it's the styles (in the stylesheet) which reference the "class" attributes on elements in the HTML files. So if there's no stylesheet referenced, the "class" attributes have no effect. > 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, I've altered the HTML Writer so that if both settings.stylesheet (--stylesheet) and settings.stylesheet_path (--stylesheet-path) are None or "", there will be no <link rel="stylesheet" ... /> added to the output. Note that if you use the standard config file in tools/docutils.conf, it does set settings.stylesheet_path, so you'll have to override explicitly. > and in this case I'd expect to get html text without class > references in html elements. ... > Such a behaviour does not seem to be very complicated, so maybe it > could be possible to add this functionality in the current code? If that's what you want, you'll have to supply the code. There's no harm having ``class="whatever"`` attributes on HTML elements when there's no stylesheet. It would be easy to add as a setting/option, but I'll leave it to you because I don't think it's useful. I'll be happy to accept a patch. > 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="http://www.example.com/an" > >http://www.example.com/an</a> url with spaces> > > which seems to be incorrect, right? Note that according to the RFC, your example should be interpreted as: http://www.example.com/anurlwithspaces Which is *not* what you asked for. I wrote: >> The reStructuredText parser also joins long multi-line URLs in >> targets. This applies to the "target" construct only:: .. _target: http://www.example.com/a/very/long/ path/broken/across/lines My comment does not apply to standalone URLs in text, with or without angle brackets (which have no special meaning now). As for "The current code does not seem to follow the quoted RFC 2396", that's true. However, please realize that the quoted text comes from Appendix E, "Recommendations for Delimiting URI in Context". A recommendation, not a specification. The first sentence reads: URI are often transmitted through formats that do not provide a clear context for their interpretation. reStructuredText *does* provide a clear context for the interpretation of URIs, via the "target" construct. The appendix goes on to say: For robustness, software that accepts user-typed URI should attempt to recognize and strip both delimiters and embedded whitespace. And I wrote: >> I wouldn't mind adding the ability to join broken URLs in free text >> as well, if surrounded by brackets. This is the first time this issue has come up. If this feature is important to you, I would be pleased to accept a patch that implements it. But the patch should implement the behavior described in the RFC, *not* the ad-hoc behavior witnessed in MS Outlook. The ambiguous and non-standard MS Outlook behavior will *not* be supported. -- David Goodger <go...@py...> Open-source projects: - Python Docutils: http://docutils.sourceforge.net/ (includes reStructuredText: http://docutils.sf.net/rst.html) - The Go Tools Project: http://gotools.sourceforge.net/ |
From: David G. <go...@py...> - 2002-11-13 00:56:28
|
Greg Ward wrote: > By default Docutils generates HTML that starts with these two lines: > > <?xml version="1.0" encoding="us-ascii"?> This is known as the "XML declaration". The "<?...?>" construct is a "processing instruction". I've added a space just before the closing "?>" in the writer; it's legal, shouldn't hurt, and may make a difference. Processing instructions have been around since the beginning of SGML, so are already a part of HTML. SGML processing instructions look a bit different though: "<?...>"; no closing "?". > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> This is the "document type declaration". It declares the "document type definition" (DTD) which is the schema of the document. > That looks fine to me, but the web hosting provider for my personal > web page (www.gerg.ca) is using some server-side software that gags > on it. For example, compare > http://www.gerg.ca/software/optik/basic.html > with > http://optik.sourceforge.net/basic.html > > If I remove the "<?xml ... ?>" line from the www.gerg.ca copy, it > works just fine. > > I'm 99% sure that Docutils is in the right, and the server-side > expansion done by my web hosting provider is broken. However, I > would like to be able cite chapter and verse of the XHTML spec to > prove my point. Can someone point me in the right direction? The XHTML spec is here: <http://www.w3.org/TR/xhtml1>. Appendix C is a must-read. HTML's spec is here: <http://www.w3.org/TR/html>. The XML spec is here: <http://www.w3.org/TR/REC-xml>. Section 2.1, "Well-Formed XML Documents", lists the constructs making up an XML document. Section 2.8, "Prolog and Document Type Declaration", states: [Definition: XML documents should begin with an XML declaration which specifies the version of XML being used.] The spec lists the exact meaning of "should". It wouldn't be difficult to add a setting/option to avoid outputting the XML declaration. However, XHTML appendix C.1, "Processing Instructions and the XML Declaration", says Be aware that processing instructions are rendered on some user agents. However, also note that when the XML declaration is not included in a document, the document can only use the default character encodings UTF-8 or UTF-16. US-ASCII *is* a subset of UTF-8, however ISO-Latin-1 *is not*. -- 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: Greg W. <gw...@me...> - 2002-11-12 18:40:39
|
By default Docutils generates HTML that starts with these two lines: <?xml version="1.0" encoding="us-ascii"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> That looks fine to me, but the web hosting provider for my personal web page (www.gerg.ca) is using some server-side software that gags on it. For example, compare http://www.gerg.ca/software/optik/basic.html with http://optik.sourceforge.net/basic.html If I remove the "<?xml ... ?>" line from the www.gerg.ca copy, it works just fine. I'm 99% sure that Docutils is in the right, and the server-side expansion done by my web hosting provider is broken. However, I would like to be able cite chapter and verse of the XHTML spec to prove my point. Can someone point me in the right direction? Thanks -- Greg |