RE: marginalia use case issues

Victor,

Thank you for your interest in XSL.

The XSL FO SG has necessarily limited to scope of XSL 1.1
in an attempt to get it out sooner rather than later.

We have added inside and outside to float for XSL 1.1, and
that might allow you to get some of what you wants, but any
further changes in this area are deemed to be beyond the scope
of XSL 1.1.

We will add further work in this area to our list of potential 
post-1.1 features, but this cannot be taken as any kind of commitment.

Paul Grosso
for the XSL FO SG 

> -----Original Message-----
> From: xsl-editors-request@w3.org 
> [mailto:xsl-editors-request@w3.org] On Behalf Of Victor Mote
> Sent: Wednesday, 12 May, 2004 23:27
> To: 'XSL Editors'
> Subject: marginalia use case issues
> 
> 
> Dear XSL Editors:
> 
> The use case I would like to discuss is pretty well 
> documented by RenderX
> here:
> http://xep.xattic.com/xep/testsuite/usecases/marginalia.pdf
> specifically, the second scenario listed there, which they describe as
> duplex marginalia. There are at least two use cases where the 
> solution that
> they propose fails, and for which I don't think the XSL-FO 
> Standard (either
> 1.0 or the 1.1 proposal) allows a solution. My comments 
> assume a lr-tb page
> orientation:
> 
> 1. The artificially-created marginalia "area" created by the maneuver
> described there will intrude into any footnotes that are in 
> the same flow.
> The desired effect is that the footnote "area" would have 
> precedence over
> the marginalia "area".
> 
> 2. Other fo:float objects, such as drop caps, may be affected by the
> clear="both" attribute that is required for the solution, 
> even though they
> are never vertically aligned (i.e. they are conceptually in different
> columnar parts of the page).
> 
> I have some proposals regarding these issues:
> 
> Predicate Issue
> ---------------
> All of the above is dependent upon the RenderX extension 
> float="inside |
> outside". I would like to propose that this extension, or something
> functionally similar be added to the standard.
> 
> #1: Footnote/Marginalia Precedence
> ----------------------------------
> The best solution that I can think of here is to add 
> "inside-indent" and
> "outside-indent" properties in all places where "start-indent" and
> "end-indent" are allowed, which would be mapped internally to either
> "start-indent" or "end-indent" depending on the 
> odd-even/right-left value of
> the page.
> 
> Another possible solution would be to allow the inline 
> progression dimension
> properties of the footnote-reference-area (and presumably the
> before-float-reference) to be manipulated as part of the creation of a
> page-master object.
> 
> There may be other solutions as well.
> 
> I realize that both float="inside | outside" and
> inside-indent/outside-indent are probably of limited use in 
> systems whose
> ipd is vertical, but I don't see that they are of any harm either. In
> general, it strikes me as being useful for "inside" and 
> "outside" concepts
> to be applied to margins and nearly anything else that deals 
> with "start",
> "end", "before" and "after" concepts. However, I do not have 
> any use cases
> in mind at the moment for such features.
> 
> I am not sure, but I think these items would be relatively easy for
> implementors to implement, at least if they already handle
> text-align="inside | outside".
> 
> #2: Other float items
> ---------------------
> The workaround allowing marginalia creates an artificial area in the
> region-body for the marginalia. Within this "column", a user 
> probably wants
> to keep each float clear of the others. In a situation, such 
> as RenderX's
> implementation, where a float can float to the inside or 
> outside (as well as
> start or end), floats must use clear="both" to get that 
> effect. The problem
> is that there may be other floats on the page, that are *not* in the
> marginalia column, but that share either a conceptual float="start" or
> float="end" because of the internal mapping that would be 
> done to get from
> float="inside" or float="outside". So, for example, if 
> marginalia floats
> float to the inside, and the main text has drop caps that 
> always float to
> the "start" side, then both of these effectively have a 
> "start" value on
> odd-numbered (recto) pages. Assuming the user has kept these 
> in different
> "columns", there is no possibility of collision between them, 
> yet the needed
> clear="both" in the marginalia floats will not allow them to both be
> intersected by a line in the inline-progression-dimension.
> 
> The best solution I have come up with so far is a "class" 
> property for the
> float object, that would allow these floats to be 
> conceptually segregated.
> Then, the "clear" property could list the class(es) that the 
> float should be
> kept clear of. Alternatively (but less flexibly), the "clear" 
> property could
> simply have an option that allowed it be clear of floats in 
> its same class,
> perhaps clear="this-class" or clear="same".
> 
> Conclusion
> ----------
> I apologize for the brevity of the above discussion, and the 
> inexactness of
> some of my terminology. It is my hope that since you probably 
> spend a lot of
> time thinking about these issues, you already know what I am 
> talking about.
> If not, and if I have not provided enough detail, please let 
> me know, and I
> will be glad to expand as needed.
> 
> BTW, thanks for your efforts on the standard. It is 
> *extremely* useful.
> Thanks also for your consideration of the above items.
> 
> Victor Mote (mailto:vic@outfitr.com)
> Enterprise Outfitters (www.outfitr.com)
> 2025 Eddington Way
> Colorado Springs, Colorado 80916
> Voice +1 (719) 622-0650, Fax +1 (720) 293-0044
> 
>

Received on Friday, 15 October 2004 20:41:53 UTC