numbering paragraphs - again

A while ago I posted about paragraph numbering. What I want is to be
able to have number paragraphs like:

1. Heading.
   1.1 Sub-heading.

       1.1.1 First paragraph of stuff...

       1.1.2 Second paragraph of stuff....

   1.2 Another sub-heading.

        1.2.1 Yet more stuff...

2. Another main heading

   2.1 a paragraph that's a bit higher level than those up there.

Anyway - you get the idea.

So today I hacked a bit of css that gives me this, at least for html
output. It'll probably break in some circumstances, but it works for the
documents I'm looking at now.

 <at> include(html4css1.css)

body { counter-reset: h1 p;}

h1:not(.title) { counter-increment: h1;

rst2latex: fontenc default

rst2latex includes the following:
\usepackage[T1]{fontenc}

This gives me "fuzzy" screen output.
E.g., a serifs on a capital T
are *very* badly rendered.
I tried a couple different viewers,
including Acrobat.

1. Why is the rendering so poor? Iiuc, I see
the actual fonts are type 3, which does not
support hinting, so I'm guessing this is
the problem.

2. When so many documents are being produced
for web viewing, why is this a good default?

3. How to turn it off?

Alan Isaac

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

Re: rst2latex: fontenc default

On 2009-11-10, Alan G Isaac wrote:
> rst2latex includes the following:
> \usepackage[T1]{fontenc}

> This gives me "fuzzy" screen output.

This is a well known problem. (Even discussed in this list and
docutils-devel.)

> 1. Why is the rendering so poor? 

Most probably because bitmap fonts are used.

> 2. When so many documents are being produced
> for web viewing, why is this a good default?

* T1 is the recommended (by the LaTeX team) font encoding. (OT1 is the
  default only because of the TeX policy of no changes to the defauls,
  not even improvements/fixes.)

* The way forward would be to set a T1-encoded vector font as Docutils
  default font. This was discussed without reaching a consensus yet.

* Using the advantage of the several output options for a common source,
  documents for web viewing are besten produced with the HTML writer and
  the print version with the LaTeX writer.

* Avoid hidden problems: While the bad look will be visible at first
  glance, the text extraction problem will only be revealed once you
  search my name (or some other accented text) in a PDF document.

Re: rst2latex: fontenc default

On 11/11/2009 4:25 AM, Guenter Milde wrote:
> * The way forward would be to set a T1-encoded vector font as Docutils
>    default font. This was discussed without reaching a consensus yet.

Shouldn't the use of T1 encoding as the default
be postponed until a consensus is reached on this
(if ever)?

Right now the default output of rst2latex produces
bad looking (onscreen) PDF files.  Saying "use HTML"
for onscreen viewing is really not a response.

Cheers,
Alan Isaac

PS Thanks for the helpful summary.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

Test suite failure

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

Re: Test suite failure

Dear David,

how should we procede with this false positive in the test suite?

On 2009-11-13, Robert Anderson wrote:

Thanks for reporting.

The error below should not turn up with the 0.6 release,
could it be that you have both, the 0.6 release and a daily
snapshot or SVN repository download installed?

> quicktest.py (Docutils 0.6 [release])
> Mac OS X 10.5.6
> Python 2.5

...

> UserWarning: Module docutils was already imported from
> /Users/robertanderson/Downloads/docutils/docutils/__init__.py, but
> /Library/Python/2.5/site-packages/docutils-0.6-py2.5.egg is being added to
> sys.path

The error itself is a false positive: 

* we test error reporting for the unicode directive in an included file.

* the acutal error thrown by Python depends on the Python build, as
  Python support for "wide" Unicode characters is optional (see PEP: 261).

> test_parsers/test_rst/test_directives/test_include.py:
...
> .. include:: test_parsers/test_rst/test_directives/include10.txt
...

> -  ValueError: unichr() arg not in range(0x110000) (wide Python build)
> +  ValueError: code too large (long int too large to convert to int)

This test is deactivated in release 0.6, as it test the known bug with
source/line report in included files.

The source/line report bug is fixed for directive errors, however it
might be better not to test it with a unicode directive (due to the
Python-build-dependend error).

Günter

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Docutils-users mailing list
Docutils-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/docutils-users

Please use "Reply All" to reply to the list.

Re: Test suite failure

2009/11/16 Guenter Milde <milde <at> users.berlios.de>:
> how should we procede with this false positive in the test suite?

The problem is that the Docutils error reporting often depends on the
text generated by Python exceptions. And that text changes between
versions of Python. There is a mechanism for dealing with differences
in exceptions between versions of Python: generate a similar
exception, extract the text, and interpolate that text into the test.
See the last test in
test/test_parsers/test_rst/test_directives/test_unicode.py for an
example. We simply do the same thing here.

It's a bit of a pain to handle these cases, but limited. We should
handle such cases as required, in the same way they have been handled
in the past.

-- David

> On 2009-11-13, Robert Anderson wrote:
>
> Thanks for reporting.
>
> The error below should not turn up with the 0.6 release,
> could it be that you have both, the 0.6 release and a daily
> snapshot or SVN repository download installed?
>
>> quicktest.py (Docutils 0.6 [release])
>> Mac OS X 10.5.6
>> Python 2.5
>
> ...
>
>> UserWarning: Module docutils was already imported from
>> /Users/robertanderson/Downloads/docutils/docutils/__init__.py, but
>> /Library/Python/2.5/site-packages/docutils-0.6-py2.5.egg is being added to
>> sys.path
>
>
> The error itself is a false positive:
>
> * we test error reporting for the unicode directive in an included file.
>
> * the acutal error thrown by Python depends on the Python build, as
>  Python support for "wide" Unicode characters is optional (see PEP: 261).
>
>> test_parsers/test_rst/test_directives/test_include.py:
> ...
>> .. include:: test_parsers/test_rst/test_directives/include10.txt
> ...
>
>> -  ValueError: unichr() arg not in range(0x110000) (wide Python build)
>> +  ValueError: code too large (long int too large to convert to int)
>
>
> This test is deactivated in release 0.6, as it test the known bug with
> source/line report in included files.
>
> The source/line report bug is fixed for directive errors, however it
> might be better not to test it with a unicode directive (due to the
> Python-build-dependend error).
>
> Günter

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Docutils-users mailing list
Docutils-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/docutils-users

Please use "Reply All" to reply to the list.

Re: rst2latex: fontenc default

On 2009-11-13, Alan G Isaac wrote:
> On 11/11/2009 4:25 AM, Guenter Milde wrote:
>> * The way forward would be to set a T1-encoded vector font as Docutils
>>    default font. This was discussed without reaching a consensus yet.

> Shouldn't the use of T1 encoding as the default
> be postponed until a consensus is reached on this
> (if ever)?

No. T1 was the default in release 0.5 (indirectly via the deprecated
"ae" package). It is the recommended font setting for valid reasons
and superior in also in print.

> Right now the default output of rst2latex produces
> bad looking (onscreen) PDF files.  Saying "use HTML"
> for onscreen viewing is really not a response.

I did not propose *use HTML* as a remedy. Instead I propose to use a
suitable font. (See <http://docutils.sf.net/docs/user/config.html> for
details.)

What I said is, that as Docutils provides export to HTML, the primary use
(what we need to care for in the first instance) for LaTeX/PDF export is
hardcopies. 

That said, I agree that also on-screen viewing of generated PDFs should
give professional results "out of the box", as this is what the LaTeX
writer (and Docutils) will be measured with by "first timers".

I have a bunch of ideas on how to solve the issue, which we could discuss
in docutils-devel. As a stop-gap measure, we could consider setting
--stylesheet=mathptmx as default.

Günter

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Docutils-users mailing list
Docutils-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/docutils-users

Please use "Reply All" to reply to the list.

Re: Test suite failure

On 2009-11-16, David Goodger wrote:
> 2009/11/16 Guenter Milde <milde <at> users.berlios.de>:
>> how should we procede with this false positive in the test suite?

> The problem is that the Docutils error reporting often depends on the
> text generated by Python exceptions. And that text changes between
> versions of Python. 

In this case the text (and even the exception) varies between different
builds of the same version, but the problem (and cure) are similar.

> There is a mechanism for dealing with differences
> in exceptions between versions of Python: generate a similar
> exception, extract the text, and interpolate that text into the test.
> See the last test in
> test/test_parsers/test_rst/test_directives/test_unicode.py for an
> example. We simply do the same thing here.

Thanks for the pointer.

> It's a bit of a pain to handle these cases, but limited. We should
> handle such cases as required, in the same way they have been handled
> in the past.

However, the offending case in test_include.py tests not the unicode
directive, but error reporting for problems in included files.

* If we are going to replicate test cases for every possible reporter
  call, this should be done re-using the original test cases. Otherwise a
  lot of duplicate code needs to be maintained.

* If we agree to test a representative subset, we can concentrate on less
  fragile test cases. 

I'd prefer the second way. The attached patch does this.

Thanks,

Günter

Exec: svn 'diff' 2>&1
Dir: /home/milde/Code/Python/docutils-svn/docutils/test/test_parsers/test_rst/test_directives/

Index: include10.txt
===================================================================
--- include10.txt	(Revision 6188)
+++ include10.txt	(Arbeitskopie)
 <at>  <at>  -1,4 +1,4  <at>  <at> 
-.. |bad| unicode:: 0xFFFFFFFFF
+.. include:: <nonexistent>

 hi
 -----
Index: test_include.py
===================================================================
--- test_include.py	(Revision 6188)
+++ test_include.py	(Arbeitskopie)
 <at>  <at>  -325,25 +325,20  <at>  <at> 
 """ % utf_16_file_rel],
 #  <at>  <at>  <at>  BUG with errors reported with incorrect "source" & "line":
 ["""\
-Testing bad charent includes:
+Testing errors in included file:

 .. include:: %s
 """ % include10,
 """\
 <document source="test data">
     <paragraph>
-        Testing bad charent includes:
-    <system_message level="3" line="1" source="%s" type="ERROR">
+        Testing errors in included file:
+    <system_message level="4" line="1" source="%s" type="SEVERE">
         <paragraph>
-            Invalid character code: 0xFFFFFFFFF
-            ValueError: unichr() arg not in range(0x110000) (wide Python build)
+            Problems with "include" directive path:
+            IOError: [Errno 2] No such file or directory: '%s'.
         <literal_block xml:space="preserve">
-            unicode:: 0xFFFFFFFFF
-    <system_message level="2" line="1" source="%s" type="WARNING">
-        <paragraph>
-            Substitution definition "bad" empty or invalid.
-        <literal_block xml:space="preserve">
-            .. |bad| unicode:: 0xFFFFFFFFF
+            .. include:: <nonexistent>
     <section dupnames="hi" ids="hi">
         <title>
             hi
 <at>  <at>  -361,7 +356,7  <at>  <at> 
         <system_message backrefs="id1" level="1" line="10" source="%s" type="INFO">
             <paragraph>
                 Duplicate implicit target name: "hi".
-""" % (include10rel, include10rel, include10rel, include10rel)],
+""" % (include10rel, nonexistent_rel, include10rel, include10rel)],
 ["""\
 Include file with whitespace in the path:

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Docutils-users mailing list
Docutils-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/docutils-users

Please use "Reply All" to reply to the list.

Re: rst2latex: fontenc default

On 11/16/2009 2:52 PM, Guenter Milde wrote:
> What I said is, that as Docutils provides export to HTML, the primary use
> (what we need to care for in the first instance) for LaTeX/PDF export is
> hardcopies.

The problem with that claim is that it overlooks many ways
that LaTeX produced PDFs are used.  Two examples are:
1. for good looking math (but not intended to print), and
2. for comment exchange (via Acrobat markup)

Alan Isaac

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july