docutils-develop Mailing List for Docutils: Documentation Utilities (Page 406)

> > On Mon, 11 Nov 2002, Julien T. Letessier wrote:
> >
> > > On Nov 6, 2002, at 21:29, David Goodger  was heard saying:
> > >
> > > > These documents look *very* good!  You've made a lot of progress.
> > >
> > > IMHO, they look way better using the stylesheet I provided--in particular,
it
> > > mostly solves the footnote problem.
> > >
> > > I guess things will become easier if I commit my changes myself ;)
> >
> > i did commit your changes, didn't i ?
>
> sorry, my mistake---i didn't send the last updates :)
> anyways, i'll commit them myself next time!

i want to propose some changes:

style.tex should hold: the font (as sayed earlier palatino make pdfs bigger)

settings required for proper layout should be set by the writer (written
to the output): this concerns your solution for footnotes and figures.

the inclusion of the style file should be done after setting defaults,
so there is a possibility to overwrite defaults.

caveats: if an option is given to the documentclass other packages
  recognize it automatically (at least i read so), otherwise every
  concerned package needs the option (it said so in th FM).

and we need documented stylefiles so people have an idea what to use
it for.

-- 
 BINGO: next-generation Outsourcing
 --- Engelbert Gruber -------+
 SSG Fintl,Gruber,Lassnig   /
 A6410 Telfs Untermarkt 9  /
 Tel. ++43-5262-64727 ----+

On Mon, 11 Nov 2002, Julien T. Letessier wrote:

> On Nov 6, 2002, at 21:29, David Goodger  was heard saying:
>
> > These documents look *very* good!  You've made a lot of progress.
>
> IMHO, they look way better using the stylesheet I provided--in particular, it
> mostly solves the footnote problem.
>
> I guess things will become easier if I commit my changes myself ;)

i did commit your changes, didn't i ?


-- 
 BINGO: completely leverage other's inexpensive benefits
 --- Engelbert Gruber -------+
 SSG Fintl,Gruber,Lassnig   /
 A6410 Telfs Untermarkt 9  /
 Tel. ++43-5262-64727 ----+

On Nov 6, 2002, at 21:29, David Goodger  was heard saying:

> These documents look *very* good!  You've made a lot of progress.

IMHO, they look way better using the stylesheet I provided--in particular, it
mostly solves the footnote problem.

I guess things will become easier if I commit my changes myself ;)

Oh, and, *thanks* David, for being less lazy than we are, and preparing a
to-do list... You last mail is now flagged as 'important' in my mailbox :)

Cheers,
-- 
Julien T. Letessier                   aim: JLetessier
Post-graduate ENSIMAG Student         web: http://www.mezis.net
IMAG IVR Master Student               email: co...@me...
---------------------------------------------------------------
SourceForge projects:
Solarpack: Distributing free software for Solaris
Docutils:  Python documentation framework
---------------------------------------------------------------

On Fri, 8 Nov 2002, David Goodger wrote:

> [David]
> >> * Shouldn't literal blocks be indented, or have some kind of
> >>   decoration (solid left margin, etc.)?  I think relying on the
> >>   typeface is too subtle; indentation helps distinguish literal
> >>   blocks from the surrounding text.  Inline literals look fine the
> >>   way they are.
>
> [Engelbert]
> > donot talk about intendation (see test.txt line_block) latex
> > is sovereign over space vertical and horicontal.
>
> If that's true, then LaTeX is forcing you to mis-format your document.
> Perhaps the literal block (or verbatim or whatever) primitive doesn't
> support indentation.  In that case, put it inside a block quote that
> *does* allow indentation.

david currently i am happy that this and the address docinfo does
correct linebreak. this is done inside encode (which does more and more,
and could you have a quick glance at it, if you could think of
another way to do it).

> I treat HTML as a set of primitives.  I try to keep the generated HTML
> documents "clean", but only where practical.  Don't try to create
> pristine TeX output if it's just that: output.  Sometimes faking it is
> OK.

then latex might be not optimal, latex is made to enforce layout rules
that the users never thought of (IMHO)
maybe another possibility would beto use tex not latex, but not for now.

> >> * The "dedication" and "abstract" bibliographic fields get
> >>   transformed to "topic" elements, specifically <topic
> >>   class="dedication"> and <topic class="abstract"> in the internal
> >>   doctree.  Topic should be rendered like sections (i.e., title
> >>   above the body), only indented or otherwise set off from the rest
> >>   of the document.  See
> >>   http://docutils.sf.net/spec/doctree.html#topic .
> >
> > i know: latex has an abstract environment and thanks (a footnote to
> > the document title), but as described earlier, i am not sure about
> > the direction.
>
> I don't follow.

\begin{abstract}
this and that
\end{abstract}

is the way to add an abstract in latex, which then puts it in correct
place.

> > we use pagenumbering from latex and section numbering from docutils
> > (docutils has sectionnumbering because html does not have it, but
> > docutils uses <ol> numbering from html).
>
> What does this have to do with anything?

the html writer generates the section numbering, but does not
generate the ol-numbering.

in latex the writer could allow latex to generate section and
ol-numbering.

> >> * Why does the "figure" (section 2.14.2) appear at the very end of
> >>   the document?  I could understand it floating to the top or
> >>   bottom of the page it appears on, but it moves too far.
> >
> > latex figures are moveable (as are tables, what should it do if it
> > does not fit on this page) therefore a reference to a figure says
> > "see fig.132" and there is a "list of figures".
>
> But there's no reason for a figure to move all the way to the end of
> the document.  Could it be because the image is so large?  (IIRC,
> TeX's algorithm for things too big to put on a page is to try them on
> the next page, but if the thing is too large for *any* page,
> degenerate cases may result.)

you described it correct i guess.

> >> [DG] Please feel free to take this list and incorporat it in your
> >> To-Do
> >
> > [EG] feel free to do it yourself :-) my sandbox has no fence.
>
> [DG] Just a suggestion, take it or leave it as you like.  I've got
> plenty on *my* To-Do list, thanks.

i meant you could put it into my todo, not you should fix it.

although if you find some time to make a code review this could help
both of us, because you also are writing a writer. if you do review
just make comments like # BUG or so.

cheers

--
engelbert gruber
email: eng...@ss...

On Fri, 8 Nov 2002, David Goodger wrote:

> gr...@us... wrote:
> > is it correct that the numbering scheme is not taken from source.
>
> No.  It works in HTML.  What output format/Writer are you talking
> about?

tools/html.py, whatever it uses. i see to it closer.


--
engelbert gruber
email: eng...@ss...

Fred L. Drake, Jr. wrote:
> Is the goal to have the content portion of .ht files be reST, or to
> allow HT2HTML to start with reST content to begin with?

What's the distinction?

Actually, the Docutils component that Oliver wrote produces ordinary .ht
intermediate files: RFC822 headers plus regular HTML.  It's an ht2html
"Writer".  The way it's written now, one would have to run Docutils and then
ht2html.  It would almost require a Makefile.  Not ideal.

But it should be easy to make an ht2html "Reader" (Docutils code calls
ht2html) or a generator module for ht2html (which would call Docutils code).
One of these days I'd like to actually *use* ht2html, and dig through the
code; then I'll have a better idea of which side should be "in control".

> I'm sure either could be done, but using .ht files with reST for the
> body would be the easier of the two.

Yes, they would look *exactly* like reStructuredText PEP source files.

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

>>>>> "DG" == David Goodger <go...@py...> writes:

    DG> I don't know how encoding-friendly ht2html is.

Probably not at all.  Or to put it another way, it's completely
ignorant of all such issues.

-Barry

David Goodger writes:
 > I agree.  There has been some interest in integrating the two recently.
 > Oliver Rutherfurd has written a preliminary Writer component for .ht output:
 > http://docutils.sourceforge.net/sandbox/oliverr/ht/

Cool!

 > I think this is a roundabout way of doing the job.  Please take a look at
 > the link above.  It produces real .ht files, with the title in the RFC822
 > header.  The encoding could go there too (assuming it's ASCII-compatible).
 > I don't know how encoding-friendly ht2html is.

I doubt it is, but it could be made more so.

 > Ideally, I'd like to see a system which programmatically controls both
 > Docutils and ht2html, so that intermediate files don't have to be created.
 > I haven't looked into the ht2html code enough yet to know if this is
 > feasible.

Is the goal to have the content portion of .ht files be reST, or to
allow HT2HTML to start with reST content to begin with?  I'm sure
either could be done, but using .ht files with reST for the body would
be the easier of the two.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation

On Fri, 8 Nov 2002 14:16:30 -0800 (PST) Brett Cannon <ba...@OC...>
wrote:

[...]
> > I wouldn't be surprised if we can't get any better syntax than what's
> > already been proposed.  There are only so many characters in 7-bit
> > ASCII.
> 
> Could always move to Unicode.  =)

And then we'd have the problem of deciding *which* unicode char that
represents an arros (there's probably quite a lot of them) to use... :)

---
Adam Chodorowski <ad...@ch...>

Du räknar så dåligt att du måste vara naken för att kunna räkna till 21.
    -- Brad S / Datormagazin

[David Goodger]

> First, nobody's been asking for it.  Simon Budig, the original
> proposer, has been quiet.  There are old sayings that are applicable
> here: "the squeaky wheel gets the grease" and "out of sight, out of
> mind".
>

Well that issue has now been solved.  =)

> Second, I'm still not comfortable with any of the syntax variations.
> Each of them has the problem of "poor plaintext readability", but
> that's a direct consequence of putting the URL in the text (inline).
> Can't be helped.  It's the nature of the beast.
>

Yes, unfortunately.  I am afraid this one might come down to the least
offensive solution.

> Listed below are the "front-runner" (#1) and Brett's proposed syntax
> variations:
>
> 1. `phrase reference <" rel="nofollow">http://www.example.org/phrase_reference/>`__
>
> 2. `phrase reference`->http://www.example.org/phrase_reference/

<snip>

>
> Of the new proposals (2-5), #2 is the least objectionable to me.  All
> the others look much too cluttered, and "@" already has the
> connotation of email addresses.  But #2 lacks consistency with the
> existing reference syntaxes, which all use trailing underscores.
> Attempting to fix that leads us to:
>
> 6. `phrase reference`__ ->http://www.example.org/phrase_reference/
>
> But the whole point is that
>
>     The underscore can be thought of as a right-pointing arrow.  The
>     trailing underscores point away from hyperlink references, and the
>     leading underscores point toward `hyperlink targets`_.
>

I don't view the underscores like that (might be my training in philosophy
and symbolic logic).  I see them more just as visual delineators for the
reST parser and not as a metaphorical pointer.  This is especially true
since the hyperlink that the underscores supposedly point to are never on
the same line and can quite easily have other text between the text and
the link.

I do understand the point that it does not exactly fit in with the rest of
reST.  But then again I personally find the angle brackets obtrusive and
ugly.  If I wanted angle brackets I would be using XML.  =)

> I still think syntax #1 above is the best alternative.  The brackets
> serve a useful function, since they're associated with URLs already.

True, but then having a syntax that somehow connects to the beginning of
the URL serves the same purpose of association.

> Don't forget that not all URLs are absolute (beginning with
> "http://"); many are relative, and don't look URLs without the
> brackets.  Let's look at all the variations with relative URLs:
>
> 1. `phrase reference <relative_url>`__
>
> 2. `phrase reference`->relative_url
>
> 3. `phrase reference`@relative_url
>
> 4. `phrase reference`__ @relative_url
>
> 5. `phrase reference`_@_relative_url
>
> 6. `phrase reference`__ ->relative_url
>
> 7. `phrase reference`__ __<relative_url>
>
> To me, syntax #1 is even more strongly in front with relative URLs.
>

Here is a case where #1 looks better to me then before, but not enough to
discount #2 for me.  But then again I am biased toward how it looks for
absolute hyperlinks since that is what all of my links are.

> I wouldn't be surprised if we can't get any better syntax than what's
> already been proposed.  There are only so many characters in 7-bit
> ASCII.
>

Could always move to Unicode.  =)

> CALL FOR OPINIONS: Please take a look at the implementation notes
> (http://docutils.sf.net/spec/notes.html#inline-external-targets) and
> tell us what you think.  The alternatives are: implement this as a
> general feature; require a global/pragma directive to enable it;
> require a local directive; or don't implement it at all.
>

I vote for general feature or a directive.  Either was I want the feature.
=)

> Just thought of a better name for this beast: "embedded targets".
>

Using "embedded" works for me, but not targets.  When I hear "target" I
think of internal document target liks <a name="Target1" />.  "Embedded
hyperlinks" sounds better to me.

-Brett

gr...@us... wrote:
> is it correct that the numbering scheme is not taken from source.

No.  It works in HTML.  What output format/Writer are you talking
about?

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

[David]
>> How about getting docutils-users added too (for completeness)?

[Michael]
> Well, sure.  But it doesn't seem to get much traffic.  I've fired
> off a request, so it should appear after the next post to the list.

Thank you!  Gmane has a much better web interface than the SourceForge
mail archives.  And I'm sure the news gateway is useful too.

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

Brett Cannon wrote:
> Since this is my first post to the list I should probably introduce
> myself.  My name is Brett Cannon and I write the python-dev Summary.
> That is also where my use of Docutils and reST stems from.  This is
> also why I would love to see a way to do inline hyperlinks.

Welcome, Brett!  Your Python-Dev Summaries are a perfect example of
the kind of document where inline targets would be beneficial.  This
feature has languished unattended for two reasons:

First, nobody's been asking for it.  Simon Budig, the original
proposer, has been quiet.  There are old sayings that are applicable
here: "the squeaky wheel gets the grease" and "out of sight, out of
mind".

(There's also the old Japanese saying, "the nail that sticks up gets
hammered down".  It's a cultural thing, group harmony versus
individual creativity and innovation.  Draw your own conclusions.)

Second, I'm still not comfortable with any of the syntax variations.
Each of them has the problem of "poor plaintext readability", but
that's a direct consequence of putting the URL in the text (inline).
Can't be helped.  It's the nature of the beast.

Listed below are the "front-runner" (#1) and Brett's proposed syntax
variations:

1. `phrase reference <" rel="nofollow">http://www.example.org/phrase_reference/>`__

2. `phrase reference`->http://www.example.org/phrase_reference/

3. `phrase reference`@http://www.example.org/phrase_reference/

4. `phrase reference`__ @http://www.example.org/phrase_reference/

5. `phrase reference`_@_http://www.example.org/phrase_reference/

Of the new proposals (2-5), #2 is the least objectionable to me.  All
the others look much too cluttered, and "@" already has the
connotation of email addresses.  But #2 lacks consistency with the
existing reference syntaxes, which all use trailing underscores.
Attempting to fix that leads us to:

6. `phrase reference`__ ->http://www.example.org/phrase_reference/

But the whole point is that

    The underscore can be thought of as a right-pointing arrow.  The
    trailing underscores point away from hyperlink references, and the
    leading underscores point toward `hyperlink targets`_.

    (http://docutils.sf.net/spec/rst/reStructuredText.html
    #hyperlink-references)

Factoring that back in, we're led back to syntax alternative #2 in
http://docutils.sf.net/spec/rst/alternatives.html#inline-external-targets:

7. `phrase reference`__ __<" rel="nofollow">http://www.example.org/phrase_reference/>

I still think syntax #1 above is the best alternative.  The brackets
serve a useful function, since they're associated with URLs already.
Don't forget that not all URLs are absolute (beginning with
"http://"); many are relative, and don't look URLs without the
brackets.  Let's look at all the variations with relative URLs:

1. `phrase reference <relative_url>`__

2. `phrase reference`->relative_url

3. `phrase reference`@relative_url

4. `phrase reference`__ @relative_url

5. `phrase reference`_@_relative_url

6. `phrase reference`__ ->relative_url

7. `phrase reference`__ __<relative_url>

To me, syntax #1 is even more strongly in front with relative URLs.

> I just realized that ambiguity with the ending of the hyperlink and
> possible punctuation might be an issue.

In email or news messages, yes, but that's true of any URL.  The URL
recognition depends on the client software.  The PiperMail software
that provides web access to Python mailing lists always includes a
trailing period if a URL appears at the end of a sentence (like this:
"... see http://www.example.org.").  The reStructuredText parser
always leaves off that pesky trailing punctuation though.  I realize
that your application, the Python-Dev Summaries, is primarily a
mail/news message, so that's important.  All you can do is keep on
delimiting the URLs somehow, with <brackets> or a space before the
period .

> Anyway, these are just some suggestions I came up with.

And thanks for them!

> I am willing to do my part to get in-line hyperlinks into reST if a
> reasonable syntax can be agreed upon.

I wouldn't be surprised if we can't get any better syntax than what's
already been proposed.  There are only so many characters in 7-bit
ASCII.

CALL FOR OPINIONS: Please take a look at the implementation notes
(http://docutils.sf.net/spec/notes.html#inline-external-targets) and
tell us what you think.  The alternatives are: implement this as a
general feature; require a global/pragma directive to enable it;
require a local directive; or don't implement it at all.

Just thought of a better name for this beast: "embedded targets".

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

[David]
>> So should directive options be translated too?

[Adam]
> IMHO, yes. If we translate everything else, directive options should
> also be translated. For consistency, if nothing else...

So all we need now is an implementation...

[David] 
>> * Shouldn't literal blocks be indented, or have some kind of
>>   decoration (solid left margin, etc.)?  I think relying on the
>>   typeface is too subtle; indentation helps distinguish literal
>>   blocks from the surrounding text.  Inline literals look fine the
>>   way they are.

[Engelbert]
> donot talk about intendation (see test.txt line_block) latex
> is sovereign over space vertical and horicontal.

If that's true, then LaTeX is forcing you to mis-format your document.
Perhaps the literal block (or verbatim or whatever) primitive doesn't
support indentation.  In that case, put it inside a block quote that
*does* allow indentation.

I treat HTML as a set of primitives.  I try to keep the generated HTML
documents "clean", but only where practical.  Don't try to create
pristine TeX output if it's just that: output.  Sometimes faking it is
OK.

>> * The "dedication" and "abstract" bibliographic fields get
>>   transformed to "topic" elements, specifically <topic
>>   class="dedication"> and <topic class="abstract"> in the internal
>>   doctree.  Topic should be rendered like sections (i.e., title
>>   above the body), only indented or otherwise set off from the rest
>>   of the document.  See
>>   http://docutils.sf.net/spec/doctree.html#topic .
> 
> i know: latex has an abstract environment and thanks (a footnote to
> the document title), but as described earlier, i am not sure about
> the direction.

I don't follow.

> we use pagenumbering from latex and section numbering from docutils
> (docutils has sectionnumbering because html does not have it, but
> docutils uses <ol> numbering from html).

What does this have to do with anything?

>> * Why does the "figure" (section 2.14.2) appear at the very end of
>>   the document?  I could understand it floating to the top or
>>   bottom of the page it appears on, but it moves too far.
> 
> latex figures are moveable (as are tables, what should it do if it
> does not fit on this page) therefore a reference to a figure says
> "see fig.132" and there is a "list of figures".

But there's no reason for a figure to move all the way to the end of
the document.  Could it be because the image is so large?  (IIRC,
TeX's algorithm for things too big to put on a page is to try them on
the next page, but if the thing is too large for *any* page,
degenerate cases may result.)

Again, if the TeX environment is fighting you, don't use the TeX
environment.  Just fake it.

>> Please feel free to take this list and incorporat it in your To-Do
> 
> feel free to do it yourself :-) my sandbox has no fence.

Just a suggestion, take it or leave it as you like.  I've got plenty
on *my* To-Do list, thanks.

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

[David]
>> Docutils is meant to be a tool for everyone, not just programmers
>> who understand the concept of "little language".  It may now be
>> limited to hackers & techies, but that's just because it hasn't
>> matured enough.

[Engelbert]
> .. note:: matureing means we end where latex is.

I *think* I disagree, but I'm not quite sure what you are saying so
I'll reserve judgement. ;)

>> However, all the documentation is in English, so how would people
>> know about translated directive names etc.?
> 
> this is a bug in the documentation not in the concept.
> a translation table could be generated from the source modules.

Good idea.  Added to the to-do list.

> can we have the fallback AND the document_language, means
> in german i want to use *raw* or *unbearbeitet*.

Yes, I suppose.  Currently a warning (level-2 system message) is
generated in this case.  That could be downgraded to info/level-1,
which is normally suppressed.  Unless the "--strict-language" option
was set, in which case the warning would be upgraded to an
error/level-3.

> We have a third audience, although a silent one, the processing
> system.

To the processing system, they're just identifiers.  As long as
they're unique, it doesn't care what the base language is.

> ``include`` is not real a document content, but a processing
> directive, if this is for the *reader* it should read ``see file``.

Perhaps "insert" would be a better directive name?

But I take your point.  Some directives, like "note" and "image", are
names (nouns) of constructs without native syntax, and mean "this is a
[note]" or "put an [image] here".  Others, like "include" or
"section-autonumbering" (a.k.a. "sectnum"), are more like commands,
saying "[include] that file here" or "number my sections
automatically".

>  include in english is not a word it is a verb and a noun.

"Include" is a verb.  The only time I've heard it used as a noun is by
programmers, referring to C's "#include" directive as "an include".
This is non-standard usage.  The noun form is "inclusion".

> I am for quick starts. The fastest solution is *make it a policy*.

OK.  Policy: all directives shall be translated.  English names may
also be used, but native names take precedence in case of a conflict.

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

[David]
>> BTW, de.py needs translations of the "raw", "include", and "replace"
>> directives.  Could you please?

[Engelbert]
> i put the in as comments, dont know a proper word yet, would be a
> sentence.  but saying "include" in a document is not document
> content, but a processing command, the document would say "here the
> contents of xxx would be inserted" or "see xxxx for details" but not
> "include". for me these are two different audiences.

All I can suggest is to read the description in
http://docutils.sf.net/spec/rst/directives.html and decide on the best
word for your language.

> should we support both 'raw' and 'unbearbeitet'.

If "raw" is a German word, then sure.  Otherwise, it will be available
via the fall-back language, English.

>>       'topic': 'topic',  # Inhalt, Thema or =D0berbegriff
>>
>> There can be many keys with the same value.  Two of them anyway;
>> "inhalt" is already used for "contents".  Are they homonyms?
>=20
> actually it is =B8berbegriff (a summarizing (herding) concept ?)
> but this does not mean that this is the exact usage in document
> processing. e.g. contents is something different for a book writer
> an e-business monkey or a grocery worker.
...
> so what is a topic: something summarizing (the title sums up the
> document as does a chapter title ...)

"Contents" is short for "table of contents".  "Topic" is a kind of
self-contained subsection, or an admonition (like the "note"
directive) with its own title.  It's not a summary.  I suspect that
"=B8berbegriff" may not be the correct translation (but what do I know).

> inside the writer many things come as a topic and the writer has to
> decide when it is a title, that is why topic_class is there.

Don't understand.

> i am more in programming so thinking half english, as i understand
> these are domain specific translations, so xp says get a domain
> expert.

Or become one ;)

> so your intention is "directives translation is optional"
> so it is not an error if none is present, but if they are there
> we test them.

No, I think it should be an error if no directive translations are
present.

Idea (added to To Do list): the "test_language.py" module could test
all languages when run by "alltests.py", and it could accept a
language name argument if run as a script, like this::

    test_language.py de

If no argument, the default would be to test all language modules.

--=20
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/

Handzsuj,Thomas wrote:
> I have a suggestion for using ht2html together with docutils
> (http://docutils.sourceforge.net/)
> 
> The advantage is that I have to deal only with simple and readable ASCII
> files.

I agree.  There has been some interest in integrating the two recently.
Oliver Rutherfurd has written a preliminary Writer component for .ht output:
http://docutils.sourceforge.net/sandbox/oliverr/ht/

> The problem is that docutils creates normal html files. The information in
> the header of these files (e.g. title, charset) is lost if I use them as ht
> files.
> 
> To transfer this information I wrote a simple Parser based on SGMLParser. It
> collects information from the body and the get_.. functions take this
> information.

I think this is a roundabout way of doing the job.  Please take a look at
the link above.  It produces real .ht files, with the title in the RFC822
header.  The encoding could go there too (assuming it's ASCII-compatible).
I don't know how encoding-friendly ht2html is.

Ideally, I'd like to see a system which programmatically controls both
Docutils and ht2html, so that intermediate files don't have to be created.
I haven't looked into the ht2html code enough yet to know if this is
feasible.

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

is it correct that the numbering scheme is not taken from source.

this::

   ordered list with numbering.

   1. one
   2. two

   another list with Uppercase letters.

   A. an A
   B. a B

   how does it look like.


produces this::

   ordered list with numbering.
    1. one
    2. two

   another list with Uppercase letters.
    1. an A
    2. a B

   how does it look like.



-- 
 BINGO: completely leverage other's inexpensive benefits
 --- Engelbert Gruber -------+
 SSG Fintl,Gruber,Lassnig   /
 A6410 Telfs Untermarkt 9  /
 Tel. ++43-5262-64727 ----+

David Goodger <go...@py...> writes:

> [David]
> >> I saw it on the docutils-checkins list.  Subscribe at
> >> http://lists.sf.net/lists/listinfo/docutils-checkins to keep up to
> >> date on changes to CVS.
> 
> [Michael]
> > Or read it on Gmane; I got -checkins and -develop added a couple of
> > weeks back.
> 
> Aha!  So *you're* the instigator!  Could be useful; thanks.

It's a damn sight easier to subscribe to a newsgroup than a mailing
list!  I don't even have to muck with procmail.

> How about getting docutils-users added too (for completeness)?

Well, sure.  But it doesn't seem to get much traffic.  I've fired off
a request, so it should appear after the next post to the list.

Cheers,
M.

I've just checked in code for ViewList and StringList classes to
docutils/statemachine.py.  StringList objects are now used inside the
state machine (the guts of the parser) instead of standard Python
lists.  The change should be internal-only, with no outside effects,
but outside code should be tested.  Please let me know if there are
any problems.

Here's the ViewList class docstring:

    List with extended functionality: slices of ViewList objects are
    child lists, linked to their parents. Changes made to a child list
    also affect the parent list.  A child list is effectively a "view"
    (in the SQL sense) of the parent list.  Changes to parent lists,
    however, do *not* affect active child lists.  If a parent list is
    changed, any active child lists should be recreated.

    The start and end of the slice can be trimmed using the
    `trim_start()` and `trim_end()` methods, without affecting the
    parent list.  The link between child and parent lists can be
    broken by calling `disconnect()` on the child list.

    Also, ViewList objects keep track of the source & offset of each
    item. This information is accessible via the `source()`,
    `offset()`, and `info()` methods.

BTW, this solves the "include" directive problems brought up by Brett
Porter last week.  (A long way to go to fix a small problem!  But it
should pay off in the long term.)

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

[David]
>> I saw it on the docutils-checkins list.  Subscribe at
>> http://lists.sf.net/lists/listinfo/docutils-checkins to keep up to
>> date on changes to CVS.

[Michael]
> Or read it on Gmane; I got -checkins and -develop added a couple of
> weeks back.

Aha!  So *you're* the instigator!  Could be useful; thanks.

How about getting docutils-users added too (for completeness)?

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

[David]
>> For those who would prefer to use English directive names, a
>> command-line option could be added.

[Vasko]
> ok, I agree with this. command-line will be fine,

Could you translate docutils/parsers/rst/languages/en.py for us?

> but, *please*, make bibliographic fields optionally in english, too

I am of mixed feelings about this, but I will add it to the to-do
list.  If you really want it, a patch is the fastest way to get it
implemented!

> attached is diff for unicode version of sk.py with translated
> bibliographics fields, too

Thank you.  May I ask you for updates in the future?

I noticed that the é (\u00e9) was removed from the end of the
translation of "abstract" ("Abstraktne").  Should it be there?

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

> bibliographic field lists.  For those who would prefer to use English
> directive names, a command-line option could be added.

ok, I agree with this. command-line will be fine, but, *please*,
make bibliographic fields optionally in english, too

attached is diff for unicode version of sk.py with translated
bibliographics fields, too

thanks,
miro

David Goodger <go...@py...> writes:

> gr...@us... wrote:
> > On Tue, 5 Nov 2002, David Goodger wrote:
> >> I noticed that Engelbert Gruber has already added sk.py to CVS.
> >> Unfortunately,
> >>
> >>     --- NEW FILE: sk.py ---
> >>     (This appears to be a binary file; contents omitted.)
> >>
> >> That's exactly what I'm talking about.
> >
> > sorry but since a week or so cvs hangs after the last file
> > so this did not get through to me.
> 
> I saw it on the docutils-checkins list.  Subscribe at
> http://lists.sf.net/lists/listinfo/docutils-checkins to keep up to
> date on changes to CVS.

Or read it on Gmane; I got -checkins and -develop added a couple of
weeks back.

Cheers,
M.

-- 
  While preceding your entrance with a grenade is a good tactic in
  Quake, it can lead to problems if attempted at work.    -- C Hacking
               -- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html