docutils-develop — For developer discussions of the implementation.

[Docutils-develop] [docutils:bugs] #461 docutils sdist contains html files in egg-info

[Günter M. <mi...@us...>]

Unfortunately, the spurious HTML files crept into the docutils0.20 sdist again :(
We are working on this.


---

**[bugs:#461] docutils sdist contains html files in egg-info**

**Status:** open-fixed
**Created:** Wed Nov 16, 2022 02:40 PM UTC by Karolina Surma
**Last Updated:** Thu Dec 01, 2022 04:15 PM UTC
**Owner:** nobody


When packaging docutils 0.19 in Fedora, we realized there are HTML files in the distribution's egg-info (next to the txt "original" ones) which make their way to the wheel too.
```
dependency_links.html
SOURCES.html
top_level.html
```

It looks like something, possibly `tools/buildhtml.py`, makes a batch conversion of the txt files in the project. It should probably ignore the egg-info directory when run.


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:bugs] #467 sdist is missing tox.ini

[Günter M. <mi...@us...>]

Something went wrong. [r9379] now includes tox.ini in the MANIFEST.in, so I hope the best for 0.20.1.


---

**[bugs:#467] sdist is missing tox.ini**

**Status:** open-fixed
**Created:** Thu Feb 23, 2023 12:48 PM UTC by Marcel Telka
**Last Updated:** Wed May 10, 2023 07:37 AM UTC
**Owner:** nobody


The sdist package at PyPI is missing tox.ini file.  Please add the file to sdist to make downstream testing easier.  Thank you.


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:bugs] #470 Test failures with Pygments >= 2.13.0

[Günter M. <mi...@us...>]

Thank you for reporting.
There was a fix for Pygments >= 2.14 in [r9354].
Could you test if the problem persists with [Docutils 0.20](https://pypi.org/project/docutils/0.20/)?
(I am afraid, yes.)


---

**[bugs:#470] Test failures with Pygments >= 2.13.0**

**Status:** open
**Created:** Tue May 09, 2023 09:34 AM UTC by Jakub Kulik
**Last Updated:** Tue May 09, 2023 09:34 AM UTC
**Owner:** nobody
**Attachments:**

- [test.log.txt](https://sourceforge.net/p/docutils/bugs/470/attachment/test.log.txt) (33.2 kB; text/plain)


Since Pygments 2.13.0, I am seeing several test failures most likely related to changes in white space handling. The test log is attached.


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:bugs] #471 0.20 fails tests on pypy3

[Günter M. <mi...@us...>]

Thank you for reporting this issue.
It is a "false alarm", the different output should not trigger a test failure.

How do you start the test with PyPy3?
Does the same error show if you run "docutils/test/alltests.py" with Python 3.9.16?


---

**[bugs:#471] 0.20 fails tests on pypy3**

**Status:** open
**Created:** Wed May 10, 2023 02:53 AM UTC by Michał Górny
**Last Updated:** Wed May 10, 2023 02:53 AM UTC
**Owner:** nobody


When running the test suite of the 0.20 release on PyPy3, I get the following test failure:

```
Testing Docutils 0.20 with Python 3.9.16 on 2023-05-10 at 04:44:04
OS: Linux 6.2.14-gentoo-dist #1 SMP PREEMPT_DYNAMIC Mon May  1 15:03:02 -00 2023 (linux, Linux-6.2.14-gentoo-dist-x86_64-AMD_Ryzen_5_3600_6-Core_Processor-with-glibc2.37)
Working directory: /tmp/portage/dev-python/docutils-0.20/work/docutils-0.20/test
Docutils package: /tmp/portage/dev-python/docutils-0.20/work/docutils-0.20/docutils
.....................................................................s................................................................................................................................................................................................................s..............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................E.............................................
======================================================================
FAIL: test_embed_embed_stylesheet (test_writers.test_latex2e.WriterPublishTestCase) (id="samples_embed_stylesheet['two-styles'][0]")
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/portage/dev-python/docutils-0.20/work/docutils-0.20/test/test_writers/test_latex2e.py", line 151, in test_embed_embed_stylesheet
    self.assertEqual(output, expected)
AssertionError: "\\do[452 chars]ory: PosixPath('data/spam.sty')\n% embedded st[439 chars]t}\n" != "\\do[452 chars]ory: 'data/spam.sty'\n% embedded stylesheet: d[428 chars]t}\n"
  \documentclass[a4paper]{article}
  % generated by Docutils <https://docutils.sourceforge.io/>
  \usepackage{cmap} % fix search and cut-and-paste in Acrobat
  \usepackage{ifthen}
  \usepackage[T1]{fontenc}
  
  %%% Custom LaTeX preamble
  % PDF Standard Fonts
  \usepackage{mathptmx} % Times
  \usepackage[scaled=.90]{helvet}
  \usepackage{courier}
  
  %%% User specified packages and stylesheets
  % Cannot embed stylesheet:
- %  [Errno 2] No such file or directory: PosixPath('data/spam.sty')
?                                         ----------               -
+ %  [Errno 2] No such file or directory: 'data/spam.sty'
  % embedded stylesheet: data/ham.tex
  \newcommand{\ham}{wonderful ham}
  
  
  %%% Fallback definitions for Docutils-specific commands
  
  % hyperlinks:
  \ifthenelse{\isundefined{\hypersetup}}{
    \usepackage[colorlinks=true,linkcolor=blue,urlcolor=blue]{hyperref}
    \usepackage{bookmark}
    \urlstyle{same} % normal text font (alternatives: tt, rm, sf)
  }{}
  
  %%% Body
  \begin{document}
  
  two stylesheets embedded in the header
  
  \end{document}


----------------------------------------------------------------------
Ran 1636 tests in 14.868s

FAILED (failures=1, skipped=2)
Elapsed time: 15.745 seconds
```


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:bugs] #471 0.20 fails tests on pypy3

[Michał G. <mgo...@us...>]

---

**[bugs:#471] 0.20 fails tests on pypy3**

**Status:** open
**Created:** Wed May 10, 2023 02:53 AM UTC by Michał Górny
**Last Updated:** Wed May 10, 2023 02:53 AM UTC
**Owner:** nobody


When running the test suite of the 0.20 release on PyPy3, I get the following test failure:

```
Testing Docutils 0.20 with Python 3.9.16 on 2023-05-10 at 04:44:04
OS: Linux 6.2.14-gentoo-dist #1 SMP PREEMPT_DYNAMIC Mon May  1 15:03:02 -00 2023 (linux, Linux-6.2.14-gentoo-dist-x86_64-AMD_Ryzen_5_3600_6-Core_Processor-with-glibc2.37)
Working directory: /tmp/portage/dev-python/docutils-0.20/work/docutils-0.20/test
Docutils package: /tmp/portage/dev-python/docutils-0.20/work/docutils-0.20/docutils
.....................................................................s................................................................................................................................................................................................................s..............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................E.............................................
======================================================================
FAIL: test_embed_embed_stylesheet (test_writers.test_latex2e.WriterPublishTestCase) (id="samples_embed_stylesheet['two-styles'][0]")
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/portage/dev-python/docutils-0.20/work/docutils-0.20/test/test_writers/test_latex2e.py", line 151, in test_embed_embed_stylesheet
    self.assertEqual(output, expected)
AssertionError: "\\do[452 chars]ory: PosixPath('data/spam.sty')\n% embedded st[439 chars]t}\n" != "\\do[452 chars]ory: 'data/spam.sty'\n% embedded stylesheet: d[428 chars]t}\n"
  \documentclass[a4paper]{article}
  % generated by Docutils <https://docutils.sourceforge.io/>
  \usepackage{cmap} % fix search and cut-and-paste in Acrobat
  \usepackage{ifthen}
  \usepackage[T1]{fontenc}
  
  %%% Custom LaTeX preamble
  % PDF Standard Fonts
  \usepackage{mathptmx} % Times
  \usepackage[scaled=.90]{helvet}
  \usepackage{courier}
  
  %%% User specified packages and stylesheets
  % Cannot embed stylesheet:
- %  [Errno 2] No such file or directory: PosixPath('data/spam.sty')
?                                         ----------               -
+ %  [Errno 2] No such file or directory: 'data/spam.sty'
  % embedded stylesheet: data/ham.tex
  \newcommand{\ham}{wonderful ham}
  
  
  %%% Fallback definitions for Docutils-specific commands
  
  % hyperlinks:
  \ifthenelse{\isundefined{\hypersetup}}{
    \usepackage[colorlinks=true,linkcolor=blue,urlcolor=blue]{hyperref}
    \usepackage{bookmark}
    \urlstyle{same} % normal text font (alternatives: tt, rm, sf)
  }{}
  
  %%% Body
  \begin{document}
  
  two stylesheets embedded in the header
  
  \end{document}


----------------------------------------------------------------------
Ran 1636 tests in 14.868s

FAILED (failures=1, skipped=2)
Elapsed time: 15.745 seconds
```


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] docutils release 0.20 is out on pip

[engelbert g. <eng...@gm...>]

hello,

after the quiet test period, 0.20 is the new release

Nothing changed from rc1 aside from dropping the postfix

cheers
 e


*Release Notes*
Note

Docutils 0.20 is the last version supporting Python 3.7 and 3.8.

    General

        Support Python 3.11 (patch #198 by Hugo van Kemenade).

    Output changes:

    HTML5:

        Use dpub-ARIA role "doc-footnote" (instead of ARIA role "note") for
footnotes.
    LaTeX:

        Do not load the inputenc package in UTF-8 encoded LaTeX sources.
(UTF-8 is the default encoding for LaTeX2e since 2018).

    Configuration changes:

        Settings in the [latex2e writer] configuration file section are now
ignored by the "xetex" writer. Place common settings in section [latex
writers].

        New command line setting output. Obsoletes the <destination>
positional argument (cf. future changes).

    utils.find_file_in_dirs() now returns a POSIX path also on Windows;
utils.get_stylesheet_list() no longer converts \ to /.

    docutils/languages/ docutils/parsers/rst/languages/

        Support Ukrainian. Patch by Dmytro Kazanzhy.

    test/coverage.sh

        Removed. Use the coverage.py project instead, coverage run
test/alltests.py and coverage report.

    tools/

        Moved quicktest.py to tools/dev/.


Detailed changes in https://docutils.sourceforge.io/HISTORY.html

Re: [Docutils-develop] release 0.20 plan -- rc1

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

Dear Docutils developers,

On 2023-05-04, engelbert gruber wrote:

> 0.20 is in it's final

> * rc1 before the weekend may 6./7.

Thank you, Engelbert, for the pre-release.

> * release on tuesday , next May 9 or if someone needs more test time, 
>   May 16.

I did not get any feedback from rc1 and also don't expect more.
IMO, releasing 0.20 today is fine.

We can set the version after the release to 0.20.1.dev and wait with
any incompatible changes to "master/trunk" for one or two weeks so that
in case of problems it is straightforward to do a fixup release.

Thanks,
Günter

[Docutils-develop] docutils 0.20rc1 released

[engelbert g. <eng...@gm...>]

The release candidate is on pip

When installing with pip add the --pre option::

  pip install --pre docutils

cheers
 e

*Release Notes*

Note

Docutils 0.20 is the last version supporting Python 3.7 and 3.8.

   -

   General
   -

      Support Python 3.11 (patch #198 by Hugo van Kemenade).
      -

   Output changes:
   HTML5:

   Use dpub-ARIA role "doc-footnote" (instead of ARIA role "note") for
   footnotes.
   LaTeX:

   Do not load the inputenc package in UTF-8 encoded LaTeX sources. (UTF-8
   is the default encoding for LaTeX2e since 2018).
   -

   Configuration changes:
   -

      Settings in the [latex2e writer] configuration file section are now
      ignored by the "xetex" writer. Place common settings in section [latex
      writers]
      <https://docutils.sourceforge.io/docs/user/config.html#latex-writers>.
      -

      New command line setting output
      <https://docutils.sourceforge.io/docs/user/config.html#output>.
      Obsoletes the <destination> positional argument (cf. future changes
      <https://docutils.sourceforge.io/RELEASE-NOTES.html#command-line-usage-pattern>
      ).
      -

   utils.find_file_in_dirs() now returns a POSIX path also on Windows;
   utils.get_stylesheet_list() no longer converts \ to /.
   -

   docutils/languages/ docutils/parsers/rst/languages/
   -

      Support Ukrainian. Patch by Dmytro Kazanzhy.
      -

   test/coverage.sh
   -

      Removed. Use the coverage.py <https://pypi.org/project/coverage/>
      project instead, coverage run test/alltests.py and coverage report.
      -

   tools/
   -

      Moved quicktest.py to tools/dev/.


Detailed changes in https://docutils.sourceforge.io/HISTORY.html

[Docutils-develop] release 0.20 plan -- rc1

[engelbert g. <eng...@gm...>]

hello everyone

0.20 is in it's final

* rc1 before the weekend may 6./7.
* release on tuesday , next may 9 or if someone needs more test time,  may
16.

all the best
 e

Re: [Docutils-develop] Release 0.20

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

Dear Docutils developers,

after the next round of "last minute fixes" I propose to freeze the repository
and release the current state as next Docutils version.


On 2023-04-25, Adam Turner wrote:

> I have tested on Python 3.7, 3.8, 3.9, 3.10, 3.11, and 3.12.0a7 -- all
> supported Python versions. Following [r9363], all tests pass with no
> warnings and with ``-W error`` enabled.

Excellent. Thank you.

...

> Ok -- I have no strong feelings either way -- if Engelbert is happy to
> release 0.20 with no 'rc1' stage then that works with me! I agree we
> didn't get much feedback.

I suggest either 0.20rc1 before the weekend or 0.20 after the weekend.
Engelbert, could you decide (and tell us) which you prefer and can manage?


> ...

>>>> The API documentation "publisher.txt" now has the example

>>>>     output = bytes(publish_string(...))

>>>> (which depends on `OutputString` features).

>>> Can we mark this feature as provisional? Personally, I don't think
>>> that we should support this form of ``bytes`` conversion long-term,
>>> and I see the ``OutputString`` as a transitional class, again not
>>> one that will be around for a long time.

>> OK.

> I'll reply to this point in my reply to your other note

[r9369] reverts the addition of `io.OutString` and the "auto_encode"
argument for core.publish_string() and core.publish_from_docstring(). I
hope this can give us a clean start for discussing a consensus on the
desired end state of the "String I/O interface" and the best way to reach
it.


Thanks,

Günter

[Docutils-develop] [docutils:patches] #114 rst2odt_prepstyles.py: Port to ElementTree

[Günter M. <mi...@us...>]

- **status**: pending-remind --> open-accepted
- **Comment**:

Applied in [r9365].
(Without the handling of Python <2.5 as we no longer support Python 2.)

Thank you for the patch.



---

** [patches:#114] rst2odt_prepstyles.py: Port to ElementTree**

**Status:** open-accepted
**Group:** None
**Created:** Mon Aug 05, 2013 02:12 PM UTC by Michael Schutte
**Last Updated:** Wed Apr 26, 2023 12:17 PM UTC
**Owner:** nobody
**Attachments:**

- [rst2odt_prepstyles-elementtree.diff](https://sourceforge.net/p/docutils/patches/114/attachment/rst2odt_prepstyles-elementtree.diff) (1.8 kB; text/x-patch)


rst2odt_prepstyles.py currently uses lxml to parse, modify and write XML.  The attached patch makes it use ElementTree instead, which has been part of Python's standard library since 2.5.


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/patches/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/patches/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:patches] Re: #114 rst2odt_prepstyles.py: Port to ElementTree

[Dmitry S. <man...@us...>]

First error can be fixed by replacing `el.attrib.keys()` with `list(el.attrib)`. Second error can be fixed by changing argument of os.fdopen from `w` to `wb`.

I am attaching an updated version of the patch. Although you may want to commit `w` to `wb` change as a separate revision, for ease of backporting.


Attachments:

- [rst2odt_prepstyles-elementtree.patch](https://sourceforge.net/p/docutils/patches/_discuss/thread/1beea79a/ed4c/3422/attachment/rst2odt_prepstyles-elementtree.patch) (1.6 kB; text/x-patch)


---

** [patches:#114] rst2odt_prepstyles.py: Port to ElementTree**

**Status:** pending-remind
**Group:** None
**Created:** Mon Aug 05, 2013 02:12 PM UTC by Michael Schutte
**Last Updated:** Wed Apr 26, 2023 11:58 AM UTC
**Owner:** nobody
**Attachments:**

- [rst2odt_prepstyles-elementtree.diff](https://sourceforge.net/p/docutils/patches/114/attachment/rst2odt_prepstyles-elementtree.diff) (1.8 kB; text/x-patch)


rst2odt_prepstyles.py currently uses lxml to parse, modify and write XML.  The attached patch makes it use ElementTree instead, which has been part of Python's standard library since 2.5.


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/patches/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/patches/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:patches] #114 rst2odt_prepstyles.py: Port to ElementTree

[Günter M. <mi...@us...>]

> lxml is not part of standard library, while xml.etree is. 

I see. Thanks for the clarification.

When I try to use the patched script on a copy of `docutils/writers/odf_odt/styles.odt`, I get an error:

    /usr/local/src/docutils-git-svn/docutils/tools/rst2odt_prepstyles.py styles.odt 
    Traceback (most recent call last):
      File "/usr/local/src/docutils-git-svn/docutils/tools/rst2odt_prepstyles.py", line 78, in <module>
    main()
      File "/usr/local/src/docutils-git-svn/docutils/tools/rst2odt_prepstyles.py", line 74, in main
    prepstyle(filename)
      File "/usr/local/src/docutils-git-svn/docutils/tools/rst2odt_prepstyles.py", line 48, in prepstyle
    for attr in el.attrib.keys():
    RuntimeError: dictionary changed size during iteration

BTW, the non-patched version fails with:

~~~
/usr/local/src/docutils-git-svn/docutils/tools/rst2odt_prepstyles.py styles.odt 
Traceback (most recent call last):
  File "/usr/local/src/docutils-git-svn/docutils/tools/rst2odt_prepstyles.py", line 67, in <module>
    main()
  File "/usr/local/src/docutils-git-svn/docutils/tools/rst2odt_prepstyles.py", line 63, in main
    prepstyle(filename)
  File "/usr/local/src/docutils-git-svn/docutils/tools/rst2odt_prepstyles.py", line 49, in prepstyle
    zout.writestr(item, zin.read(item.filename))
  File "/usr/lib/python3.9/zipfile.py", line 1802, in writestr
    with self.open(zinfo, mode='w') as dest:
  File "/usr/lib/python3.9/zipfile.py", line 1505, in open
    return self._open_to_write(zinfo, force_zip64=force_zip64)
  File "/usr/lib/python3.9/zipfile.py", line 1600, in _open_to_write
    self.fp.write(zinfo.FileHeader(zip64))
TypeError: write() argument must be str, not bytes
Exception ignored in: <function ZipFile.__del__ at 0x7f7e5b555700>
Traceback (most recent call last):
  File "/usr/lib/python3.9/zipfile.py", line 1807, in __del__
    self.close()
  File "/usr/lib/python3.9/zipfile.py", line 1825, in close
    self._write_end_record()
  File "/usr/lib/python3.9/zipfile.py", line 1919, in _write_end_record
    self.fp.write(endrec)
TypeError: write() argument must be str, not bytes
~~~

    



---

** [patches:#114] rst2odt_prepstyles.py: Port to ElementTree**

**Status:** pending-remind
**Group:** None
**Created:** Mon Aug 05, 2013 02:12 PM UTC by Michael Schutte
**Last Updated:** Fri Apr 21, 2023 08:52 PM UTC
**Owner:** nobody
**Attachments:**

- [rst2odt_prepstyles-elementtree.diff](https://sourceforge.net/p/docutils/patches/114/attachment/rst2odt_prepstyles-elementtree.diff) (1.8 kB; text/x-patch)


rst2odt_prepstyles.py currently uses lxml to parse, modify and write XML.  The attached patch makes it use ElementTree instead, which has been part of Python's standard library since 2.5.


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/patches/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/patches/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

Re: [Docutils-develop] Release 0.20

[Adam T. <aat...@ou...>]

Dear Günter, all,

>> I have tested on Ubuntu 22.04 LTS and Windows 10, and against Sphinx.
>> All tests are passing,

> Good news. What are the tested Python versions?
> Could someone test with Python 3.11?

I have tested on Python 3.7, 3.8, 3.9, 3.10, 3.11, and 3.12.0a7 -- all supported Python versions. Following [r9363], all tests pass with no
warnings and with ``-W error`` enabled.

...

>> Please may we release a 0.20b1 first so that I might ask downstream
>> projects to test, as with the 0.19 release?

> My experience from the latest pre-releases was minimal to no feedback.
> However, if you have other experiences of expectations, I agree with a
> pre-release.

> I suggest "rc1" instead of "beta" (as I really like
> 0.20 coming out soon and rather see a not too distant 0.21...).

Ok -- I have no strong feelings either way -- if Engelbert is happy to
release 0.20 with no 'rc1' stage then that works with me! I agree we
didn't get much feedback.

...

>>> The API documentation "publisher.txt" now has the example

>>>     output = bytes(publish_string(...))

>>> (which depends on `OutputString` features).

>> Can we mark this feature as provisional? Personally, I don't think
>> that we should support this form of ``bytes`` conversion long-term,
>> and I see the ``OutputString`` as a transitional class, again not
>> one that will be around for a long time.

> OK.

I'll reply to this point in my reply to your other note

...

>> Sorry for the rather long message appended to a release thread, but
>> as you note, perhaps the decision cannot be delayed, as the
>> documentation contains a recipie that we may later regret declaring
>> support for.

> My suggestion for the next steps:

> ...

> * Push "deprecation warning" patch (Adam).

Done! [r9363]


Thanks,
Adam

Re: [Docutils-develop] Release 0.20

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

Dear Docutils developers,

On 2023-04-23, Adam Turner wrote:

...

> For me, the point of this exercise and deprecation process is to
> reach an end-state where ``publish_string`` always returns ``str``.

This would be a clean and simple end state.
It is problematic for ``output_encoding != 'utf-8'``
and/or ``output_encoding_error_handler != 'strict'``.


> To summarise the problem as I understand it:

> * Some output formats may contain information about the encoding of
>   the document

>   - SGML based markup languages (XML, HTML) may contain an internal
>     encoding declaration.
>   - TeX based languages (LaTeX, XeLaTeX, etc) may contain an internal
>     encoding macro.

> * All of these formats have default encodings

>   - XML defaults to a UTF-8 encoding if the encoding attribute is not
>     specified, since XML 1.0 (2008)
>       https://www.w3.org/TR/xml/#charencoding
>   - HTML 5 requires a UTF-8 charset
>     https://html.spec.whatwg.org/#charset
>   - LaTeX's default encoding is UTF-8, since 2018
>     https://tug.org/TUGboat/tb39-1/tb121ltnews28.pdf
>   - XeTeX I believe has always defaulted to UTF-8.

* (g|n|t)roff (used for man pages) has no default encoding and (AFAIK) no
  universal syntax for an encoding declaration in the source.

  groff has no built-in support for UTF-8.
  https://www.gnu.org/software/groff/manual/groff.html#Input-Encodings
  There is a pre-processor for UTF-8 encoded sources.
  https://stackoverflow.com/questions/23138930/text-codepage-in-groff
  https://stackoverflow.com/questions/52732988/nroff-groff-does-not-properly-convert-utf-8-encoded-file

* ODT and epub are binary formats without a universal "natural"
  representation as `str` (the output may include bitmap graphics).

* The "output_encoding" setting also decides over the use of literal
  characters vs. a macro representation for several non-ASCII characters
  in LaTeX., e.g. ``\dag{}`` for the footnote mark † (0x2020).

* For XML and HTML, the "output_encoding_error_handler" setting may decide
  over "make or break" in case of non-encodable characters.
  (With "xmlcharrefreplace", unencodable characters can be used with
  XML/HTML output. The unencodable characters are still present in the
  `str` representation of the output document.)



> * If a user asks for output as a Unicode ``str``, I believe it is
>   reasonable to assume these defaults (UTF-8 encoding).
>
> * If a user asks for output as a Unicode ``str``, but overrides the
>   ``output_encoding`` setting, I believe it is reasonable to assume
>   that the user is now responsible for conversion of the ``str`` to
>   ``bytes`` for serialisation to disk, and we should not support an
>   output format that does this by 'magic'. We could declare this as
>   unsupported behaviour as an alternative, and just issue an error.

Users of applications that utilise the Docutils publisher API may be
unaware of the internals (whether this application calls 
``publish_string()`` or uses another part of the API).
Currently an end user of such applications can customise the output
encoding and error handling in a "docutils.conf" config file (unless
explicitly forbidden by the application).

Changing the behaviour of the "string I/O" interface should not silently
start ignoring the configuration settings.

Application developers should be made aware of this change before it
bites their downstream users (e.g. in the docstring of the new function,
the "future changes" announcement and the API docs).

> * If a user asks for binary output (a ``bytes`` instance), I think it
>   is reasonable to use ``output_encoding``
    and ``output_encoding_error_handler``
>   to encode the ``str`` 
>   instance we use internally to a ``bytes`` instance.


> * We therefore need to decide the following end-state positions:

>   a) Do we want to support (long-term) outputting ``bytes`` from
>      the core publish API?

I  agree to not returning ``bytes`` from a "String I/O" interface.
(The core publish API also provides two functions with "File I/O" and
publish_parts() and publish_doctree() with alternative interfaces.)

>   b) Do we want to support (long-term) encodings other than UTF-8?

At least for a medium-term time-frame, I'd keep support for other encodings
(not necessarily for the "String I/O" interface).


> * If (a) is true, we should decide if it is through a dedicated
>   function, or through an overloaded signature (the current status)

... or through publish_parts() (see below).

>   You have previously argued for keeping the "core" interface as
>   small as possible, and I would strongly advocate against overloaded
>   return types, perhaps leading to us not supporting returning
>   ``bytes`` from the core publish API.

>   This may be a reasonable position, as if a user knows that he wants
>   bytes output, he should set the output encoding explicitly anyway,
>   and therefore he has control over the encoding from ``str`` to
>   ``bytes`` as he can e.g. do:

>   .. code:: python

>      encoding = 'latin1'
>        out_str = publish_string(source,
>            settings_overrides={'output_encoding': encoding}
>        )
>        assert isinstance(out_str, str)
>        out_bytes = out_str.encode(encoding)
>
>   in a hypothetical future where ``publish_string`` always returns
>   ``str`` instances.

There are problems with this approach:

The "settings_override" dictionay only overrides the "Docutils defaults"
with "programmatic defaults". A different value in a configuration file
would still override this programmatic default.

Applications can disable configuration file parsing, but not for
individual settings. To keep configurability, the application would need
to parse configuration settings on its own and call publish_string() with
a ``settings`` object: ``publish_string(source, settings=settings, …)``.

An application developer does not need to be the end user (and hence may
not know the desired output encoding), e.g., a 3rd party Docutils
extension application may want to provide a file I/O interface but do
some post-processing on the document returned from the writer.

However, see the alternative "bytes-output recipe" below.


> * If (b) is false, we could simplify the I/O code a great deal. I
>   think it may be reasonable to expect the user to be responsible
>   for encoding conversions, or to move Docutils' code to handle that
>   away from the core and into the command-line interface, for example.

At least the "File I/O" interface (which is part of the core API) should
IMO, support a configurable output encoding for the next couple of
versions/years. 

The command line interface (`core.publish_cmdline()`) is part of the core
API, too.


Proposal
========

Keep it simple:

* replace `publish_string()` with a new function `publish_str()` that
  returns a `str` instance and raises an error

  - for binary writer output (e.g. ODT writer)
  - if 'output_encoding' is not in ("utf-8", "")

* Accordingly replace `io.StringOutput` with a new `io.StrOutput` class.

* Implement `publish_str()` and `StrOutput` in Docutils 0.21 to give them
  proper testing and time for implementation details to settle while
  getting the bugfixes out now.

* Think about the future of `publish_from_doctree()`.

Rationale:

* The different behaviour of the new string I/O interface merits a new
  function name. Application developers using the string I/O API will
  have to change their code anyway.
  
  Applications will at some stage break with the old function name,
  (hopefully tested by their developers), not only with certain
  configuration values (which may be easily overlooked by developers).

* The confusing co-existence of `publish_str()` vs. `publish_string()` is
  temporary and moderated by the deprecation warning that comes with the
  use of `publish_string()`.


Steps towards 0.20

* Revert the introduction of the "OutString" class.

* Revert the addition of the "auto_encode" attribute.

* Add ['errors'] to the `parts provided by all writers`__.

  __ https://docutils.sourceforge.io/docs/api/publisher.html#parts-provided-by-all-writers

* Mark `core.publish_string()` and `io.StringOutput` as deprecated.
  (This includes deprecation of the special pseudo-encoding value "unicode".)

* Document upcoming changes

  - There will be a new "string I/O interface" in 0.21.

  - The already working and future-proof way to get `str` output is ::

      out_str = publish_parts(...)['whole']
      assert isinstance(out_str, str) # ODT writer returns `bytes`

    This approach ignores the "output_encoding" and
    "output_encoding_error_handler" settings.

  - The future-proof and configuration-proof way to get `bytes` output is ::

      parts = publish_parts(...)
      out = parts['whole']
      if isinstance(out, str):
          out_bytes = out_str.encode(parts['encoding'], parts['errors'])

    Alternatively, the return value of `publish_file()` (with a "dummy"
    file object) can be used.


Would this be a sensible way forward?

Günter

Re: [Docutils-develop] Release 0.20

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

Dear Docutils developers,

On 2023-04-23, Adam Turner wrote:

> I have tested on Ubuntu 22.04 LTS and Windows 10, and against Sphinx.
> All tests are passing, 

Good news. What are the tested Python versions?
Could someone test with Python 3.11?

> though I would strongly reccomend to apply the
> attached patch to avoid a false-positive warning during testing.

I agree with the patch.


...

> Please may we release a 0.20b1 first so that I might ask downstream
> projects to test, as with the 0.19 release?

My experience from the latest pre-releases was minimal to no feedback.
However, if you have other experiences of expectations, I agree with a
pre-release. 

I suggest "rc1" instead of "beta" (as I really like
0.20 coming out soon and rather see a not too distant 0.21...).


...

>> The API documentation "publisher.txt" now has the example

>>     output = bytes(publish_string(...))

>> (which depends on `OutputString` features).

> Can we mark this feature as provisional? Personally, I don't think
> that we should support this form of ``bytes`` conversion long-term,
> and I see the ``OutputString`` as a transitional class, again not
> one that will be around for a long time.

OK.

...

> Sorry for the rather long message appended to a release thread, but
> as you note, perhaps the decision cannot be delayed, as the
> documentation contains a recipie that we may later regret declaring
> support for.

My suggestion for the next steps:

* "Thaw" the repository.

* Push "deprecation warning" patch (Adam).

* Reach a consensus about the parts of `publish_string()`
  that need to be settled in release 0.20 (see separate reply).

  Implement/revert changes. (GM)
  
* Release 0.21rc1 (Engelbert?)


@engelbert: Can we thaw for "last minute fixes".


Günter

Re: [Docutils-develop] Release 0.20

[Adam T. <aat...@ou...>]

Dear Günter, all,

> I finished my work on the preparations towards Docutils 0.20.

> Please check and test.

I have tested on Ubuntu 22.04 LTS and Windows 10, and against Sphinx.
All tests are passing, though I would strongly reccomend to apply the
attached patch to avoid a false-positive warning during testing.

----

> Engelbert, can you prepare a release for next week?

Please may we release a 0.20b1 first so that I might ask downstream
projects to test, as with the 0.19 release? I am happy to help with
this, though I don't have the ability to upload to Docutils on PyPI
at the moment.

----

>>> I left the decision about the end state of this transition open...

>> A decision to make later, and one that doesn't block the 0.20
>> release!

> Yes and no: if we want to give users advise on a stable recipe to
> avoid beeing hit by the default-change, we would need agreement of
> what will (most likely) be kept stable.

> The API documentation "publisher.txt" now has the example

>     output = bytes(publish_string(...))

> (which depends on `OutputString` features).

Can we mark this feature as provisional? Personally, I don't think
that we should support this form of ``bytes`` conversion long-term,
and I see the ``OutputString`` as a transitional class, again not
one that will be around for a long time.

For me, the point of this exercise and deprecation process is to
reach an end-state where ``publish_string`` always returns ``str``.
Perhaps we should return to discussing ``publish_str`` and
``publish_bytes`` functions?

To summarise the problem as I understand it:

* Some output formats may contain information about the encoding of
  the document

  - SGML based markup languages (XML, HTML) may contain an internal
    encoding declaration.
  - TeX based languages (LaTeX, XeLaTeX, etc) may contain an internal
    encoding macro.

* All of these formats have default encodings

  - XML defaults to a UTF-8 encoding if the encoding attribute is not
    specified, since XML 1.0 (2008)
	
	https://www.w3.org/TR/xml/#charencoding
  - HTML 5 requires a UTF-8 charset 
    https://html.spec.whatwg.org/#charset
  - LaTeX's default encoding is UTF-8, since 2018
    https://tug.org/TUGboat/tb39-1/tb121ltnews28.pdf
  - XeTeX I believe has always defaulted to UTF-8.
  
* If a user asks for output as a Unicode ``str``, I believe it is
  reasonable to assume these defaults (UTF-8 encoding).

* If a user asks for output as a Unicode ``str``, but overrides the
  ``output_encoding`` setting, I believe it is reasonable to assume
  that the user is now responsible for conversion of the ``str`` to
  ``bytes`` for serialisation to disk, and we should not support an
  output format that does this by 'magic'. We could declare this as
  unsupported behaviour as an alternative, and just issue an error.

* If a user asks for binary output (a ``bytes`` instance), I think it
  is reasonable to use ``output_encoding`` to encode the ``str``
  instance we use internally to a ``bytes`` instance.

* We therefore need to decide the following end-state positions:

  a) Do we want to support (long-term) outputting ``bytes`` from
     the core publish API?
	 
  b) Do we want to support (long-term) encodings other than UTF-8?
  
* If (a) is true, we should decide if it is through a dedicated
  function, or through an overloaded signature (the current status).
  You have previously argued for keeping the "core" interface as
  small as possible, and I would strongly advocate against overloaded
  return types, perhaps leading to us not supporting returning
  ``bytes`` from the core publish API.
  
  This may be a reasonable position, as if a user knows that he wants
  bytes output, he should set the output encoding explicitly anyway,
  and therefore he has control over the encoding from ``str`` to
  ``bytes`` as he can e.g. do:
  
  .. code:: python
  
     encoding = 'latin1'
	 out_str = publish_string(source,
	     settings_overrides={'output_encoding': encoding}
	 )
	 assert isinstance(out_str, str)
	 out_bytes = out_str.encode(encoding)
	 
  In a hypothetical future where ``publish_string`` always returns
  ``str`` instances.

* If (b) is false, we could simplify the I/O code a great deal. I
  think it may be reasonable to expect the user to be responsible
  for encoding conversions, or to move Docutils' code to handle that
  away from the core and into the command-line interface, for example.
  
Sorry for the rather long message appended to a release thread, but
as you note, perhaps the decision cannot be delayed, as the
documentation contains a recipie that we may later regret declaring
support for.

----

Thanks,
Adam

----------

>From 5031c0ff9923057a5a12a80551b67992dcb2b4df Mon Sep 17 00:00:00 2001
From: Adam Turner <908...@us...>
Date: Sun, 23 Apr 2023 16:50:15 +0100
Subject: [PATCH] Ignore ``CSVTable.HeaderDialect`` deprecation warning

---
 docutils/docutils/parsers/rst/directives/tables.py | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/docutils/docutils/parsers/rst/directives/tables.py b/docutils/docutils/parsers/rst/directives/tables.py
index 446034828..8212f2cfc 100644
--- a/docutils/docutils/parsers/rst/directives/tables.py
+++ b/docutils/docutils/parsers/rst/directives/tables.py
@@ -64,8 +64,11 @@ def process_header_option(self):
         table_head = []
         max_header_cols = 0
         if 'header' in self.options:   # separate table header in option
+            with warnings.catch_warnings():
+                warnings.simplefilter('ignore')
+                header_dialect = self.HeaderDialect()
             rows, max_header_cols = self.parse_csv_data_into_rows(
-                self.options['header'].split('\n'), self.HeaderDialect(),
+                self.options['header'].split('\n'), header_dialect,
                 source)
             table_head.extend(rows)
         return table_head, max_header_cols
-- 
2.40.0.windows.1

[Docutils-develop] [docutils:patches] Re: #114 rst2odt_prepstyles.py: Port to ElementTree

[Dmitry S. <man...@us...>]

lxml is not part of standard library, while xml.etree is. So we are adding a dependency on a 3rdparty project for no good reason.

I am attaching a version of this patch which applies cleanly to master branch of git mirror.


Attachments:

- [rst2odt_prepstyles-elementtree.patch](https://sourceforge.net/p/docutils/patches/_discuss/thread/1beea79a/3f73/fab1/attachment/rst2odt_prepstyles-elementtree.patch) (1.3 kB; text/x-patch)


---

** [patches:#114] rst2odt_prepstyles.py: Port to ElementTree**

**Status:** pending-remind
**Group:** None
**Created:** Mon Aug 05, 2013 02:12 PM UTC by Michael Schutte
**Last Updated:** Tue Apr 18, 2023 06:56 PM UTC
**Owner:** nobody
**Attachments:**

- [rst2odt_prepstyles-elementtree.diff](https://sourceforge.net/p/docutils/patches/114/attachment/rst2odt_prepstyles-elementtree.diff) (1.8 kB; text/x-patch)


rst2odt_prepstyles.py currently uses lxml to parse, modify and write XML.  The attached patch makes it use ElementTree instead, which has been part of Python's standard library since 2.5.


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/patches/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/patches/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

Re: [Docutils-develop] Release 0.20

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

Dear Docutils developers,

I finished my work on the preparations towards Docutils 0.20.

Please check and test.

I propose a freeze starting tomorrow: don't commit stuff without asking
here on the list in advance.

Engelbert, can you prepare a release for next week?

Have a nice weekend,

Günter

[Docutils-develop] [docutils:bugs] Re: #458 Two issues regarding manpage writer and .TH

[Dmitry S. <man...@us...>]

One of the original bugs in Debian is fixed now. Regarding the other bug, I have [forwarded][1] your response to the original reporter, but he has not replied. So yes, I think you can close this bug.

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016527#22


---

** [bugs:#458] Two issues regarding manpage writer and .TH**

**Status:** open
**Labels:** manpage writer 
**Created:** Mon Sep 05, 2022 11:13 AM UTC by Dmitry Shachnev
**Last Updated:** Thu Apr 20, 2023 04:47 PM UTC
**Owner:** nobody


Dear docutils developers,

I received two bug reports in Debian regarding the content of .TH macro in man pages:

First bug — https://bugs.debian.org/1016527 — asks that the value of `--date` argument be used for the third argument of `.TH`, instead of putting it on a separate line (Generated on: YYYY-MM-DD).

Second bug — https://bugs.debian.org/1018737 — asks that docutils not set fifth argument of `.TH` to empty string, but omit it completely and rely on the default value.

Please see those bugs for more detailed descriptions (and some discussion, in the first bug).


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:bugs] Re: #458 Two issues regarding manpage writer and .TH

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

set to open-fixed
commandline --date is not usable, but docinfo-date is used
noone complained about the value of source or answered so I will leave it
there



On Thu, 20 Apr 2023 at 18:47, "Günter Milde" <mi...@us...>
wrote:

> Is there still work to do or can we set this issue to "open-fixed" and
> close it once 0.20 is out?
> ------------------------------
>
> * [bugs:#458] <https://sourceforge.net/p/docutils/bugs/458/> Two issues
> regarding manpage writer and .TH*
>
> *Status:* open
> *Labels:* manpage writer
> *Created:* Mon Sep 05, 2022 11:13 AM UTC by Dmitry Shachnev
> *Last Updated:* Thu Nov 03, 2022 10:01 AM UTC
> *Owner:* nobody
>
> Dear docutils developers,
>
> I received two bug reports in Debian regarding the content of .TH macro in
> man pages:
>
> First bug — https://bugs.debian.org/1016527 — asks that the value of
> --date argument be used for the third argument of .TH, instead of putting
> it on a separate line (Generated on: YYYY-MM-DD).
>
> Second bug — https://bugs.debian.org/1018737 — asks that docutils not set
> fifth argument of .TH to empty string, but omit it completely and rely on
> the default value.
>
> Please see those bugs for more detailed descriptions (and some discussion,
> in the first bug).
> ------------------------------
>
> Sent from sourceforge.net because you indicated interest in
> https://sourceforge.net/p/docutils/bugs/458/
>
> To unsubscribe from further messages, please visit
> https://sourceforge.net/auth/subscriptions/
>



---

** [bugs:#458] Two issues regarding manpage writer and .TH**

**Status:** open
**Labels:** manpage writer 
**Created:** Mon Sep 05, 2022 11:13 AM UTC by Dmitry Shachnev
**Last Updated:** Thu Apr 20, 2023 04:47 PM UTC
**Owner:** nobody


Dear docutils developers,

I received two bug reports in Debian regarding the content of .TH macro in man pages:

First bug — https://bugs.debian.org/1016527 — asks that the value of `--date` argument be used for the third argument of `.TH`, instead of putting it on a separate line (Generated on: YYYY-MM-DD).

Second bug — https://bugs.debian.org/1018737 — asks that docutils not set fifth argument of `.TH` to empty string, but omit it completely and rely on the default value.

Please see those bugs for more detailed descriptions (and some discussion, in the first bug).


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:bugs] #458 Two issues regarding manpage writer and .TH

[Günter M. <mi...@us...>]

Is there still work to do or can we set this issue to "open-fixed" and close it once 0.20 is out?


---

** [bugs:#458] Two issues regarding manpage writer and .TH**

**Status:** open
**Labels:** manpage writer 
**Created:** Mon Sep 05, 2022 11:13 AM UTC by Dmitry Shachnev
**Last Updated:** Thu Nov 03, 2022 10:01 AM UTC
**Owner:** nobody


Dear docutils developers,

I received two bug reports in Debian regarding the content of .TH macro in man pages:

First bug — https://bugs.debian.org/1016527 — asks that the value of `--date` argument be used for the third argument of `.TH`, instead of putting it on a separate line (Generated on: YYYY-MM-DD).

Second bug — https://bugs.debian.org/1018737 — asks that docutils not set fifth argument of `.TH` to empty string, but omit it completely and rely on the default value.

Please see those bugs for more detailed descriptions (and some discussion, in the first bug).


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:bugs] #468 New release of libpaper (paperconf) breaks rst2odt

[Günter M. <mi...@us...>]

- **summary**: New release of libpaper (paperconf) breark rst2odt --> New release of libpaper (paperconf) breaks rst2odt



---

** [bugs:#468] New release of libpaper (paperconf) breaks rst2odt**

**Status:** open
**Created:** Wed Mar 08, 2023 10:59 AM UTC by fouinix
**Last Updated:** Thu Apr 20, 2023 12:34 PM UTC
**Owner:** nobody


Hello,
It seems a new release of libpaper has broken rst2odt. `paperconf -s` no longer exists:

~~~
paperconf -s 
(null): unknown option ‘-s’
~~~


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:bugs] #468 New release of libpaper (paperconf) breark rst2odt

[Günter M. <mi...@us...>]

And a test stub. (A proper test would need an independent method to find out if the user has a configured page size and check it is properly retrieved.)


Attachments:

- [odt-paperconf-test.patch](https://sourceforge.net/p/docutils/bugs/_discuss/thread/fffea678d7/36c5/attachment/odt-paperconf-test.patch) (1.2 kB; text/x-patch)


---

** [bugs:#468] New release of libpaper (paperconf) breark rst2odt**

**Status:** open
**Created:** Wed Mar 08, 2023 10:59 AM UTC by fouinix
**Last Updated:** Thu Apr 20, 2023 12:32 PM UTC
**Owner:** nobody


Hello,
It seems a new release of libpaper has broken rst2odt. `paperconf -s` no longer exists:

~~~
paperconf -s 
(null): unknown option ‘-s’
~~~


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:bugs] #468 New release of libpaper (paperconf) breark rst2odt

[Günter M. <mi...@us...>]

The attached patch combines the "old" code with your change suggestion.
"flake8" shows a number of complaints (e.g. variable "txt"  never used).
Also, the regexp looks overly complicated and I'd rather use re.search() than re.split().
Did you test the proposed change?


Attachments:

- [odt-paperconf.patch](https://sourceforge.net/p/docutils/bugs/_discuss/thread/fffea678d7/0bc9/attachment/odt-paperconf.patch) (2.6 kB; text/x-patch)


---

** [bugs:#468] New release of libpaper (paperconf) breark rst2odt**

**Status:** open
**Created:** Wed Mar 08, 2023 10:59 AM UTC by fouinix
**Last Updated:** Wed Apr 19, 2023 01:23 PM UTC
**Owner:** nobody


Hello,
It seems a new release of libpaper has broken rst2odt. `paperconf -s` no longer exists:

~~~
paperconf -s 
(null): unknown option ‘-s’
~~~


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.