[PATCH 0 of 6] reStructuredText help output

Martin Geisler mg at lazybytes.net
Thu Jul 16 10:11:06 CDT 2009


FUJIWARA Katsunori <fujiwara at ascade.co.jp> writes:

> Hi, Martin.
>
> At Fri, 10 Jul 2009 13:54:31 +0200,
> Martin Geisler wrote:
>
>> * The third changeset uses the new minirst module.
>> 
>>   To see how this effects the output, please take a look at the .out
>>   files from the unit tests. You can see that this mostly changes
>>   literal blocks which are no longer indented. This is a *feature* :-)
>>   We can now decide in one place that we want our literal blocks to be
>>   indented (I suggest we indent them with 2 spaces).
>> 
>>   Also, try resizing your terminal: the text is now re-wrapped
>>   automatically. This makes it easier for translators: they no longer
>>   have to wrap at 70 or 78 characters when this is redone on output.
>
> Following terminal resizing looks good!

I'm glad you like it -- it was very simple to add after parsing the
text.

> But complete following terminal resizing seems not to be readable.
>
> For example, according to "Requirements for Japanese Text Layout" of
> W3C, the best line length for readers is around 52 (Japanese)
> characters on the paper media.
>
> # http://www.w3.org/TR/2009/NOTE-jlreq-20090604/
> # see: (note 2) of C in "2.4.2 Considerations in Designing the Kihon-hanmen"
>
> "52 (Japanese) characters" is as same as 104 English characters, so I
> think that following terminal resizing should be stopped at the most
> about 100 English characters.

I think you are right. I've seen recommendations of ~70 characters per
line in English text. With the normal 4 character margin on the left and
2 character margin to the right we are not far from that standard.

I'm fine with putting a cap at 100 characters. How does that sound?

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.


More information about the Mercurial-devel mailing list