Re: markers in redesign
Peter B. West wrote: More heart-in-the-mouth stuff for me, as I have coded the pre- and post-order iterators in Node according to another interpretation, and I have just had a mad search to try to justify it. From the DOM Level 2 Traversal and Range spec glossary: document order The term document order has the same meaning as depth first, pre-order traversal, which is equivalent to the order in which the start tags occur in the text representation of the document. Ouch, I mistakenly used in-order traversal, instead of pre-order traversal. This clears up quite a few mysteries! Does spec reading cause temporary brain damage? This means if there are FOs generating nested areas with markers with the same marker-class in nested FOs, the outermost marker will be retrieved unless a isFirst() or isLast() preference kicks in. This still leaves the question: Does a block with a break-before=page or a break-after=page span two pages, or will it always be the first/last area on the page its content is rendered on? Examples fo:block id=A fo:marker marker-class=I id=m1/ fo:block id=B break-after=page fo:marker marker-class=I id=m2/ ... /fo:block /fo:block Does last-ending-within-page retrieve m1 or m2? I'd think m2. fo:block id=A break-after=page fo:marker marker-class=I id=m1/ fo:block id=B fo:marker marker-class=I id=m2/ ... /fo:block /fo:block Does last-ending-within-page retrieve m1 or m2? Probably m1, but where in the spec can I find backing for this opinion? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: markers in redesign
J.Pietschmann wrote at 3 Mar 2003 21:58:55 +0100: This still leaves the question: Does a block with a break-before=page or a break-after=page span two pages, or will it always be the first/last area on the page its content is rendered on? One page (assuming it fits within one page). 7.19.1, break-after Specifies that the first normal area generated by formatting the next formatting object, if any, shall be the first one placed in a particular context (e.g., page-area, column-area). 7.19.2, break-before Specifies that the first area generated by this formatting object shall be the first one placed in a particular context (e.g., page-area, column-area). Examples fo:block id=A fo:marker marker-class=I id=m1/ fo:block id=B break-after=page fo:marker marker-class=I id=m2/ ... /fo:block /fo:block Does last-ending-within-page retrieve m1 or m2? I'd think m2. So do I. fo:block id=A break-after=page fo:marker marker-class=I id=m1/ fo:block id=B fo:marker marker-class=I id=m2/ ... /fo:block /fo:block Does last-ending-within-page retrieve m1 or m2? Probably m1, but where in the spec can I find backing for this opinion? I think m2, since B follows A in a pre-order traversal order. 7.23.3. retrieve-position last-ending-within-page Specifies a preference for retrieving the children of an fo:marker attached to an area that is within the containing page whose is-last trait is set to true and that follows in the area tree any other similarly constrained area that is attached to an identically named fo:marker, using pre-order traversal order. Regards, Tony Graham XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3x(70)19708 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: markers in redesign
This still leaves the question: Does a block with a break-before=page or a break-after=page span two pages, or will it always be the first/last area on the page its content is rendered on? Examples fo:block id=A fo:marker marker-class=I id=m1/ fo:block id=B break-after=page fo:marker marker-class=I id=m2/ ... /fo:block /fo:block Does last-ending-within-page retrieve m1 or m2? I'd think m2. The area from block A will always be a parent of the area from block B. So surely that after block B ends then the containing block A will end. The forced break only tells us that we should force a break at that position otherwise it is the same as a normal break. fo:block id=A break-after=page fo:marker marker-class=I id=m1/ fo:block id=B fo:marker marker-class=I id=m2/ ... /fo:block /fo:block Does last-ending-within-page retrieve m1 or m2? Probably m1, but where in the spec can I find backing for this opinion? Look in 4.2.5 Stacking constraints. In the diagram case 2, A is before B. So that in your example the after edge of block A is after the after edge of block B, so m1. Keiron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: markers in redesign
Hello, I reexamined the marker problematic again. There are a few issues not yet mentioned. First some odd wording: The properties of the fo:retrieve-marker impose a hierarchy of preference on the areas of the area tree... Unfortunately, they don't define this hierarchy directly but instead define how preferences are derived from this hierarchy. Every area in the hierarchy is considered preferential to, or better than, any area below it in the hierarchy. I suppose the 'hierarchy' mentioned here is the marker preference hierarchy rather than the area tree hierarchy. Further: When comparing two areas to determine which one is better, the terms first and last refer to the pre-order traversal order of the area tree. It's hard to see what purpose the marker preference hierarchy serves, as the real definition of the preferences is still done in terms of the area tree hierarchy. The quote above shows another problem: I'm used to the term pre-order in context of binary trees, where it means that first the first/left subtree is visited, then the node itself, then the last/right subtree. Unfortunately, the area tree is hardly a binary tree. How should the term be interpreted in this context? Let's take an example: fo:block id=A fo:marker marker-class=I id=m1/ fo:block id=B fo:marker marker-class=I id=m2/ ... /fo:block /fo:block Block B is, according to my interpretation of pre-order before block A, therefore retrieving class I with first-starting-within-page would get marker 2. Also, retrieving with either last-starting-within-page or last-ending-within-page should return marker m1. A common sense approach should probably yield first-starting-within-page: m1 last-starting-within-page: m2 last-ending-within-page: m1 The last one is of course debatable, there are arguments (using a glossary example) in favor of resulting in m2. If hierarchy in Every area in the hierarchy is considered preferential to, or better than, any area below it in the hierarchy. is interpreted as area tree hierarchy, always m1 would be retrieved, because the area generated by block A has both isFirst() and isLast() and is always above the area from block B. This interpretation is a bit better than the to the letter interpretation for first-starting-within-page and last-ending-within-page but doesn't really fit well for last-starting-within-page. Another interesting example fo:block id=A fo:marker marker-class=I id=m1/ fo:block id=B break-after=page fo:marker marker-class=I id=m2/ ... /fo:block /fo:block I interpret this that the area block A creates two areas, one of the first and one zero size area on the second page. Mind you, this is not at all clear from the spec, I more or less grabbed this out of the blue. The common sense result for the first page would mean last-ending-within-page returns m2. On the second page, every retrieve-position retrieves m1, of course. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: markers in redesign
J.Pietschmann wrote: Hello, I reexamined the marker problematic again. ... When comparing two areas to determine which one is better, the terms first and last refer to the pre-order traversal order of the area tree. ... The quote above shows another problem: I'm used to the term pre-order in context of binary trees, where it means that first the first/left subtree is visited, then the node itself, then the last/right subtree. Unfortunately, the area tree is hardly a binary tree. How should the term be interpreted in this context? Let's take an example: fo:block id=A fo:marker marker-class=I id=m1/ fo:block id=B fo:marker marker-class=I id=m2/ ... /fo:block /fo:block Joerg, More heart-in-the-mouth stuff for me, as I have coded the pre- and post-order iterators in Node according to another interpretation, and I have just had a mad search to try to justify it. From the DOM Level 2 Traversal and Range spec glossary: document order The term document order has the same meaning as depth first, pre-order traversal, which is equivalent to the order in which the start tags occur in the text representation of the document. In such an ordering, A precedes B. Block B is, according to my interpretation of pre-order before block A, therefore retrieving class I with first-starting-within-page would get marker 2. Also, retrieving with either last-starting-within-page or last-ending-within-page should return marker m1. -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: markers in redesign
Hi all, I think I am getting an idea of the markers with Peter's and others points but I don't fully understand how it should work or be implemented. Anyway I have committed the code of how it might roughly work and hopefully it is correct for the containing page. It isn't that much code anyway, it is mainly a matter of getting the logic right. When we know how it definitely should work then we can adjust it if necessary. Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: markers in redesign
Keiron Liddle wrote: Hi all, I think I am getting an idea of the markers with Peter's and others points but I don't fully understand how it should work or be implemented. Anyway I have committed the code of how it might roughly work and hopefully it is correct for the containing page. It isn't that much code any-way, it is mainly a matter of getting the logic right. When we know how it definitely should work then we can adjust it if necessary. Keiron, I have a couple of notes concerning markers in my posting on alt.design integration. What helped me in coming to terms with them was considering the simple usage of dictionary headings. The static-content will be the same on every page, extracting the first and last words defined on the page. On every page, though, the result will be different. I don't have the imagination for use cases for other situations, but one can easily envisage a case where page n and page n+1 retrieve the same marker; page n from the containing-page, and page n+1 from the previous page. -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: markers in redesign
Keiron Liddle wrote: How do you jump from the first sentance to the second one. The containing page refers to the page where the marker is first formatted not where the retrieve-marker occurs. A marker generates areas after being retrieved by a retrieve-marker. The containing page is the page where the first, and indeed all areas generated by the marker after such a retrieval will occur. There is no such concept of a page where a certain FO occurs, in particular if static content is involved, which is necessarily the case if the FO is a retrieve-marker. I vote for a clarification and a re-write, the containing page is defined by the retrieved marker, the marker to retrieve is defined by the containing page. The formulation is indeed most contrived, but there is only one reasonable possibility to get out of the circle. I admit I have no really good idea how to reformulate the whole mess. BTW there are attempts on EXSLFO to muddy this issue further by allowing retrieve-marker in the normal flow... J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: markers in redesign
Keiron Liddle wrote: Keiron Liddle wrote: How do you jump from the first sentance to the second one. The containing page refers to the page where the marker is first formatted not where the retrieve-marker occurs. A marker generates areas after being retrieved by a retrieve-marker. The containing page is the page where the first, and indeed all areas generated by the marker after such a retrieval will occur. Do you mean the page where the current retrieve-marker will retrieve the current marker and add the area(s). Which we could call the current page for convenience. Yes. But really we should call it the containing page. Conceptually, the fo:marker and its children replace the invoking fo:retrieve-marker. The point of a particular fo:retrieve-marker is fixed, so the point of expansion of the retrieved fo:marker is fixed, whereas the actual fo:marker that will be retrieved is not fixed. So what happens if there is no marker on the current page but there was a marker on the previous page. This marker on the previous page generated or retruned the first area from the retrieved marker and therefore is the containing page in some context. But the marker subtree from the previous page is tranposed into the same containing page. Another point, why have this statement: A qualifying area within a page is better than any qualifying area within a preceding page, Unless it is possible that if there is no qualifying marker on the current page then it is possible to retrieve a marker from a preceding page. Yes, it is possible, but again, the qualifying marker on a previous page will be transposed to the containing page - the page whose fo:retrieve-marker started all the trouble. The rest of the above-quoted sentence, following the comma, is: ...except that areas do not have a position in the hierarchy if they are within pages that follow the containing page. In my reading, the implication is that the containing page is an absolute point of reference - the page in which the fo:retrieve-marker accurs. -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: markers in redesign
But the marker subtree from the previous page is tranposed into the same containing page. Where do you get that from, how is it transposed, I have not seen any information about this? Considering all the retrieve positions refer to areas in the containing page then these markers transposed from a previous page are not attached to areas in the containing page. Are you agreeing then that if it cannot find it on the current page it should look an the previous page and so on, or does this transposing do something else. Another point, why have this statement: A qualifying area within a page is better than any qualifying area within a preceding page, Unless it is possible that if there is no qualifying marker on the current page then it is possible to retrieve a marker from a preceding page. Yes, it is possible, but again, the qualifying marker on a previous page will be transposed to the containing page - the page whose fo:retrieve-marker started all the trouble. The rest of the above-quoted sentence, following the comma, is: ...except that areas do not have a position in the hierarchy if they are within pages that follow the containing page. In my reading, the implication is that the containing page is an absolute point of reference - the page in which the fo:retrieve-marker accurs. Yes, one of the many contradictions. I presume you mean where the fo:retrieve- marker is replaced with the retrieved marker (since it occurs on every page with that static content). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: markers in redesign
Keiron Liddle wrote: But the marker subtree from the previous page is tranposed into the same containing page. Where do you get that from, how is it transposed, I have not seen any information about this? I was thinking of 6.11.4 fo:retrieve-marker Areas: The fo:retrieve-marker does not directly generate any area. It is (conceptually) replaced by the children of the fo:marker that it retrieves. Considering all the retrieve positions refer to areas in the containing page then these markers transposed from a previous page are not attached to areas in the containing page. Are you agreeing then that if it cannot find it on the current page it should look an the previous page and so on, or does this transposing do something else. I agree. In that case, the transposition is from the fo:marker subtree on a previous page. Another point, why have this statement: A qualifying area within a page is better than any qualifying area within a preceding page, Unless it is possible that if there is no qualifying marker on the current page then it is possible to retrieve a marker from a preceding page. Yes, it is possible, but again, the qualifying marker on a previous page will be transposed to the containing page - the page whose fo:retrieve-marker started all the trouble. The rest of the above-quoted sentence, following the comma, is: ...except that areas do not have a position in the hierarchy if they are within pages that follow the containing page. In my reading, the implication is that the containing page is an absolute point of reference - the page in which the fo:retrieve-marker accurs. Yes, one of the many contradictions. I presume you mean where the fo:retrieve- marker is replaced with the retrieved marker (since it occurs on every page with that static content). Yes. It occurs on every page, but for every page the replacement fo:marker has to be recalculated. The process is particular to each fo:retrieve-marker on each page. -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: markers in redesign
J.Pietschmann wrote: Arved Sandstrom wrote: The thing that bugs me is, when there is no qualifying area in the containing page (Note to spec editors: try saying currently-formatted page), after filtering, then it becomes anarchy. It seems like user preferences based on retrieve-position lose all relevance. In other words, there is an elaborate set of definitions based on the current page, with a hierarchy defined by retrieve-position, but as soon as one establishes that there is no such qualifying area on the current page, than it's just the first qualifying area one can find, moving back in the document. Exactly. All definitions regarding retrieve-position exclusively refer to the current page. There is not a single word on what should happen if there is no matching marker on the current page but several on the previous page which are eligible. FOP picks the last, but there is absolutely nothing in the spec which backs this, and I searched thoroughly last weekend. It's a worry. I think the decision is a sensible extrapolation from the fact that, where pages are concerned, nearer is better. However, it is clearly an oversight by the editors. Has anyone written to them on this point? BTW for the page sequence retrieving scope there is a current page sequence casually mentioned but definition of the term is left to imagination, in contrast to the meticulous definition of current page. Additionally, some oddball examples for discussion and fun: fo:block fo:footnotefo:inline/fo:footnote-bodyfo:block fo:marker marker-class-name=foo/stuff/fo:block /fo:footnote-body/fo:footnote /fo:block fo:block fo:marker marker-class-name=foo/stuff /fo:block Which one is the last? Because the relevant context is the area tree, I would think that the footnote would be the last. Similarly for fo:block-container position=absolute top=10cm left=0cm width=5cm height=5cm fo:marker marker-class-name=foo/fo:blockstufffo:block /fo:block-container fo:block-container position=absolute top=0cm left=0cm width=5cm height=5cm fo:marker marker-class-name=foo/fo:blockstufffo:block /fo:block-container This one is trickier. It seems to me that the fact that out-of-line areas are defined to have no impact on the layout of normal areas might imply that such areas occupy a position in the area tree which is independent of their eventual position on the page. That aspect is determined by the particular positioning properties of the fo, independently of the normal layout flow. In that case, it would be tempting to assume that such areas are regarded as occurring in the area tree at the point of their definition. If so, then, even though the second area with top of 0cm will precede the first on the page, it follows the first in the area tree. This interpretation would help with the case in which the markers are defined in both absolutely positioned and normal areas. -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: markers in redesign
Looking at it again, I disagree. The containing page is the page containing the first area generated or returned by the children of the retrieved fo:marker. That is, the page on which the fo:retrieve-marker occurs in the static-content. This will only vary if the retrieval forces a re-layout. How do you jump from the first sentance to the second one. The containing page refers to the page where the marker is first formatted not where the retrieve-marker occurs. I vote for a clarification and a re-write, the containing page is defined by the retrieved marker, the marker to retrieve is defined by the containing page. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: markers in redesign
-Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED] Sent: February 25, 2003 9:16 PM To: [EMAIL PROTECTED] Subject: Re: markers in redesign Looking at it again, I disagree. The containing page is the page containing the first area generated or returned by the children of the retrieved fo:marker. That is, the page on which the fo:retrieve-marker occurs in the static-content. This will only vary if the retrieval forces a re-layout. How do you jump from the first sentance to the second one. The containing page refers to the page where the marker is first formatted not where the retrieve-marker occurs. That's now my opinion also, after my re-read. I made the other assumption based on the obfuscated language. I vote for a clarification and a re-write, the containing page is defined by the retrieved marker, the marker to retrieve is defined by the containing page. I think we can all agree on asking for a rewrite. :-) Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: markers in redesign
Hi, Keiron I interpret 6.11.4 as follows. Number one, the names have to match - marker-class-name and retrieve-class-name. This is straightforward. It defines qualifying areas. Number two, qualifying areas are excluded if they follow the page being formatted, regardless of retrieve-boundary. So retrieve-boundary essentially defines the backward limits. Finally, retrieve-boundary also restricts qualifying areas in the backward direction: page says that if it's not on the currently being-formatted page, it isn't up for consideration. For last-starting-within-page, is-first is clear enough I think. An FO is generating and returning areas on the containing page, and the first one is...well, the first one. :-) So it is the optimal candidate if its parent FO has qualifying markers. With reference to your [2], return to the def'n of qualifying area: name-matching, period. I assume last in this context means last geometrically, as opposed to some other last. Eg, immediately preceding as one normally reads a document. I think whoever wrote this portion (markers) made the spec too abstruse. I finally just broke my rule of adhering to the law, and considered the use cases, and decided what made sense. :-) Arved -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED] Sent: February 23, 2003 6:49 PM To: [EMAIL PROTECTED] Subject: Re: markers in redesign Hi all, Is it correct that it should look for markers on the current page and if page boundary is current page then stop there. If boundary is page-sequence then keep going backwards on each page until a marker is found or reaches the start of the page-sequence and similarly for the document boundary. I'm trying to work out exactly how the markers should work. For the first starting within page and last ending I am fine with. First including carry-over seems okay. Last starting within page is a bit confusing. A statement [1] in the spec suggests that it shouldn't really find the last starting in the page but rather find the closest node to the root in the area tree that is the last starting area. Another statement [2] seems confusing but maybe this is if it is searching previous pages. So if this was in a page then block a would be the last starting in the page. -start-- ... block id=a block id=b /block ---pos1- block id=c /block /block end--- But if there is a column break in pos1 the last starting in page will become block c as block a is not starting in that part of the area tree. If this is the case then there are two possible cases when starting an area: isfirst and other. When finishing an area there are: islast, (had) isfirst and both. This will supply enough information to add only the needed markers to the area tree. These markers can then be kept for later retrieval. [1] Every area in the hierarchy is considered preferential to, or better than, any area below it in the hierarchy. [2] If there is no such area, then the last qualifying area in the containing page is better than any other area. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: markers in redesign
Keiron Liddle wrote: Hi all, Is it correct that it should look for markers on the current page and if page boundary is current page then stop there. If boundary is page-sequence then keep going backwards on each page until a marker is found or reaches the start of the page-sequence and similarly for the document boundary. I'm trying to work out exactly how the markers should work. For the first starting within page and last ending I am fine with. First including carry-over seems okay. Last starting within page is a bit confusing. A statement [1] in the spec suggests that it shouldn't really find the last starting in the page but rather find the closest node to the root in the area tree that is the last starting area. Another statement [2] seems confusing but maybe this is if it is searching previous pages. So if this was in a page then block a would be the last starting in the page. -start-- ... block id=a block id=b /block ---pos1- block id=c /block /block end--- But if there is a column break in pos1 the last starting in page will become block c as block a is not starting in that part of the area tree. Keiron, I haven't looked at markers too closely, but I would tend to think that, in the first case, block c is the last-starting-within-page. Blocks a, b and c all qualify; they all have an is-first trait of true. So which one follows all others in the area tree, *in pre-order traversal order*? Pre-order traversal gives us a, b, c. So c follows in the area tree any other similarly constrained area. Then the column break would have no impact on the selection. It seems to me that the hierarchy is not the same as the area tree or fo tree hierarchy. It is a unique hierarchy constructed by applying the constraints on the qualifying areas. The boundary conditions impose absolute constraints - violate one and you are out. But the other conditions are not absolute, and they, along with actual page for multi-page boundaries, are used to construct the hierarchy. I think. Peter If this is the case then there are two possible cases when starting an area: isfirst and other. When finishing an area there are: islast, (had) isfirst and both. This will supply enough information to add only the needed markers to the area tree. These markers can then be kept for later retrieval. [1] Every area in the hierarchy is considered preferential to, or better than, any area below it in the hierarchy. [2] If there is no such area, then the last qualifying area in the containing page is better than any other area. -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: markers in redesign
Comments below. -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED] Sent: February 24, 2003 6:53 AM To: [EMAIL PROTECTED] Subject: Re: markers in redesign [ SNIP ] It seems to me that the hierarchy is not the same as the area tree or fo tree hierarchy. It is a unique hierarchy constructed by applying the constraints on the qualifying areas. The boundary conditions impose absolute constraints - violate one and you are out. But the other conditions are not absolute, and they, along with actual page for multi-page boundaries, are used to construct the hierarchy. Yes, that's my interpretation. Precisely so. It is tempting to confuse hierarchy for tree. But the language of the spec in regard of markers defines a different hierarchy, one which happens to map closely to the area tree, but is highly filtered. I re-assert that in the case of this particular section of the spec, we can fall back on common sense, although normally I am loath to do so (it may sound funny to hear that, but I am a professional software developer, and I'd rather follow the letter than the spirit. That approach usually assures better code, and better specs). That means to me that in this case we use the use cases in the spec to identify what makes sense. Markers are amenable to this, as opposed to reference-orientation, because the latter is an artificial concept, and several interpretations may apply. That means, to me, first, that we use the naming to identify qualifying areas. Two, we use retrieve-boundary to filter out qualifying areas. I make that distinction, because qualifying areas are defined by the naming alone. Three, we use retrieve-position coupled with area traits (and the traits are easy to establish) to figure out the best qualifier on the _current_ page. The thing that bugs me is, when there is no qualifying area in the containing page (Note to spec editors: try saying currently-formatted page), after filtering, then it becomes anarchy. It seems like user preferences based on retrieve-position lose all relevance. In other words, there is an elaborate set of definitions based on the current page, with a hierarchy defined by retrieve-position, but as soon as one establishes that there is no such qualifying area on the current page, than it's just the first qualifying area one can find, moving back in the document. Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: markers in redesign
Arved Sandstrom wrote: ... That means, to me, first, that we use the naming to identify qualifying areas. Two, we use retrieve-boundary to filter out qualifying areas. I make that distinction, because qualifying areas are defined by the naming alone. Three, we use retrieve-position coupled with area traits (and the traits are easy to establish) to figure out the best qualifier on the _current_ page. The thing that bugs me is, when there is no qualifying area in the containing page (Note to spec editors: try saying currently-formatted page), after filtering, then it becomes anarchy. It seems like user preferences based on retrieve-position lose all relevance. In other words, there is an elaborate set of definitions based on the current page, with a hierarchy defined by retrieve-position, but as soon as one establishes that there is no such qualifying area on the current page, than it's just the first qualifying area one can find, moving back in the document. I suppose that one way of looking at this is that retrieve-position is inherently this-page based, and that to try to extend the retrieve-position logic in a consistent way to, say, previous page, would add a layer of some complication. The easy solution is to declare that, if you blew it with the retrieve-position properties, all bets are off, and we go into emergency mode. -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: markers in redesign
Arved Sandstrom wrote at 24 Feb 2003 08:01:40 -0400: Comments below. -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED] Sent: February 24, 2003 6:53 AM To: [EMAIL PROTECTED] Subject: Re: markers in redesign [ SNIP ] It seems to me that the hierarchy is not the same as the area tree or fo tree hierarchy. It is a unique hierarchy constructed by applying the constraints on the qualifying areas. The boundary conditions impose absolute constraints - violate one and you are out. But the other conditions are not absolute, and they, along with actual page for multi-page boundaries, are used to construct the hierarchy. Yes, that's my interpretation. Precisely so. It is tempting to confuse hierarchy for tree. But the language of the spec in regard of markers defines a different hierarchy, one which happens to map closely to the area tree, but is highly filtered. It's not just areas. fo:wrapper 'does not generate any areas', but also 'may always have a sequence of zero or more fo:markers as its initial children.' ... The thing that bugs me is, when there is no qualifying area in the containing page (Note to spec editors: try saying currently-formatted page), after filtering, then it becomes anarchy. It seems like user I wasn't there when the spec was written, but it seems to me that 'currently-formatted page' presupposes making pages on the fly and doesn't quite describe pages that are unbounded in one or both directions (i.e. where there is only ever one page) and also doesn't describe the possible processing model of making all the pages from the fo:flow and then going back and fixing up the static content. Regards, Tony Graham XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3x(70)19708 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: markers in redesign
Comments inline. -Original Message- From: Tony Graham [mailto:[EMAIL PROTECTED] Sent: February 24, 2003 10:26 AM To: [EMAIL PROTECTED] Subject: RE: markers in redesign Arved Sandstrom wrote at 24 Feb 2003 08:01:40 -0400: Comments below. -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED] Sent: February 24, 2003 6:53 AM To: [EMAIL PROTECTED] Subject: Re: markers in redesign [ SNIP ] It seems to me that the hierarchy is not the same as the area tree or fo tree hierarchy. It is a unique hierarchy constructed by applying the constraints on the qualifying areas. The boundary conditions impose absolute constraints - violate one and you are out. But the other conditions are not absolute, and they, along with actual page for multi-page boundaries, are used to construct the hierarchy. Yes, that's my interpretation. Precisely so. It is tempting to confuse hierarchy for tree. But the language of the spec in regard of markers defines a different hierarchy, one which happens to map closely to the area tree, but is highly filtered. It's not just areas. fo:wrapper 'does not generate any areas', but also 'may always have a sequence of zero or more fo:markers as its initial children.' No, you're quite right, Tony, fo:wrapper does not generate areas. But it _returns_ areas, assuming that its children do (there are presumably some pathological cases), and those areas are what markers act on. wrapper is transparent. I may have missed your point on this. ... The thing that bugs me is, when there is no qualifying area in the containing page (Note to spec editors: try saying currently-formatted page), after filtering, then it becomes anarchy. It seems like user I wasn't there when the spec was written, but it seems to me that 'currently-formatted page' presupposes making pages on the fly and doesn't quite describe pages that are unbounded in one or both directions (i.e. where there is only ever one page) and also doesn't describe the possible processing model of making all the pages from the fo:flow and then going back and fixing up the static content. OK, you've got me here. :-) I fall into the trap of ignoring media-usage too frequently. So the point is well taken. Regarding the second point, that processing model ignores an error-if-overflow value for overflow; process a thousand pages and then only afterwards find out that you ought to have aborted with a message? Regards, Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: markers in redesign
Arved Sandstrom wrote: I assume last in this context means last geometrically, as opposed to some other last. I'd think it's the last area generated and inserted in the area tree by the parent FO of the marker, if applicable. This is of course usually the last, geometrically, for some reasonably intuitive definition of geometrically. Odd things may happen if the marker is attached to a footnode body of a footnote broken across several pages... I think whoever wrote this portion (markers) made the spec too abstruse. I finally just broke my rule of adhering to the law, and considered the use cases, and decided what made sense. :-) Heresy! :-) If we are discussing odd stuff, is it really true that the blocks in a footnote body inherit the start-indent of the block which contains the footnote? Actually, FOP does this, and I can't find anything in the spec providing for the contrary. Same applies to side floats, thereby perhaps leading to nice circularity problems... J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: markers in redesign
Arved Sandstrom wrote: The thing that bugs me is, when there is no qualifying area in the containing page (Note to spec editors: try saying currently-formatted page), after filtering, then it becomes anarchy. It seems like user preferences based on retrieve-position lose all relevance. In other words, there is an elaborate set of definitions based on the current page, with a hierarchy defined by retrieve-position, but as soon as one establishes that there is no such qualifying area on the current page, than it's just the first qualifying area one can find, moving back in the document. Exactly. All definitions regarding retrieve-position exclusively refer to the current page. There is not a single word on what should happen if there is no matching marker on the current page but several on the previous page which are eligible. FOP picks the last, but there is absolutely nothing in the spec which backs this, and I searched thoroughly last weekend. BTW for the page sequence retrieving scope there is a current page sequence casually mentioned but definition of the term is left to imagination, in contrast to the meticulous definition of current page. Additionally, some oddball examples for discussion and fun: fo:block fo:footnotefo:inline/fo:footnote-bodyfo:block fo:marker marker-class-name=foo/stuff/fo:block /fo:footnote-body/fo:footnote /fo:block fo:block fo:marker marker-class-name=foo/stuff /fo:block Which one is the last? Similarly for fo:block-container position=absolute top=10cm left=0cm width=5cm height=5cm fo:marker marker-class-name=foo/fo:blockstufffo:block /fo:block-container fo:block-container position=absolute top=0cm left=0cm width=5cm height=5cm fo:marker marker-class-name=foo/fo:blockstufffo:block /fo:block-container J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: markers in redesign
Keiron, I haven't looked at markers too closely, but I would tend to think that, in the first case, block c is the last-starting-within-page. Blocks a, b and c all qualify; they all have an is-first trait of true. So which one follows all others in the area tree, *in pre-order traversal order*? Pre-order traversal gives us a, b, c. So c follows in the area tree any other similarly constrained area. So does b and c follow a, what is the definition of follows. I agree with your reasoning but we are talking about the spec. Just that off-hand statement about every area being better than an area below. I think they need to explain the implications of what the definitions are. If you think of last-starting as sort of the opposite of first-including-carryover (which doesn't need to have an is-last), then the parent a actually comes first. But that is only wild speculation. Then the column break would have no impact on the selection. It seems to me that the hierarchy is not the same as the area tree or fo tree hierarchy. It is a unique hierarchy constructed by applying the constraints on the qualifying areas. The boundary conditions impose absolute constraints - violate one and you are out. But the other conditions are not absolute, and they, along with actual page for multi-page boundaries, are used to construct the hierarchy. I think. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: markers in redesign
Exactly. All definitions regarding retrieve-position exclusively refer to the current page. There is not a single word on what should happen if there is no matching marker on the current page but several on the previous page which are eligible. FOP picks the last, but there is absolutely nothing in the spec which backs this, and I searched thoroughly last weekend. For the current page or containing page I take it to mean like so (assuming doc or page-sequence boundary): If we are on the third page of a document and we want to retrieve a first-starting- within-page then it will look on page 3, if it finds the marker then fine. If not then there is no such area (on the current page) and it should look at page 2. Page 2 is now the containing page and it looks for a marker that is first-starting-within- page on page 2. Then page 1... Admitedly it doesn't actually say that, but I can't interpret the wording otherwise. BTW for the page sequence retrieving scope there is a current page sequence casually mentioned but definition of the term is left to imagination, in contrast to the meticulous definition of current page. Additionally, some oddball examples for discussion and fun: fo:block fo:footnotefo:inline/fo:footnote-bodyfo:block fo:marker marker-class-name=foo/stuff/fo:block /fo:footnote-body/fo:footnote /fo:block fo:block fo:marker marker-class-name=foo/stuff /fo:block Isn't the footnote in an area that is after the main-reference area and hence last. Which one is the last? Similarly for fo:block-container position=absolute top=10cm left=0cm width=5cm height=5cm fo:marker marker-class-name=foo/fo:blockstufffo:block /fo:block-container fo:block-container position=absolute top=0cm left=0cm width=5cm height=5cm fo:marker marker-class-name=foo/fo:blockstufffo:block /fo:block-container Ordering stays, regardless of where it is drawn. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: markers in redesign
I haven't looked at markers too closely, but I would tend to think that, in the first case, block c is the last-starting-within-page. Blocks a, b and c all qualify; they all have an is-first trait of true. So which one follows all others in the area tree, *in pre-order traversal order*? Pre-order traversal gives us a, b, c. So c follows in the area tree any other similarly constrained area. Then the column break would have no impact on the selection. I re-read that part and what you say makes sense now. It's all very confusing. It seems to me that the hierarchy is not the same as the area tree or fo tree hierarchy. It is a unique hierarchy constructed by applying the constraints on the qualifying areas. The boundary conditions impose absolute constraints - violate one and you are out. But the other conditions are not absolute, and they, along with actual page for multi-page boundaries, are used to construct the hierarchy. I think. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: markers in redesign
Comments below. -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED] Sent: February 24, 2003 10:59 PM To: [EMAIL PROTECTED] Subject: Re: markers in redesign Exactly. All definitions regarding retrieve-position exclusively refer to the current page. There is not a single word on what should happen if there is no matching marker on the current page but several on the previous page which are eligible. FOP picks the last, but there is absolutely nothing in the spec which backs this, and I searched thoroughly last weekend. For the current page or containing page I take it to mean like so (assuming doc or page-sequence boundary): If we are on the third page of a document and we want to retrieve a first-starting- within-page then it will look on page 3, if it finds the marker then fine. If not then there is no such area (on the current page) and it should look at page 2. Page 2 is now the containing page and it looks for a marker that is first-starting-within- page on page 2. Then page 1... Admitedly it doesn't actually say that, but I can't interpret the wording otherwise. [ SNIP ] I re-read the spec so exhaustively that my eyes are burning. :-) I think Keiron is right. Boy, it would be cool if they could rewrite that section, though. :-) Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: markers in redesign
Hi all, Is it correct that it should look for markers on the current page and if page boundary is current page then stop there. If boundary is page-sequence then keep going backwards on each page until a marker is found or reaches the start of the page-sequence and similarly for the document boundary. I'm trying to work out exactly how the markers should work. For the first starting within page and last ending I am fine with. First including carry-over seems okay. Last starting within page is a bit confusing. A statement [1] in the spec suggests that it shouldn't really find the last starting in the page but rather find the closest node to the root in the area tree that is the last starting area. Another statement [2] seems confusing but maybe this is if it is searching previous pages. So if this was in a page then block a would be the last starting in the page. -start-- ... block id=a block id=b /block ---pos1- block id=c /block /block end--- But if there is a column break in pos1 the last starting in page will become block c as block a is not starting in that part of the area tree. If this is the case then there are two possible cases when starting an area: isfirst and other. When finishing an area there are: islast, (had) isfirst and both. This will supply enough information to add only the needed markers to the area tree. These markers can then be kept for later retrieval. [1] Every area in the hierarchy is considered preferential to, or better than, any area below it in the hierarchy. [2] If there is no such area, then the last qualifying area in the containing page is better than any other area. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
markers in redesign
Hi all, Since the topic is being discussed why don't we look at implementing markers in the redesign. I'll try to do what is obvious, getting the markers from the fo, adding when adding areas and retrieving when needed. I think some areas need changing so that the layout manager type is resolved after resolving markers, for example with tables it shouldn't make any assumptions about the type of child. I don't understand the boundaries etc. so I might need some help there. Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
