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

This is a multi-part message in MIME format.
--===============7569789193439271999==
Content-Type: multipart/related; boundary="===============3972643344790651630=="

This is a multi-part message in MIME format.
--===============3972643344790651630==
Content-Type: multipart/alternative; boundary="===============5792799494590863047=="
MIME-Version: 1.0

--===============5792799494590863047==
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

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



---

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

**Status:** closed-fixed
**Created:** Wed Aug 07, 2024 02:25 AM UTC by Adam  Turner
**Last Updated:** Wed Jul 30, 2025 09:11 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 [email protected] 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.
--===============5792799494590863047==
MIME-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<div class="markdown_content"><ul>
<li><strong>status</strong>: open-fixed --&gt; closed-fixed</li>
</ul>
<hr/>
<p><strong><a class="alink strikethrough" href="https://sourceforge.net/p/docutils/bugs/493/">[bugs:#493]</a> Test failure on Windows with embedded images</strong></p>
<p><strong>Status:</strong> closed-fixed<br/>
<strong>Created:</strong> Wed Aug 07, 2024 02:25 AM UTC by Adam  Turner<br/>
<strong>Last Updated:</strong> Wed Jul 30, 2025 09:11 AM UTC<br/>
<strong>Owner:</strong> nobody</p>
<p>xref <a class="alink" href="https://sourceforge.net/p/docutils/code/9785/">[r9785]</a>, <a class="alink" href="https://sourceforge.net/p/docutils/code/9853/">[r9853]</a>, <a class="alink" href="https://sourceforge.net/p/docutils/code/9855/">[r9855]</a></p>
<p>Dear <a class="user-mention" href="https://sourceforge.net/u/milde/profile/">@milde</a>,</p>
<p>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.</p>
<p>I believe the following demonstrates the problem:</p>
<div class="codehilite"><pre><span></span><code><span class="gp">&gt;&gt;&gt; </span><span class="kn">import</span><span class="w"> </span><span class="nn">sys</span><span class="p">;</span> <span class="nb">print</span><span class="p">(</span><span class="n">sys</span><span class="o">.</span><span class="n">platform</span><span class="p">)</span>
<span class="go">win32</span>
<span class="gp">&gt;&gt;&gt; </span><span class="kn">import</span><span class="w"> </span><span class="nn">urllib.parse</span><span class="o">,</span><span class="w"> </span><span class="nn">urllib.request</span>
<span class="gp">&gt;&gt;&gt; </span><span class="n">urllib</span><span class="o">.</span><span class="n">request</span><span class="o">.</span><span class="n">url2pathname</span><span class="p">(</span><span class="s1">'test/data/circle-broken.svg'</span><span class="p">)</span>
<span class="go">'test\\data\\circle-broken.svg'</span>
<span class="gp">&gt;&gt;&gt; </span><span class="n">urllib</span><span class="o">.</span><span class="n">parse</span><span class="o">.</span><span class="n">unquote</span><span class="p">(</span><span class="s1">'test/data/circle-broken.svg'</span><span class="p">)</span>
<span class="go">'test/data/circle-broken.svg'</span>
</code></pre></div>

<p>Currently, we use <code>imagepath = urllib.request.url2pathname(uri_parts.path)</code>, which converts path separators to their platform-native format. On UNIX, <code>url2pathname</code> simply calls <code>unquote</code>, but on Windows it handles UNC paths (<code>\\host\path\</code>) and escaped drive letters (<code>///C|/users/</code>).</p>
<p>I don't know what led to using <code>url2pathname()</code>, as it is quite specialised (the docstring notes "not recommended for general use"). Is it possible to use the simpler <code>unquote()</code> here?  </p>
<p>For local file paths (e.g. without a <code>file:///</code> 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).</p>
<p>A</p>
<hr/>
<p>Sent from sourceforge.net because [email protected] is subscribed to <a href="https://sourceforge.net/p/docutils/bugs/">https://sourceforge.net/p/docutils/bugs/</a></p>
<p>To unsubscribe from further messages, a project admin can change settings at <a href="https://sourceforge.net/p/docutils/admin/bugs/options.">https://sourceforge.net/p/docutils/admin/bugs/options.</a>  Or, if this is a mailing list, you can unsubscribe from the mailing list.</p></div>
--===============5792799494590863047==--

--===============3972643344790651630==--


--===============7569789193439271999==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============7569789193439271999==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline