[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