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.

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.

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)

- 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)

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)

> 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).

Julien RIVAUD