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>
Content-Type: text/plain; charset=utf-8
Message-ID:  <556B1417.3060900@morningstar2.co.uk>
Date:         Sun, 31 May 2015 15:00:55 +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:  <556A2446.5090004@free.fr>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Content-Transfer-Encoding: 8bit
Status: R

On 30/05/2015 21:57, Julien RIVAUD (_FrnchFrgg_) wrote:
> Le 30/05/2015 22:10, Joseph Wright a écrit :
> 
>> Further to this, I believe I have sorted the issues. I am happy to
>> update CTAN tomorrow with the new code: would that be helpful?
> 
> Sure, but don't feel pressed to update, I'm not severely bitten by the
> bug (I'm planning to only use margins, but wanted to see if a later
> "wrapfig"-like system, using cutouts or parshapes, would interact well.

I've sent the update to CTAN. One of the design aims for me in the
approach taken to parshape was exactly allowing wrapfig-like effects
with lists and the like. As such, this was quite an important issue to fix.
> Thinking further about what features packages would need, I currently see:
> 
> -> 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.

> -> have some kind of cumulative parshape settings (easy for a single
> paragraph, just by reading and computing sums, but harder in the general
> case:
> 
> if you do in order
> 
> \galley_set_parshape_multi:*
> \galley_set_parshape_single:*
> \galley_set_parshape_relative_multi:*
> 
> Then computing the right parshapes for later paragraph is hard IIUC
> because the parshape settings are not stored independently and rather
> read back from eTeX as needed... So until the reset done by the endofpar
> hook, you don't have access to next par settings (unless you parse the
> reset tl, which I find ugly and error prone). The good part with the
> current way is that if parshapes are touched by galley-unaware code,
> everything still works.

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.

> -> a way to setup parshapes that continue through paragraph boundaries
> (great for wrapfig-like cutouts). But maybe it is better to do that
> manually with begin/end par hooks, because the code might decide that
> the parskip accounts for a line, or other fancy stuff.

It wasn't working properly before, but the entire point of a cutout as
I've conceptualised it is that it's an arbitrary shape imposed on the
text after setting margins and measure, and that it explicitly applies
to a fixed number of lines rather than on a paragraph basis. I'd
recommend trying the now-working code! (On the business of how one
determines how many lines count, that may require some recalculation
depending on the spacing active. As you say, that seems best added to a
paragraph hook rather than trying to incorporate it into the core
mechanism.)
--
Joseph Wright