docutils-develop — For developer discussions of the implementation.

[Docutils-develop] [docutils:feature-requests] #62 code-block should support :caption:

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

- Description has changed:

Diff:

~~~~

--- old
+++ new
@@ -2,13 +2,10 @@
 
 This to work
 
-```
-.. code-block:: 
-          :caption: Hello
+    .. code-block:: 
+        :caption: Hello
           
           print("ciao")
-          
- ```
  
  ## Instead
  

~~~~




---

**[feature-requests:#62] code-block should support :caption:**

**Status:** open
**Group:** Default
**Created:** Tue Apr 09, 2019 09:50 AM UTC by Roberto Polli
**Last Updated:** Fri Aug 20, 2021 11:10 AM UTC
**Owner:** nobody


## I expect

This to work

    .. code-block:: 
        :caption: Hello
          
          print("ciao")
 
 ## Instead
 
 D000 Error in "code-block" directive:
unknown option: "caption".




---

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

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

[Docutils-develop] [docutils:feature-requests] #110 Move from "optparse" to "argparse".

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

Ticket moved from /p/docutils/bugs/441/


---

**[feature-requests:#110] Move from "optparse" to "argparse".**

**Status:** open
**Group:** None
**Created:** Thu Jan 06, 2022 03:02 PM UTC by Günter Milde
**Last Updated:** Sat Oct 19, 2024 10:10 AM UTC
**Owner:** Günter Milde


The optparse documentation says:
> Deprecated since version 3.2: The optparse module is deprecated and will not be developed further; development will continue with the argparse module.

We are currently suppressing related deprecation warnings in the test suite.
After raising the Python dependency to >=3.7, now may be the right time to make the move.


---

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

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

[Docutils-develop] [docutils:bugs] #487 Ambiguous license in test/test_utils/test_math/test__init__.py

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

- **status**: open-fixed --> closed-fixed
- **Comment**:

With the declaration in the comment above and the fix in [r9656], this issue should be resolved.



---

**[bugs:#487] Ambiguous license in test/test_utils/test_math/test__init__.py**

**Status:** closed-fixed
**Created:** Wed Apr 24, 2024 08:57 PM UTC by Dmitry Shachnev
**Last Updated:** Thu Apr 25, 2024 07:27 AM UTC
**Owner:** nobody


Dear Günter,

The header of [this file](https://sourceforge.net/p/docutils/code/HEAD/tree/trunk/docutils/test/test_utils/test_math/test__init__.py) says:

```python
#!/usr/bin/env python3
# :Copyright: © 2024 Günter Milde.

#             Released without warranty under the terms of the
#             GNU General Public License (v. 2 or later)

# :License: Released under the terms of the `2-Clause BSD license`_, in short:
#
#    Copying and distribution of this file, with or without modification,
#    are permitted in any medium without royalty provided the copyright
#    notice and this notice are preserved.
#    This file is offered as-is, without any warranty.
#
# .. _2-Clause BSD license: https://opensource.org/licenses/BSD-2-Clause
```

So it mentions both GPL and BSD license.

Do both licenses really apply, and if not, can the extra one be removed?




---

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] suggestion for better manpage image handling

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

Dear Engelbert, dear Docutils developers,

with man pages usually presented on a terminal, it is no surprise that
the "manpage" writer does not support images. However, the current
behavior around this limitation may, IMO, be iproved.

If the image has an "alt" attribute, use its value *instead of* the filename.
Example::

  text

  .. image:: gibsnich.png
     :alt: an image of something

  more text

With ``rst2man foo.rst > foo.roff`` I get a ::

  (WARNING/2) "image" not supported

and `man ./foo.roff` shows::


  ()                                                                        ()

  Name
          - text [image: an image of something/gibsnich.png]

         more text

I would prefer an (INFO/1) instead of a warning and ::

  ()                                                                        ()

  Name
         text

	     an image of something

         more text



For images without an :alt: attribute, the warning should be kept
but amended with something in the line of

   (WARNING/2) "image" not supported by "manpage" writer.
   Please provide an "alt" attribute with textual replacement.


Thanks,

Günter

[Docutils-develop] [docutils:feature-requests] #108 "title" option for the "image" directive

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

- **status**: open --> pending-works-for-me



---

**[feature-requests:#108] "title" option for the "image" directive**

**Status:** pending-works-for-me
**Group:** Default
**Created:** Sun Sep 29, 2024 08:41 AM UTC by toastal
**Last Updated:** Tue Oct 15, 2024 07:57 PM UTC
**Owner:** nobody


Like `image`’s `:alt:` directive, allow `:title:` for creating titles on pointer hover. The use case here is different from alt as alt is for assistive technologies & titles are more to give a labels for images for those with pointer cursors.

Expected input

~~~
.. image:: /house.jxl
	:alt: Home
	:title: Navigate home
	:target: /

.. image:: /cat.jxl
	:alt: A Siamese cat on a chair
	:title: Chula says, “meow”
~~~

Expected HTML output

~~~
<a href="/"><img src="/house.jxl" alt="Home" title="Navigate home"></a>
<img src="/cat.jxl" alt="A Siamese cat on a chair" title="Chula says, “meow”">
~~~

~~~






---

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

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

[Docutils-develop] [docutils:bugs] #493 Test failure on Windows with embedded images

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

- **status**: open --> pending-works-for-me
- **Comment**:

@aa-turner: Can we close this bug?



---

**[bugs:#493] Test failure on Windows with embedded images**

**Status:** pending-works-for-me
**Created:** Wed Aug 07, 2024 02:25 AM UTC by Adam  Turner
**Last Updated:** Fri Aug 30, 2024 11:39 AM UTC
**Owner:** nobody


xref [r9785], [r9853], [r9855]

Dear @milde,

Thank you for the fix to my recent patch. It seems neither my patch nor the fix addressed the root cause of the test failures, as tests have resumed failing on Windows.

I believe the following demonstrates the problem:

```pycon
>>> import sys; print(sys.platform)
win32
>>> import urllib.parse, urllib.request
>>> urllib.request.url2pathname('test/data/circle-broken.svg')
'test\\data\\circle-broken.svg'
>>> urllib.parse.unquote('test/data/circle-broken.svg')
'test/data/circle-broken.svg'
```

Currently, we use `imagepath = urllib.request.url2pathname(uri_parts.path)`, which converts path separators to their platform-native format. On UNIX, `url2pathname` simply calls `unquote`, but on Windows it handles UNC paths (``\\host\path\``) and escaped drive letters (``///C|/users/``).

I don't know what led to using `url2pathname()`, as it is quite specialised (the docstring notes "not recommended for general use"). Is it possible to use the simpler `unquote()` here?  

For local file paths (e.g. without a ``file:///`` scheme), should we even be using URI parsing? Perhaps we should use proper path handling if there is no URI scheme (i.e. the user has provided a file-path).

A


---

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:feature-requests] Re: #109 Drop outdated copy of roman.py in docutils/utils

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

Yes, it's also fine for us.


---

**[feature-requests:#109] Drop outdated copy of roman.py in docutils/utils**

**Status:** open
**Group:** Default
**Created:** Fri Oct 04, 2024 09:17 AM UTC by Günter Milde
**Last Updated:** Tue Oct 15, 2024 06:46 PM UTC
**Owner:** nobody


Back in the days without pypi and pip, Docutils developers decided to ship a copy of the small auxiliary module  [roman.py](https://pypi.org/project/roman/)  with Docutils in order to allow the package to stay free of any dependencies except Python (also a pre-requisite for the proposed inclusion of Docutils into the standard library).

In the year 2024, however, depending on an external module that 

* is available on pip, 
* has no other dependencies, and 
* is maintained 
 
should not pose an obstacle to Docutils users.

Commits  [r9845] and [r9846] added and adopted an alternative implementation of Roman  numeral support but did not remove the copy of the upstream `roman.py`.

I propose to remove both, `utils/roman.py` and `utils/_roman_numeral.py` and declare a dependency on [roman](https://pypi.org/project/roman/) instead.
(Lowercase roman to int support was added in the [upstream repo commit ffc86c4](https://github.com/zopefoundation/roman/commit/ffc86c43cb58438a37b9f5791669c35b17902957) Oct 1, 2024, so we would need to work around this until a roman.py release with this fix is available.


---

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

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

[Docutils-develop] [docutils:feature-requests] #108 "title" option for the "image" directive

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

If at all, an attribute/option to-be-translated to the HTML "title" attribute would come under a different name ( maybe "tooltip"):

* Looking at its [description in the HTML standard](https://html.spec.whatwg.org/multipage/dom.html#the-title-attribute), the title attribute is misnamed. It contains "advisory information" presented as a tooltip (if at all). 
* It can easily be confused with the HTML [`<title>` element](https://html.spec.whatwg.org/multipage/semantics.html#the-title-element).
* In  Docutils, there is already a ["title" attribute](https://docutils.sourceforge.io/docs/ref/doctree.html#title-1): Used on the `<document>` element for the "metadata title" (which corresponds to the HTML `<title>` element!

In HTML, "title" is one of the common attributes, supported by (almost) all elements. Where should Docutils/rST support stop?

The LaTeX package "pdfcomment" provides a `\pdftooltip` macro that may be used for
pop-ups in PDF output. Like the HTML "title" attribute, it may be used on paragraphs, tables, footnotes references...

However, whether support for an attribute you should not rely on is a valuable addition for a lightweight markup language remains questionable, especially as for the rare use cases exist workarounds in form of CSS rules or "raw" HTML.

Commit [r9950] adds support for class values on the figure caption. Now you can write:
~~~
.. figure:: meow.png
    .. class:: tooltip

   A siamese cat.
~~~
and style the resulting  HTML5 writer output with

     figcaption.tooltip {
       display: none;
       padding: 0.5em;
       width: 20vh;
       background: lightyellow;
       }
     figure:hover figcaption.tooltip { 
       display: block; 
       position: absolute;
       }

To suppress the tooltip in PDF output, convert with 

    rst2latex --strip-elements-with-class=tooltip



---

**[feature-requests:#108] "title" option for the "image" directive**

**Status:** open
**Group:** Default
**Created:** Sun Sep 29, 2024 08:41 AM UTC by toastal
**Last Updated:** Mon Oct 14, 2024 06:46 AM UTC
**Owner:** nobody


Like `image`’s `:alt:` directive, allow `:title:` for creating titles on pointer hover. The use case here is different from alt as alt is for assistive technologies & titles are more to give a labels for images for those with pointer cursors.

Expected input

~~~
.. image:: /house.jxl
	:alt: Home
	:title: Navigate home
	:target: /

.. image:: /cat.jxl
	:alt: A Siamese cat on a chair
	:title: Chula says, “meow”
~~~

Expected HTML output

~~~
<a href="/"><img src="/house.jxl" alt="Home" title="Navigate home"></a>
<img src="/cat.jxl" alt="A Siamese cat on a chair" title="Chula says, “meow”">
~~~

~~~






---

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

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

[Docutils-develop] [docutils:feature-requests] #109 Drop outdated copy of roman.py in docutils/utils

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

OK then. 
@mandriver: Would an alternative module be OK for Debian? The roman-patch would be obsoleted either way.


---

**[feature-requests:#109] Drop outdated copy of roman.py in docutils/utils**

**Status:** open
**Group:** Default
**Created:** Fri Oct 04, 2024 09:17 AM UTC by Günter Milde
**Last Updated:** Fri Oct 04, 2024 09:37 AM UTC
**Owner:** nobody


Back in the days without pypi and pip, Docutils developers decided to ship a copy of the small auxiliary module  [roman.py](https://pypi.org/project/roman/)  with Docutils in order to allow the package to stay free of any dependencies except Python (also a pre-requisite for the proposed inclusion of Docutils into the standard library).

In the year 2024, however, depending on an external module that 

* is available on pip, 
* has no other dependencies, and 
* is maintained 
 
should not pose an obstacle to Docutils users.

Commits  [r9845] and [r9846] added and adopted an alternative implementation of Roman  numeral support but did not remove the copy of the upstream `roman.py`.

I propose to remove both, `utils/roman.py` and `utils/_roman_numeral.py` and declare a dependency on [roman](https://pypi.org/project/roman/) instead.
(Lowercase roman to int support was added in the [upstream repo commit ffc86c4](https://github.com/zopefoundation/roman/commit/ffc86c43cb58438a37b9f5791669c35b17902957) Oct 1, 2024, so we would need to work around this until a roman.py release with this fix is available.


---

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

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

[Docutils-develop] [docutils:bugs] #494 rst2odt: TypeError with --stylesheet=styles.xml

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

Thank you for report and analysis.
Could you try if the attached patch fixed the problem?


Attachments:

- [0001-ODT-writer-Fix-handling-of-.xml-stylesheets.patch](https://sourceforge.net/p/docutils/bugs/_discuss/thread/167e32f6f0/3352/attachment/0001-ODT-writer-Fix-handling-of-.xml-stylesheets.patch) (3.3 kB; text/x-patch)


---

**[bugs:#494] rst2odt: TypeError with --stylesheet=styles.xml**

**Status:** open
**Labels:** ODT Writer 
**Created:** Fri Oct 04, 2024 10:52 AM UTC by Paul Kishimoto
**Last Updated:** Sun Oct 13, 2024 02:14 PM UTC
**Owner:** nobody


The documentation (page “ODT Writer for Docutils”, section [“4 Styles and Classes”](https://docutils.sourceforge.io/docs/user/odt.html#styles-and-classes)) states:
> Note that with the `--stylesheet` command line option, you can use either `styles.odt` or `styles.xml`, as described below. Use of `styles.odt` is recommended over `styles.xml`.

With Python 3.12.3 and docutils 0.21.2, it appears that styles.xml is not usable, either from the command line or programmatically.

To reproduce from the command line:
1. A file `empty.rst`.
2. A file `styles.xml`, extracted from any valid ODT archive.
3. Run `$ docutils --writer=odt --stylesheet=styles.xml --traceback empty.rst >bug.odt`

The output is:
```
Traceback (most recent call last):
  File "/home/khaeru/.venv/3.12/bin/docutils", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/home/khaeru/.venv/3.12/lib/python3.12/site-packages/docutils/__main__.py", line 78, in main
    publish_cmdline(reader_name=args.reader,
  File "/home/khaeru/.venv/3.12/lib/python3.12/site-packages/docutils/core.py", line 402, in publish_cmdline
    output = publisher.publish(
             ^^^^^^^^^^^^^^^^^^
  File "/home/khaeru/.venv/3.12/lib/python3.12/site-packages/docutils/core.py", line 237, in publish
    output = self.writer.write(self.document, self.destination)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/khaeru/.venv/3.12/lib/python3.12/site-packages/docutils/writers/__init__.py", line 80, in write
    self.translate()
  File "/home/khaeru/.venv/3.12/lib/python3.12/site-packages/docutils/writers/odf_odt/__init__.py", line 510, in translate
    self.visitor.retrieve_styles(self.EXTENSION)
  File "/home/khaeru/.venv/3.12/lib/python3.12/site-packages/docutils/writers/odf_odt/__init__.py", line 941, in retrieve_styles
    self.dom_stylesheetcontent = etree.fromstring(
                                 ^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/xml/etree/ElementTree.py", line 1335, in XML
    parser.feed(text)
TypeError: a bytes-like object is required, not 'NoneType'
```

The same error occurs when calling:
```python
from docutils.core import publish_string

publish_string(
    source="",
    writer_name="odt",
    settings_overrides={"stylesheet": "styles.xml"},
)
```

This seems to be a consequence of `ODFTranslator.retrieve_styles()` ([here](https://sourceforge.net/p/docutils/code/HEAD/tree/trunk/docutils/docutils/writers/odf_odt/__init__.py#l925)), wherein:

1. `s2 = None` is set.
2. If the provided path has extension `extension` (e.g. ".odt"), it is overwritten with content read from `content.xml` in the archive; **but** if the provided path has extension ".xml", it remains `None`.
3. This value is assigned to `self.str_stylesheetcontent` and then parsed with `etree.tostring()`.

Also, the parsed `self.dom_stylesheetcontent` does not appear to be used anywhere else in the module. It's not clear why it is needed.


---

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] #495 locale.Error: unsupported locale setting

[Artur S. <r2...@us...>]

I somehow missed that Silesian Polish is set for some options. After changing that I no longer experience the issue. This must have been set by KDE Plasma as ~/.config/plasma-localerc contained options with those values. But how the values ended up in the file is a mistery for me.

Thank you for help


---

**[bugs:#495] locale.Error: unsupported locale setting**

**Status:** pending-remind
**Created:** Tue Oct 08, 2024 11:34 AM UTC by Artur Stępniak
**Last Updated:** Tue Oct 15, 2024 01:51 PM UTC
**Owner:** nobody


I'm getting "locale.Error: unsupported locale setting" when running e.g. rst2man docs/man/openvpn3-log.1.rst  | groff -Tutf8 -man

Full output:
~~~
Traceback (most recent call last):
  File "/usr/bin/rst2man", line 8, in <module>
    sys.exit(rst2man())
             ^^^^^^^^^
  File "/usr/lib/python3.12/site-packages/docutils/core.py", line 760, in rst2man
    rst2something('manpage', 'Unix manual (troff)', 'user/manpage.html')
  File "/usr/lib/python3.12/site-packages/docutils/core.py", line 739, in rst2something
    locale.setlocale(locale.LC_ALL, '')
  File "/usr/lib/python3.12/locale.py", line 615, in setlocale
    return _setlocale(category, locale)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
locale.Error: unsupported locale setting
~~~

my locale setting:
~~~
locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=szl_PL.UTF-8
LC_CTYPE="szl_PL.UTF-8"
LC_NUMERIC=pl_PL.UTF-8
LC_TIME=pl_PL.UTF-8
LC_COLLATE="szl_PL.UTF-8"
LC_MONETARY=pl_PL.UTF-8
LC_MESSAGES="szl_PL.UTF-8"
LC_PAPER=pl_PL.UTF-8
LC_NAME=pl_PL.UTF-8
LC_ADDRESS=pl_PL.UTF-8
LC_TELEPHONE=pl_PL.UTF-8
LC_MEASUREMENT=pl_PL.UTF-8
LC_IDENTIFICATION=pl_PL.UTF-8
LC_ALL=
~~~


---

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] #495 locale.Error: unsupported locale setting

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

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

Thank you for the report.

The error for the `locale`  shell command: "locale: Cannot set LC_ALL to default locale: No such file or directory" shows that on your system , the locale setup for LC_ALL is missing something or invalid. It may be related to the rather uncommon locale for Silesian Polish.

OTOH, all Docutils command line tools set up the user's default locale in the way recommended in the documentation of the "locale" standard module https://docs.python.org/3/library/locale.html#locale.setlocale. The locale value is, e.g. used for formatting with certain values in the ["date" substitution directive](https://docutils.sourceforge.io/docs/ref/rst/directives.html#date).

A small web search shows, that "unsupported locale setting" is a quite common problem for Python apps (e.g. https://stackoverflow.com/questions/14547631/python-locale-error-unsupported-locale-setting). 

The best fix would be to get a stable and complet "locale" support on your system (silencing the errors from the `locale` command).
As a workaround, you may experiment with `export LC_ALL=C` or `export LC_ALL=pl_PL.UTF-8` before calling the Docutils command line tools.

OTOH, as locale settings are no core part of Docutils processing, it may be an ideo to catch the `locale.Error` report it as a warning and proceed with the Python default.




---

**[bugs:#495] locale.Error: unsupported locale setting**

**Status:** pending-remind
**Created:** Tue Oct 08, 2024 11:34 AM UTC by Artur Stępniak
**Last Updated:** Tue Oct 08, 2024 11:34 AM UTC
**Owner:** nobody


I'm getting "locale.Error: unsupported locale setting" when running e.g. rst2man docs/man/openvpn3-log.1.rst  | groff -Tutf8 -man

Full output:
~~~
Traceback (most recent call last):
  File "/usr/bin/rst2man", line 8, in <module>
    sys.exit(rst2man())
             ^^^^^^^^^
  File "/usr/lib/python3.12/site-packages/docutils/core.py", line 760, in rst2man
    rst2something('manpage', 'Unix manual (troff)', 'user/manpage.html')
  File "/usr/lib/python3.12/site-packages/docutils/core.py", line 739, in rst2something
    locale.setlocale(locale.LC_ALL, '')
  File "/usr/lib/python3.12/locale.py", line 615, in setlocale
    return _setlocale(category, locale)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
locale.Error: unsupported locale setting
~~~

my locale setting:
~~~
locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=szl_PL.UTF-8
LC_CTYPE="szl_PL.UTF-8"
LC_NUMERIC=pl_PL.UTF-8
LC_TIME=pl_PL.UTF-8
LC_COLLATE="szl_PL.UTF-8"
LC_MONETARY=pl_PL.UTF-8
LC_MESSAGES="szl_PL.UTF-8"
LC_PAPER=pl_PL.UTF-8
LC_NAME=pl_PL.UTF-8
LC_ADDRESS=pl_PL.UTF-8
LC_TELEPHONE=pl_PL.UTF-8
LC_MEASUREMENT=pl_PL.UTF-8
LC_IDENTIFICATION=pl_PL.UTF-8
LC_ALL=
~~~


---

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:feature-requests] #108 "title" option for the "image" directive

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

- **summary**: Image title directive option --> "title" option for the "image" directive



---

**[feature-requests:#108] "title" option for the "image" directive**

**Status:** open
**Group:** Default
**Created:** Sun Sep 29, 2024 08:41 AM UTC by toastal
**Last Updated:** Tue Oct 01, 2024 07:21 AM UTC
**Owner:** nobody


Like `image`’s `:alt:` directive, allow `:title:` for creating titles on pointer hover. The use case here is different from alt as alt is for assistive technologies & titles are more to give a labels for images for those with pointer cursors.

Expected input

~~~
.. image:: /house.jxl
	:alt: Home
	:title: Navigate home
	:target: /

.. image:: /cat.jxl
	:alt: A Siamese cat on a chair
	:title: Chula says, “meow”
~~~

Expected HTML output

~~~
<a href="/"><img src="/house.jxl" alt="Home" title="Navigate home"></a>
<img src="/cat.jxl" alt="A Siamese cat on a chair" title="Chula says, “meow”">
~~~

~~~






---

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

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

[Docutils-develop] [docutils:bugs] #494 rst2odt: TypeError with --stylesheet=styles.xml

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

- **labels**:  --> ODT Writer



---

**[bugs:#494] rst2odt: TypeError with --stylesheet=styles.xml**

**Status:** open
**Labels:** ODT Writer 
**Created:** Fri Oct 04, 2024 10:52 AM UTC by Paul Kishimoto
**Last Updated:** Fri Oct 04, 2024 10:52 AM UTC
**Owner:** nobody


The documentation (page “ODT Writer for Docutils”, section [“4 Styles and Classes”](https://docutils.sourceforge.io/docs/user/odt.html#styles-and-classes)) states:
> Note that with the `--stylesheet` command line option, you can use either `styles.odt` or `styles.xml`, as described below. Use of `styles.odt` is recommended over `styles.xml`.

With Python 3.12.3 and docutils 0.21.2, it appears that styles.xml is not usable, either from the command line or programmatically.

To reproduce from the command line:
1. A file `empty.rst`.
2. A file `styles.xml`, extracted from any valid ODT archive.
3. Run `$ docutils --writer=odt --stylesheet=styles.xml --traceback empty.rst >bug.odt`

The output is:
```
Traceback (most recent call last):
  File "/home/khaeru/.venv/3.12/bin/docutils", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/home/khaeru/.venv/3.12/lib/python3.12/site-packages/docutils/__main__.py", line 78, in main
    publish_cmdline(reader_name=args.reader,
  File "/home/khaeru/.venv/3.12/lib/python3.12/site-packages/docutils/core.py", line 402, in publish_cmdline
    output = publisher.publish(
             ^^^^^^^^^^^^^^^^^^
  File "/home/khaeru/.venv/3.12/lib/python3.12/site-packages/docutils/core.py", line 237, in publish
    output = self.writer.write(self.document, self.destination)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/khaeru/.venv/3.12/lib/python3.12/site-packages/docutils/writers/__init__.py", line 80, in write
    self.translate()
  File "/home/khaeru/.venv/3.12/lib/python3.12/site-packages/docutils/writers/odf_odt/__init__.py", line 510, in translate
    self.visitor.retrieve_styles(self.EXTENSION)
  File "/home/khaeru/.venv/3.12/lib/python3.12/site-packages/docutils/writers/odf_odt/__init__.py", line 941, in retrieve_styles
    self.dom_stylesheetcontent = etree.fromstring(
                                 ^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/xml/etree/ElementTree.py", line 1335, in XML
    parser.feed(text)
TypeError: a bytes-like object is required, not 'NoneType'
```

The same error occurs when calling:
```python
from docutils.core import publish_string

publish_string(
    source="",
    writer_name="odt",
    settings_overrides={"stylesheet": "styles.xml"},
)
```

This seems to be a consequence of `ODFTranslator.retrieve_styles()` ([here](https://sourceforge.net/p/docutils/code/HEAD/tree/trunk/docutils/docutils/writers/odf_odt/__init__.py#l925)), wherein:

1. `s2 = None` is set.
2. If the provided path has extension `extension` (e.g. ".odt"), it is overwritten with content read from `content.xml` in the archive; **but** if the provided path has extension ".xml", it remains `None`.
3. This value is assigned to `self.str_stylesheetcontent` and then parsed with `etree.tostring()`.

Also, the parsed `self.dom_stylesheetcontent` does not appear to be used anywhere else in the module. It's not clear why it is needed.


---

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:feature-requests] #41 Not all Node instances have the source and line attributes set

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

Since [r9949] , the rST parser also adds internal source and line attributes to
    `<compound>`, `<container>`, `<sidebar>`, `<topic>`, `<line_block>`,
    and `<line>` nodes.


---

**[feature-requests:#41] Not all Node instances have the source and line attributes set**

**Status:** open
**Group:** sandbox
**Created:** Sun Jan 12, 2014 07:21 PM UTC by Brecht Machiels
**Last Updated:** Mon Nov 13, 2023 10:35 PM UTC
**Owner:** nobody


The source and line attributes of Node elements are not set for all types of elements. For example, these attributes never get set on bulleted or enumerated list nodes. Other elements (such as literal block) don't have source set depending on the context.


---

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

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

[Docutils-develop] [docutils:bugs] #495 locale.Error: unsupported locale setting

[Artur S. <r2...@us...>]

---

**[bugs:#495] locale.Error: unsupported locale setting**

**Status:** open
**Created:** Tue Oct 08, 2024 11:34 AM UTC by Artur Stępniak
**Last Updated:** Tue Oct 08, 2024 11:34 AM UTC
**Owner:** nobody


I'm getting "locale.Error: unsupported locale setting" when running e.g. rst2man docs/man/openvpn3-log.1.rst  | groff -Tutf8 -man

Full output:
~~~
Traceback (most recent call last):
  File "/usr/bin/rst2man", line 8, in <module>
    sys.exit(rst2man())
             ^^^^^^^^^
  File "/usr/lib/python3.12/site-packages/docutils/core.py", line 760, in rst2man
    rst2something('manpage', 'Unix manual (troff)', 'user/manpage.html')
  File "/usr/lib/python3.12/site-packages/docutils/core.py", line 739, in rst2something
    locale.setlocale(locale.LC_ALL, '')
  File "/usr/lib/python3.12/locale.py", line 615, in setlocale
    return _setlocale(category, locale)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
locale.Error: unsupported locale setting
~~~

my locale setting:
~~~
locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=szl_PL.UTF-8
LC_CTYPE="szl_PL.UTF-8"
LC_NUMERIC=pl_PL.UTF-8
LC_TIME=pl_PL.UTF-8
LC_COLLATE="szl_PL.UTF-8"
LC_MONETARY=pl_PL.UTF-8
LC_MESSAGES="szl_PL.UTF-8"
LC_PAPER=pl_PL.UTF-8
LC_NAME=pl_PL.UTF-8
LC_ADDRESS=pl_PL.UTF-8
LC_TELEPHONE=pl_PL.UTF-8
LC_MEASUREMENT=pl_PL.UTF-8
LC_IDENTIFICATION=pl_PL.UTF-8
LC_ALL=
~~~


---

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:patches] #212 Simplify type hints for readers, parsers, writers modules.

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

Also the type hint `-> Any | _DefaultT` seems not to add any info over a simple `-> Any` for a function with name `get()` or `setdefault()` with a function argument named "default".


Attachments:

- [0001-Trim-down-overhead-of-type-hints-2.patch](https://sourceforge.net/p/docutils/patches/_discuss/thread/dcbb0a5e26/44c9/attachment/0001-Trim-down-overhead-of-type-hints-2.patch) (2.3 kB; text/x-patch)


---

**[patches:#212] Simplify type hints for readers, parsers, writers modules.**

**Status:** open
**Group:** None
**Created:** Fri Oct 04, 2024 10:50 AM UTC by Günter Milde
**Last Updated:** Fri Oct 04, 2024 10:50 AM UTC
**Owner:** nobody
**Attachments:**

- [0001-Trim-down-overhead-of-type-hints.patch](https://sourceforge.net/p/docutils/patches/212/attachment/0001-Trim-down-overhead-of-type-hints.patch) (12.6 kB; text/x-patch)


Commits [r9872], [r9873], and [r9874] added type hints for the
"readers", "parsers", and "writers" modules increasing their size by
42, 70, and 112 lines respectively.


The reason is the provision of the exact output value for a set of specific
input vales via the `@overload` decorator for the auxiliary functions
`get_*_class()`.

IMO, this is an overkill: the `@overload` is fine, if different types of
input values result in different types of output values 
but not for individual values of the same type that return a class that is
a subclass of a well defined abstract base class (readers.Reader,
parsers.Parser, writers.Writer) and where the set of admissible values is
not known (any 3rd party component is found, too).

My argument is, that the `get_*_class()` function is intended for use
when the component class is fetched at runtime from user configuration
(which means we only know that the return value conforms to the interface
of the abstract base class).

In cases where a statical type checker knows the `reader_name`,
`parser_name`, `writer_name` (and this matters) there is no need to use
`get_*_class()` but the calling code may directly import the component
class.

Unless there is a convincing use case, I suggest the attached patch to reverse  the changes to
the `get_*_class()` functions.





---

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:bugs] #494 rst2odt: TypeError with --stylesheet=styles.xml

[Paul K. <kh...@us...>]

---

**[bugs:#494] rst2odt: TypeError with --stylesheet=styles.xml**

**Status:** open
**Created:** Fri Oct 04, 2024 10:52 AM UTC by Paul Kishimoto
**Last Updated:** Fri Oct 04, 2024 10:52 AM UTC
**Owner:** nobody


The documentation (page “ODT Writer for Docutils”, section [“4 Styles and Classes”](https://docutils.sourceforge.io/docs/user/odt.html#styles-and-classes)) states:
> Note that with the `--stylesheet` command line option, you can use either `styles.odt` or `styles.xml`, as described below. Use of `styles.odt` is recommended over `styles.xml`.

With Python 3.12.3 and docutils 0.21.2, it appears that styles.xml is not usable, either from the command line or programmatically.

To reproduce from the command line:
1. A file `empty.rst`.
2. A file `styles.xml`, extracted from any valid ODT archive.
3. Run `$ docutils --writer=odt --stylesheet=styles.xml --traceback empty.rst >bug.odt`

The output is:
```
Traceback (most recent call last):
  File "/home/khaeru/.venv/3.12/bin/docutils", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/home/khaeru/.venv/3.12/lib/python3.12/site-packages/docutils/__main__.py", line 78, in main
    publish_cmdline(reader_name=args.reader,
  File "/home/khaeru/.venv/3.12/lib/python3.12/site-packages/docutils/core.py", line 402, in publish_cmdline
    output = publisher.publish(
             ^^^^^^^^^^^^^^^^^^
  File "/home/khaeru/.venv/3.12/lib/python3.12/site-packages/docutils/core.py", line 237, in publish
    output = self.writer.write(self.document, self.destination)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/khaeru/.venv/3.12/lib/python3.12/site-packages/docutils/writers/__init__.py", line 80, in write
    self.translate()
  File "/home/khaeru/.venv/3.12/lib/python3.12/site-packages/docutils/writers/odf_odt/__init__.py", line 510, in translate
    self.visitor.retrieve_styles(self.EXTENSION)
  File "/home/khaeru/.venv/3.12/lib/python3.12/site-packages/docutils/writers/odf_odt/__init__.py", line 941, in retrieve_styles
    self.dom_stylesheetcontent = etree.fromstring(
                                 ^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/xml/etree/ElementTree.py", line 1335, in XML
    parser.feed(text)
TypeError: a bytes-like object is required, not 'NoneType'
```

The same error occurs when calling:
```python
from docutils.core import publish_string

publish_string(
    source="",
    writer_name="odt",
    settings_overrides={"stylesheet": "styles.xml"},
)
```

This seems to be a consequence of `ODFTranslator.retrieve_styles()` ([here](https://sourceforge.net/p/docutils/code/HEAD/tree/trunk/docutils/docutils/writers/odf_odt/__init__.py#l925)), wherein:

1. `s2 = None` is set.
2. If the provided path has extension `extension` (e.g. ".odt"), it is overwritten with content read from `content.xml` in the archive; **but** if the provided path has extension ".xml", it remains `None`.
3. This value is assigned to `self.str_stylesheetcontent` and then parsed with `etree.tostring()`.

Also, the parsed `self.dom_stylesheetcontent` does not appear to be used anywhere else in the module. It's not clear why it is needed.


---

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:patches] #212 Simplify type hints for readers, parsers, writers modules.

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

---

**[patches:#212] Simplify type hints for readers, parsers, writers modules.**

**Status:** open
**Group:** None
**Created:** Fri Oct 04, 2024 10:50 AM UTC by Günter Milde
**Last Updated:** Fri Oct 04, 2024 10:50 AM UTC
**Owner:** nobody
**Attachments:**

- [0001-Trim-down-overhead-of-type-hints.patch](https://sourceforge.net/p/docutils/patches/212/attachment/0001-Trim-down-overhead-of-type-hints.patch) (12.6 kB; text/x-patch)


Commits [r9872], [r9873], and [r9874] added type hints for the
"readers", "parsers", and "writers" modules increasing their size by
42, 70, and 112 lines respectively.


The reason is the provision of the exact output value for a set of specific
input vales via the `@overload` decorator for the auxiliary functions
`get_*_class()`.

IMO, this is an overkill: the `@overload` is fine, if different types of
input values result in different types of output values 
but not for individual values of the same type that return a class that is
a subclass of a well defined abstract base class (readers.Reader,
parsers.Parser, writers.Writer) and where the set of admissible values is
not known (any 3rd party component is found, too).

My argument is, that the `get_*_class()` function is intended for use
when the component class is fetched at runtime from user configuration
(which means we only know that the return value conforms to the interface
of the abstract base class).

In cases where a statical type checker knows the `reader_name`,
`parser_name`, `writer_name` (and this matters) there is no need to use
`get_*_class()` but the calling code may directly import the component
class.

Unless there is a convincing use case, I suggest the attached patch to reverse  the changes to
the `get_*_class()` functions.





---

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:feature-requests] #109 Drop outdated copy of roman.py in docutils/utils

[Adam T. <aa-...@us...>]

Dear Günter,

I would suggest deleting `utils/roman.py` instead (it was an oversight in my patch).

Docutils (via Sphinx) is tested on every commit to CPython, so having a third party package that we don't maintain in the 'critical path' dependency chain is unhelpful, as it means that we would either have to patch `roman` ourselves (as you propose to do now) or wait for someone else to release a fix.

`utils/_roman_numeral.py` is a small module containing well-tested code, and designed with Docutils's needs in mind. It is also more permissively licensed.

A


---

**[feature-requests:#109] Drop outdated copy of roman.py in docutils/utils**

**Status:** open
**Group:** Default
**Created:** Fri Oct 04, 2024 09:17 AM UTC by Günter Milde
**Last Updated:** Fri Oct 04, 2024 09:32 AM UTC
**Owner:** nobody


Back in the days without pypi and pip, Docutils developers decided to ship a copy of the small auxiliary module  [roman.py](https://pypi.org/project/roman/)  with Docutils in order to allow the package to stay free of any dependencies except Python (also a pre-requisite for the proposed inclusion of Docutils into the standard library).

In the year 2024, however, depending on an external module that 

* is available on pip, 
* has no other dependencies, and 
* is maintained 
 
should not pose an obstacle to Docutils users.

Commits  [r9845] and [r9846] added and adopted an alternative implementation of Roman  numeral support but did not remove the copy of the upstream `roman.py`.

I propose to remove both, `utils/roman.py` and `utils/_roman_numeral.py` and declare a dependency on [roman](https://pypi.org/project/roman/) instead.
(Lowercase roman to int support was added in the [upstream repo commit ffc86c4](https://github.com/zopefoundation/roman/commit/ffc86c43cb58438a37b9f5791669c35b17902957) Oct 1, 2024, so we would need to work around this until a roman.py release with this fix is available.


---

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

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

[Docutils-develop] [docutils:feature-requests] #109 Drop outdated copy of roman.py in docutils/utils

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

+1 from me as a Debian packager. We currently carry a patch to use system version of roman, so I will be able to drop that patch.


---

**[feature-requests:#109] Drop outdated copy of roman.py in docutils/utils**

**Status:** open
**Group:** Default
**Created:** Fri Oct 04, 2024 09:17 AM UTC by Günter Milde
**Last Updated:** Fri Oct 04, 2024 09:29 AM UTC
**Owner:** nobody


Back in the days without pypi and pip, Docutils developers decided to ship a copy of the small auxiliary module  [roman.py](https://pypi.org/project/roman/)  with Docutils in order to allow the package to stay free of any dependencies except Python (also a pre-requisite for the proposed inclusion of Docutils into the standard library).

In the year 2024, however, depending on an external module that 

* is available on pip, 
* has no other dependencies, and 
* is maintained 
 
should not pose an obstacle to Docutils users.

Commits  [r9845] and [r9846] added and adopted an alternative implementation of Roman  numeral support but did not remove the copy of the upstream `roman.py`.

I propose to remove both, `utils/roman.py` and `utils/_roman_numeral.py` and declare a dependency on [roman](https://pypi.org/project/roman/) instead.
(Lowercase roman to int support was added in the [upstream repo commit ffc86c4](https://github.com/zopefoundation/roman/commit/ffc86c43cb58438a37b9f5791669c35b17902957) Oct 1, 2024, so we would need to work around this until a roman.py release with this fix is available.


---

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

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

[Docutils-develop] [docutils:feature-requests] #109 Drop outdated copy of roman.py in docutils/utils

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

- Description has changed:

Diff:

~~~~

--- old
+++ new
@@ -1,5 +1,4 @@
 Back in the days without pypi and pip, Docutils developers decided to ship a copy of the small auxiliary module  [roman.py](https://pypi.org/project/roman/)  with Docutils in order to allow the package to stay free of any dependencies except Python (also a pre-requisite for the proposed inclusion of Docutils into the standard library).
-Commits  [r9845] and [r9846] added and adopted an alternative implementation of Roman  numeral support but did not remove the copy of the upstream `roman.py`.
 
 In the year 2024, however, depending on an external module that 
 
@@ -9,5 +8,7 @@
  
 should not pose an obstacle to Docutils users.
 
-I propose to remove both, `utils/roman.py` and `utils/_roman_numeral.py` and declare a dependency on [roman.py](https://pypi.org/project/roman/) instead.
-(Lowercase roman to int support was added in the [upstream repo commit ffc86c4] (https://github.com/zopefoundation/roman/commit/ffc86c43cb58438a37b9f5791669c35b17902957) Oct 1, 2024, so we would need to work around this until a release with this fix is available.
+Commits  [r9845] and [r9846] added and adopted an alternative implementation of Roman  numeral support but did not remove the copy of the upstream `roman.py`.
+
+I propose to remove both, `utils/roman.py` and `utils/_roman_numeral.py` and declare a dependency on [roman](https://pypi.org/project/roman/) instead.
+(Lowercase roman to int support was added in the [upstream repo commit ffc86c4](https://github.com/zopefoundation/roman/commit/ffc86c43cb58438a37b9f5791669c35b17902957) Oct 1, 2024, so we would need to work around this until a roman.py release with this fix is available.

~~~~




---

**[feature-requests:#109] Drop outdated copy of roman.py in docutils/utils**

**Status:** open
**Group:** Default
**Created:** Fri Oct 04, 2024 09:17 AM UTC by Günter Milde
**Last Updated:** Fri Oct 04, 2024 09:17 AM UTC
**Owner:** nobody


Back in the days without pypi and pip, Docutils developers decided to ship a copy of the small auxiliary module  [roman.py](https://pypi.org/project/roman/)  with Docutils in order to allow the package to stay free of any dependencies except Python (also a pre-requisite for the proposed inclusion of Docutils into the standard library).

In the year 2024, however, depending on an external module that 

* is available on pip, 
* has no other dependencies, and 
* is maintained 
 
should not pose an obstacle to Docutils users.

Commits  [r9845] and [r9846] added and adopted an alternative implementation of Roman  numeral support but did not remove the copy of the upstream `roman.py`.

I propose to remove both, `utils/roman.py` and `utils/_roman_numeral.py` and declare a dependency on [roman](https://pypi.org/project/roman/) instead.
(Lowercase roman to int support was added in the [upstream repo commit ffc86c4](https://github.com/zopefoundation/roman/commit/ffc86c43cb58438a37b9f5791669c35b17902957) Oct 1, 2024, so we would need to work around this until a roman.py release with this fix is available.


---

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

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

[Docutils-develop] [docutils:feature-requests] #109 Drop outdated copy of roman.py in docutils/utils

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

---

**[feature-requests:#109] Drop outdated copy of roman.py in docutils/utils**

**Status:** open
**Group:** Default
**Created:** Fri Oct 04, 2024 09:17 AM UTC by Günter Milde
**Last Updated:** Fri Oct 04, 2024 09:17 AM UTC
**Owner:** nobody


Back in the days without pypi and pip, Docutils developers decided to ship a copy of the small auxiliary module  [roman.py](https://pypi.org/project/roman/)  with Docutils in order to allow the package to stay free of any dependencies except Python (also a pre-requisite for the proposed inclusion of Docutils into the standard library).
Commits  [r9845] and [r9846] added and adopted an alternative implementation of Roman  numeral support but did not remove the copy of the upstream `roman.py`.

In the year 2024, however, depending on an external module that 

* is available on pip, 
* has no other dependencies, and 
* is maintained 
 
should not pose an obstacle to Docutils users.

I propose to remove both, `utils/roman.py` and `utils/_roman_numeral.py` and declare a dependency on [roman.py](https://pypi.org/project/roman/) instead.
(Lowercase roman to int support was added in the [upstream repo commit ffc86c4] (https://github.com/zopefoundation/roman/commit/ffc86c43cb58438a37b9f5791669c35b17902957) Oct 1, 2024, so we would need to work around this until a release with this fix is available.


---

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

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

[Docutils-develop] [docutils:feature-requests] #57 add vh and vw as allowable length units

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

- **status**: open --> open-fixed



---

**[feature-requests:#57] add vh and vw as allowable length units**

**Status:** open-fixed
**Group:** Default
**Created:** Fri Oct 13, 2017 09:31 AM UTC by Robin Shannon
**Last Updated:** Tue Oct 01, 2024 07:20 AM UTC
**Owner:** nobody


In css, vh and vw are percentages of the view-window. It would be nice if these were added to the allowable length units (line 225 in parsers/rst/directives/__init__.py). For non html outputs it might make sense to convert them into percentages.


---

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

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

[Docutils-develop] [docutils:feature-requests] #108 Image title directive option

[toastal <to...@us...>]

I would say the title is strictly for HTML output. In the way that touch pointers often can’t read the `title`, it is left for cursor pointer & screen readers. Thinking about it in this sense tho, I think even if the HTML attribute is called `title` the name is probably easily confused with something visible. HTML spec says to not ‘rely’ on it, but it makes a good place for Easter eggs or other flavor commentary.

For context, my existing workaround is, as you noted, using a `.. figure` & post-processing based on a specific CSS class to 1) move `<figcaption>` contents to `title`, 2) ‘unwrap’ the parent `figure` node to just leave the `<img>` behind, but this feels like a hack/abuse, especially since the flavor text isn’t meant to be visible for PDFs which the `.. figure` would show.

More info: https://html.spec.whatwg.org/multipage/dom.html#the-title-attribute


---

**[feature-requests:#108] Image title directive option**

**Status:** open
**Group:** Default
**Created:** Sun Sep 29, 2024 08:41 AM UTC by toastal
**Last Updated:** Tue Oct 01, 2024 07:00 AM UTC
**Owner:** nobody


Like `image`’s `:alt:` directive, allow `:title:` for creating titles on pointer hover. The use case here is different from alt as alt is for assistive technologies & titles are more to give a labels for images for those with pointer cursors.

Expected input

~~~
.. image:: /house.jxl
	:alt: Home
	:title: Navigate home
	:target: /

.. image:: /cat.jxl
	:alt: A Siamese cat on a chair
	:title: Chula says, “meow”
~~~

Expected HTML output

~~~
<a href="/"><img src="/house.jxl" alt="Home" title="Navigate home"></a>
<img src="/cat.jxl" alt="A Siamese cat on a chair" title="Chula says, “meow”">
~~~

~~~






---

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

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