docutils-develop — For developer discussions of the implementation.

Re: [Docutils-develop] Re: LaTeX/PDF critique

[<eng...@ss...>]

On Sun, 17 Nov 2002, Simon Budig wrote:

> gr...@us... (gr...@us...) wrote:
> > On Wed, 6 Nov 2002, David Goodger wrote:
> > > * Since TeX uses curly quotes (which it expresses ``thusly''), perhaps
> > >   the LaTeX writer could convert regular double-quotes to TeX-style
> > >   quotes?  Or can TeX/LaTeX do that automatically?  Currently all
> > >   double-quotes look like (just blur your eyes a bit ;)::
> > >
> > >       99    99
> > >         this
> > >
> > >   whereas they should look like this::
> > >
> > >       66    99
> > >         this
> > >
> > >   If it's not feasible to get proper curly quotes, then the Writer
> > >   should use straight quotes.  Better to be ugly (straight quotes)
> > >   than wrong (bad curlies).
> >
> > is in the todo (latex2e-README.txt (someday i wipe my sand/dustbox))
>
> Whee! Typographically correct quotes!
>
> I'd just like to point out, that this is something that differs a bit
> in different languages. In Germany the following is used:
>
>                  66
>             this
>          99

should work in the last cvs (maybe a week or so).

> Also there are the options
>
>           >> this <<    (german)
>
> and       << this >>    (french IIRC)

should be possible to be done similar than the quotes. but this means
we sooner or later start parsing the text. up to now the writer just
did markups. (just to note)

whatfore are the << bracketts used typographically i mean.

> It would be *very* cool if one could select this somehow.  :-)

selection should be automatic (IMHO) by -l de for german.

-- 
 BINGO: assertively disseminate unique opportunities
 --- Engelbert Gruber -------+
 SSG Fintl,Gruber,Lassnig   /
 A6410 Telfs Untermarkt 9  /
 Tel. ++43-5262-64727 ----+

Re: [Docutils-develop] Re: Style sheet [was: LaTeX/PDF critique]

[<gr...@us...>]

On Sun, 17 Nov 2002, Julien Letessier wrote:

> On mardi, nov 12, 2002, at 07:59 Europe/Paris,
> gr...@us... wrote:
>
> > 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.
>
> sounds logical. i'll hard-code my TeX hacks into latex2e.py (if that's
> what you mean)

correct

> > the inclusion of the style file should be done after setting defaults,
> > so there is a possibility to overwrite defaults.
>
> yep, I'm perfectly okay ith that.
>
> > 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).
>
> As  a TeXnician, I've always considered as a bad habit using
> 'documentclass' options to set defaults for the various packages --
> rather specify the options exactly when needed. But if it makes your
> life easier, fine.

this was just a note, i donot know anything more about it.

i just learned this recently, and if have no idea how much this is needed.
this way we would not have to know which package uses which option,
but then again we might have to know what options to give to
documentclass.

> One point though -- I think we should keep the 'geometry' package
> included -- the '\geometry' command can be used in the stylesheet to
> modify the settings.

fine with me.

> > and we need documented stylefiles so people have an idea what to use
> > it for.
>
> You mean, provide a few documented examples?

yes

-- 
 BINGO: best of breed products and services
 --- Engelbert Gruber -------+
 SSG Fintl,Gruber,Lassnig   /
 A6410 Telfs Untermarkt 9  /
 Tel. ++43-5262-64727 ----+

Re: [Docutils-develop] Re: LaTeX/PDF critique

[Simon B. <Sim...@un...>]

gr...@us... (gr...@us...) wrote:
> On Wed, 6 Nov 2002, David Goodger wrote:
> > * Since TeX uses curly quotes (which it expresses ``thusly''), perhaps
> >   the LaTeX writer could convert regular double-quotes to TeX-style
> >   quotes?  Or can TeX/LaTeX do that automatically?  Currently all
> >   double-quotes look like (just blur your eyes a bit ;)::
> >
> >       99    99
> >         this
> >
> >   whereas they should look like this::
> >
> >       66    99
> >         this
> >
> >   If it's not feasible to get proper curly quotes, then the Writer
> >   should use straight quotes.  Better to be ugly (straight quotes)
> >   than wrong (bad curlies).
> 
> is in the todo (latex2e-README.txt (someday i wipe my sand/dustbox))

Whee! Typographically correct quotes!

I'd just like to point out, that this is something that differs a bit
in different languages. In Germany the following is used:

                 66
            this
         99

Also there are the options

          >> this <<    (german)

and       << this >>    (french IIRC)

It would be *very* cool if one could select this somehow.  :-)


Bye,
        Simon

PS: I am very happy about the inline target stuff. Thanks David!

-- 
      Sim...@un...       http://www.home.unix-ag.org/simon/

[Docutils-develop] Re: Style sheet [was: LaTeX/PDF critique]

[Julien L. <me...@fr...>]

On mardi, nov 12, 2002, at 07:59 Europe/Paris, 
gr...@us... wrote:

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

sounds logical. i'll hard-code my TeX hacks into latex2e.py (if that's 
what you mean)

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

yep, I'm perfectly okay ith that.

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

As  a TeXnician, I've always considered as a bad habit using 
'documentclass' options to set defaults for the various packages -- 
rather specify the options exactly when needed. But if it makes your 
life easier, fine.

One point though -- I think we should keep the 'geometry' package 
included -- the '\geometry' command can be used in the stylesheet to 
modify the settings.

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

You mean, provide a few documented examples?

Cheers,

-- julien

[Docutils-develop] Re: [Doc-SIG] Update to Docutils

[Brett C. <ba...@OC...>]

[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

[Docutils-develop] Update to Docutils

[David G. <go...@py...>]

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/

Re: [Docutils-develop] Unittests question

[Richard J. <rj...@ek...>]

On Fri, 15 Nov 2002 4:27 pm, Andreas Jung wrote:
> --On Freitag, 15. November 2002 09:02 +1100 Richard Jones
> <rj...@ek...> wrote:
> > On Fri, 15 Nov 2002 6:14 am, Andreas Jung wrote:
> >> - the test reside currently outside the docutils package instead
> >>   inside the package (as most Zope packages do).
> >
> > Is this an absolute necessity? It seems odd to install unit tests,
> > especially  since they'll probably never be run...
> >
> > I only ask becuase I do the same thing with my projects.
> >
> there are testrunners working all night to run all unittest
> for the different versions. I don't know why they should never be
> run?

Yes, but do the testrunners have to run the tests from the python std library? 

And surely users will rarely run unit tests every night?


    Richard

Re: [Docutils-develop] Unittests question

[Richard J. <rj...@ek...>]

On Fri, 15 Nov 2002 6:14 am, Andreas Jung wrote:
> - the test reside currently outside the docutils package instead
>   inside the package (as most Zope packages do).

Is this an absolute necessity? It seems odd to install unit tests, especially 
since they'll probably never be run...

I only ask becuase I do the same thing with my projects.


   Richard

Re: [Docutils-develop] Unittests question

[David G. <go...@py...>]

Andreas Jung wrote:
> I am currently thinking about checking the docutils tests into
> the zope core but I have currently three problems with that:
> 
> - not all tests pass (latest docutils checkout)

The addition of the test_language.py module has pointed out some
deficiencies.  Missing are a French translation of directive names (I
have a promise of a module) and some Swedish directive translations.
I hope they'll be added soon and then all tests will pass again.

> - the tests do not support Zope testrunner (a script that searches
>   for test*.py files containing  test_suite() method that return
>   an instance of unittest.makeSuite())

There's no standard (that I know of) for directories of unit tests.
Everybody makes up their own, so it's no surprise that we don't follow
the same standard!  I think ours works well and would make a good
addition to the standard unittest.py.  (Zope's may be just as good or
better; I wouldn't know.)

Each of the Docutils test modules either

* contains multiple unittest.TestCase subclasses (modules directly in
  docutils/test), or

* has a "suite" function that returns an instance of
  unittest.TestSuite (modules in subdirectories of docutils/test).

It would be easy enough to add ``test_suite = suite`` to each of the
latter group of test modules, if that works for Zope.  I don't know
what to do about the former group though.

Please note that the docutils/test/DocutilsTestSupport.py module is
used by all of the test modules.  The subdirectories are in fact
packages, with __init__.py files which help individual test modules to
find and import the DocutilsTestSupport module (which in turn imports
package_unittest.py).

> - the test reside currently outside the docutils package instead
>   inside the package (as most Zope packages do).

Docutils is installed using Distutils (setup.py), and I don't see the
point in copying test modules to Python's site-packages directory.
The test code takes up a lot of disk space, more than the Docutils
code itself.

But you're welcome to copy the test directory in for Zope.

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

[Docutils-develop] Re: [Doc-SIG] in-line hyperlinks

[David G. <go...@py...>]

Sorry about the delay replying.

[David]
>> 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`_.

[Brett]
> 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.

Of course they're "visual delineators"; so is *all* syntax.  In the
end, everything is just pixels on a screen or ink on paper.  The point
is that in reStructuredText's terms, the underscores *act* as if
they're right-pointing arrows, pointing away from references and
toward targets.  Example below.  The existing forms of hyperlinks use
underscores in this way, and I don't see any value in adding new
syntax ("->") to do the same conceptual job.  Also, the underscore
syntax (which originated with Setext) was chosen because underscores
are unobtrusive; "->" stands out more.

>> Just thought of a better name for this beast: "embedded targets".
>
> Using "embedded" works for me, but not targets.

This is in terms of the reStructuredText vocabulary, in which a
"hyperlink" is made up of two parts, a "reference" and a "target".
The vocabulary is established, and it's not going to change without a
good strong reason.

Putting them together, we have a reference::

    name_

and a target::

    .. _name: URL

The reference name is what ties the two together.

In any case, I'm going to call it "embedded URI", which is very
specific.

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

I'm going to make it a general feature.

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

Re: [Docutils-develop] Unittests question

[Andreas J. <an...@an...>]

there are testrunners working all night to run all unittest
for the different versions. I don't know why they should never be
run?

-aj

--On Freitag, 15. November 2002 09:02 +1100 Richard Jones 
<rj...@ek...> wrote:

> On Fri, 15 Nov 2002 6:14 am, Andreas Jung wrote:
>> - the test reside currently outside the docutils package instead
>>   inside the package (as most Zope packages do).
>
> Is this an absolute necessity? It seems odd to install unit tests,
> especially  since they'll probably never be run...
>
> I only ask becuase I do the same thing with my projects.
>
>
>    Richard




    ---------------------------------------------------------------------
   -    Andreas Jung                     http://www.andreas-jung.com   -
  -   EMail: andreas at andreas-jung.com                              -
   -            "Life is too short to (re)write parsers"               -
    ---------------------------------------------------------------------

[Docutils-develop] Unittests question

[Andreas J. <an...@an...>]

I am currently thinking about checking the docutils tests into
the zope core but I have currently three problems with that:

- not all tests pass (latest docutils checkout)

- the tests do not support Zope testrunner (a script that searches
  for test*.py files containing  test_suite() method that return
  an instance of unittest.makeSuite())

- the test reside currently outside the docutils package instead
  inside the package (as most Zope packages do).

Zophistas love unittests and it would be a shame to leave them out.

Any ideas?

Andreas


    ---------------------------------------------------------------------
   -    Andreas Jung                     http://www.andreas-jung.com   -
  -   EMail: andreas at andreas-jung.com                              -
   -            "Life is too short to (re)write parsers"               -
    ---------------------------------------------------------------------

Re: [Docutils-develop] test_language.py

[Aahz <aa...@py...>]

On Wed, Nov 13, 2002, David Goodger wrote:
> Aahz wrote:
>> On Tue, Nov 12, 2002, David Goodger wrote:
>>>
>>> General tip: at the top of script files, don't use::
>>> 
>>> #!/usr/bin/python
>>> 
>>> Please use this instead::
>>> 
>>> #! /usr/bin/env python
>> 
>> Enh.  Too many sysadmins I know decry this practice as a security risk.
> 
> Do you know of any good references?  Genuinely curious.

No handy references, but IIRC, the primary worry is that someone could
install a nasty shell script into your path named "python".  Also, with
the regular version increases in Python, I've seen more people recommend
using a specific version number.

As for myself, I usually call my scripts as "python script.py", which is
guaranteed to work in Windoze.

>> It's not in PEP 8.
> 
> PEP 8 doesn't mention hash-bangs or script execution at all; I don't
> get the point.

The point was that you seemed to be pushing it as a "standard", and I
was reminding you that it's not.
-- 
Aahz (aa...@py...)           <*>         http://www.pythoncraft.com/

A: No.
Q: Is top-posting okay?

Re: [Docutils-develop] test_language.py

[David G. <go...@py...>]

eng...@ss... wrote:
> therefore en should be tested too (but i failed at it).

The en (English) module is being tested now.  I also added a check
for translations of all directives.

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

Re: [Docutils-develop] docutils/parsers/rst/languages/sk.py

[David G. <go...@py...>]

Vasko Miroslav wrote:
> I'm sending translated $subject as patch against CVS snapshot
...
> btw, do I have cvs write access for docutils module?

Yes, you do.  Please feel free to check in the patch yourself.

> one thing I want to know, docutils/languages/sk.py has punctuated characters
> translated as \Uxxxx, and my python2 (2.1.1, 2.1.3, 2.2.1) translates these
> characters as \xxx.  how can I get \Uxxxx representation?

The "unicode-escape" or "raw-unicode-escape" encoding might give it, but
ISTR that it gives \xXY instead of \u00XY.  \u00XY is equivalent to \xXY; I
used all-\uXXXX for consistency only.

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

[Docutils-develop] docutils/parsers/rst/languages/sk.py

[Vasko M. <va...@di...>]

hi,

I'm sending translated $subject as patch against CVS snapshot

one thing I want to know, docutils/languages/sk.py has punctuated =
characters translated as \Uxxxx, and my python2 (2.1.1, 2.1.3, 2.2.1) =
translates these characters as \xxx.  how can I get \Uxxxx =
representation?

thanks,
miro

btw, do I have cvs write access for docutils module?
 <<rst.sk.diff.gz>>=20

[Docutils-develop] Re: test_language.py

[Michael H. <mw...@py...>]

Richard Jones <rj...@ek...> writes:

> Someone mentioned to me that distutils (possibly recent versions) does some 
> sort of automagic munging of that line itself, but I haven't had a chance to 
> look into it.

Yeah, it does.  Since 2.1 (I think).  I remember hacking it to work
when installing Python itself.

Cheers,
M.

-- 
  I saw `cout' being shifted "Hello world" times to the left and
  stopped right there.                                -- Steve Gonedes

Re: [Docutils-develop] test_language.py

[<eng...@ss...>]

def test_directives(self): does not work, because::

  func, msg = directives.directive(d, module, None)

does not raise an error. inserted::

  if not func:
      failures += "%s (%s)," % (d, "unknown directive")

therefore en should be tested too (but i failed at it).

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

Re: [Docutils-develop] test_language.py

[David G. <go...@py...>]

> On Tue, Nov 12, 2002, David Goodger wrote:
>> General tip: at the top of script files, don't use::
>> 
>> #!/usr/bin/python
>> 
>> Please use this instead::
>> 
>> #! /usr/bin/env python

Aahz wrote:
> Enh.  Too many sysadmins I know decry this practice as a security risk.

Do you know of any good references?  Genuinely curious.

> While I use the trick myself, I'm not at all comfortable pushing it as a
> solution for general scripts.

I don't see how hard-coding a possibly-nonexistent, possibly-erroneous path
is any better.  It had me genuinely confused for a minute or two, wondering
why the complaint about bad syntax on a "function(*args)"-type call.

> It's not in PEP 8.

PEP 8 doesn't mention hash-bangs or script execution at all; I don't get the
point.

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

Re: [Docutils-develop] test_language.py

[Richard J. <rj...@ek...>]

On Wed, 13 Nov 2002 12:30 pm, David Goodger wrote:
> General tip: at the top of script files, don't use::
>
>     #!/usr/bin/python
>
> Please use this instead::
>
>     #! /usr/bin/env python
>
> The former is hard-coded.  For example, it finds Python 1.5.2 on
> RedHat.  The latter finds an executable called "python" on the user's
> path.  I've set up my environment so Python 2.2 is found first.  Some
> people will have their Python interpreter at /usr/local/bin/python or
> non-standard places.

A better scheme which is used in moinmoin and roundup setup.py installers is 
to munge the #! line when the script is installed so that it is hard-coded to 
use the same interpreter that ran the setup.py file. It also generates a .bat 
wrapper on windows that does an analogous thing for windows.

As Aahz pointed out, some people are touchy about "/usr/bin/env python". Being 
a sad little redhat user, even that line won't work for me because the real 
python is called "python2" on my system. The above setup.py trick 
automatically handles that situation.

Someone mentioned to me that distutils (possibly recent versions) does some 
sort of automagic munging of that line itself, but I haven't had a chance to 
look into it.


    Richard

Re: [Docutils-develop] test_language.py

[Aahz <aa...@py...>]

On Tue, Nov 12, 2002, David Goodger wrote:
>
> General tip: at the top of script files, don't use::
> 
>     #!/usr/bin/python
> 
> Please use this instead::
> 
>     #! /usr/bin/env python

Enh.  Too many sysadmins I know decry this practice as a security risk.
While I use the trick myself, I'm not at all comfortable pushing it as a
solution for general scripts.  It's not in PEP 8.
-- 
Aahz (aa...@py...)           <*>         http://www.pythoncraft.com/

A: No.
Q: Is top-posting okay?

Re: [Docutils-develop] test_language.py

[David G. <go...@py...>]

eng...@ss... wrote:
> maybe some kind soul can have a look at it.

Checked in your initial copy plus some extensive changes (see below).
Thanks!

> it does get all docutils.languages (even en_US should work).

Great, we can add US slang!  How about ".. contents-y'all::"? ;)
(Yes, I know a directive can't have a "'" in its name.)

I don't know if we'll ever need country/dialect codes, but in PEP 258
I defined the language codes as case-insensitive, so the module name
should actually be "en_us.py" (lower case).

> but i would like to setup a testcase per language so the
> test is not broken by the first error.

What is needed here is a dynamic, data-driven test suite.  Most of the
Docutils test modules use the test/DocutilsTestSupport.py module for
this.  I've modified the test_language.py code to use this framework,
dynamically creating a test (a TestCase object) for each language and
method.

> and this is my first try at unittest

You chose a challenge to begin with.  I suggest you look at
test_nodes.py, test_statemachine.py, or test_utils.py for more typical
examples.

General tip: at the top of script files, don't use::

    #!/usr/bin/python

Please use this instead::

    #! /usr/bin/env python

The former is hard-coded.  For example, it finds Python 1.5.2 on
RedHat.  The latter finds an executable called "python" on the user's
path.  I've set up my environment so Python 2.2 is found first.  Some
people will have their Python interpreter at /usr/local/bin/python or
non-standard places.

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

[Docutils-develop] using reStructuredText with ht2html

[Oliver R. <ol...@ru...>]

Hi All,

I've written a guide explaining how I'm using reStructuredText
with ht2html to create my website.

For anyone interested in reading it, the article can
be found here:

 http://www.rutherfurd.net/articles/rst-ht2html.html

Thanks to David Goodger for his feedback on this article.

Comments and criticism welcome!

-Ollie
ol...@ru...

[Docutils-develop] test_language.py

[<eng...@ss...>]

maybe some kind soul can have a look at it.

it does get all docutils.languages (even en_US should work).

but i would like to setup a testcase per language so the
test is not broken by the first error.

and this is my first try at unittest

-- 
 --- Engelbert Gruber -------+
 SSG Fintl,Gruber,Lassnig   /
 A6410 Telfs Untermarkt 9  /
 Tel. ++43-5262-64727 ----+

[Docutils-develop] RE: language for directives etc.

[Vasko M. <va...@di...>]

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

ok, tomorrow, it will be done

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

I can take a look at the code through weekend

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

of course

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

it is correct as in actual version of CVS

miro