references: <55676BAC.7010604@free.fr> <55678C62.1090601@morningstar2.co.uk>
            <556A194A.9070501@morningstar2.co.uk>
user-agent:  Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
             Icedove/38.0
mime-version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Message-ID:  <556A2446.5090004@free.fr>
Date:         Sat, 30 May 2015 22:57:42 +0200
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: "Julien RIVAUD (_FrnchFrgg_)" <frnchfrgg@FREE.FR>
Subject: Re: l3galley, margins/parshapes and cutouts
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <556A194A.9070501@morningstar2.co.uk>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Content-Transfer-Encoding: 8bit
Status: R

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.

(My goal is to write an enumerate/itemize/... environment using l3galley 
or xgalley, because when writing exams I often need to put the figure 
wherever there's room for, and wrapfig&co don't live well with lists)


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

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

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


Cheers,

Julien "_FrnchFrgg_" RIVAUD