User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0)
            Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
References: <55676BAC.7010604@free.fr> <55678C62.1090601@morningstar2.co.uk>   
            <556A194A.9070501@morningstar2.co.uk> <556A2446.5090004@free.fr>   
            <556B1417.3060900@morningstar2.co.uk> <556B1C0D.2020900@free.fr>
Content-Type: text/plain; charset=utf-8
Message-ID:  <556B3C70.9020106@morningstar2.co.uk>
Date:         Sun, 31 May 2015 17:53:04 +0100
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: Joseph Wright <joseph.wright@MORNINGSTAR2.CO.UK>
Subject: Re: l3galley, margins/parshapes and cutouts
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <556B1C0D.2020900@free.fr>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Content-Transfer-Encoding: 8bit
Status: R

On 31/05/2015 15:34, Julien RIVAUD (_FrnchFrgg_) wrote:
> Le 31/05/2015 16:00, Joseph Wright a écrit :
> 
>>> -> a way to read currently setup parshapes in clist form (so that it can
>>> be edited then fed back to l3galley). It would then be easier to have
>>> cutouts implemented as simple wrappers around parshapes (at least for
>>> the current paragraph).
>>
>> I don't see the requirement to read back raw parshapes. Indeed, as the
>> concept is that margins, measure and cutouts are separate concepts,
>> access to the raw parshape sounds like a bad idea! For example, if you
>> are coding a list-like structure you've no idea is some other code will
>> alter the margins or impose a cutout, so should not expect to be able to
>> set the raw parshape.
> 
> If internally parshapes/cutouts are stored so that they can be
> cumulative, then that's not needed. It was more an implementation need
> that a real interface requirement.

I'm most interested in interface use cases: implementations can and do
change, and one LaTeX3 idea is that we are very specifically *not*
giving any assurance on internals, only what we document.

> The idea is that if parshapes aren't cumulative (with a way to reset
> them if needed), then a package using parshapes to do, say hanging items
> or theorem heads would clobber a parshape previously set by a
> wrapfig-like package, unless it reads them back to add to them instead
> of wiping previous settings.

Yes, but the point is such things done by l3galley don't suffer from this.

> Some real reasons to read parshapes would be:
> 
> - ensuring that consecutive lines have the same shape (I can envision
> environments that would prefer to get a rectangular area, even if it
> means a smaller one)

You mean for example if a cutout overlaps with a block of text that
should be rectangular? Tricky, as a cutout should have some visual
'bite' into the text block. Probably if implemented this should be a
particular type of measure rather than requiring reading back the raw
\parshape.

> - querying the space some line will have (e.g., to decide if the first
> enumerate label should be on the same line as the surrounding enumerate
> item, or if we should typeset pending labels then start a new paragraph
> --- \leavevmode\par for LaTeX2e)

A query mechanism for the shape is certainly possible, as it would only
require that we have a forced setting of \parshape followed by an
e-TeX-based lookup.

> Of course, both of these could/would better be solved with other means
> (maybe carefully crafted penalties/skips for the second one, because I'm
> not sure that in a galley setting we really need to delay label
> typesetting, even if the code needs to know if the last thing we typeset
> *is* a label)

Quite true. You also need to know which line you are interested in,
which I guess is OK if it's the first line of a paragraph but unlikely
to be helpful after that.

>> I've refactored the entire area here, so there is no longer an internal
>> readback of the \parshape primitive. However, the data structures are
>> largely internal. I'd expect any higher-level interface to track the
>> settings it is requesting itself.
> 
> So you trade compatibility with legacy code ? (Currently, enumitem
> already does strange things when xgalley is loaded, but most things work
> normally).

The big picture for l3galley is controlling what goes onto the MVL. That
can only be done if all code uses the correct mechanisms. As such,
whilst l3galley will load with LaTeX2e it's quite clear that *anything*
that interacts with the galley/MVL has to be modified to use the new
code. There's a reason it's down as 'experimental': the code here cannot
be used with arbitrary LaTeX2e documents. As such, there has never been
any intention to work with anything else messing with \parshape.
--
Joseph Wright