docutils-users Mailing List for Docutils: Documentation Utilities (Page 325)

＜事業者＞ジュエリーノン　２度と配信いたしませんので配信不要の方はこのままご返信くださいtak...@ni...
＜送信者＞mcco taketu yosihttp://www6.plala.or.jp/taketu 拒否tak...@ni... 
＜内容＞無料プレゼント　●リニューアルオープン記念につきシルバーリングまたは18金ピアスを５００名様にプレゼントいたします。応募方法はこちらからどうぞ
http://www.paw.hi-ho.ne.jp/taketu/

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

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/

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.

----- 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.

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/

----- 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.

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/

[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

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/

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
> >     &lt;<a href=3D"http://www.example.com/an"
> >     >http://www.example.com/an</a> url with spaces&gt;
> >=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

[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
> 
>     &lt;<a href="http://www.example.com/an"
>     >http://www.example.com/an</a> url with spaces&gt;
> 
> 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/

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/

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

On Mon, Nov 11, 2002 at 08:53:01PM -0500, David Goodger wrote:
> > It looks like I cannot get only the body of the text (what is located
> > between <body> ... </body>) without some addtional programming,
>=20
> Correct.  You'll need a specialized Writer component.  Take a look at
> the files in http://docutils.sf.net/sandbox/oliverr/ht/ .  This seems
> to be a common requirement for people, so a custom HTML-body-only
> Writer could be useful.  I don't know what to do about the DocTitle
> transform in this case though (in docutils/transforms/frontmatter.py).
I believe, the best approach is to just ignore it. :)  Those who really
need it, could access it through the document instance.

> > nor it's possible to get rid of use stylesheets at all.
>=20
> I'm not sure what you mean by this or what you want.  Please
> elaborate.
The current code does produce HTML elements with classes referencing to
a stylesheet.  I'd say that the rendering without a stylesheet seems to
be OK for me, so I'd like to specify None as the stylesheet name, and in
this case I'd expect to get html text without class references in html
elements.

> The html4css1.py Writer is designed to use a stylesheet, as
> recommended by the latest HTML specs.  If you want HTML that doesn't
> require a stylesheet at all, a new Writer would be needed.
Such a behaviour does not seem to be very complicated, so maybe it could
be possible to add this functionality in the current code?

> [ URLs with spaces ]
>=20
> According to RFC 2396 "Uniform Resource Identifiers (URI): Generic
> Syntax", spaces are not valid URI/URL characters.  It does say this:
>=20
>    In some cases, extra whitespace (spaces, linebreaks, tabs, etc.)
>    may need to be added to break long URI across lines. The whitespace
>    should be ignored when extracting the URI.
>    ...
>    Using <> angle brackets around each URI is especially recommended
>    as a delimiting style for URI that contain whitespace.
>=20
> The syntax you propose would conflict with this, especially if the
> MS-style URL were to break across lines:
>=20
>     <http://www.example.com/a/very/long/
>     path/broken/across/lines>
>=20
> Is the whitespace after "long/" significant or not?  The RFC says it's
> not.  The reStructuredText parser also joins long multi-line URLs in
> targets.  I wouldn't mind adding the ability to join broken URLs in
> free text as well, if surrounded by brackets.
>=20
> So the answer to your question is, I think I'd say no thanks.
> Whitespace in URLs is a pain; I think it's better just to avoid it.
Hmm.  The current code does not seem to follow the quoted RFC 2396 then.
I did specify

    <http://www.example.com/an url with spaces>

(which seems to be correct according to this RFC) and as result got

    &lt;<a
    href=3D"http://www.example.com/an">http://www.example.com/an</a>
    url with spaces&gt;

which seems to be incorrect, right?

--
Misha

Mikhail Sobolev wrote:
> Having downloaded the 0.2 version, I tried to write a simple program
> to convert from text to HTML.  It turned to out to be not that easy.
> Fortunately, in mailing list archives I found a suggestion to
> download the snapshot and proceed with publish_string helper.  This
> works great, thank you.

Thank you for checking the archives!

> I have two questions, however.
>
> It looks like I cannot get only the body of the text (what is located
> between <body> ... </body>) without some addtional programming,

Correct.  You'll need a specialized Writer component.  Take a look at
the files in http://docutils.sf.net/sandbox/oliverr/ht/ .  This seems
to be a common requirement for people, so a custom HTML-body-only
Writer could be useful.  I don't know what to do about the DocTitle
transform in this case though (in docutils/transforms/frontmatter.py).

> nor it's possible to get rid of use stylesheets at all.

I'm not sure what you mean by this or what you want.  Please
elaborate.

The html4css1.py Writer is designed to use a stylesheet, as
recommended by the latest HTML specs.  If you want HTML that doesn't
require a stylesheet at all, a new Writer would be needed.

> The second comes from my rather extensive use of Outlook (yes, a
> Microsoft product) "highlighting".  In cases, when the path or the
> file name contain spaces, it's very convenient to just enclose the
> whole consruction in angle brackets (like, <schema://some
> path/with/spaces/and a file>), and you do not really have to worry
> about converting those in %20.  What would you say about such a
> feature?

According to RFC 2396 "Uniform Resource Identifiers (URI): Generic
Syntax", spaces are not valid URI/URL characters.  It does say this:

   In some cases, extra whitespace (spaces, linebreaks, tabs, etc.)
   may need to be added to break long URI across lines. The whitespace
   should be ignored when extracting the URI.
   ...
   Using <> angle brackets around each URI is especially recommended
   as a delimiting style for URI that contain whitespace.

The syntax you propose would conflict with this, especially if the
MS-style URL were to break across lines:

    <http://www.example.com/a/very/long/
    path/broken/across/lines>

Is the whitespace after "long/" significant or not?  The RFC says it's
not.  The reStructuredText parser also joins long multi-line URLs in
targets.  I wouldn't mind adding the ability to join broken URLs in
free text as well, if surrounded by brackets.

So the answer to your question is, I think I'd say no thanks.
Whitespace in URLs is a pain; I think it's better just to avoid it.

-- 
David Goodger  <go...@py...>  Open-source projects:
  - Python Docutils: http://docutils.sourceforge.net/
    (includes reStructuredText: http://docutils.sf.net/rst.html)
  - The Go Tools Project: http://gotools.sourceforge.net/

Hi

I need to convert plain text (with some formatting) to HTML format, and,
fortunately, this module provide this functionality (among other). :)

Having downloaded the 0.2 version, I tried to write a simple program to
convert from text to HTML.  It turned to out to be not that easy.
Fortunately, in mailing list archives I found a suggestion to download
the snapshot and proceed with publish_string helper.  This works great,
thank you.

I have two questions, however.

It looks like I cannot get only the body of the text (what is located
between <body> ... </body>) without some addtional programming, nor it's
possible to get rid of use stylesheets at all.  What would be the best
way to accomplish this?

The second comes from my rather extensive use of Outlook (yes, a
Microsoft product) "highlighting".  In cases, when the path or the file
name contain spaces, it's very convenient to just enclose the whole
consruction in angle brackets (like, <schema://some path/with/spaces/and
a file>), and you do not really have to worry about converting those in
%20.  What would you say about such a feature?

Best Regards,

--
Misha

Greetings from Bali...
Beyond the immediate victims, the terrorist acts of 12 Oct 2002 in Bali send chilling shivers to the islands tourism industry, the very lifeblood of the island. Tourism industry in Bali employs hundreds of thousands of people, feeding around 3 million people in the island. If tourists stop coming, there will be a lot more victims...
We are calling for Backpackers around the world to help revive tourism to Bali!
To help do this, we have created a portal for Backpackers to visit Bali: http://www.budgetbali.com Please kindly visit the site. 
You can book online over 100 bed-and-breakfasts at heavily discounted prices. Long stays deals, homestays and rental homes are coming soon. We will also be putting in a forum and continue to improve the site. Inputs and suggestions are most welcome, as well as other resources that would be useful and links exchanges with other backpacking resources on the net. 
Sincerely,
--Eka Ginting
Enter your text here. ----------------------------------------------------------------------- *** indo.com CRM - Mailing List Management *** 
indo.com - the leading internet company in indonesia
<br>
http://www.indo.com & http://www.orientmagix.com : great deals for traveling to Indonesia & ASEAN
<br>
http://www.paketrupiah.com : instant travel in comfort and good time for Indonesian residents
<br>
http://www.rajacraft.com : buy quality indonesian crafts at wholesale prices
<br>
http://www.siliconbali.com : deploy internet technology for your business
<br>

 Sent using http://www.turbocustomer.com - guaranteed lower costs to send your email, SMS, and international faxes!<p>click <a href="http://www.turbocustomer.com/unsub.php3?op=unsub&email=doc...@li...&coid=3">UNSUBSCRIBE</a> to unsubscribe</p>

Brett g Porter wrote:
> I'm trying to document a C struct that's like:
> 
> ::
>     {
>         int field1;
>         int field2;
>     }
> 
> by keeping the code in literal blocks (in reality, it's a rather
> large struct, and not every member needs annotation, something like:
> 
> ::
>     {
>         int field1;
> 
> This is a clever note about field1
> 
> ::
> 
>         int field2;
> 
> this is another witticism
> 
> ::
>     }
> 
> ...but the indentation for the literal ``int field2;`` is not
> consistent (because it doesn't have the curly braces to give it that
> indentation context any more.
> 
> Suggestions for how to accomplish what I'm trying?

First, don't forget that you need a blank line after the "::" (it must
be alone or at the end of a paragraph).

The simplest way I can think of is to use some text to mark the left
edge of your literal block.  I'd choose ellipsis ("..."), since it
indicates "continuing...":

    ::

        ...
            int field2;

    this is another witticism

    ::

        ...
        }

Or the entire thing could be bordered on the left:

    ::

        |   {
        |       int field1;
        |       int field2;
        |   }

(When splitting up the block, preserve the border bars.)

Or even line numbers:

    ::

        13: {
        14:     int field1;
        15:     int field2;
        16: }

Another way would be to use the "parsed-literal" directive:

    .. parsed-literal::
       \
           int field2;

The backslash establishes the left edge but disappears after parsing.
You have to be careful with parsed-literals though, becuase any inline
markup *is* parsed.

Finally, a runtime setting (set via directives and/or command-line
options) could be introduced to establish fixed indentation levels.
The parser could then assume, for example, that Literal blocks always
begin 4 spaces to the right of the surrounding text.  This would
require implementation of course.  The quickest way to implementation
is to submit a patch!

-- 
David Goodger  <go...@us...>  Open-source projects:
  - Python Docutils: http://docutils.sourceforge.net/
    (includes reStructuredText: http://docutils.sf.net/rst.html)
  - The Go Tools Project: http://gotools.sourceforge.net/

Okay, here's what I'm trying to do -- I understand why I'm getting th=
e
output I'm getting, but I don't like it <g>.

I'm trying to document a C struct that's like:

::
    {
        int field1;
        int field2;
    }

by keeping the code in literal blocks (in reality, it's a rather larg=
e
struct, and not every member needs annotation, something like:

::
    {
        int field1;

This is a clever note about field1

::

        int field2;

this is another witticism

::
    }

=2E..but the indentation for the literal ``int field2;`` is not consi=
stent
(because it doesn't have the curly braces to give it that indentation
context any more.

Suggestions for how to accomplish what I'm trying?

thx...




--
//  Today's Oblique Strategy (=A9 Brian Eno/Peter Schmidt):
//  Do nothing for as long as possible
//  Brett g Porter * BgP...@ac...

[David]
>> From http://docutils.sf.net/spec/doctree.html#transitions:
>>
>>     A transition may not begin or end a section or document, nor
>>     may two transitions be immediately adjacent.
>>
>> The transitions were between sections (easy to see if you use the
>> tools/publish.py front end).  The parser isn't enforcing that rule,
>> which is a bug that should be fixed.

Fixed.  The parser now enforces the structure; transitions aren't
allowed at the beginning or end of sections or the document itself.

>> Removing the transitions turns up a much more serious bug though,
>> generating a traceback.  *This* could be an "include" directive
>> bug.  I'll look into it.

[Brett]
> ...that's why I put the transitions in -- I found that sequential
> "include"s with no intervening text stopped all the processing

You should have reported *that* as a bug! ;)

> putting transitions inbetween stopped the complaints.

That will work as a temporary work-around, until the "include"
directive problem is fixed.  I don't know *why* it works (or why it's
needed) yet.

It turns out that part the problem is quite deep.  The "include"
directive starts a nested parse, which means that a section in the
included file must be complete (it can't start in the included file
and finish in the master file).  This isn't very useful, so the
implementation of the "include" directive has to be rethought.
Unfortunately, to fix "include" it may be necessary to rework a very
low-level aspect of the parser.  If you're interested, I'll be
following up on this on the docutils-develop list
(http://lists.sf.net/lists/listinfo/docutils-develop).

> Unfortunately I've been in the position of needing to convert an
> existing doc over to reStructuredText in a hurry, and haven't had
> much time to study the spec or the code closely.

Understandable :)

> Kudos again on building a system that let me get as far as I did in
> a few hours!

Thanks.

-- 
David Goodger  <go...@us...>  Open-source projects:
  - Python Docutils: http://docutils.sourceforge.net/
    (includes reStructuredText: http://docutils.sf.net/rst.html)
  - The Go Tools Project: http://gotools.sourceforge.net/

----- Original Message -----
From: "David Goodger" <go...@us...>
To: "Brett g Porter" <bgp...@ac...>;
<doc...@li...>
Sent: Tuesday, October 29, 2002 7:55 PM
Subject: Re: [Docutils-users] problems with .. include:: ?


> Brett g Porter wrote:
> > I'm really enjoying Restructured Text.
>
> Glad to hear it!  (No space though: reStructuredText.)

Sorry -- as someone who insists that the world honor my request to lowercase
my middle initial, I guarantee that I'll get it right from now on.

> > I grabbed the cvs snapshot yesterday
> > and everything was working as documented and as expected until I started
> > dividing a very large document up into chapters and using the
> > .. include::
> >
> > directive to pull the chapters into the 'real' output document. Chapters
> > that are pulled in via the include directive are omitted from the
generated
> > table of contents. Well, on closer examination, the very last chapter
pulled
> > in is included, but none of the others are.
>
> That actually had nothing to do with the "include" directive.  It was
> because of the transitions (lines of dashes in a.txt) between sections.
The
> table of contents is compiled in reverse from the end of the document,
> stopping at the first non-section; in this case a transition.  Thus only
the
> last section got in.
>
> From http://docutils.sf.net/spec/doctree.html#transitions:
>
>     A transition may not begin or end a section or document, nor may
>     two transitions be immediately adjacent.
>
> The transitions were between sections (easy to see if you use the
> tools/publish.py front end).  The parser isn't enforcing that rule, which
is
> a bug that should be fixed.  Removing the transitions turns up a much more
> serious bug though, generating a traceback.  *This* could be an "include"
> directive bug.  I'll look into it.
>
...that's why I put the transitions in -- I found that sequential "include"s
with no intervening text stopped all the processing and (through guessing
and blind luck) that putting transitions inbetween stopped the complaints.
Unfortunately I've been in the position of needing to convert an existing
doc over to reStructuredText in a hurry, and haven't had much time to study
the spec or the code closely. Kudos again on building a system that let me
get as far as I did in a few hours!

BgP

Brett g Porter wrote:
> I'm really enjoying Restructured Text.

Glad to hear it!  (No space though: reStructuredText.)

> I grabbed the cvs snapshot yesterday
> and everything was working as documented and as expected until I started
> dividing a very large document up into chapters and using the
> .. include::
> 
> directive to pull the chapters into the 'real' output document. Chapters
> that are pulled in via the include directive are omitted from the generated
> table of contents. Well, on closer examination, the very last chapter pulled
> in is included, but none of the others are.

That actually had nothing to do with the "include" directive.  It was
because of the transitions (lines of dashes in a.txt) between sections.  The
table of contents is compiled in reverse from the end of the document,
stopping at the first non-section; in this case a transition.  Thus only the
last section got in.

From http://docutils.sf.net/spec/doctree.html#transitions:

    A transition may not begin or end a section or document, nor may
    two transitions be immediately adjacent.

The transitions were between sections (easy to see if you use the
tools/publish.py front end).  The parser isn't enforcing that rule, which is
a bug that should be fixed.  Removing the transitions turns up a much more
serious bug though, generating a traceback.  *This* could be an "include"
directive bug.  I'll look into it.

> Is this a known limitation? Something that will be fixed? Or is this one of
> those "push up your sleeves and fix it, pal" things?

Not a known problem until now; thanks for the bug report.  It ought to be
fixed at some point, when someone considers it important enought to fix.  If
it's important to *you*, you should definitely attempt a fix or at least a
diagnosis.  Bug-fix patches are *always* welcome!  The docutils-develop list
is the best place to discuss bugs in the code.

-- 
David Goodger  <go...@us...>  Open-source projects:
  - Python Docutils: http://docutils.sourceforge.net/
    (includes reStructuredText: http://docutils.sf.net/rst.html)
  - The Go Tools Project: http://gotools.sourceforge.net/

Hi --

I'm really enjoying Restructured Text. I grabbed the cvs snapshot yes=
terday
and everything was working as documented and as expected until I star=
ted
dividing a very large document up into chapters and using the
=2E. include::

directive to pull the chapters into the 'real' output document. Chapt=
ers
that are pulled in via the include directive are omitted from the gen=
erated
table of contents. Well, on closer examination, the very last chapter=
 pulled
in is included, but none of the others are.

For example, I've created the following 4 files
a.txt ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
A Restructured Text include Test
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=2E. contents::

--------------

=2E. include:: b.txt


--------------

=2E. include:: c.txt


--------------

=2E. include:: d.txt


b.txt~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This is b.txt!
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Some body text here...


c.txt ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is C dot text
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


and also some body text in here!


d.txt~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
D . txt reporting for duty!
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

complete with a body!


end~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~`

This generates the following HTML (note that only the last one appear=
s in
the TOC)...



<?xml version=3D"1.0" encoding=3D"utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang=3D"en">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf=
-8" />
<meta name=3D"generator" content=3D"Docutils 0.2.7:
http://docutils.sourceforge.net/" />
<title>A Restructured Text include Test</title>
<link rel=3D"stylesheet" href=3D"default.css" type=3D"text/css" />
</head>
<body>
<div class=3D"document" id=3D"a-restructured-text-include-test">
<h1 class=3D"title">A Restructured Text include Test</h1>
<div class=3D"contents topic" id=3D"contents">
<p class=3D"topic-title"><a name=3D"contents">Contents</a></p>
<ul class=3D"simple">
<li><a class=3D"reference" href=3D"#d-txt-reporting-for-duty" id=3D"i=
d1"
name=3D"id1">
D . txt reporting for duty!</a></li>
</ul>
</div>
<hr />
<p>text here?</p>
<div class=3D"section" id=3D"this-is-b-txt">
<h1><a name=3D"this-is-b-txt">This is b.txt!</a></h1>
<p>Some body text here...</p>
</div>
<hr />
<div class=3D"section" id=3D"this-is-c-dot-text">
<h1><a name=3D"this-is-c-dot-text">This is C dot text</a></h1>
<p>and also some body text in here!</p>
</div>
<hr />
<div class=3D"section" id=3D"d-txt-reporting-for-duty">
<h1><a class=3D"toc-backref" href=3D"#id1" name=3D"d-txt-reporting-fo=
r-duty">D .
txt reporting for duty!</a></h1>
<p>complete with a body!</p>
</div>
</div>
</body>
</html>



Is this a known limitation? Something that will be fixed? Or is this =
one of
those "push up your sleeves and fix it, pal" things?




--
//  Today's Oblique Strategy (=A9 Brian Eno/Peter Schmidt):
//  Ask your body
//  Brett g Porter * BgP...@ac...
//  http://mywebpages.comcast.net/bgporter/

These questions are more suitable for the docutils-develop list;
cross-posting.

Ian Bicking wrote:
> To serve as an instructional sample I'm making a very simply Wiki --
> I'd like to use reST as the markup, since it's not an example in
> parsing (and I like the reST markup more than most Wiki markups to
> boot).

Great!  Please share the results if you can.  I know that some
intregration with MoinMoin has been done, although incomplete I
believe.  See
http://twistedmatrix.com/users/jh.twistd/moin/moin.cgi/RestSample

> So, to do this I need to convert reST to HTML.  I looked around in
> buildhtml.py to get an idea, but I found it surprisingly difficult
> to figure out just what I would need to do.

buildhtml.py is a complicated beast, trying to be a kind of "make",
recursively building HTML for regular and PEP files with integrated
local config file support.  It's not a good example to begin with.

> Could someone perhaps tell me what the easiest way to do this is?

First, make sure you're using the latest code from CVS or from the
snapshot: <http://docutils.sf.net/docutils-snapshot.tgz>.  Look in the
docutils/core.py file at the "publish_string" convenience function.
It is probably what you want.

Beyond the docstrings, there is no related developer documentation
yet.  Contributions are, of course, most welcome!

Perhaps the tools/pep2html.py module is a better example, function
"fix_rst_pep".  Docutils is called in one (logical) line of code::

    output = core.publish_string(
        source=''.join(input_lines),
        source_path=inpath,
        destination_path=outfile.name,
        reader_name='pep',
        parser_name='restructuredtext',
        writer_name='pep_html',
        settings=docutils_settings)

> I'm not sure of the relevance of the options, the importance of
> FileIO, or some of the other abstractions involved in this
> operation.

I've since renamed "options" to "settings": they're runtime
configuration settings (see
http://docutils.sf.net/docs/tools.html#configuration-file-entries).
For now, just use a convenience function with no explicit settings;
the defaults should be fine.
 
FileIO is an implementation detail; use strings with "publish_string"
or file-like objects with "publish_file".  Be sure to read the
docstrings.

> Also -- is there a good hook in reST that I can use for Wiki links?
> The linking mechanism reST has is fine for internal and external
> links, but doesn't fit right for Wiki links (which fall somewhere in
> between).  If I could capture failed internal links and turn them
> into inter-wiki-page links, that would be perfect.  Failing that, if
> there was some way I could introduce another markup easily that
> would be great.

There's mention of Wikis as an example potential Reader component in
PEP 258 (http://docutils.sf.net/spec/pep-0258.html#readers).  A Wiki
Reader could subclass the standard parser, or we could build in hooks
if they prove general enough.  The PEP Reader
(docutils/readers/pep.py) first subclassed the parser (still does,
minimally: the "Inliner" class), but most of the code was moved into
the parser proper for other client code to use.

I would suggest that Wiki links retain the trailing "_" of regular
reStructuredText links, and a mechanism be added to do some kind of
lookup from a Wiki target database.  The extra syntax (trailing "_")
removes ambiguity inherent in CamelCase WikiLinks (such as anything
written by Angus MacDuff).

> If there isn't an easy way, I'll probably just look for WikiNames in
> the generated HTML, and do the substitution then.  I'll have to do
> some dynamic fixup anyway, to distinguish between existent Wiki
> pages and to-be-created links.

A proper integrated approach would be best IMO, and welcome.  Please
subscribe to docutils-develop
(http://lists.sf.net/lists/listinfo/docutils-develop) and discuss it
there.  I'll be happy to help.

-- 
David Goodger  <go...@us...>  Open-source projects:
  - Python Docutils: http://docutils.sourceforge.net/
    (includes reStructuredText: http://docutils.sf.net/rst.html)
  - The Go Tools Project: http://gotools.sourceforge.net/