Docutils: Documentation Utilities

On 2011-12-13, Fays Dominique wrote:

> I do not find a way to number automatically figures or tables. This
> exists in TeX, does it exists in rest?

You can enable this in the LaTeX export of "formal" tables and in the
"html4_strict" writer (in the sandbox).

However, automatic numbers are not (yet) supported in references to
figures and tables. This is in the TODO list.

Günter

"Fays Dominique" <dominique.fays@...> writes:

> I do not find a way to justify some text in reST. 
>
> Can we choose an alignment other that left / center ?

reST is for marking up the document structure. Styling (the
representation in the rendered form) is not its job.

Use the styling features of the target format, and specify the style
when rendering the document.

-- 
 \        “All opinions are not equal. Some are a very great deal more |
  `\    robust, sophisticated and well supported in logic and argument |
_o__)                                     than others.” —Douglas Adams |
Ben Finney

On 2011-12-13, Fays Dominique wrote:

> I do not find a way to justify some text in reST. 

> Can we choose an alignment other that left / center ?

Alignment in the rst source is always necessarily left -- because
indentation carries meaning.


Alignment in the output can be configured in a two-step approach:

a) Give the to-be-aligned input a class value

b) Add a styling rule to the stylesheet. (Easy for HTML/CSS, limited support
   for LaTeX.)
   
Actually, the default CSS stylesheet has pre-defined rules for the class
values "align-left", "align-center", "align-right", so giving these class
values to some object will suffice for the HTML writers. Example::

  .. class:: align-center
  
  This paragraph is center aligned.
  
There is a working example with a center-aligned line block in the
functional tests (standalone_rst_...).

Günter

On Wed, Dec 14, 2011 at 13:54, Justin Haynes <jtor14@...> wrote:
> So first off, I am way new to docutils!  I'm using sphinx to generate a
> document but I want to include data from csvs inline.
>
> For example:
>
> i want to read data from a file called surveyed.csv into a sentence that
> reads:
>
> The number of people surveyed was ___ .
>
> where the blank is the number contained in the first column of the second
> row of the csv.  if necessary, the csv can be output as a single number with
> no header or extra columns.
>
>
> I'm sure this is easy, but I'm at a loss!!

At first I was going to answer that it wasn't possible to include
external text inline. But then I thought of a way that might work, and
was pleasantly surprised when it did work. It's a bit convoluted, so
it's not surprising that you weren't able to figure out how. We'll use
the "include" directive [1]_ in conjunction with a substitution
definition [2]_ using "replace" [3]_.

.. [1] "include" directive:
http://docutils.sourceforge.net/docs/ref/rst/directives.html#including-an-external-document-fragment

.. [2] substitution definitions:
http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#substitution-definitions

.. [3] "replace" directive:
http://docutils.sourceforge.net/docs/ref/rst/directives.html#replacement-text

There's no way for "include" to extract a specific column from a CSV
file. You can specify a range of lines to include, and there are other
options (see [1]_). So you'll probably have to adjust your input
source accordingly.

Assuming that the value to include is in a file called
"number-surveyed.txt", here's how to do it in your document:

"""
.. |surveyed| replace::

   .. include:: number-surveyed.txt

The number of people surveyed was |surveyed|.
"""

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

Thanks for the quick response!

thats perfect!

my hackish workaround is

.. |surveyed| raw:: html
                      :file: surveyed.csv


where its only the single value I wanted to include.


On Wed, Dec 14, 2011 at 11:32 AM, David Goodger <goodger@...> wrote:

> On Wed, Dec 14, 2011 at 13:54, Justin Haynes <jtor14@...> wrote:
> > So first off, I am way new to docutils!  I'm using sphinx to generate a
> > document but I want to include data from csvs inline.
> >
> > For example:
> >
> > i want to read data from a file called surveyed.csv into a sentence that
> > reads:
> >
> > The number of people surveyed was ___ .
> >
> > where the blank is the number contained in the first column of the second
> > row of the csv.  if necessary, the csv can be output as a single number
> with
> > no header or extra columns.
> >
> >
> > I'm sure this is easy, but I'm at a loss!!
>
> At first I was going to answer that it wasn't possible to include
> external text inline. But then I thought of a way that might work, and
> was pleasantly surprised when it did work. It's a bit convoluted, so
> it's not surprising that you weren't able to figure out how. We'll use
> the "include" directive [1]_ in conjunction with a substitution
> definition [2]_ using "replace" [3]_.
>
> .. [1] "include" directive:
>
> http://docutils.sourceforge.net/docs/ref/rst/directives.html#including-an-external-document-fragment
>
> .. [2] substitution definitions:
>
> http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#substitution-definitions
>
> .. [3] "replace" directive:
>
> http://docutils.sourceforge.net/docs/ref/rst/directives.html#replacement-text
>
> There's no way for "include" to extract a specific column from a CSV
> file. You can specify a range of lines to include, and there are other
> options (see [1]_). So you'll probably have to adjust your input
> source accordingly.
>
> Assuming that the value to include is in a file called
> "number-surveyed.txt", here's how to do it in your document:
>
> """
> .. |surveyed| replace::
>
>   .. include:: number-surveyed.txt
>
> The number of people surveyed was |surveyed|.
> """
>
> --
> David Goodger <http://python.net/~goodger>
>

[Guenter Milde] wrote & schrieb:
>  Did you do some manual substitution?

No.



>  Does the browser title show a macron or an upper half block?

I'm trying to answer these and more questions here:
http://mbless.de/4us/typo3-oo2rest/07-docutils-bug-hunting/Docutils,%20Windows%207%2064bit,%20Encodings,%202011-12-01.pdf

Using screenshots again to avoid other sources of error.

The result files are there as well:
http://mbless.de/4us/typo3-oo2rest/07-docutils-bug-hunting/

>What happens if you set a different code page in the dos box?
>(see e.g. http://www.daniweb.com/software-development/python/threads/316301)

As stated in the PDF as well:
"""
It doesn't make sense to change the codepage of a Dosbox because then
there will be errors in other areas.

http://www.google.de/search?q=python+windows+unicode+filenames
finds this and more:

http://stackoverflow.com/questions/3789924/python-os-walk-and-japanese-filename-crash
Tenor: Changing cp doesn't work. And indeed, I can switch to Unicode,
but then next Enter closes the dosbox.

This seems to be an important page:
http://wiki.python.org/moin/PrintFails
 
Cool, it seems I can use an environment variable
"PYTHONIOENCODING=cp850:backslashreplace" while
"PYTHONIOENCODING=ascii:strict" is implicit.
"""

Martin

-- 
http://mbless.de

Hi Günter (Milde),

I think I have detangled the encoding puzzle concerning concerning
Windows and the reported error. Here is a summary of my findings:

* This works:
   import locale

Hello Günter,

I think I have detangled the encoding puzzle concerning Windows and
the reported error. Here is a summary of my findings:

Interactive Session 1 (Dosbox)
==============================
E:\kannweg>python
Python 2.7.2 (default, Jun 12 2011, 15:08:59)
 [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" 
for more information.

01 >>> import locale
02 
03 >>> locale.getlocale()
04 (None, None)
05 
06 >>> locale.getdefaultlocale()
07 ('de_DE', 'cp1252')
08 
09 >>> locale.setlocale(locale.LC_ALL,'')
10 'German_Germany.1252'
11 
12 >>> locale.getlocale()
13 ('de_DE', 'cp1252')


[01] importing locale works
[03] Initially no locale is set.
[09] http://docs.python.org/library/locale.html
""" According to POSIX, a program which has not called
setlocale(LC_ALL, '') runs using the portable 'C' locale. Calling
setlocale(LC_ALL, '') lets it use the default locale as defined by the
LANG variable..."""
[12] Now locale.getlocale() returns something != None as value

Worth noting: the default encoding is always "windows" = 'cp1252'



Interactive Session 2 (Dosbox)
==============================

01 E:\kannweg>echo "" >empty.py
02 E:\kannweg>python -i empty.py grüße
03 >>> import sys
04 >>> import locale
05 >>> locale_encoding = locale.getdefaultlocale()[1]
06 >>> locale_encoding
07 'cp1252'
08 
09 >>> sys.argv[1]
10 'gr\xfc\xdfe'
11 
12 >>> sys.argv[1].decode(locale_encoding)
13 u'gr\xfc\xdfe'
14 
15 >>> print sys.argv[1].decode(locale_encoding)
16 grüße
17 
18 >>> u'grüße'
19 u'gr\xfc\xdfe'
20 
21 >>> 'grüße'
22 'gr\x81\xe1e'
23 
24 >>> print 'grüße'
25 grüße
26 
27 >>> print u'grüße'.encode('cp850')
28 grüße
29 
30 >>> 'grüße'.decode('cp850')
31 u'gr\xfc\xdfe'
32 
33 >>> print 'grüße'.decode('cp850')
34 grüße
35 
36 >>> print sys.argv[1]
37 gr³¯e
38 
39 >>> sys.argv[1].decode('cp850')
40 u'gr\xb3\u2580e'
41 
42 >>> print sys.argv[1].decode('cp850')
43 gr³¯e
44
45 >>> sys.stdin.encoding
46 'cp850'
47
48 >>> sys.stdout.encoding
49 'cp850'


Conclusions:

[15] The commandline argument 'grüße' = sys.argv[1]
is of type 'str' and has 'cp1252' encoding (!!!)

[24,33] 'grüße' entered at the interactive prompt has
'cp850' = sys.stdin.encoding.

u'grüße' will be correct.

str('grüße') will print correctly if the encoding
of the string is == sys.stdout.encoding


Interactive Session 3 (PythonWin)
=================================

# cyrillic filename
>>> fname = u'\u043a\u0430\u0440\u0442\u0438\u043d\u0430.jpg'

# create file works
>>> file(fname,'w').close()

# open file works
>>> f1 = file(fname)
>>> f1.close()

Note: File operations (and os.listdir(upath)!) handle unicode
filenames if the filename parameter 'fname' or path name
'upath' are of type unicode.



Suspected error in test suite
=============================

# $Id: test_dependencies.py 7220 2011-11-11 10:31:48Z milde $
lines 38..39:
        record = docutils.io.FileInput(source_path=recordfile,
 encoding=sys.getfilesystemencoding())

I suspect 'sys.getfilesystemencoding()' is completely wrong here,
as it has the value "mbcs" which is somehow Pythons way
of characterizing the method that windows uses to encode FILENAMES.
It seems to me that the 'encoding' parameter is going to be
applied to the file content.


I haven't really understood the test suite yet so I can't come
up with a patch.

My very summary at the end is:
==============================
- decode commandline parameters this way:
  sys.argv[1].decode(locale.getlocale()[1] or
locale.getdefaultlocale()[1])

- working with unicode strings is great

- non unicode strings you want to print have to have
  encoding 'sys.stdout.encoding'

- to work with unicode fileNAMES several parameters
  need to be of type unicode


HTH - hoping this helps ...

Martin

-- 
http://mbless.de

[Martin Bless] wrote & schrieb:

>Hi Günter (Milde),
>
>I think I have detangled the encoding puzzle concerning concerning
>Windows and the reported error. Here is a summary of my findings:
>
>* This works:
>   import locale


Sorry, that wasn't intended to be sent.

On 2011-12-03, Martin Bless wrote:

> I think I have detangled the encoding puzzle concerning Windows and
> the reported error. Here is a summary of my findings:

> Interactive Session 1 (Dosbox)
...

> [03] Initially no locale is set.
...
> Worth noting: the default encoding is always "windows" = 'cp1252'

I suppose this depends on your general Windows settings (Language,
Encoding).


> Interactive Session 2 (Dosbox)
>==============================

> 01 E:\kannweg>echo "" >empty.py
> 02 E:\kannweg>python -i empty.py grüße

...


> 09 >>> sys.argv[1]
> 10 'gr\xfc\xdfe'
> 11 
> 12 >>> sys.argv[1].decode(locale_encoding)
> 13 u'gr\xfc\xdfe'
...
> 27 >>> print u'grüße'.encode('cp850')
> 28 grüße
...
> 36 >>> print sys.argv[1]
> 37 gr³¯e
...
> 45 >>> sys.stdin.encoding
> 46 'cp850'
> 48 >>> sys.stdout.encoding
> 49 'cp850'

So the command line is "seen" by Python as an cp1252-encoded string
even if the stdin/stdout encoding is cp850!

> Conclusions:

> [15] The commandline argument 'grüße' = sys.argv[1]
> is of type 'str' and has 'cp1252' encoding (!!!)

> str('grüße') will print correctly if the encoding
> of the string is == sys.stdout.encoding

-> decoding the command line (sys.argv) shall use
   docutils.frontend.locale_encoding and not sys.stdin.encoding!
   
> Interactive Session 3 (PythonWin)
>=================================

> # cyrillic filename
>>>> fname = u'\u043a\u0430\u0440\u0442\u0438\u043d\u0430.jpg'

> # create file works
>>>> file(fname,'w').close()

> # open file works
>>>> f1 = file(fname)
>>>> f1.close()

> Note: File operations (and os.listdir(upath)!) handle unicode
> filenames if the filename parameter 'fname' or path name
> 'upath' are of type unicode.


> Suspected error in test suite
>=============================

> # $Id: test_dependencies.py 7220 2011-11-11 10:31:48Z milde $
> lines 38..39:
>         record = docutils.io.FileInput(source_path=recordfile,
>  encoding=sys.getfilesystemencoding())

> I suspect 'sys.getfilesystemencoding()' is completely wrong here,
> as it has the value "mbcs" which is somehow Pythons way
> of characterizing the method that windows uses to encode FILENAMES.
> It seems to me that the 'encoding' parameter is going to be
> applied to the file content.

True. I will remove the `encoding=...` option. Does this solve problem?
(If not, please post the output of just running test_dependencies.py.)


> My very summary at the end is:
>==============================
> - decode commandline parameters this way:
>   sys.argv[1].decode(locale.getlocale()[1] or
> locale.getdefaultlocale()[1])

> - working with unicode strings is great

great pain as soon as you need I/O, if you have to care for Python 2 and
3 as well as several OSs with different encoding settings...

> - non unicode strings you want to print have to have
>   encoding 'sys.stdout.encoding'

This is done for error/diagnostic output.

However, converted documents shall be (and are) encoded in the encoding
specified by the "output-encoding" config setting - independent on the
target stream (be it a file, the console or a pipe to another program).


Thanks for the tests. I will change the command line decoding.

Günter

[Guenter Milde] wrote & schrieb:

>-> decoding the command line (sys.argv) shall use
>   docutils.frontend.locale_encoding and not sys.stdin.encoding!

[...]
>True. I will remove the `encoding=...` option. Does this solve problem?
>(If not, please post the output of just running test_dependencies.py.)


There is one error left in test_dependencies.py.
And one in test_heuristics_latin1.py


==============================
Docutils version used:
==============================
Revision: 7247
Author: milde
Date: Montag, 5. Dezember 2011 22:20:43
Message: argv_encoding != sys.stdin.encoding

Thanks to Martin Bless for the report and tests.
----
Modified : /trunk/docutils/docutils/core.py
Modified : /trunk/docutils/test/test_command_line.py


==============================
Test: alltests.py, Win 7 64bit
==============================

E:\kannweg>python alltests.py
Testing Docutils 0.9 [repository] with Python 2.7.2 on 2011-12-06 at
09:47:04
[...]
........................................................
======================================================================
FAIL: test_dependencies (test_dependencies.RecordDependenciesTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Repositories\docutils\test\test_dependencies.py", line 52,
in test_dependencies
    u'\u043a\u0430\u0440\u0442\u0438\u043d\u0430.jpg'])
AssertionError: Lists differ: [u'data/include.txt', u'data/r... !=
['data/include.txt', 'data/raw...

First differing element 3:
???????.jpg
\u043a\u0430\u0440\u0442\u0438\u043d\u0430.jpg

- [u'data/include.txt', u'data/raw.txt', u'some_image.png',
u'???????.jpg']
+ ['data/include.txt',
+  'data/raw.txt',
+  'some_image.png',
+  u'\u043a\u0430\u0440\u0442\u0438\u043d\u0430.jpg']

======================================================================
FAIL: test_heuristics_latin1 (test_io.InputTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Repositories\docutils\test\test_io.py", line 81, in
test_heuristics_latin1
    self.assertEqual(input.successful_encoding, 'latin-1')
AssertionError: 'cp1252' != 'latin-1'

----------------------------------------------------------------------
Ran 1176 tests in 16.232s

FAILED (failures=2)
Elapsed time: 32.541 seconds


Thank you for fixing this!

Martin

-- 
http://mbless.de

On 2011-12-06, Martin Bless wrote:
> [Guenter Milde] wrote & schrieb:

>>-> decoding the command line (sys.argv) shall use
>>   docutils.frontend.locale_encoding and not sys.stdin.encoding!

> [...]
>>True. I will remove the `encoding=...` option. Does this solve problem?
>>(If not, please post the output of just running test_dependencies.py.)


> There is one error left in test_dependencies.py.
> And one in test_heuristics_latin1.py


>==============================
> Docutils version used:
>==============================
> Revision: 7247
> Author: milde
> Date: Montag, 5. Dezember 2011 22:20:43
> Message: argv_encoding != sys.stdin.encoding

> Thanks to Martin Bless for the report and tests.
> ----
> Modified : /trunk/docutils/docutils/core.py
> Modified : /trunk/docutils/test/test_command_line.py


>==============================
> Test: alltests.py, Win 7 64bit
>==============================

> E:\kannweg>python alltests.py
> Testing Docutils 0.9 [repository] with Python 2.7.2 on 2011-12-06 at
> 09:47:04
> [...]
> ........................................................
>======================================================================
> FAIL: test_dependencies (test_dependencies.RecordDependenciesTests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "D:\Repositories\docutils\test\test_dependencies.py", line 52,
> in test_dependencies
>     u'\u043a\u0430\u0440\u0442\u0438\u043d\u0430.jpg'])
> AssertionError: Lists differ: [u'data/include.txt', u'data/r... !=
> ['data/include.txt', 'data/raw...

> First differing element 3:
> ???????.jpg
> \u043a\u0430\u0440\u0442\u0438\u043d\u0430.jpg

> - [u'data/include.txt', u'data/raw.txt', u'some_image.png',
> u'???????.jpg']
> + ['data/include.txt',
> +  'data/raw.txt',
> +  'some_image.png',
> +  u'\u043a\u0430\u0440\u0442\u0438\u043d\u0430.jpg']

I forgot an important point: The record file is generated during the
Doctutils run and stores the names of files required to generate the
output document. (See
http://docutils.sourceforge.net/docs/user/config.html#record-dependencies
) This is why its content is encoded in the file system encoding. 

In order to prevent encoding errors while writing this file but still
have some meaningful and reversible content, the encoding-error-handler
is set to xmlcharrefreplace in the DependencyList class in utils.py. The
test case needs to read the file with these settings and compare the
content to a list of unicode strings.

Does it work with the following patch?

--- test_dependencies.py	(Revision 7246)
+++ test_dependencies.py	(Arbeitskopie)
@@ -35,8 +35,10 @@
         docutils.core.publish_file(
             destination=DocutilsTestSupport.DevNull(), **settings)
         settings['settings_overrides']['record_dependencies'].close()
+        # The record file contains filenames in the local file system encoding
         record = docutils.io.FileInput(source_path=recordfile,
-                                       encoding='utf8')
+                                       encoding=sys.getfilesystemencoding(),
+                                       error_handler='xmlcharrefreplace')
         return record.read().splitlines()
 
     def test_dependencies(self):



>======================================================================
> FAIL: test_heuristics_latin1 (test_io.InputTests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "D:\Repositories\docutils\test\test_io.py", line 81, in
> test_heuristics_latin1
>     self.assertEqual(input.successful_encoding, 'latin-1')
> AssertionError: 'cp1252' != 'latin-1'

This is a false positive. The heuristics should try the locale encoding
(if it is specified) before the "last ressort" latin-1.

Fixet in Revision 7248.


Thanks

Günter

[Guenter Milde] wrote & schrieb:

>I forgot an important point: The record file is generated during the
>Doctutils run and stores the names of files required to generate the
>output document. (See
>http://docutils.sourceforge.net/docs/user/config.html#record-dependencies
>) This is why its content is encoded in the file system encoding. 

Ok, I understand the reasoning. But reality is different. Using the
right unicode filename in Python file functions is totally ok and
works as expected.

Therefore the following patch would make good code bad:

>Does it work with the following patch?
>
>--- test_dependencies.py	(Revision 7246)
>+++ test_dependencies.py	(Arbeitskopie)
>@@ -35,8 +35,10 @@
>         docutils.core.publish_file(
>             destination=DocutilsTestSupport.DevNull(), **settings)
>         settings['settings_overrides']['record_dependencies'].close()
>+        # The record file contains filenames in the local file system encoding
>         record = docutils.io.FileInput(source_path=recordfile,
>-                                       encoding='utf8')
>+                                       encoding=sys.getfilesystemencoding(),
>+                                       error_handler='xmlcharrefreplace')
>         return record.read().splitlines()
> 
>     def test_dependencies(self):

I did, I tried it, just to be sure: It doesn't resolve the error.

BTW: Yes, the other errors is gone, only one left!

I suspect, Python's name for the Windows filesystemencoding 'mbcs' ist
just an indicator.

http://de.wikipedia.org/wiki/Multibyte_Character_Set

http://docs.python.org/howto/unicode.html says:

"""
For example, Mac OS X uses UTF-8 while Windows uses a configurable
encoding; on Windows, Python uses the name “mbcs” to refer to whatever
the currently configured encoding is.
"""

The reason for the remaining error in test_dependencies.py is most
probably the the Python file functions ARE NOT call with unicode
parameters but with string parameters.

Using the cyrillic filename which is correctly shown in windows I get:

>>> import os
>>> os.listdir( '.' )
['???????.jpg']
>>> os.listdir( u'.' )
[u'\u043a\u0430\u0440\u0442\u0438\u043d\u0430.jpg']

http://docs.python.org/library/os.html

"""
os.listdir(path)

    Return a list containing the names of the entries in the directory
given by path. The list is in arbitrary order. It does not include the
special entries '.' and '..' even if they are present in the
directory.

    Availability: Unix, Windows.

    Changed in version 2.3: On Windows NT/2k/XP and Unix, if path is a
Unicode object, the result will be a list of Unicode objects.
Undecodable filenames will still be returned as string objects.
"""

Martin

-- 
http://mbless.de

On 2011-12-06, Martin Bless wrote:
> [Guenter Milde] wrote & schrieb:

>>I forgot an important point: The record file is generated during the
>>Doctutils run and stores the names of files required to generate the
>>output document. (See
>>http://docutils.sourceforge.net/docs/user/config.html#record-dependencies
>>) This is why its content is encoded in the file system encoding. 

> Ok, I understand the reasoning. But reality is different. Using the
> right unicode filename in Python file functions is totally ok and
> works as expected.

However, this record file is not (only) intended for Python. The existing
use case is the "make" utility. And to write a unicode string to a file you
need to agree on an encoding. At least on Linux, using
sys.filesystemencoding is sensible, because then the paths in the
record-file can be used by any program without re-encoding.

> Therefore the following patch would make good code bad:

We have to differentiate between the code and the test!
The patch does not change the "real" code (i.e. the behaviour of Docutils).
It only brings the test in line with that behaviour.

The "offending" test was done to make sure that bug [ 3434355 ] is fixed.
(prevent errors recording non-ASCII filenames). The failure with
non-utf8-Windows may point to a problem with the behavior or be just a
false positive.

The correct behaviour is currently discussed in the docutils-devel
list. I invite you to join the thread.


>>Does it work with the following patch?

> I did, I tried it, just to be sure: It doesn't resolve the error.

Schade. What is the actual error/traceback with this patch?

...

> I suspect, Python's name for the Windows filesystemencoding 'mbcs' ist
> just an indicator.

> http://de.wikipedia.org/wiki/Multibyte_Character_Set

> http://docs.python.org/howto/unicode.html says:

> """
> For example, Mac OS X uses UTF-8 while Windows uses a configurable
> encoding; on Windows, Python uses the name “mbcs” to refer to whatever
> the currently configured encoding is.
> """

Thanks for this information. This means that we might need a test for 
sys.getfilesystemencoding == 'mcbs' and use the locale_encoding in this case.

However, this is a change to be done in utils.py in the first place
(if the file-system-encoding is to be used for the record file).

> The reason for the remaining error in test_dependencies.py is most
> probably the the Python file functions ARE NOT call with unicode
> parameters but with string parameters.

test_dependencies.py is testing whether the dependencies are correctly
written to a "record file". This includes testing that the intended
encoding and encoding-error-handler are used.

Thanks,

Günter