LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Mime-Version:
1.0 (Apple Message framework v624)
Content-Type:
text/plain; charset=ISO-8859-1; format=flowed
Date:
Fri, 15 Feb 2008 00:20:44 +0100
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Subject:
From:
Lars Hellström <[log in to unmask]>
In-Reply-To:
Content-Transfer-Encoding:
8bit
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments:
text/plain (256 lines)
12 feb 2008 kl. 22.21 skrev Frank Mittelbach:

> Hi Lars,
>
> in summary \inserts have been developed to
> support footnotes (for which they work reasonable enough) and 
> everything else
> was an afterthought trying to apply the methods and for documents with 
> minimal
> requirements for floats that works well enough but beyond that ...

Unrelated, but perhaps interesting: It occurred to me when reading up 
on this part of TeX that one thing the PlainTeX floats do more or less 
automatically (because they are \inserts) is that they can split. While 
this is probably not useful for figures, it could be useful for certain 
types of tables, where one on one hand does not want them to be part of 
the body text and on the other doesn't want to page-split them 
manually. Is support for something along those lines being considered 
for XOR? (I think in Plain it's just a matter of placing an \halign 
inside a float, but the LaTeX mechanisms all seem to bend the wrong way 
for this, so it would have to be done by the OR explicitly.)

>>>> (The OR is an area I haven't
>>>> fiddled around with much; I imagine there might be problems with
>>>> material and/or information being irreversibly lost when one leaves
>>>> the
>>>> OR.) Could of course be that it's still not good enough.
>>
>> If I recall it correctly, there are some things TeX throws away
>> irreversibly, but eTeX added some primitive (<something>discards, I
>> think) that lets you rebreak vertical material without loss...
>
> you comment on yourself here :-) but yes you are right there are ways 
> to
> rebreak without loss but the eTeX discards isn't really the best way 
> to do
> that (imho). in any way, that part is nicely working in xor

I suppose I was (in a talking to onself kind of way) asking about the 
current knowledge about the state of this matter -- wondering whether 
the eTeX add-on really solved everything or conversely someone had 
discovered another piece of data that was lost.

>> Monotonicity is a principle (the
>> implementation of which may prove nontrivial). However, one idea could
>> be to do the full rebreak of the page, and then compute the combined
>> height to which the columns were split; require this quantity to be a
>> monotonous function of rebreak count. (See pseudocode below.)
>
> have to study your pseudocode in more detail later tonight and think 
> about
> it. but one question generally: do you  think its behavior can be
> explained/comprehended without putting the algorithm next to you and 
> think
> very hard about what it does to your intput?

Explained/comprehended? Yes.
Predicted? Probably not.

> or say it differently: what I was asking and still struggling with is 
> an input
> method of specifyin page layout directives so that
>
>  - taking version A of a typeset document I have a clue where and how 
> to
>    place some directive to achieve a desired change?

That shouldn't be a problem in the algorithm I sketched.

>  - taking version B of a document (the one with the directive in) both 
> a
>    source and typeset output and it becomes immediately (some sort of
>    immediate anyway :-) understandable why the source compiles in this
>    manner?

When the loop stops because directives[i-1] = directives[i] (current 
set of directives end up on the current page) this shouldn't be a 
problem. (BTW, the typical case is that i=1 and directives[1] = 
directives[0] = empty, so it shouldn't be slow either, but in this 
discussion we worry about the difficult cases.) Comprehension is 
tougher when the loop stops because the column changes are no longer 
monotonous, but if this is accompanied with a warning message then I 
think it could be accepted.

> I still haven't been able to convince myself that this is possible 
> unless the
> directive acts on the "next" page or the directive is one that only
> reorganizes the page content but not add or substract from it (in 
> which case
> it could work on the "current" page). So my question is really to 
> describe an
> input method that has this property ob being understandable.
>
> here is an example why i think this is so difficult:
>
>   The AAA, BBB, CCC are floats and (A) and so on are callouts. 
> Furthermore the
> design only allows 2 floats per page. [D1] is a place where we want to 
> place a
> directive because with the default layout we end up with tree pages as 
> this:
>
>
>   AAAAAAAAA     CCCCCCCCC     xxxxxx
>   AAAAAAAAA     CCCCCCCCC
>                 CCCCCCCCC
>   xx(A)x(B)
>   xxxx(C)xx     xxxxxxxxx
>   xxxxx[D1]     xxxxxxxxx
>     xxxxxxx       xxxxxxx
>   xxxxxxxxx     xxxxxxxxx
>                 xxxxxxxxx
>   BBBBBBBBB       xxxxxxx
>   BBBBBBBBB     xxxxxxxxx
>   BBBBBBBBB     xxxxxxxxx
>
> so we put in [D1] the directive that says "allow 3 floats on current 
> page". As
> a result we end up with 2 pages like this.
>
>   AAAAAAAAA     xxxxx[D1]
>   AAAAAAAAA       xxxxxxx
>   BBBBBBBBB     xxxxxxxxx
>   BBBBBBBBB     xxxx[D2]x
>   BBBBBBBBB       xxxxxxx
>                 xxxx[D3]x
>   xx(A)x(B)     xxxxxxxxx
>   xxxx(C)xx       xxxxxxx
>                 xxxxxxxxx
>   CCCCCCCCC     xxxxxxxxx
>   CCCCCCCCC     xxxxxx
>   CCCCCCCCC

I suspect the second layout is more likely to be what the user wanted. 
It is also the layout my algorithm would choose. One gets

  directives[0] = empty
  directives[1] = [D1]
  directives[2] = empty
  directives[3] = [D1]

etc., whereas pagetotal[1] > pagetotal[2] < pagetotal[3] = 
pagetotal[1], so by nonmonotonicity we shipout pagetry[2].

> Now the problem is the directive is now on the next page so its 
> semantics need
> to be slightly adjusted from what we thought it was or we get a 
> flipflop
> layout:

I suspect that you, by insisting on that there for every directive 
should be a full explanation of what it does in all eventualities, are 
making it unnecessarily hard for yourself. There must in the system 
also be higher level rules controlling which directives are taken into 
account, and some things are better explained as part of these than as 
part of the individual directives.

> something like
>
>   D1 = allow 3 floats on the page this directive would fall if it 
> wouldn't
>        been active

This should perhaps rather have the form:

    D1 = allow 3 floats on page (class 1b directive).

Class 1 directives might be those that take effect only on a single 
page. Subclass 1b might then be "Typically the page on which the 
directive appears, but it might also be a neighbouring page if the 
directive falls close to an astable page break; in the latter case 
you'll get a warning"

> now while this may algorithmically sound, I think it would be very 
> hard  to
> comprehend what the hell is happening if I give you the final document 
> because
> it is hard to image where D1 would end up if not active and worse
> understanding how different directives interact with each other, e.g., 
> if
> there is also a need to manipulate the second page in some manner, why 
> is
> [D2] or [D3] acting on the second page but [D1] on the first ...
>
> As i said from an algorithmic perspective this is all explainable 
> behavior but
> just looking at source and result ... urg, don't you agree?

Well, there is also the log file to take into account. A warning there 
seems appropriate, but what that warning should say is perhaps less 
obvious. "Warning: Output routine directive moved off target page"?

> of course there is the possibilitiy to use the first definition of the
> directive, accept that flipflops are possible and then simply detect 
> them (and
> if they happen not use the directive but flag an error.

The main problem with "not use the directive" is that it is hard to 
tell which directive was to blame for a particular flipflop.

> would that be an acceptable approach? perhaps, ...
>
>  - it would clearly tell the user that he/she had placed the directive 
> in a
>    place that doesn't stay on "current" page if the directive is put 
> in force,
>    so hey ... move this thing

Also it might be close to what was wanted.

Remember, however, that "move this thing" might not be an option: The 
directive might be emitted from deep within the bowels of a \section or 
the like.

>  - but at least one downside is that this would happen with a fairly 
> positive
>    propability

If "fairly positive propability" means >0 then I'm with you, but if you 
rather meant >0.5 (or even >>0) then I'm more skeptical.

>    and so people would need to do a lot of good guessing where
>    things have to be placed (this is an issue for multicolumn layouts 
> not with
>    a good number of floats not so much with single column once like in 
> the
>    above example)

Not sure I follow what you say here.

> ... this is why life in 2e and 2.09 was so nice and easy, directives 
> either
> changed only look and feel (like placement of page number but not 
> galley
> content or they simply forced a new page first like number of column 
> changes
> or \clearpage ...

Isn't that just "directives act on next page", but less systematically 
(as one would expect in 2.09)?


Another matter: Number-of-floats directives may be striking, but they 
are also not very natural to put in the source of a document, so 
perhaps they belong rather in the discussion of external control.

What is more typical for internal control would be running head/foot 
control. Here one finds the phenonemon that not all directives should 
take effect for the page they are on! In changing \pagestyle so that 
the respective heights of head and foot changes, the change to the foot 
should take effect on the page of the directive, but the change to the 
head should only take effect on the page after ... kind of \firstmark 
vs. \botmark.

Lars Hellström

ATOM RSS1 RSS2