docutils-users — General discussions, questions, help requests.

Re: [Docutils-users] Is rst2odt -l cs supposed to work?

[Guenter M. <mi...@us...>]

Dear Dave,

On 2017-05-19, Dave Kuhlman wrote:

> I did the following:

> 1. Merged your changes (patch file below) into my local repository.

> 2. Did a bit of testing.  I had an exception when a document
>    contained an admonition.  I fixed that.

> 3. Committed these changes to the central repository.

> Thank you for your help with this.  

> Let me know if/when there is something more I can do.

I have one more patch that makes the code failsafe for Python
implementations missing the locale module (e.g. Jython).

If you could add a short summary of changed to the HISTORY.txt file,
we should be ready for release.

Thanks,

Günter



Index: __init__.py
===================================================================
--- __init__.py	(Revision 8070)
+++ __init__.py	(Arbeitskopie)
@@ -24,7 +24,10 @@
 import copy
 import urllib2
 import docutils
-import locale
+try:
+    import locale # module missing in Jython
+except ImportError:
+    pass
 from docutils import frontend, nodes, utils, writers, languages
 from docutils.readers import standalone
 from docutils.transforms import references
@@ -589,7 +592,10 @@
                 elif len(subtag) == 1:
                     break   # 1-letter tag is never before valid region tag
             if region_code is None:
-                rcode = locale.normalize(language_code)
+                try:
+                    rcode = locale.normalize(language_code)
+                except NameError:
+                    rcode = language_code
                 rcode = rcode.split('_')
                 if len(rcode) > 1:
                     rcode = rcode[1].split('.')
@@ -596,11 +602,10 @@
                     region_code = rcode[0]
                 if region_code is None:
                     self.document.reporter.warning(
-                        'invalid language-region.  '
-                        'Could not find region with locale.normalize().  '
-                        'If language is supplied, then you must specify '
-                        'both language and region (ll-RR).  Examples: '
-                        'es-MX (Spanish, Mexico), en-AU (English, Australia).')
+                        'invalid language-region.\n'
+                        '  Could not find region with locale.normalize().\n'
+                        '  Please specify both language and region (ll-RR).\n'
+                        '  Examples: es-MX (Spanish, Mexico), en-AU (English, Australia).')
         # Update the style ElementTree with the language and region.
         # Note that we keep a reference to the modified node because
         # it is possible that ElementTree will throw away the Python

Re: [Docutils-users] Is rst2odt -l cs supposed to work?

[Dave K. <dku...@da...>]

Günter,

I did the following:

1. Merged your changes (patch file below) into my local repository.

2. Did a bit of testing.  I had an exception when a document
   contained an admonition.  I fixed that.

3. Committed these changes to the central repository.

Thank you for your help with this.  Let me know if/when there is
something more I can do.

Dave K


On Thu, May 18, 2017 at 07:42:35PM +0000, Guenter Milde wrote:
> Dear Dave,
> 
> On 2017-05-16, Dave Kuhlman wrote:
> 
> > I did the commit.
> 
> > And, before I did so, I took Matěj's suggestion about using
> > ``locale.normalize(lang), so now you can use::
> 
> >     $ rst2odt.py -l cs somedoc.txt somedoc.odt
> >     $ rst2odt.py -l es somedoc.txt somedoc.odt
> 
> > to get Czech and Spanish (Spain).
> 
> Fine.
> 
> > And, of course, you can override the region, for example::
> 
> >     $ rst2odt.py -l cs-GB  somedoc.txt somedoc.odt
> >     $ rst2odt.py -l es-mx somedoc.txt somedoc.odt
> 
> > to get British English and Mexican Spanish.
> 
> 
> I suggest the patch below to allow for BCP 47 tags like
> 
>   de-Latf-AT        # second tag is script, region in 3rd position
>   de-latf           # second tag is script, no region given
>   de-1901           # second tag is variant (here: spelling), no region given
>   
> 
> Further changes:
> 
> The RuntimeError if locale.normalize fails to find a region tag is
> replaced with a Warning: a missing region tag does not prevent export
> of a functional output document.
> 
> The RuntimeError for empty "self.visitor.language_code" is removed on the
> assumption that if a user calls ``--language=""``, this indicates that no
> language should be written into the output --- which is exactly what happens
> in this case.
> 
> From the function "languages.normalize_language_tag()", we only need the
> replacement of "_" by "-". This is better done with a string method.
> 
> 
> Günter
> 
> 
> Dir: /home/milde/Code/Python/docutils-svn/docutils/docutils/writers/odf_odt/
> 
> Index: __init__.py
> ===================================================================
> --- __init__.py	(Revision 8069)
> +++ __init__.py	(Arbeitskopie)
> @@ -572,38 +572,35 @@
>          s1 = self.get_stylesheet()
>          # Set default language in document to be generated.
>          # Language is specified by the -l/--language command line option.
> -        # Allowed values are "ll", "ll-rr" or "ll_rr", where ll is language
> -        # and rr is region.  If region is omitted, we use
> +        # The format is described in BCP 47.  If region is omitted, we use
>          # local.normalize(ll) to obtain a region.
>          language_code = None
>          region_code = None
> -        if len(self.visitor.normalized_language_code) > 0:
> -            language_ids = self.visitor.normalized_language_code[0].split('-')
> -            if len(language_ids) == 2:
> -                language_code = language_ids[0]
> -                region_code = language_ids[1]
> -            elif len(language_ids) == 1:
> -                language_code = language_ids[0]
> +        if self.visitor.language_code:
> +            language_ids = self.visitor.language_code.replace('_','-')
> +            language_ids = language_ids.split('-')
> +            # first tag is primary language tag
> +            language_code = language_ids[0].lower()
> +            # 2-letter region subtag may follow in 2nd or 3rd position
> +            for subtag in language_ids[1:]:
> +                if len(subtag) == 2 and subtag.isalpha():
> +                    region_code = subtag.upper()
> +                    break
> +                elif len(subtag) == 1:
> +                    break # 1-letter tag is never before valid region tag
> +            if region_code is None:
>                  rcode = locale.normalize(language_code)
>                  rcode = rcode.split('_')
>                  if len(rcode) > 1:
> -                    rcode = rcode[1]
> -                    rcode = rcode.split('.')
> -                    if len(rcode) >= 1:
> -                        region_code = rcode[0]
> +                    rcode = rcode[1].split('.')
> +                    region_code = rcode[0]
>                  if region_code is None:
> -                    raise RuntimeError(
> +                    self.document.reporter.warning(
>                          'invalid language-region.  '
>                          'Could not find region with locale.normalize().  '
>                          'If language is supplied, then you must specify '
> -                        'both lanauge and region (ll-rr).  Examples: '
> -                        'es-mx (Spanish, Mexico), en-au (English, Australia).')
> -        else:
> -            raise RuntimeError(
> -                'invalid language-region. '
> -                'Format must be "ll-rr" or "ll_rr", where ll is language '
> -                'and rr is region. '
> -                'See https://en.wikipedia.org/wiki/IETF_language_tag')
> +                        'both language and region (ll-RR).  Examples: '
> +                        'es-MX (Spanish, Mexico), en-AU (English, Australia).')
>          # Update the style ElementTree with the language and region.
>          # Note that we keep a reference to the modified node because
>          # it is possible that ElementTree will throw away the Python
> @@ -888,8 +885,6 @@
>          self.language = languages.get_language(
>              self.language_code,
>              document.reporter)
> -        self.normalized_language_code = languages.normalize_language_tag(
> -            self.language_code)
>          self.format_map = {}
>          if self.settings.odf_config_file:
>              from ConfigParser import ConfigParser
>   
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Docutils-users mailing list
> Doc...@li...
> https://lists.sourceforge.net/lists/listinfo/docutils-users
> 
> Please use "Reply All" to reply to the list.

-- 

Dave Kuhlman
http://www.davekuhlman.org

Re: [Docutils-users] Is rst2odt -l cs supposed to work?

[Guenter M. <mi...@us...>]

Dear Dave,

On 2017-05-16, Dave Kuhlman wrote:

> I did the commit.

> And, before I did so, I took Matěj's suggestion about using
> ``locale.normalize(lang), so now you can use::

>     $ rst2odt.py -l cs somedoc.txt somedoc.odt
>     $ rst2odt.py -l es somedoc.txt somedoc.odt

> to get Czech and Spanish (Spain).

Fine.

> And, of course, you can override the region, for example::

>     $ rst2odt.py -l cs-GB  somedoc.txt somedoc.odt
>     $ rst2odt.py -l es-mx somedoc.txt somedoc.odt

> to get British English and Mexican Spanish.


I suggest the patch below to allow for BCP 47 tags like

  de-Latf-AT        # second tag is script, region in 3rd position
  de-latf           # second tag is script, no region given
  de-1901           # second tag is variant (here: spelling), no region given
  

Further changes:

The RuntimeError if locale.normalize fails to find a region tag is
replaced with a Warning: a missing region tag does not prevent export
of a functional output document.

The RuntimeError for empty "self.visitor.language_code" is removed on the
assumption that if a user calls ``--language=""``, this indicates that no
language should be written into the output --- which is exactly what happens
in this case.

>From the function "languages.normalize_language_tag()", we only need the
replacement of "_" by "-". This is better done with a string method.


Günter


Dir: /home/milde/Code/Python/docutils-svn/docutils/docutils/writers/odf_odt/

Index: __init__.py
===================================================================
--- __init__.py	(Revision 8069)
+++ __init__.py	(Arbeitskopie)
@@ -572,38 +572,35 @@
         s1 = self.get_stylesheet()
         # Set default language in document to be generated.
         # Language is specified by the -l/--language command line option.
-        # Allowed values are "ll", "ll-rr" or "ll_rr", where ll is language
-        # and rr is region.  If region is omitted, we use
+        # The format is described in BCP 47.  If region is omitted, we use
         # local.normalize(ll) to obtain a region.
         language_code = None
         region_code = None
-        if len(self.visitor.normalized_language_code) > 0:
-            language_ids = self.visitor.normalized_language_code[0].split('-')
-            if len(language_ids) == 2:
-                language_code = language_ids[0]
-                region_code = language_ids[1]
-            elif len(language_ids) == 1:
-                language_code = language_ids[0]
+        if self.visitor.language_code:
+            language_ids = self.visitor.language_code.replace('_','-')
+            language_ids = language_ids.split('-')
+            # first tag is primary language tag
+            language_code = language_ids[0].lower()
+            # 2-letter region subtag may follow in 2nd or 3rd position
+            for subtag in language_ids[1:]:
+                if len(subtag) == 2 and subtag.isalpha():
+                    region_code = subtag.upper()
+                    break
+                elif len(subtag) == 1:
+                    break # 1-letter tag is never before valid region tag
+            if region_code is None:
                 rcode = locale.normalize(language_code)
                 rcode = rcode.split('_')
                 if len(rcode) > 1:
-                    rcode = rcode[1]
-                    rcode = rcode.split('.')
-                    if len(rcode) >= 1:
-                        region_code = rcode[0]
+                    rcode = rcode[1].split('.')
+                    region_code = rcode[0]
                 if region_code is None:
-                    raise RuntimeError(
+                    self.document.reporter.warning(
                         'invalid language-region.  '
                         'Could not find region with locale.normalize().  '
                         'If language is supplied, then you must specify '
-                        'both lanauge and region (ll-rr).  Examples: '
-                        'es-mx (Spanish, Mexico), en-au (English, Australia).')
-        else:
-            raise RuntimeError(
-                'invalid language-region. '
-                'Format must be "ll-rr" or "ll_rr", where ll is language '
-                'and rr is region. '
-                'See https://en.wikipedia.org/wiki/IETF_language_tag')
+                        'both language and region (ll-RR).  Examples: '
+                        'es-MX (Spanish, Mexico), en-AU (English, Australia).')
         # Update the style ElementTree with the language and region.
         # Note that we keep a reference to the modified node because
         # it is possible that ElementTree will throw away the Python
@@ -888,8 +885,6 @@
         self.language = languages.get_language(
             self.language_code,
             document.reporter)
-        self.normalized_language_code = languages.normalize_language_tag(
-            self.language_code)
         self.format_map = {}
         if self.settings.odf_config_file:
             from ConfigParser import ConfigParser
  

Re: [Docutils-users] Is rst2odt -l cs supposed to work?

[Matěj C. <mc...@ce...>]

On 2017-05-16, 21:48 GMT, Dave Kuhlman wrote:
> And, Matěj, thanks for being patient with me and thank you for 
> all your help with this.

You did all the real work. Thank you!

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ce...
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
Of course I'm respectable. I'm old. Politicians, ugly buildings,
and whores all get respectable if they last long enough.
      --John Huston in "Chinatown."

Re: [Docutils-users] Is rst2odt -l cs supposed to work?

[Dave K. <dku...@da...>]

> Thank you for that suggestion, Matěj.  I did know about that.

Rats.  Meant to say I did *not* know.

And, Matěj, thanks for being patient with me and thank you for all
your help with this.

Dave K.

On Tue, May 16, 2017 at 02:29:00PM -0700, Dave Kuhlman wrote:
> Günter and Matěj,
> 
> I did the commit.
> 
> And, before I did so, I took Matěj's suggestion about using
> ``locale.normalize(lang), so now you can use::
> 
>     $ rst2odt.py -l cs somedoc.txt somedoc.odt
>     $ rst2odt.py -l es somedoc.txt somedoc.odt
> 
> to get Czech and Spanish (Spain).
> 
> And, of course, you can override the region, for example::
> 
>     $ rst2odt.py -l cs-GB  somedoc.txt somedoc.odt
>     $ rst2odt.py -l es-mx somedoc.txt somedoc.odt
> 
> to get British English and Mexican Spanish.
> 
> Thank you for that suggestion, Matěj.  I did know about that.
> 
> Dave K.
> 
> 
> On Tue, May 16, 2017 at 12:10:04PM +0000, Guenter Milde wrote:
> > On 2017-05-16, Matej Cepl wrote:
> > > On 16/05/17 01:42, Dave Kuhlman wrote:
> > 
> > >> 1. Images that use ":width: xx%" are scaled to the line width.
> > ...
> > 
> > >> 2. The header/title of an admonition (for example, a note) now
> > >>    follows the style of the admonition header
> > ...
> > 
> > >> 3. The unit test error that you found is fixed.
> > ...
> > 
> > Wonderfull. Thanks a lot for taking care of this.
> > 
> > >> Please let me know if we are getting closer, what else needs fixing,
> > >> etc.
> > 
> > > This works for me. As far as me I would get this let be released.
> > 
> > I second this, please commit and then it may be really time for 0.14!
> > 
> > 
> > I have one remaining question:
> > 
> > I understand, that LO/OO expects both, language and region tag of a document
> > to be set. 
> > I also understand that auto-filling the region tag is tricky.
> > 
> > What happens exactly, if in an rst2odt-exported document the language tag is
> > set but the region tag is missing:
> > 
> > a) an error/warning
> > b) the region is set to "US"
> > c) the region is set according to the users locale?
> > 
> > What should Docutils do in these cases?
> > 
> > >> By default, it was passing in "en" as the language, whereas now it
> > >> needs to be "en-US" or to be omitted.  I overrode it with "en-US".
> > 
> > Ther problem here is, that according to our specs, the default for
> > "language-code" is
> > 
> >   Default: English ("en").  Options: ``--language, -l``.
> > 
> > Unless absolutely required otherwise, I suggest passing just "en".
> > 
> > If this is not possible, the odt writer could use a different default
> > (this needs to be documented).
> > 
> > Rationale: not only Mexican and Castillean Spaniards disagree about the
> > default region tag for a language, narrowing "en" to American English 
> > must at least be documented.
> > 
> > But this may also be sorted out later.
> > 
> > 
> > Thanks again,
> > 
> > Günter
> > 
> > 
> > ------------------------------------------------------------------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________
> > Docutils-users mailing list
> > Doc...@li...
> > https://lists.sourceforge.net/lists/listinfo/docutils-users
> > 
> > Please use "Reply All" to reply to the list.
> 
> -- 
> 
> Dave Kuhlman
> http://www.davekuhlman.org
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Docutils-users mailing list
> Doc...@li...
> https://lists.sourceforge.net/lists/listinfo/docutils-users
> 
> Please use "Reply All" to reply to the list.

-- 

Dave Kuhlman
http://www.davekuhlman.org

Re: [Docutils-users] Is rst2odt -l cs supposed to work?

[Dave K. <dku...@da...>]

Günter and Matěj,

I did the commit.

And, before I did so, I took Matěj's suggestion about using
``locale.normalize(lang), so now you can use::

    $ rst2odt.py -l cs somedoc.txt somedoc.odt
    $ rst2odt.py -l es somedoc.txt somedoc.odt

to get Czech and Spanish (Spain).

And, of course, you can override the region, for example::

    $ rst2odt.py -l cs-GB  somedoc.txt somedoc.odt
    $ rst2odt.py -l es-mx somedoc.txt somedoc.odt

to get British English and Mexican Spanish.

Thank you for that suggestion, Matěj.  I did know about that.

Dave K.


On Tue, May 16, 2017 at 12:10:04PM +0000, Guenter Milde wrote:
> On 2017-05-16, Matej Cepl wrote:
> > On 16/05/17 01:42, Dave Kuhlman wrote:
> 
> >> 1. Images that use ":width: xx%" are scaled to the line width.
> ...
> 
> >> 2. The header/title of an admonition (for example, a note) now
> >>    follows the style of the admonition header
> ...
> 
> >> 3. The unit test error that you found is fixed.
> ...
> 
> Wonderfull. Thanks a lot for taking care of this.
> 
> >> Please let me know if we are getting closer, what else needs fixing,
> >> etc.
> 
> > This works for me. As far as me I would get this let be released.
> 
> I second this, please commit and then it may be really time for 0.14!
> 
> 
> I have one remaining question:
> 
> I understand, that LO/OO expects both, language and region tag of a document
> to be set. 
> I also understand that auto-filling the region tag is tricky.
> 
> What happens exactly, if in an rst2odt-exported document the language tag is
> set but the region tag is missing:
> 
> a) an error/warning
> b) the region is set to "US"
> c) the region is set according to the users locale?
> 
> What should Docutils do in these cases?
> 
> >> By default, it was passing in "en" as the language, whereas now it
> >> needs to be "en-US" or to be omitted.  I overrode it with "en-US".
> 
> Ther problem here is, that according to our specs, the default for
> "language-code" is
> 
>   Default: English ("en").  Options: ``--language, -l``.
> 
> Unless absolutely required otherwise, I suggest passing just "en".
> 
> If this is not possible, the odt writer could use a different default
> (this needs to be documented).
> 
> Rationale: not only Mexican and Castillean Spaniards disagree about the
> default region tag for a language, narrowing "en" to American English 
> must at least be documented.
> 
> But this may also be sorted out later.
> 
> 
> Thanks again,
> 
> Günter
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Docutils-users mailing list
> Doc...@li...
> https://lists.sourceforge.net/lists/listinfo/docutils-users
> 
> Please use "Reply All" to reply to the list.

-- 

Dave Kuhlman
http://www.davekuhlman.org

Re: [Docutils-users] Is rst2odt -l cs supposed to work?

[Matěj C. <mc...@ce...>]

On 2017-05-16, 12:10 GMT, Guenter Milde wrote:
> Unless absolutely required otherwise, I suggest passing just 
> "en".
>
> If this is not possible, the odt writer could use a different default
> (this needs to be documented).
>
> Rationale: not only Mexican and Castillean Spaniards disagree about the
> default region tag for a language, narrowing "en" to American English 
> must at least be documented.

What about locale.normalize() (https://is.gd/dZe2bZ)?

    In [1]: import locale

    In [2]: locale.normalize('en')
    Out[2]: 'en_US.ISO8859-1'

    In [3]: locale.normalize('cs')
    Out[3]: 'cs_CZ.ISO8859-2'

    In [4]: locale.normalize('es')
    Out[4]: 'es_ES.ISO8859-1'

    In [5]: locale.normalize('fr')
    Out[5]: 'fr_FR.ISO8859-1'

    In [6]:

(that encoding is bad, I would prefer UTF-8 all the time, but 
that’s another point)

Best,

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ce...
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
Of course I'm respectable. I'm old. Politicians, ugly buildings,
and whores all get respectable if they last long enough.
      --John Huston in "Chinatown."

Re: [Docutils-users] Is rst2odt -l cs supposed to work?

[Guenter M. <mi...@us...>]

On 2017-05-16, Matej Cepl wrote:
> On 16/05/17 01:42, Dave Kuhlman wrote:

>> 1. Images that use ":width: xx%" are scaled to the line width.
...

>> 2. The header/title of an admonition (for example, a note) now
>>    follows the style of the admonition header
...

>> 3. The unit test error that you found is fixed.
...

Wonderfull. Thanks a lot for taking care of this.

>> Please let me know if we are getting closer, what else needs fixing,
>> etc.

> This works for me. As far as me I would get this let be released.

I second this, please commit and then it may be really time for 0.14!


I have one remaining question:

I understand, that LO/OO expects both, language and region tag of a document
to be set. 
I also understand that auto-filling the region tag is tricky.

What happens exactly, if in an rst2odt-exported document the language tag is
set but the region tag is missing:

a) an error/warning
b) the region is set to "US"
c) the region is set according to the users locale?

What should Docutils do in these cases?

>> By default, it was passing in "en" as the language, whereas now it
>> needs to be "en-US" or to be omitted.  I overrode it with "en-US".

Ther problem here is, that according to our specs, the default for
"language-code" is

  Default: English ("en").  Options: ``--language, -l``.

Unless absolutely required otherwise, I suggest passing just "en".

If this is not possible, the odt writer could use a different default
(this needs to be documented).

Rationale: not only Mexican and Castillean Spaniards disagree about the
default region tag for a language, narrowing "en" to American English 
must at least be documented.

But this may also be sorted out later.


Thanks again,

Günter

Re: [Docutils-users] Is rst2odt -l cs supposed to work?

[Matej C. <mc...@ce...>]

On 16/05/17 01:42, Dave Kuhlman wrote:
> 1. Images that use ":width: xx%" are scaled to the line width.  Note
>    that if, after generating the .odt file, you edit it with
>    LibreOffice Writer, and you use menu item Format/Page to modify
>    the page width, the image size does *not* automatically adjust.
>    Is this a needed feature?  If it is, you could try to right-click
>    on the image and edit its properties.  But, none of that seemed
>    satisfactory to me.

I don’t think it is necessary. I believe that the primary use of rst2odt
is for sharing the document for review (tracking changes and notes are
working really well with LOWriter) or for providing camera-ready copies
of documents for those who prefer Word-like format. For both cases I
would just need to be sure that images look like when run through other
rst2* programs. If somebody wants to take .odt for serious editing, she
can very well make sure images work for her.

> 2. The header/title of an admonition (for example, a note) now
>    follows the style of the admonition header (for example,
>    rststyle-admon-note-hdr, rststyle-admon-warning-hdr, etc).  I was
>    mistakenly using the admonition title after it had been
>    translated (for example, to "Poznámka!") to generate the style.
>    And, there is no style named "rststyle-admon-Poznámka!-hdr".

Perfect. Thanks.

> 3. The unit test error that you found is fixed.  By default, it was
>    passing in "en" as the language, whereas now it needs to be
>    "en-US" or to be omitted.  I overrode it with "en-US".

Awesome.

> Wow.  This is turning out to be more fun than I thought it would.
> 
> Please let me know if we are getting closer, what else needs fixing,
> etc.

This works for me. As far as me I would get this let be released.

Thank you very much,

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ce...
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8

Of course I'm respectable. I'm old. Politicians, ugly buildings,
and whores all get respectable if they last long enough.
      --John Huston in "Chinatown."

Re: [Docutils-users] Is rst2odt -l cs supposed to work?

[Dave K. <dku...@da...>]

Matěj,

Here is what I believe I fixed:

1. Images that use ":width: xx%" are scaled to the line width.  Note
   that if, after generating the .odt file, you edit it with
   LibreOffice Writer, and you use menu item Format/Page to modify
   the page width, the image size does *not* automatically adjust.
   Is this a needed feature?  If it is, you could try to right-click
   on the image and edit its properties.  But, none of that seemed
   satisfactory to me.

2. The header/title of an admonition (for example, a note) now
   follows the style of the admonition header (for example,
   rststyle-admon-note-hdr, rststyle-admon-warning-hdr, etc).  I was
   mistakenly using the admonition title after it had been
   translated (for example, to "Poznámka!") to generate the style.
   And, there is no style named "rststyle-admon-Poznámka!-hdr".

3. The unit test error that you found is fixed.  By default, it was
   passing in "en" as the language, whereas now it needs to be
   "en-US" or to be omitted.  I overrode it with "en-US".

The modified files are attached to a separate message.

Wow.  This is turning out to be more fun than I thought it would.

Please let me know if we are getting closer, what else needs fixing,
etc.

Dave

-- 

Dave Kuhlman
http://www.davekuhlman.org

Re: [Docutils-users] Is rst2odt -l cs supposed to work?

[Matej C. <mc...@ce...>]

On 13/05/17 00:33, Dave Kuhlman wrote:
>    The reason for the small scale factor is that your image is quite
>    large.  The size returned by PIL (the Python Image Library)
>    for your image (frantisek_xaversky.jpg) is 2448 X 3264.  That's
>    pixels, I suppose.  The conversion factor that I found at
>    http://www.unitconversion.org/unit_converter/typography-ex.html
>    is 1 px = 0.0264 cm.  So, for example, 2448 * 0.0264 * .15 =
>    9.69 cm, which is a reasonable starting width for your image on a
>    page, and you can adjust from there.

I think we have misunderstanding here.
http://docutils.sourceforge.net/docs/ref/rst/directives.html#image says,
that ``width`` parameter has as units “length or percentage of the
current line width”. It seems to me you think that percent means the
scaling factor. It doesn’t. rst2xetex does it perfectly well (see PDF I
have attached to one of the earlier emails to you).

Best,

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ce...
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8

Of course I'm respectable. I'm old. Politicians, ugly buildings,
and whores all get respectable if they last long enough.
      --John Huston in "Chinatown."

Re: [Docutils-users] Is rst2odt -l cs supposed to work?

[Dave K. <dku...@da...>]

Matěj,

I've got another fix for our issues.  You will need to evaluate them
yourself.

1. For language and region/country, now, with ODT writer, if you use
   the -l/--language command line option, then you must specify both
   language and country, for example, es_mx (Mexican Spanish), en-au
   (Australian English), and of course cs-cz.  This is because the
   ODT writer needs both, if it changes the language.  People have
   been fighting over whose language and/or religion is superior for
   hundreds of years.  I say, let them keep fighting; I'm not going
   to step in the middle of that.  If you go to UAM (Universidad
   Autónoma Madrid), I'm sure they will tell you that the default
   should be es-es; if you go to UNAM (Universidad Nacional Autónoma
   de México) they will tell you the default should be es-mx.

   In a previous email, Günter Milde says:

        Docutils should accept and work with the generic tag "cs"
        and expand it to "cs-CZ" in cases where it would be
        misinterpreted as "cs-US" by some dumb back-end.

   But, I don't know how to do that in the general case.

2. Image size -- I've reworked this quite severely.  The ODT writer
   now tries to achieve a little consistency by converting all units
   to centimeters.  For your image, you might want to start with
   something like the following and adjust from there::

        .. image:: images/frantisek_xaversky.jpg
            :scale: 15%
            :align: center
            :alt: Svatý František Xaverský v Mikulášském chrámu

   The reason for the small scale factor is that your image is quite
   large.  The size returned by PIL (the Python Image Library)
   for your image (frantisek_xaversky.jpg) is 2448 X 3264.  That's
   pixels, I suppose.  The conversion factor that I found at
   http://www.unitconversion.org/unit_converter/typography-ex.html
   is 1 px = 0.0264 cm.  So, for example, 2448 * 0.0264 * .15 =
   9.69 cm, which is a reasonable starting width for your image on a
   page, and you can adjust from there.

I've attached a new version of docutils/writers/odf_odt/__init__.py
to a separate message.  Please let me know what you think.

Dave K.
-- 

Dave Kuhlman
http://www.davekuhlman.org

Re: [Docutils-users] Is rst2odt -l cs supposed to work?

[Guenter M. <mi...@us...>]

On 2017-05-11, Matěj Cepl wrote:
> On 2017-05-11, 12:40 GMT, Guenter Milde wrote:
>>   .../docutils/languages/cs.py
>>   .../docutils/parsers/rst/languages/cs.py

> Especially the second file looks quite hopelessly :(

>>> You can try "-l cs", but you end up with the language 
>>> "cs-US", which
>>> I'm guessing you do not want.

>> This seems wrong in any case. It should stay "cs" without the optional
>> region subtag.

> I would think the default to be cs_CS (as in de_DE, fr_FR, 
> es_ES, it_IT etc., which are all “safe, default” dialects of the 
> main language)

I agree, that the "main country" is a reasonable default for cases where some
back-end application *requires* a region subtag.¹


> which is wrong however, because CS was the 
> abbreviation for Czechoslovakia and it does not exist anymore.

Note the difference: "cs" is the tag for the Czech language while the
region tag (ISO 3166-1 alpha-2 code) for the Czech Republic is "CZ". 
If a region subtag is required, "cs-CZ" should be used for the Czech
language.


Docutils should accept and work with the generic tag "cs" and expand it
to "cs-CZ" in cases where it would be misinterpreted as "cs-US" by some
dumb back-end.


Günter


¹ However, it is not "safe", as *any* region subtag narrows the specification:

   2.1.  Syntax

   A language tag is composed from a sequence of one or more "subtags",
   each of which refines or narrows the range of language identified by
   the overall tag. 
   
   -- BCP 47

    2.2.4.  Region Subtag
    
    Region subtags are used to indicate linguistic variations associated
    with or appropriate to a specific country, territory, or region.
    Typically, a region subtag is used to indicate variations such as
    regional dialects or usage, or region-specific spelling conventions.
    
    
    ... the region subtag MAY be omitted, as when it adds no
    distinguishing value to the tag.

    -- BCP 47

Re: [Docutils-users] ISBN URL?

[Guenter M. <mi...@us...>]

On 2017-05-10, David Goodger wrote:
> On Fri, Jul 1, 2016 at 3:11 PM, Matej Cepl <mc...@ce...> wrote:
>> Hi,

>> I still cannot shake off a bad habit of reading pieces of dead
>> wood, so I refer in my writing quite often to ISBNs. So, normally
>> it looks like this:
...
>>     orci “`Four loves`_”.  Vestibulum pretium dui dolor, ac
...

>>     .. _`Four loves`:
>>         https://en.wikipedia.org/wiki/Special:BookSources?isbn=0156329301

>> I would prefer to be able either to use the reference like

>>     .. _`Four loves`:
>>         isbn:0156329301

>> and docutils would generate proper URL
> ...
>> Do you know about something like this already made?

RFC-3187__ defines the mechanism for mapping an ISBN to a URN.

__ http://www.faqs.org/rfcs/rfc3187.html

For example: "urn:ISBN:1-56592-149-6"

  Note that the hyphens in the ISBN are optional (and should be removed
  before comparing two ISBN URNs) and that the 'ISBN' URN namespace
  identifier is case-insensitive.

  -- http://www.ukoln.ac.uk/metadata/dcmi-ieee/identifiers/

In theory, RFC 2187 is implemented
(https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml),
i.e. the rst source::

   `The Four Loves <urn:isbn:0156329301>`__ (embedded)
   
   The Four Loves: urn:ISBN:0156329301      (stand alone)
   
   
   `The Four Loves`_                        ("classical")
   
   .. _the four loves: urn:ISBN:0156329301

results in valid HTML.

Unfortunately, this does not help in praxi, as
        
  Your browser would have to have a "resolver" installed for ISBN numbers
  that would find a URL for the resource. As far as I know, no browsers
  have taken a stab at implementing resolvers as called for by the RFC.
  –- Stephen Ostermiller Feb 24 at 8:57 
  
  http://stackoverflow.com/questions/4913343/what-is-the-difference-between-uri-url-and-urn



> This is very similar to the RFC & PEP roles (e.g. :RFC:`2732` &
>:PEP:`12`), although those show the numbers, and I infer that you
> don't want to show the actual ISBN.

...

> Several syntax options are described here:
> http://docutils.sourceforge.net/docs/dev/rst/alternatives.html#parameterized-interpreted-text

> Choosing one syntax option arbitrarily, for example, an ISBN role
> could be implemented that takes this reST::

>     :ISBN:`The Four Loves <0156329301>`

> and results in HTML like::

>     <a href="https://en.wikipedia.org/wiki/Special:BookSources?isbn=0156329301">The
> Four Loves</a>

> One might want the ISBN itself and not the title, so::

>     :ISBN:`0156329301`

> could result in this HTML::

>     <a href="https://en.wikipedia.org/wiki/Special:BookSources?isbn=0156329301">ISBN
> 0156329301</a>

> This could either be implemented as a single ISBN role with different
> output depending on the input, or as two separate roles (e.g. ISBN for
> the number without a title, and refisbn for the titled reference).



Alternatively, Docutils could provide a "URN resolver" for ISBNs.

An transform would map ``refuri="urn:ISBN:0156329301"`` to an URL using a
configurable URL template similar to the ``rfc-base-url``.


Another alternative would be an "ISBN namespace" for rST hyperlink targets,
for constructs like ::

 .. _The Four Loves: ISBN:0156329301

or ::

 `The Four Loves <ISBN:0156329301>`_

and similar to relative URLs with alias like `` `<foobar.py>`_`` ::

  The Four Loves `<ISBN:0156329301>`_


This way, we can leverage the existing syntax that provides flexibility for
both, display or hiding of the actual number without the need to open the
can of parameterized roles.


Günter

  

Re: [Docutils-users] ISBN URL?

[Matěj C. <mc...@ce...>]

On 2017-05-11, 15:59 GMT, David Goodger wrote:
> I disagree. I can envisage cases where one might want to write 
> something like,
>
>     See `The Four Loves` by C. S. Lewis (:ISBN:`0156329301`).
>
> Note: the result would *not* be just a plain ISBN number, but "ISBN" +
> the number, in a link.
>
> Flexibility is a good thing.

I did not say that this could not be useful for some exceptional 
cases (inside of the list of references), but the normal 
situation should what I described.

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ce...
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
Of course I'm respectable. I'm old. Politicians, ugly buildings,
and whores all get respectable if they last long enough.
      --John Huston in "Chinatown."

Re: [Docutils-users] ISBN URL?

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

On Thu, May 11, 2017 at 10:37 AM, Matěj Cepl <mc...@ce...> wrote:
> On 2017-05-10, 21:03 GMT, David Goodger wrote:
>> In my inbox I noticed that this went without any replies. Better
>> (very) late than never!?
>
> I have made it into https://gitlab.com/mcepl/docutils/issues/1
> on my repo and I will take a look one day (of course, merge
> requests are welcome).
>
>> Choosing one syntax option arbitrarily, for example, an ISBN
>> role could be implemented that takes this reST::
>>
>>     :ISBN:`The Four Loves <0156329301>`
>>
>> and results in HTML like::
>>
>>     <a href="https://en.w…ces?isbn=0156329301">The
>> Four Loves</a>
>
> I think this is the one I would implement. Showing plain ISBN
> numbers in the text is a bad idea IMHO and should be made
> difficult.

I disagree. I can envisage cases where one might want to write something like,

    See `The Four Loves` by C. S. Lewis (:ISBN:`0156329301`).

Note: the result would *not* be just a plain ISBN number, but "ISBN" +
the number, in a link.

Flexibility is a good thing.

> And perhaps the URL should be made configurable so we
> and our users are not forever dependent on the English
> Wikipedia.

Sure.

David Goodger
<http://python.net/~goodger>

Re: [Docutils-users] ISBN URL?

[Matěj C. <mc...@ce...>]

On 2017-05-10, 21:03 GMT, David Goodger wrote:
> In my inbox I noticed that this went without any replies. Better
> (very) late than never!?

I have made it into https://gitlab.com/mcepl/docutils/issues/1 
on my repo and I will take a look one day (of course, merge 
requests are welcome).

> Choosing one syntax option arbitrarily, for example, an ISBN 
> role could be implemented that takes this reST::
>
>     :ISBN:`The Four Loves <0156329301>`
>
> and results in HTML like::
>
>     <a href="https://en.w…ces?isbn=0156329301">The
> Four Loves</a>

I think this is the one I would implement. Showing plain ISBN 
numbers in the text is a bad idea IMHO and should be made 
difficult. And perhaps the URL should be made configurable so we 
and our users are not forever dependent on the English 
Wikipedia.

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ce...
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
Of course I'm respectable. I'm old. Politicians, ugly buildings,
and whores all get respectable if they last long enough.
      --John Huston in "Chinatown."

Re: [Docutils-users] Is rst2odt -l cs supposed to work?

[Matěj C. <mc...@ce...>]

On 2017-05-11, 12:40 GMT, Guenter Milde wrote:
>   .../docutils/languages/cs.py
>   .../docutils/parsers/rst/languages/cs.py

Especially the second file looks quite hopelessly :(

>> You can try "-l cs", but you end up with the language 
>> "cs-US", which
>> I'm guessing you do not want.
>
> This seems wrong in any case. It should stay "cs" without the optional
> region subtag.

I would think the default to be cs_CS (as in de_DE, fr_FR, 
es_ES, it_IT etc., which are all “safe, default” dialects of the 
main language), which is wrong however, because CS was the 
abbreviation for Czechoslovakia and it does not exist anymore.

Best,

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ce...
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
Of course I'm respectable. I'm old. Politicians, ugly buildings,
and whores all get respectable if they last long enough.
      --John Huston in "Chinatown."

Re: [Docutils-users] Is rst2odt -l cs supposed to work?

[Guenter M. <mi...@us...>]

Dear David,


On 2017-05-10, Dave Kuhlman wrote:

>> However, styles seems to be correct. Also, I am not sure, whether
>> I should use cs, cs-CZ, or cs_CZ language code.

> You can use "-l" or "--language" and any of:

>     cs-CZ
>     cs_CZ
>     cs-cz
>     cs_cz

> They all have the same effect, as far as I can tell.  But, "-l cs"
> does *not* work.  I don't know whether it should or not.

Generally, Docutils follows the "best current praxis" `BCP 47`__ which
says that any specifiers (like the region subtag here) is optional.

Czech-language mappings for language-dependent features of Docutils.
are in the files

  .../docutils/languages/cs.py
  .../docutils/parsers/rst/languages/cs.py

that are used for any of the above language tags.

In some cases, special files for sub-locales exist, e.g., "pt_br.py" for
Brasilanean Portugese.


The HTML writers also insert the original language tag into the document
header.

The XML writer uses the language tag to support "localized" directive names.
It does, however, not insert a language tag into the output document.
This is IMO a bug.

The LaTeX writer translates the tag into a Babel language name
(or with XeTeX/LuaTeX a Polyglossia name), if there language is supported.
Subvarieties (de-1901, de-CH, de-AT, say) are respected, if supported by
Babel/Polyglossia, e.g.

        'en-AU':        'australian',
        'en-CA':        'canadian',
        'en-GB':        'british',
        'en-NZ':        'newzealand',
        'en-US':        'american',

__ http://www.rfc-editor.org/rfc/bcp/bcp47.txt


> You can try "-l cs", but you end up with the language "cs-US", which
> I'm guessing you do not want.

This seems wrong in any case. It should stay "cs" without the optional
region subtag.

There is a function to iterate over "normalized" language tags:

  utils.normalize_language_tag()
  
    """Return a list of normalized combinations for a `BCP 47` language tag.

    Example:

    >>> normalize_language_tag('de_AT-1901')
    ['de-at-1901', 'de-at', 'de-1901', 'de']
    """
used, e.g., in the latex writer, the smartquotes transform and
``parsers.rst.languages.get_language(language_code)``.

Maybe this can also help in the odt writer?


Günter
  
 
 
 
 

Re: [Docutils-users] Is rst2odt -l cs supposed to work?

[Matěj C. <mc...@ce...>]

On 2017-05-10, 23:30 GMT, Dave Kuhlman wrote:
> I believe I've fixed the two issues you have reported below.

You did, I think this is ready for merge. Thank you!

> 1. The image now has, I believe, a reasonable width and height.
>    But, you will have to see if you agree.

Well, it is not centered and it is not squeezed to 75% as 
expected, but it is at least unmangled, so any additional 
editing can be done in LOWriter.

> 2. The label of the admonition/note has been translated.

Shouldn’t it be centered as well? Otherwise, no problem.

> They all have the same effect, as far as I can tell.  But, "-l 
> cs" does *not* work.  I don't know whether it should or not.  
> You can try "-l cs", but you end up with the language "cs-US", 
> which I'm guessing you do not want.

I don’t think such thing exists (although, there is a rather 
crazy mix of English and Czech spoken by some Czecho-Americans), 
and certainly it is not what I would like to use. So, noted.

Best,

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ce...
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
Of course I'm respectable. I'm old. Politicians, ugly buildings,
and whores all get respectable if they last long enough.
      --John Huston in "Chinatown."

Re: [Docutils-users] Is rst2odt -l cs supposed to work?

[Dave K. <dku...@da...>]

Matěj,

I believe I've fixed the two issues you have reported below.

1. The image now has, I believe, a reasonable width and height.
   But, you will have to see if you agree.

2. The label of the admonition/note has been translated.

A fixed version of ``docutils/writers/odf_odt/__init__.py`` is
attached to a separate message.

You can use "-l" or "--language" and any of:

    cs-CZ
    cs_CZ
    cs-cz
    cs_cz

They all have the same effect, as far as I can tell.  But, "-l cs"
does *not* work.  I don't know whether it should or not.  You can
try "-l cs", but you end up with the language "cs-US", which I'm
guessing you do not want.

And, thanks for your guidance on this.

Dave

On Wed, May 10, 2017 at 12:24:48AM +0200, Matěj Cepl wrote:
> On Tue, 2017-05-09 at 13:28 -0700, Dave Kuhlman wrote:
> 

[snip]

> A way better but not there yet.
> 
> When running rst2odt --language=cs_CZ v_chramu.rst v_chramu.odt I
> get the attached result with two problems (PDF generated via
> rst2xetex and xelatex is correct on both counts):
> 
> 	1. image is completely screwed up
> 
> 	2. .. note:: doesn’t have the Czech label “Poznámka”
> 
> However, styles seems to be correct. Also, I am not sure, whether
> I should use cs, cs-CZ, or cs_CZ language code.
> 
> Thank you for the great work so far.
> 
> Matěj
> 

[snip]



-- 

Dave Kuhlman
http://www.davekuhlman.org

Re: [Docutils-users] ISBN URL?

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

In my inbox I noticed that this went without any replies. Better
(very) late than never!?

On Fri, Jul 1, 2016 at 3:11 PM, Matej Cepl <mc...@ce...> wrote:
> Hi,
>
> I still cannot shake off a bad habit of reading pieces of dead
> wood, so I refer in my writing quite often to ISBNs. So, normally
> it looks like this:
>
>     Lorem ipsum dolor sit amet, consectetur adipiscing elit.
>     Phasellus at tellus sollicitudin, pellentesque orci a, ornare
>     risus. Vivamus et quam a felis aliquet sollicitudin quis ac
>     orci “`Four loves`_”.  Vestibulum pretium dui dolor, ac
>     ullamcorper sapien suscipit sed.
>
>     .. _`Four loves`:
>         https://en.wikipedia.org/wiki/Special:BookSources?isbn=0156329301
>
> I would prefer to be able either to use the reference like
>
>     .. _`Four loves`:
>         isbn:0156329301
>
> and docutils would generate proper URL
...
> Do you know about something like this already made?

This is very similar to the RFC & PEP roles (e.g. :RFC:`2732` &
:PEP:`12`), although those show the numbers, and I infer that you
don't want to show the actual ISBN. See the code in
docutils/parsers/rst/roles.py

> or to go all the way to...:
>
>     Lorem ipsum dolor sit amet, consectetur adipiscing elit.
>     Phasellus at tellus sollicitudin, pellentesque orci a, ornare
>     risus. Vivamus et quam a felis aliquet sollicitudin quis ac
>     orci isbn::``“Four loves”``,``0156329301``.  Vestibulum
>     pretium dui dolor, ac ullamcorper sapien suscipit sed.
...
> (how to make docutils role with two parameters?)

This has not been done in core Docutils. I don't know if Sphinx has
implemented a scheme for multi-parameter roles, or not (anyone?).
Several syntax options are described here:
http://docutils.sourceforge.net/docs/dev/rst/alternatives.html#parameterized-interpreted-text

Choosing one syntax option arbitrarily, for example, an ISBN role
could be implemented that takes this reST::

    :ISBN:`The Four Loves <0156329301>`

and results in HTML like::

    <a href="https://en.wikipedia.org/wiki/Special:BookSources?isbn=0156329301">The
Four Loves</a>

One might want the ISBN itself and not the title, so::

    :ISBN:`0156329301`

could result in this HTML::

    <a href="https://en.wikipedia.org/wiki/Special:BookSources?isbn=0156329301">ISBN
0156329301</a>

This could either be implemented as a single ISBN role with different
output depending on the input, or as two separate roles (e.g. ISBN for
the number without a title, and refisbn for the titled reference).

> If I am
> reading correctly the documentation_, does it mean that I have to
> write some Python?
...
> .. _documentation:
>     http://docutils.sourceforge.net/docs/howto/rst-roles.html

Yes.

> And if yes (I am a Python programmer, so it is
> not that big obstacle), could I somehow package it as
> a standalone Python package uploadable to PyPI?

Typically, I've seen such extensions be imported and registered from a
custom front-end tool. Docutils doesn't have a plug-in system.

On the other hand, if you implement this properly, there's no reason
it couldn't be added to core Docutils.

> Are there any
> such packages already available on PyPI? I cannot find any.

I don't know.

David Goodger
<http://python.net/~goodger>

Re: [Docutils-users] reStructuredText writer

[Roberto A. <ra...@kd...>]

I wrote a rst2rst once, too, it must be somewhere.

On Wed, May 10, 2017 at 3:07 PM Kevin Horn <kev...@gm...> wrote:

> Rstgen might also help: https://bitbucket.org/khorn/rstgen
>
> It was written years ago to convert some documentation from another format
> into restructuredText
>
> Probably I should clean it up and publish it on PyPI, but I've never
> managed to get around to it.
>
> On Wed, May 10, 2017 at 12:54 AM, Guenter Milde <mi...@us...>
> wrote:
>
>> On 2017-05-08, Jimmy Thrasibule wrote:
>>
>> > The docutils package does not come with any reStructuredText writer. How
>> > easy would it be to code one?
>>
>> Easy to medium. It depends on the details and knowledge of the inner
>> structures of Docutils.
>>
>> There is an unfinished attempt in the SVN repository tree
>> "lossless-rst-writer".
>>
>> > The primary use case would be to combine multiple documents into a
>> single
>> > document tree and re-write the result as reStructuredText.
>>
>>
>> An alternative is the export to XML and conversion to rST with X
>> "xml2rst", an XSLT stylesheet written by Stefan Merten.
>>
>> http://www.merten-home.de/FreeSoftware/xml2rst/index.html
>>
>> Günter
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Docutils-users mailing list
>> Doc...@li...
>> https://lists.sourceforge.net/lists/listinfo/docutils-users
>>
>> Please use "Reply All" to reply to the list.
>>
>
>
>
> --
> --
> Kevin Horn
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Docutils-users mailing list
> Doc...@li...
> https://lists.sourceforge.net/lists/listinfo/docutils-users
>
> Please use "Reply All" to reply to the list.
>

Re: [Docutils-users] reStructuredText writer

[Kevin H. <kev...@gm...>]

Rstgen might also help: https://bitbucket.org/khorn/rstgen

It was written years ago to convert some documentation from another format
into restructuredText

Probably I should clean it up and publish it on PyPI, but I've never
managed to get around to it.

On Wed, May 10, 2017 at 12:54 AM, Guenter Milde <mi...@us...> wrote:

> On 2017-05-08, Jimmy Thrasibule wrote:
>
> > The docutils package does not come with any reStructuredText writer. How
> > easy would it be to code one?
>
> Easy to medium. It depends on the details and knowledge of the inner
> structures of Docutils.
>
> There is an unfinished attempt in the SVN repository tree
> "lossless-rst-writer".
>
> > The primary use case would be to combine multiple documents into a single
> > document tree and re-write the result as reStructuredText.
>
>
> An alternative is the export to XML and conversion to rST with X
> "xml2rst", an XSLT stylesheet written by Stefan Merten.
>
> http://www.merten-home.de/FreeSoftware/xml2rst/index.html
>
> Günter
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Docutils-users mailing list
> Doc...@li...
> https://lists.sourceforge.net/lists/listinfo/docutils-users
>
> Please use "Reply All" to reply to the list.
>



-- 
--
Kevin Horn

Re: [Docutils-users] reStructuredText writer

[Guenter M. <mi...@us...>]

On 2017-05-08, Jimmy Thrasibule wrote:

> The docutils package does not come with any reStructuredText writer. How
> easy would it be to code one?

Easy to medium. It depends on the details and knowledge of the inner
structures of Docutils.

There is an unfinished attempt in the SVN repository tree
"lossless-rst-writer".

> The primary use case would be to combine multiple documents into a single
> document tree and re-write the result as reStructuredText.


An alternative is the export to XML and conversion to rST with X
"xml2rst", an XSLT stylesheet written by Stefan Merten.

http://www.merten-home.de/FreeSoftware/xml2rst/index.html

Günter