- From: Victor Mote <vic@outfitr.com>
- Date: Wed, 12 May 2004 22:26:55 -0600
- To: "'XSL Editors'" <xsl-editors@w3.org>
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 Thursday, 13 May 2004 09:54:46 UTC