Re: Doc: Clarify automatic beam setting (2701) (issue 6452072)

[dak]

On 2012/08/04 08:06:38, Trevor Daniels wrote:
> On 2012/08/03 09:35:47, dak wrote:

> > The obvious way would be to reorganize into fewer layers.

> No.  This is a long and complicated subsubsec

Reorganizing into fewer layers would mean reorganizing the containing
structure so that we don't already end up in a subsubsec.

> and the point
> of this issue is to improve clarity.  The best way of doing
> that is to introduce structure into the very long text.

A very long text is not suitable as a subsubsec.

> In particular we need to clearly distinguish the two methods of
> controlling automatic beaming so they can be contrasted and
> referenced.

> > That @i{} stuff is not really good: it has the wrong
> > spacing and penalties for a heading.  For example, it
> > might get separated by a page break from its following
> > text.

> This is a drawback, but not a disaster -- it might not
> happen.

A disaster waiting to happen is not a great thing.  In particular since
it will tend to happen undercover.  People are not likely to recheck all
page breaks just because they change an unrelated section some place
above.

> > It will also usually be followed by indented text
> > as opposed to normal headings.  And will probably
> > be indented itself.

> Neither it nor the following text are indented in html.
> In pdf the heading is indented, but in my view this is
> not detrimental to its purpose.

A heading indented as opposed to the following main paragraph shape?
Ugh, ugh, ugh.

> Far worse would be
> to use @unnumberedsubsubsec or @subsubheading as these
> all look identical in pdf and the intended structuring
> is lost.

> So on balance we should go with @address@hidden ..}} as the
> best of the poor choices available.

I don't see any balance at all.  It is not like anything precludes you
from using @unnumberedsubsubsec @address@hidden ...} so it is not like using
the heading commands for getting proper header distances, page breaks
and indentation precludes you from additional markups.

But again: the real issue to me seems that we are hiding a long chapter
inside of a subsubsec already.

http://codereview.appspot.com/6452072/