1 |
On 2010-09-30, Grant Edwards <grant.b.edwards@×××××.com> wrote: |
2 |
> On 2010-09-30, Darren Kirby <bulliver@×××××.com> wrote: |
3 |
>> On Thu, Sep 30, 2010 at 11:13 AM, Grant Edwards |
4 |
>><grant.b.edwards@×××××.com> wrote: |
5 |
>> |
6 |
>>> |
7 |
>>> I can understand that things like example code blocks or sample |
8 |
>>> command input/output blocks might need to be wide enough to require |
9 |
>>> horizontal scrolling of a browser window, but normal text paragraphs |
10 |
>>> with 160 characters per line? |
11 |
>> |
12 |
>> I'm not seeing a problem here. Sure, the lines are long but my screen |
13 |
>> is large and my resolution is high. A quick play with firefox and konq |
14 |
>> shows that the text reformats itself quite elegantly when you resize |
15 |
>> your browser window to say, 2/3 of screen width. |
16 |
> |
17 |
> I'm using firefox, and the text doesn't reformat for me. I just end |
18 |
> up with a change in the size of the horizontal scrollbar. Are you |
19 |
> sure you're looking at the same pages I was talking about? |
20 |
> |
21 |
> http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1 |
22 |
> http://www.gentoo.org/proj/en/base/embedded/handbook/?part=1&chap=2 |
23 |
|
24 |
OK, I think the problem is caused by "literal" blocks (the ones |
25 |
containing command-line examples with the light-blue background where |
26 |
nothing ever wraps). The _minimum_ line-wrap length for normal text |
27 |
paragraphs is determined by the _maximum_ line length in a literal |
28 |
block. Resizing the browser window horizontally only reformats text |
29 |
_if_ the window is wider than the longest literal block line. For |
30 |
many of the pages that requires more screen width than I, for one, |
31 |
have. |
32 |
|
33 |
IOW, for any pages with long command line examples (or program output |
34 |
examples), you end up with very unweildy text paragraphs. |
35 |
|
36 |
I'm not sure what formatting system the manual pages use (to me the |
37 |
pages look way too clean, consistent, and neat to be hand-coded). |
38 |
Using asciidoc, for example, you avoid this problem by specifying a |
39 |
maxmimum width for normal text blocks so that they won't end up being |
40 |
arbitrarily long depending on what command line examples you happen to |
41 |
have in the document. I find 40em to be a nice max width: |
42 |
|
43 |
asciidoc -a data-uri -a toc -a max-width=40em <input-file> |
44 |
|
45 |
>> I think that's a better solution than imposing some arbitrary line |
46 |
>> length on everyone no matter their screen size and resolution. |
47 |
|
48 |
No, I wouldn't want to impose an arbitrary line lenth on everybody, |
49 |
but that's exactly what we have now. The arbitrary line length that's |
50 |
imposed is (length >= max(lengths-of-lines-in-literal-blocks)). |
51 |
|
52 |
For pages without any wide literal blocks, it's not an issue, and the |
53 |
normal paragaphs reflow as they should. For most of the manual pages |
54 |
that I look at, it is an issue. |
55 |
|
56 |
I'd prefer to have the line lengths determined by the browser window, |
57 |
and that's not what we have now for much of the manual. |
58 |
|
59 |
-- |
60 |
Grant Edwards grant.b.edwards Yow! Edwin Meese made me |
61 |
at wear CORDOVANS!! |
62 |
gmail.com |