LATEX-L Archives

Mailing list for the LaTeX3 project


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
Mailing list for the LaTeX3 project <[log in to unmask]>
Wed, 5 Dec 2007 21:46:54 +0100
Mailing list for the LaTeX3 project <[log in to unmask]>
text/plain; charset=us-ascii
Frank Mittelbach <[log in to unmask]>
text/plain (130 lines)
Hi Lars,

 > (I originally posted this last week, but mail delivery failed. 
 > Reposting via web interface.)

actually delivery seemed to have worked, at least I got both versions

 > 26 nov 2007 kl. 22.47 skrev Frank Mittelbach:
 > > anything other than my first four options (from the original mail) or only some of them ?
 > One I would expect is the ability to put the _center_ of the float area at a particular position. 
 > Since this area varies in size, it would not be a special case of (2) or
 > (3).

true. a generalization of all three would then be to allow to specify a
position o the page and a relative position within the area. Then
top/bottom/center would be cases of this.

 > >     * The ratio of t1 to t2 is fixed by the design and a float AAA can be
 > >      placed into the middle position if neither t1 nor t2 become too
 > >       small. (Downside of this kind of layout might be that the positioning of
 > >       the floats drastically varies from page to page.)
 > Also, this is the thing I would expect to use for a golden ratio positioning; by enforcing a 
 > golden ratio t1:t2, the same horizontal line will split the column and the float in parts by this 
 > ratio. (To make this work, t1 would have to include any top floats and t2
 > any bottom floats.)


 > >     * The end position of t1 is fixed (vertically) so that a middle float
 > >       always starts on the same point on a page. Further restriction then that
 > >       t2 is not getting smaller as a certain value.
 > > 
 > >     * The starting starting position of t2 is fixed so that the bottom of the
 > >       middle floats always appear on the same vertical position on the page,
 > >       again with some further restrictions to the size of t1 this time.
 > I'm not so enthusiatic about those two. Having a text block of fixed size above or below all 
 > floats seems ... kind of annoying, really; a top or bottom float should always be preferable 
 > to this.

possibly. but I can see applications of the above that make sense
(typographically and otherwise). Also don't forget that the new OR will allow
you to change "float style" mid document and eventually from the outside so
that would allow you to have fixed positions that change over time (or be used
only in a single case).

 > If you want a typographical rationale, it might be good to think about the reader's 
 > expectations when following the text. A middle float is an _interruption_ in the running text 
 > -- what you're reading continues further down in the same column -- but if there in all 
 > columns are floats whose starting or ending positions all align then it's easy to interpret 
 > these floats as being aligned to the boundary between two different texts. IOW, upon seeing
 >   ttttt ttttt ttttt ttttt
 >   ttttt ttttt ttttt ttttt
 >   ttttt ttttt ttttt ttttt
 >         BBBBB ttttt DDDDD
 >   ttttt       ttttt
 >   ttttt ttttt ttttt ttttt
 >   ttttt ttttt ttttt ttttt
 >   ttttt ttttt ttttt ttttt
 >   ttttt ttttt ttttt ttttt
 > it's easy to think that what follows the third line of the first column is the first line of the 
 > second column.

absolutely. wouldn't make much sense designwise in my eyes either. but if you
set up your float style to prevent middle floats in other column if one float
is already chosen than middle float designs may work quite well. I certainly
own a couple of books that use them successfully. And the fixed position
wouldn't require you to have the same fixed position for call columns. As it
would bean attribute of the float area i could well change for different

 > >     * An obvious extension to the above could be that there are a list of
 > >       vertical starting points to choose from and some mechanism/logic to
 > >       select one of them
 > With facilities for info in the log file explaining the choices made, I
 > presume.

stronger really. the OR is supposed to write a float placement file (in fact
it does already) which you could use to change the placements from the outside
once you get to the final stages.

for example, in my trial document (which is the user doc for the OR) it

Page: 7 (7)
    Area: b12
    Area: b11
    Area: b21

Page: 8 (8)
    Area: b12
        Float: 5 (table 5) [tab:progress]

    Area: b11
        Float: 4 (table 4) [fig:fpl]

    Area: b21

The idea is that you can move the floats from one area to another (or page)
and the algorithm would then use your settings rather than any calculated

At the moment that doesn't any longer work since I added balancing but ... :-)

 > >     * ...other ideas...
 > It might be a good idea to allow for some kind of offset to values used for ratio calculations. 
 > Some designers might want to make proportions relative to the \textheight area, whereas 
 > others prefer them relative to the \paperheight area. I suspect the preferences may even 
 > vary depending on whether the float stays in the column or sticks out into
 > the margin.

yes all good thoughts ... now it only remains to get the algorithm to deal
with middle floats ... so far it steadfasty refuses to do so, though it
recognizes them already (but then drops them :-( as I haven't gotten any page
building to go with it.