RE: [REDESIGN] Line layout manager discussion
On Tue, 2002-05-07 at 03:56, Arved Sandstrom wrote: From a practical viewpoint it makes sense to wrap the block in an inline area with the traits and treat the block normally in layout terms but it still feels uncomfortable. It also introduces a whole lot of other questions about line height, padding etc. The use of line-height for inlines is as a synonym for height; one _can_ use height but only for replaced inline-level FOs. So for an original inline, say, we'd ignore a height but use line-height instead, which more often than not is just going to inherit from the block containing it. I think this is pretty straightforward. I don't know if this is what you were getting at, though. Because I figure you're on top of this already. I was referring to the line-stacking-strategy. If it is font-height then It has the same block-progression dimension for each line-area child of a block-area. This means that if we embedd the block within a line area then the line is still the same height as other lines. So even if the block is big enough to fill a page it will be placed in a line area that has the same height as as other lines with only text. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [REDESIGN] Line layout manager discussion
Comments down under... -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: May 7, 2002 4:40 AM To: [EMAIL PROTECTED] Subject: RE: [REDESIGN] Line layout manager discussion On Tue, 2002-05-07 at 03:56, Arved Sandstrom wrote: From a practical viewpoint it makes sense to wrap the block in an inline area with the traits and treat the block normally in layout terms but it still feels uncomfortable. It also introduces a whole lot of other questions about line height, padding etc. The use of line-height for inlines is as a synonym for height; one _can_ use height but only for replaced inline-level FOs. So for an original inline, say, we'd ignore a height but use line-height instead, which more often than not is just going to inherit from the block containing it. I think this is pretty straightforward. I don't know if this is what you were getting at, though. Because I figure you're on top of this already. I was referring to the line-stacking-strategy. If it is font-height then It has the same block-progression dimension for each line-area child of a block-area. This means that if we embedd the block within a line area then the line is still the same height as other lines. So even if the block is big enough to fill a page it will be placed in a line area that has the same height as as other lines with only text. font-height has the same effect on other things also, though, where a person may have some expectation that the element has a larger size. Like external-graphic, for example. Which is why a note in Section 6.6.5 even says that one normally uses max-height (the default) or line-height for this FO. I think this is a situation that would be cause for a runtime warning, using some kind of heuristics - the user has imposed conditions on the FO that really don't go well together. Something that big they should maybe think of doing a float. But the spec itself is reasonably clear on what we can expect from font-height, I think. Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [REDESIGN] Line layout manager discussion
Keiron Liddle wrote: On Sat, 2002-05-04 at 18:07, Arved Sandstrom wrote: I couldn't tell from the SVG source what you prepared the file with. I would like to use SVG myself. There is no way I am going to handcode it, though (just as with FO). I actually wrote it by hand. I tried using an editor but gave up, instead I just edit by hand and view it using batik. In this case it was fairly easy since everything is placed in a definite position. Editing SVG with Adobe Illustrator 10 works ok (small wonder), though the licence is fairly expensive if you don't use it regularly. The drawing app in OpenOffice may have SVG export, too - I heard, but didn't check myself. Fallback: If you send me design documents in vector graphics files of (almost) any kind, I can do the SVG conversion for you. I'm in office even on most weekends so this may work ok for some time. Arnd Beissner -- Cappelino Informationstechnologie GmbH Arnd Beißner Bahnhofstr. 3, 71063 Sindelfingen, Germany Email: [EMAIL PROTECTED] Phone: +49-7031-463458 Mobile: +49-173-3016917 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
AW: [REDESIGN] Line layout manager discussion
By writing renderer code with FOP 0.20.1 I observed : A basic link fo:basic-link internal-destination=dest0link wordst/fo:basic-link arrives 3 times in the PDFrenderer asynchronously, without any connection between each other. 1. as word link 2. as word words 3. as annotation rectangle This is OK with PDF. But there is an assumption on the operation of the output device. Other document formats: link rendering needs access to all related data. How about FOP extensions, new versions of xsl:fo? Deep area tree, linear sequential representation, semantics - I cannot tell. It has to be device independent. Fetching info randomly from the area tree? Some document formats need a list of fonts used at the beginning of the document or each page. Can the renderer retrieve this info from the the area tree in advance? Elimination of intermediate storage makes renderer programming straight forward. Hansuli Anderegg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [REDESIGN] Line layout manager discussion
Hi All, What it boils down to seems to be if the inline fo returns the block area or generates an inline area that contains the block area. If it generates an inline area then it will set traits on that area (border, background, link, padding etc.). If that is the case why is a footnote inline not allowed to have a block level child. Since this is effectively the same as using an inline-container. Here is another confusing statement, that makes sense for inline-container. 4.6 The dimensions of the content-rectangle for an inline-area without children is computed as specified by the generating formatting object, as are those of an inline-area with block-area children. Does computed as specified mean specified on the fo or derived from the context. From a practical viewpoint it makes sense to wrap the block in an inline area with the traits and treat the block normally in layout terms but it still feels uncomfortable. It also introduces a whole lot of other questions about line height, padding etc. Keiron. On Mon, 2002-05-06 at 03:52, Peter B. West wrote: Arved, Again, I agree that, in the conceptual area tree described in the spec, blocks embedded in inline-area generating FOs in the fo tree (e.g., fo:inline and fo:basic-link), themselves embedded in a parent fo:block, do not bubble up to the same level as the parent fo:block. Going back to your diagram, I am talking about the fo:block embedded in the basic-link. I have attached another diagram describing a subset of your original example. Let me clarify what I meant by the term bubble up in the reply to Karen. Then what seems to me to be the *intention* that layout within fo:inline and fo:basic-link proceed as though these wrappers were layout-transparent, would be made clear. That is, blocks bubbling up from below will be stacked in the BPDir without IPDir attachments from surrounding inline-areas. This refers to the spec's conceptual area tree. It arises out of my misapprehension that the nesting of fo:blocks within inline-area generators would involve a nesting of the layout within the generated inline-area. The fo:inline inline-area in the area tree would grow within the bounds of the containing line-area and block area, but limited by it. It doesn't work that way, though, as we have all discussed. These block areas bubble-up, not in terms of their containment within the appropriate set of line-area-inline-area-block-area, bu in terms of their layout consequences. Apart from any layout-altering properties defined on the containing inline-area generator, e.g.font or border changes, the text and any nested blocks are treated for layout as though they had occurred as direct children of the outer fo:block. That's what the term layout-transparent means. That, at least, is what I take the *intention* of the authors to be. And that is why I want to see some clarification of the relationship between 4.7.2 Line-building and 4.7.3 Inline-building. It seems to me that the spec decrees that the initial text of the basic-link (In basic-link in my example) is constructed into an inline-area by the Inline-building process of 4.7.3. In order to do this, it has to know about the constraints that it inherits from the already partially constructed line-area which contains Text in block . It seems to me that, conceptually at least, in the conceptual area tree model of the spec, the inline-building process needs to take account of all of the glyph substitution, insertion and deletion considerations that apply to 4.7.2, because it is now the responsibility of the inline-area generator to generate a *single* inline-area to complete the pending line-area of the parent. To do that, it will have to be able to do its own line-breaking. Clarifying this is a matter of the coherence and consistency of the spec. It is also important if you are tempted, as I am, by the idea of mimicking this conceptual model and procedure in actual code. All of the above may just mean that, while I thought I had been brought around to your way of thinking on this aspect of the spec, I may still be thinking about it very differently. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [REDESIGN] Line layout manager discussion
Interleaved commentary... -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: May 6, 2002 5:21 AM To: [EMAIL PROTECTED] Subject: Re: [REDESIGN] Line layout manager discussion Hi All, What it boils down to seems to be if the inline fo returns the block area or generates an inline area that contains the block area. If it generates an inline area then it will set traits on that area (border, background, link, padding etc.). From 4.7.3 my understanding is that any (normal) areas returned by children of the inline formatting object always become children of normal inline areas that the FO generates. Similarly for a block, by 4.7.2. So the inline FO can never _return_ a normal block area. I guess it depends on one's understanding of return. I take this not to include any nested areas. The normal block area comes back, sure, but as a child of a normal inline area. If that is the case why is a footnote inline not allowed to have a block level child. Since this is effectively the same as using an inline-container. Probably just the semantics of what the inline does for a footnote, rather than any technical reason. Here is another confusing statement, that makes sense for inline-container. 4.6 The dimensions of the content-rectangle for an inline-area without children is computed as specified by the generating formatting object, as are those of an inline-area with block-area children. Does computed as specified mean specified on the fo or derived from the context. I'm thinking, as specified on the FO. From a practical viewpoint it makes sense to wrap the block in an inline area with the traits and treat the block normally in layout terms but it still feels uncomfortable. It also introduces a whole lot of other questions about line height, padding etc. The use of line-height for inlines is as a synonym for height; one _can_ use height but only for replaced inline-level FOs. So for an original inline, say, we'd ignore a height but use line-height instead, which more often than not is just going to inherit from the block containing it. I think this is pretty straightforward. I don't know if this is what you were getting at, though. Because I figure you're on top of this already. Regards, Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [REDESIGN] Line layout manager discussion
Arved, I agree that there is no need to tie the rendering to any particular model, as long as the results are equivalent. The discussions that span this list and the Xslfo-proc-devel list testify that there are many approaches to process of layout. However, if I am reading this correctly, the proposal is to clarify the text of the spec. In that context, the treatment of the area tree and its relationship to the fo tree must be coherent and consistent, or we will be in even deeper difficulties. Peter Arved Sandstrom wrote: From what I see here you are changing the shape of the tree. The motivation seems to be to make it explicit that block areas contained within an inline area must bubble up to become direct children of the containing block area. I can't see that that is feasible, given the basic design principle of the spec that the area tree follows the fo tree. [ SNIP ] With respect to the second sentence of the above, I think we should be very clear at all times about exactly which area tree we are talking about - the conceptual area tree as described in the spec, or the real one constructed by Fop. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [REDESIGN] Line layout manager discussion
-Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: May 5, 2002 12:55 AM To: [EMAIL PROTECTED] Subject: Re: [REDESIGN] Line layout manager discussion Arved, I agree that there is no need to tie the rendering to any particular model, as long as the results are equivalent. The discussions that span this list and the Xslfo-proc-devel list testify that there are many approaches to process of layout. However, if I am reading this correctly, the proposal is to clarify the text of the spec. In that context, the treatment of the area tree and its relationship to the fo tree must be coherent and consistent, or we will be in even deeper difficulties. Peter My last post was motivated by one thing - the statement that a block area bubbles up. Well, it does not, not in the conceptual area tree described in the XSL spec. As a result I thought it worth our time to ask for some specificity when the area tree being referred to is not immediately obvious. I agree with your sentiments, particularly the last sentence. As such I think it is very important to establish exactly what area tree we are talking about in any given context. In theory there are at least 2 - the XSL 1.0 conceptual area tree, and the real tree (really, whatever structure we happen to use). There could be more. Regards, Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [REDESIGN] Line layout manager discussion
Arved, Again, I agree that, in the conceptual area tree described in the spec, blocks embedded in inline-area generating FOs in the fo tree (e.g., fo:inline and fo:basic-link), themselves embedded in a parent fo:block, do not bubble up to the same level as the parent fo:block. Going back to your diagram, I am talking about the fo:block embedded in the basic-link. I have attached another diagram describing a subset of your original example. Let me clarify what I meant by the term bubble up in the reply to Karen. Then what seems to me to be the *intention* that layout within fo:inline and fo:basic-link proceed as though these wrappers were layout-transparent, would be made clear. That is, blocks bubbling up from below will be stacked in the BPDir without IPDir attachments from surrounding inline-areas. This refers to the spec's conceptual area tree. It arises out of my misapprehension that the nesting of fo:blocks within inline-area generators would involve a nesting of the layout within the generated inline-area. The fo:inline inline-area in the area tree would grow within the bounds of the containing line-area and block area, but limited by it. It doesn't work that way, though, as we have all discussed. These block areas bubble-up, not in terms of their containment within the appropriate set of line-area-inline-area-block-area, bu in terms of their layout consequences. Apart from any layout-altering properties defined on the containing inline-area generator, e.g.font or border changes, the text and any nested blocks are treated for layout as though they had occurred as direct children of the outer fo:block. That's what the term layout-transparent means. That, at least, is what I take the *intention* of the authors to be. And that is why I want to see some clarification of the relationship between 4.7.2 Line-building and 4.7.3 Inline-building. It seems to me that the spec decrees that the initial text of the basic-link (In basic-link in my example) is constructed into an inline-area by the Inline-building process of 4.7.3. In order to do this, it has to know about the constraints that it inherits from the already partially constructed line-area which contains Text in block . It seems to me that, conceptually at least, in the conceptual area tree model of the spec, the inline-building process needs to take account of all of the glyph substitution, insertion and deletion considerations that apply to 4.7.2, because it is now the responsibility of the inline-area generator to generate a *single* inline-area to complete the pending line-area of the parent. To do that, it will have to be able to do its own line-breaking. Clarifying this is a matter of the coherence and consistency of the spec. It is also important if you are tempted, as I am, by the idea of mimicking this conceptual model and procedure in actual code. All of the above may just mean that, while I thought I had been brought around to your way of thinking on this aspect of the spec, I may still be thinking about it very differently. Peter Arved Sandstrom wrote: My last post was motivated by one thing - the statement that a block area bubbles up. Well, it does not, not in the conceptual area tree described in the XSL spec. As a result I thought it worth our time to ask for some specificity when the area tree being referred to is not immediately obvious. I agree with your sentiments, particularly the last sentence. As such I think it is very important to establish exactly what area tree we are talking about in any given context. In theory there are at least 2 - the XSL 1.0 conceptual area tree, and the real tree (really, whatever structure we happen to use). There could be more. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [REDESIGN] Line layout manager discussion
On Sat, 2002-05-04 at 18:07, Arved Sandstrom wrote: I couldn't tell from the SVG source what you prepared the file with. I would like to use SVG myself. There is no way I am going to handcode it, though (just as with FO). I actually wrote it by hand. I tried using an editor but gave up, instead I just edit by hand and view it using batik. In this case it was fairly easy since everything is placed in a definite position. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [REDESIGN] Line layout manager discussion
-Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: May 3, 2002 9:31 AM To: [EMAIL PROTECTED] Subject: Re: [REDESIGN] Line layout manager discussion Hi devs, Be careful with the abbreviations. :-) One small slip of the keys and we'll all be referred to as debutantes. I have attached a picture of how I think this process should work (in principle not necessarily with actual areas or code). I couldn't tell from the SVG source what you prepared the file with. I would like to use SVG myself. There is no way I am going to handcode it, though (just as with FO). Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [REDESIGN] Line layout manager discussion
Arved Sandstrom wrote: I couldn't tell from the SVG source what you prepared the file with. I would like to use SVG myself. There is no way I am going to handcode it, though (just as with FO). Tell me what you need and i design a diagram description language and an XSL to transform it into SVG. :-) J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [REDESIGN] Line layout manager discussion
-Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: May 2, 2002 11:26 PM To: [EMAIL PROTECTED] Subject: Re: [REDESIGN] Line layout manager discussion Karen Lease wrote: [ SNIP ] For the record, I disagree with Arved's reading of Line-Building. I read 4.7.2, point 5 as saying that a block area generated by an fo:block can contain a mixture of block areas and line areas. Agreed. In fact, it seems to me that the line-area is a pseudo-block designed to maintain the condition that the all of the children of an area must be of the same type, in the circumstance where there will clearly be block children of an fo:block, and to allow for simple block stacking in the BPDir. There is no need to wrap block areas in a line-area. On that last point let me clarify and point out that I never suggested that. By definition a line area is a block area that contains only inline areas as children. The quibble was over whether block areas returned/generated by by FO children, and line areas that wrap inline areas returned/generated by FO children, can/must/shouldn't co-exist in a single normal block area generated by the top-level block FO. I was suggesting the shouldn't viewpoint; Karen reads it differently. I am off to work so cannot comment more at the moment, on anything. :-) Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [REDESIGN] Line layout manager discussion
Hi devs, I have attached a picture of how I think this process should work (in principle not necessarily with actual areas or code). The spec should say something like: 4.7.2 A block level formatting object which contains inline level formatting objects that will create inline areas will create lines. Any block level areas that are return by child formatting objects will be placed as direct children of this block area. Any inline level areas which area return by child formatting objects will be placed into line areas. Consecutive inline areas will be placed into line areas. The sequence of child areas returned to this block area will be handled so that a sequence of inline areas will be placed into a sequence of line areas and block areas will be placed in the correct order. (part 5. point 1 then says that any child fo that returns a block area means that the block area is a direct child of the current block area) 4.7.3 An inline level formatting object creates and returns inline areas and returns any block areas. Each line area can contain only one inline area created by the inline level formatting object. This inline area is created by adding child inline areas that are allowed in the parent line area (it is not required to fit, eg. no wrap). 6.6.7 (and other inline fo's) Areas: The fo:inline returns these areas, any block areas, any page-level-out-of-line ... So does that make more sense? I think some of the confusion is that a block area can create multiple block areas but this only occurs at page/column breaks. Regards, Keiron. line.gif Description: GIF image line.svg Description: image/svg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [REDESIGN] Line layout manager discussion
Hi devs, I have attached a picture of how I think this process should work (in principle not necessarily with actual areas or code). The spec should say something like: 4.7.2 A block level formatting object which contains inline level formatting objects that will create inline areas will create lines. Any block level areas that are return by child formatting objects will be placed as direct children of this block area. Any inline level areas which area return by child formatting objects will be placed into line areas. Consecutive inline areas will be placed into line areas. The sequence of child areas returned to this block area will be handled so that a sequence of inline areas will be placed into a sequence of line areas and block areas will be placed in the correct order. (part 5. point 1 then says that any child fo that returns a block area means that the block area is a direct child of the current block area) 4.7.3 An inline level formatting object creates and returns inline areas and returns any block areas. Each line area can contain only one inline area created by the inline level formatting object. This inline area is created by adding child inline areas that are allowed in the parent line area (it is not required to fit, eg. no wrap). 6.6.7 (and other inline fo's) Areas: The fo:inline returns these areas, any block areas, any page-level-out-of-line ... So does that make more sense? I think some of the confusion is that a block area can create multiple block areas but this only occurs at page/column breaks. Regards, Keiron. line.svg Description: image/svg line.gif Description: GIF image - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [REDESIGN] Line layout manager discussion
Keiron, Keiron Liddle wrote: I'm almost thinking of going a step further. Maybe we could add annotations to the spec to clarify these things with our understanding and then present this information. Yes indeed. And an index, including especially a concept index. It seems to me that the spec writers are not as involved as they should be. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [REDESIGN] Line layout manager discussion
Arved, My apologies. I was just taking the opportunity to think aloud about aspects of the interaction between inline-areas and block-areas. Trying to make sense of the various elements of the spec leaves your ears buzzing. Peter Arved Sandstrom wrote: For the record, I disagree with Arved's reading of Line-Building. I read 4.7.2, point 5 as saying that a block area generated by an fo:block can contain a mixture of block areas and line areas. Agreed. In fact, it seems to me that the line-area is a pseudo-block designed to maintain the condition that the all of the children of an area must be of the same type, in the circumstance where there will clearly be block children of an fo:block, and to allow for simple block stacking in the BPDir. There is no need to wrap block areas in a line-area. On that last point let me clarify and point out that I never suggested that. By definition a line area is a block area that contains only inline areas as children. The quibble was over whether block areas returned/generated by by FO children, and line areas that wrap inline areas returned/generated by FO children, can/must/shouldn't co-exist in a single normal block area generated by the top-level block FO. I was suggesting the shouldn't viewpoint; Karen reads it differently. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [REDESIGN] Line layout manager discussion
Peter, Here's my point of view on where line-breaking (perhaps including hyphenation) happens. The end result of layout is a sequence of nested areas. However while layout is happening, line-breaking logic has to pretend that it's only working on a flat row of characters and other inline leaf nodes like external graphics. Keiron and I took different approaches to this, but the idea is about the same: lower level layout managers return information to the Line Layout Manager which allows it to make a decision about where to break the line. Once that decision is made, the appropriate areas can be created, depending on where the break occurs. Although it's possible to send information about IPDim down to lower level inline layout managers, I think it's simpler and clearer to concentrate knowlege (and strategy) about line-breaking in a single layout manager: the one actually creating Line Areas. There's a strong analogy with block-direction layout, where the Flow level (or perhaps the Page level?) LM is responsible for determining column/page breaks based on information provided by the lower level layout managers. The Flow and Line level LM are also responsible for justifying in either the inline or block progression dimensions and deciding how much stretch or shrink should be done. They either pass this information down to lower level layout managers (that was my plan) or do it directly on the flattened areas (Keiron's approach, at least at the line level). -Karen Peter B. West wrote: ... This leaves a question about where hyphenation is decided. In 4.7.2 point 5, there is a discussion about glyph substitution, insertion and deletion which seems to assume that the sequences of inline-areas being built into line-areas are in fact fo:characters. The corresponding sequences bubbling up from fo:inline and fo:basic-link are already wrapped as integral inline-areas and presented as a fait accompli to the parent line-builder. The fo:inline/fo:basic-link fo must obviously receive IPDim and BPDim information in order to present sane integral inline-areas to its parent, and to allow for the layout of nested fo:blocks. (This is pure hierarchical galley stuff.) In any case, there should be a correspondent in 4.7.3 to the discussion of substitution, insertion and deletion in 4.7.2, just to make it clear what the responsibilities of the inline-builder are. That's if I have this right, this time. What do you think? Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [REDESIGN] Line layout manager discussion
Arved, I'm definitely in favor of deciding how we think things are supposed to be laid out. Of course it would be nice if we were on the same wavelength with the majority of FO users and implementors... but I'm not too worried about that. Besides the stuff we're talking about currently, we need to agree on line-stacking issues (Keiron's already worked on vertical alignment, so he's probably up on that) and space specifier handling (but there I think the spec is fairly clear once one has read it 50 times or so :-). Arved Sandstrom wrote: Good...if we all agree with that then I think it is the main point gotten out of the way, because every other situation has to do with child FOs all being inline or block-level, for which the results are less dubious. . The main thing is, let's make sure that we have agreement (codified through use of these diagrammed examples) on all matters that affect placement. I understand that we want to have a warm fuzzy about our understanding of the spec, but that's not going to happen with everything. To be precise, if I can get a number of these examples created, what we can do is identify situations where we can say, this one is 100% solid (we know this is right, there is no uncertainty in the spec), this one is iffy (there may be small inconsistencies between our placement and what the spec authors intended), or this one is problematic (contradictions, for example). Once we have classified the examples, we can do damage control on the uncertain ones. Namely, let's do it this way, but let's be aware that things could be interpreted another way, and if so, how heavily committed are we in our code? On a related matter when it comes right down to brass tacks I am really only concerned about placement (accuracy of rendering). Both with Fop and with my other project I find it easier to use the conceptual areas, and I get the sense that others also feel this way, but let's face it, as long as our final result is consistent it doesn't really matter if our internal structures deviate. In general yes. So long as the extra levels of area wrappers we might or might not add in any given situation don't bring along border, padding, space-* etc. -Karen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [REDESIGN] Line layout manager discussion
Hi Keiron, I think this is a good start. I especially like the illustration which covers all aspects of the problem. I have some suggestions for the proposed text (see below). -Karen Keiron Liddle wrote: Hi devs, I have attached a picture of how I think this process should work (in principle not necessarily with actual areas or code). The spec should say something like: 4.7.2 A block level formatting object which contains inline level formatting objects that will create inline areas will create lines. A block level formatting object may contain both other block-level and inline level formatting objects. The block level FO creates and returns a block area or several block areas if it is split across more than one column or page. Any block level areas that are return[ed] by child formatting objects will be placed as direct children of this block area. Any inline level areas which are[a] return[ed] by child formatting objects will be placed into line areas. Consecutive inline areas will be placed into line areas. Minor corrections in [] above. The sequence of child areas returned to this block area will be handled so that a sequence of inline areas will be placed into a sequence of line areas and block areas will be placed in the correct order. Not sure this is quite clear enough; it also needs to express the idea that the ordering between the intermingled blocks and inlines is correct. (part 5. point 1 then says that any child fo that returns a block area means that the block area is a direct child of the current block area) 4.7.3 An inline level formatting object creates and returns inline areas and returns any block areas. Each line area can contain only one inline area created by the inline level formatting object. This inline area is created by adding child inline areas that are allowed in the parent line area (it is not required to fit, eg. no wrap). I'm not sure this is the right place to mention linebreak and overflow issues. The main idea is that an inline-level FO creates at least one inline area which holds inline areas generated and returned by any inline level child FOs. It might generate several inline areas, each one being placed in a new line area, if all its content doesn't fit in a single line. If the inline has any block-level FO descendants the block areas which they generate are directly returned by the inline FO. 6.6.7 (and other inline fo's) Areas: The fo:inline returns these areas, any block areas, any page-level-out-of-line ... So does that make more sense? I think some of the confusion is that a block area can create multiple block areas but this only occurs at page/column breaks. I assume you mean a block level FO can create multiple block areas. And similarly, an inline level FO can create multiple inline areas if it is broken into several lines. Regards, Keiron. Name: line.svg line.svgType: image/svg Encoding: base64 Name: line.gif line.gifType: GIF Image (image/gif) Encoding: base64 - 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: [REDESIGN] Line layout manager discussion
Keiron et al., Just a quick reaction to this - I'm off to sit next to the footpath reading the newspapers and drinking tea. From what I see here you are changing the shape of the tree. The motivation seems to be to make it explicit that block areas contained within an inline area must bubble up to become direct children of the containing block area. I can't see that that is feasible, given the basic design principle of the spec that the area tree follows the fo tree. Specifically, by doing that, you lose what Karen called, iirc, the semantic markers of the enclosing inline-area, e.g., fo:inline or fo:basic-link. So how does that semantic information get to the once-but-no-longer enclosed fo:block? It is possible to arrange the transfer of such information to the block-area in the area tree, but then the inheritance becomes a purely algorithmic thing, and the structural link between the fo tree and the area tree is broken. It seems to me that one reason for the murkiness in this area of the spec is that the authors are at pains to preserve this structural relationship, while at the same time ensuring that the actual layout is determined in the way you propose. I think that it's possible to do this by clarifying the particular issues about line-building and inline-building in this context. The bottom line is that I think we have to clarify the text so that it comprehensibly expresses the situation laid out in Arved's original diagram of the handling of the fo:block within an fo:basic-link within the text of an fo:block. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [REDESIGN] Line layout manager discussion
Comments below. -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: May 3, 2002 10:42 PM To: [EMAIL PROTECTED] Subject: Re: [REDESIGN] Line layout manager discussion [ SNIP ] From what I see here you are changing the shape of the tree. The motivation seems to be to make it explicit that block areas contained within an inline area must bubble up to become direct children of the containing block area. I can't see that that is feasible, given the basic design principle of the spec that the area tree follows the fo tree. Specifically, by doing that, you lose what Karen called, iirc, the semantic markers of the enclosing inline-area, e.g., fo:inline or fo:basic-link. So how does that semantic information get to the once-but-no-longer enclosed fo:block? It is possible to arrange the transfer of such information to the block-area in the area tree, but then the inheritance becomes a purely algorithmic thing, and the structural link between the fo tree and the area tree is broken. [ SNIP ] With respect to the second sentence of the above, I think we should be very clear at all times about exactly which area tree we are talking about - the conceptual area tree as described in the spec, or the real one constructed by Fop. Because in the conceptual tree block areas have a well-defined location and there is no bubbling up at all. Whereas in the real tree we can flatten completely and not have a tree at all, so we could have maximal bubbling. As far as semantic information, are we talking about during layout or once the area is passed off for rendering? Because it seems to me that if we have managers then they can take care of retaining the semantic information (e.g. all areas generated or returned in this manager belong within a link). Once the areas are passed off to the renderer practically all the information needed to properly render any area can be expressed as traits on that area - one main exception is that areas need to know their nearest ancestor reference area for positioning. I am not discounting an area tree per se - with my xslfo-proc project I find an area structure (partial in my SAX implementation) to be the most convenient way of recording current layout information. That is, manager X needs to store certain information and it may as well use Area objects to do it. But I lean strongly towards a viewpoint where the areas have no knowledge of original semantics. Regards, Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [REDESIGN] Line layout manager discussion
I agree with you (except for the last statment about one line). I found this statement interesting: 6.6.7. fo:inline An fo:inline that is a child of an fo:footnote may not have block-level children. An fo:inline that is a descendant of an fo:leader or of the fo:inline child of an fo:footnote may not have block-level children, unless it has a nearer ancestor that is an fo:inline-container. It suggests that what you are saying is correct and that block-level elements create a block area outside the immediate line area. So to have a block area inside a line area you must use the inline-container, a block is never automatically embedded. Also in this section, reading between the lines (it's amazing how they manage to contradict themselves in such a short section) 4.7.3. Inline-building An inline fo element with a block element as a child will create inline areas and return the block area. It will create a single inline area that can fit consecutive child inline areas on a single line. So the child inline areas are put into parent inline areas that are separated by line breaks and block areas. So Karen's approach is looking better. I really wish this spec would say relevant things in the right places and mention how everything is handled rather than being so vague. On 2002.05.01 04:00 Arved Sandstrom wrote: Discussion follows below. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Karen Lease Sent: April 29, 2002 5:39 PM To: [EMAIL PROTECTED] Subject: [REDESIGN] Line layout manager discussion Keiron Liddle wrote: So why flatten the inline layout managers? If we have an example like this: blockSome text basic-linka paragraph of textblockwith a block/blockand more text/basic-link and inline background=blueblue backgroundinline color=green green text blocka block/block more green/inline/inline/block The basic link produces/returns both inline areas and a block area, so it is not possible to say that the basic-link element or its layout manager would produce inline areas. So how should this be handled. If it is flattened things are easier. The layout manager can then keep range information like: starts link, ends link. I think this FO snippet is sufficiently complex as to be a good Gedankenexperiment. I prepared a PNG which illustrates the area tree as _I_ interpret the spec applying to this FO. You'll have to view the image in colour. I have taken liberties with WS, border colours, spaces, padding etc etc. I threw in one page break to make things interesting. Also, I have shown runs of texts as combined inlines, where we know in fact that they are really containers for a bunch of glyph areas. Here's some of the main principles I am keeping in mind: 1. An area must have its child areas all of the same type (inline or block); 2. No area may have more than one normal block area returned by the same fo:block; 3. No area may have more than one normal inline area returned by the same inline (fo:inline, fo:basic-link); 4. A block generates normal block areas. If a child FO returns a block area this becomes a direct child of one of those block areas. If a child returns a sequence of inline areas, these become children of line areas which are in turn children of a normal block area; 5. An inline generates normal inline areas. Each such may contain a sequence of inline areas or a single block area. Absolutely nobody else is going to agree 100% with my interpretation, but I think if we can hash this out it will allow us to really move forward with confidence. a) There are no block-level children of the top block, only inlines, so we know that the one or more block areas generated by the top-level block are going to contain line areas. Because of the page break there are 2 normal block areas generated by the top-level block; b) some text is simple - the inline goes neatly into the first line area as its first child; c) Now we hit the basic link. This generates one or more normal inlines, which are outlined in orange. The a paragraph of text is the first inline child of the first normal inline area generated by the basic-link; d) we hit the nested block. OK, this is where the anguish starts. :-) It produces at least one normal block area, by definition. I have given this a pale green background. This _cannot_ occupy the first normal inline area generated by the basic-link, because that already contains an inline area (rule 1). So it must be in a second normal inline area generated by the basic-link. By rule 3, the first line area may not contain 2 areas generated by the same inline, so that's why we terminate line aea 1 and start another; e) In the second line area (outlined in dark blue), we have the second normal inline area generated by the basic-link, outlined in orange. This contains a single block area generated
RE: [REDESIGN] Line layout manager discussion
Comments inline...actually, no, they're not, they are really block-stacking, but you get the drift. :-) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Karen Lease Sent: May 2, 2002 7:21 PM To: [EMAIL PROTECTED] Subject: Re: [REDESIGN] Line layout manager discussion Arved, Keiron et. al. I guess logically it's true that the blocks nested in inlines should be wrapped in inline areas, but it makes me nervous :-) At least they cause line breaks, that much seems sure. Good...if we all agree with that then I think it is the main point gotten out of the way, because every other situation has to do with child FOs all being inline or block-level, for which the results are less dubious. I still think that we should put pressure on the spec editors to either get rid of structure or clarify it in the next version (ha, ha). If people need blocks in inlines, they have inline-container. In fact, I'd like to think that the possibility of including block-level FOs in inline-level FOs is purely for convenience or semantic nesting and should not really affect the area tree, except to cause line breaks before and after the block areas. The most legitimate use I can see for this kind of semantic nesting is basic-link, because it could spread the link semantics over several areas; kind of a link-wrapper. The main thing is, let's make sure that we have agreement (codified through use of these diagrammed examples) on all matters that affect placement. I understand that we want to have a warm fuzzy about our understanding of the spec, but that's not going to happen with everything. To be precise, if I can get a number of these examples created, what we can do is identify situations where we can say, this one is 100% solid (we know this is right, there is no uncertainty in the spec), this one is iffy (there may be small inconsistencies between our placement and what the spec authors intended), or this one is problematic (contradictions, for example). Once we have classified the examples, we can do damage control on the uncertain ones. Namely, let's do it this way, but let's be aware that things could be interpreted another way, and if so, how heavily committed are we in our code? On a related matter when it comes right down to brass tacks I am really only concerned about placement (accuracy of rendering). Both with Fop and with my other project I find it easier to use the conceptual areas, and I get the sense that others also feel this way, but let's face it, as long as our final result is consistent it doesn't really matter if our internal structures deviate. - For the record, I disagree with Arved's reading of Line-Building. I read 4.7.2, point 5 as saying that a block area generated by an fo:block can contain a mixture of block areas and line areas. On this particular point I think we are fortunate insofar as it is not going to affect placement. Also, if we look at 4.7.3 (inline-building), I find it curious that it starts by saying TWICE that an inline FO places inline areas and anchor inline areas returned by its child FOs in inline areas which it generates, and then suddenly throws a block-area into the condition described in point 1. Looks more like a hasty copy/paste from the list for Line-building! As Keiron says, if the spec writers had been clearer, we wouldn't have to spend hours chasing our tails like this! I find the transitions from relatively formal set-oriented treatments to casual prose disconcerting. As soon as I see formal then my Pedant-O-Meter cranks way up, and I find it hard to switch off. :-) Regards, Karen Arved Sandstrom wrote: [SNIP] _If_ there were blocks nested inside the top-level block these would produce normal block areas that are single children of normal block areas produced by the top-level block. My reading of Line-Building is that normal block areas generated by a fo:block have either _single_ block areas _or_ one or more line areas as children, not a mixture. Final comment: it is the close intermingling of inlines and blocks in this example that causes so much line breaking. Clearly each of the 2 nested blocks could be wrapped in inlines (fo:inline or whatever), and as a result everything in the example, in theory, could be in _one_ line area. Anyhow, please critique away. :-) Regards, Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [REDESIGN] Line layout manager discussion
Arved, This is a good idea. I half-heartedly suggested as much to Matthew Huggett when he asked what a non-programming technical writer might contribute. It requires too deep an insight into the spec, but he (or Cyril) may of some assistance to you. What would be even more generally useful would be to get the spec editors to put up a site, possibly with disclaimers plastered all over it, to which they post FAQs on the spec. They must get a lot of repeating questions from the various parties who are trying to implement. I'm not subscribed to the xsl-editors mailing list (which I suppose I should be.) Is anyone else subscribed? If so, have requests like this been made before? Peter Arved Sandstrom wrote: Hi, Keiron I think what I should do is establish a section on the website with all the other design notes that is a central location for these kinds of studies. This could be the first one. I can undertake to start churning these out on a fairly regular basis - I think we need them. Once they are in CVS then it would be easier for others to annotate them, modify them, and what have you. We'll have to settle on a mutually agreeable figure format so as not to unduly restrict access. As far as the spec goes, absolutely, I agree. That's why I think that these diagrams help so much - in order to draw them you must work your way through the spec in detail. The process also exposes any gotchas before too much code has been written based on different assumptions. I'll proceed on the above basis and set up a place for these diagrams/studies, and crank out some more. I am somewhat reluctant to do any coding at the moment until such a time (hopefully not far away) where I am satisfied that I understand the new design well. Arved -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: May 2, 2002 6:18 AM To: [EMAIL PROTECTED] Subject: Re: [REDESIGN] Line layout manager discussion I agree with you (except for the last statment about one line). I found this statement interesting: 6.6.7. fo:inline An fo:inline that is a child of an fo:footnote may not have block-level children. An fo:inline that is a descendant of an fo:leader or of the fo:inline child of an fo:footnote may not have block-level children, unless it has a nearer ancestor that is an fo:inline-container. It suggests that what you are saying is correct and that block-level elements create a block area outside the immediate line area. So to have a block area inside a line area you must use the inline-container, a block is never automatically embedded. Also in this section, reading between the lines (it's amazing how they manage to contradict themselves in such a short section) 4.7.3. Inline-building An inline fo element with a block element as a child will create inline areas and return the block area. It will create a single inline area that can fit consecutive child inline areas on a single line. So the child inline areas are put into parent inline areas that are separated by line breaks and block areas. So Karen's approach is looking better. I really wish this spec would say relevant things in the right places and mention how everything is handled rather than being so vague. - 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: [REDESIGN] Line layout manager discussion
Comments inline. -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: May 1, 2002 2:19 AM To: [EMAIL PROTECTED] Subject: Re: [REDESIGN] Line layout manager discussion [ SNIP ] Look at basic-linka paragraph of text blockwith a block/block and more text/basic-link What about the restriction that a given area's children must all be of the one type (4.2.1 Area Types)? Doesn't that oblige us to wrap the block within an inline? Then that inline wrapper can sit in sequence with the inline-areas 't', 'e', 'x', 't', ' ', as indeed the basic-link inline-area already sits in sequence with 'S','o','m','e',' ','t','e','x','t',' '? What's your take on this? There were many discussions last year, as I recall, that espoused this viewpoint, that the area rules precluded a number of FO-level combinations and juxtapositions. This school of thought, and I belong(ed) to it, held that a block or inline contains either block FO children _or_ inline FO children, but not both. I am no longer convinced that this needs to be the case. It is certainly safe to ensure that all the children of a given FO are either block-level FOs _or_ inline-level FOs. In these cases we have area generation and layout which is (I think) well understood. But this treatment shows, I think, that the area rules can be satisfied without having to homogenize the type of FO children. 4.2.1 is a restriction on areas, as you know. Certainly the areas that I have diagrammed do not violate this constraint. N.B. I have attached the SVG generated by Dia. I don't know what the quality is like, but if the quality of the generated PNG is anything to go by, probably not too good. If we can all get access to a reasonable SVG vector editor that will write PNGs, we will be able to pass the editable file around as well, which will greatly facilitate this sort of discussion. Any candidates for a linux-enabled SVG editor? I'll have to take a look around. I happened to use Visio because it's on the machine and I'm familiar with it, plus it's a nice piece of gear. The most recent Visios do SVG, I believe, but I don't have a copy at home. We could use Postscript as well. Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
AW: [REDESIGN] Line layout manager discussion
Questions: o A basic-link in PDF means an annotation - an annotation defines a rectangle. What's the effect, if the annotation text breaks to a new line? If the basic-link contains more blocks and children? o Middle Easterner write left-to-right, top-to-bottom. Far Easterners write from top-to-bottom, right-to-left. They have their own font metrics. Is the FOP pagination able to handle this? How does it affect the area tree and the document presentation? o fo:external-graphic: can text be flowed around an image? That means, does it make sense for a user to mix text and images within the same block - unless a table is used, but this is a different setup. Hansuli Anderegg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [REDESIGN] Line layout manager discussion
Comments inline. -Original Message- From: J.U. Anderegg [mailto:[EMAIL PROTECTED]] Sent: May 1, 2002 5:19 PM To: [EMAIL PROTECTED] Subject: AW: [REDESIGN] Line layout manager discussion Questions: o A basic-link in PDF means an annotation - an annotation defines a rectangle. What's the effect, if the annotation text breaks to a new line? If the basic-link contains more blocks and children? From the XSL standpoint it's merely a question of the basic-link generating one or more normal inline areas. These map to annotation rectangles in PDF. When the inline areas in question are presented to the renderer they have behaviour traits corresponding to the internal-destination or external-destination. o Middle Easterner write left-to-right, top-to-bottom. Far Easterners write from top-to-bottom, right-to-left. They have their own font metrics. Is the FOP pagination able to handle this? How does it affect the area tree and the document presentation? Can it handle this right now? No. Apart from things like mixing text with different writing-modes, supporting different writing-modes and reference-orientations is actually not much more complicated than the specific Western case, at everything except the immediate glyph-area level. o fo:external-graphic: can text be flowed around an image? That means, does it make sense for a user to mix text and images within the same block - unless a table is used, but this is a different setup. Using a side-float is the best you can do with XSL 1.0. If you are looking to do something like TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT -- TEXT TEXT TEXT TEXT || TEXT TEXT TEXT TEXT | Image| TEXT TEXT TEXT TEXT || TEXT TEXT TEXT TEXT || TEXT TEXT TEXT TEXT -- TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT then, no, without tables and a fair bit of tweaking I don't think so. An external-graphic intermingled with PCDATA is going to normally cause the line it is in to expand to its own size (using line-height or max-height for the line-stacking-strategy), so things will look like TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT -- || | Image| || || TEXT TEXT || TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT assuming that the baseline of the external-graphic is determined by an auto value on alignment-adjust. Hope this helps. Regards, AHS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [REDESIGN] Line layout manager discussion
Karen, Some extra topics I have been thinking about: Determining best break. (What is the level of keep broken by a hyphenation, is it 0 for hyphenating and always for not?) The best break position has an equal or lower keep value and is closer to the optimum position. If there are keeps between the minimum and optimum ipd then we need to go further until a 0 keep is found or we hit the max. The best break is then known as a particular position. It looks like the layout context and break possiblity could handle finding this best break so this should be fine. Re-doing content for change in ipd or change of page. In the case of floats and footnotes these are associated with a line. If the line cannot fit then we need to remove everything and re-add for the next place. If the line contains resolved areas (ie. page number) then this line needs to be redone. There are two issues, how to start again at a particular line due to changes in ipd or resolving values and throwing away all inline areas and managers for parts that are already placed onto a finished page. This is what my LineInfo and LayoutPos are for. Alignment. Once we have the inline areas they need aligning. Using the nested inline areas will require different processing which could be more helpful in the paddng/spacing situations, I'm not sure. This is not much of an issue. On 2002.04.29 22:39 Karen Lease wrote: It's certainly true that mixing blocks in inlines, as the spec says is allowed, gets very complicated. I remember some discussion of this on the list a long while ago and I think we actually asked the XSL editors what kind of areas they imagined this generating, but never got an answer. If I understand your idea correctly, the layout areas you would generate from this example are the ones I would like to generate also. (Block area containing some lines, nested block, more lines, nested block and more lines.) Yes. Basically the same as having a block among text inside a block. Although I don't know what would happen with non-inheritable properties like background. *** I think this is clearly the key issue to decide in this round of discussions: flattened or nested. I think it is possible both ways but not necessarily easy. I noticed in the spec it says inline areas may have inline area children but its content rectangle and axamples seem a bit different from what we are talking about here. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [REDESIGN] Line layout manager discussion
Keiron Liddle wrote: Karen, On 2002.04.29 22:39 Karen Lease wrote: It's certainly true that mixing blocks in inlines, as the spec says is allowed, gets very complicated. I remember some discussion of this on the list a long while ago and I think we actually asked the XSL editors what kind of areas they imagined this generating, but never got an answer. If I understand your idea correctly, the layout areas you would generate from this example are the ones I would like to generate also. (Block area containing some lines, nested block, more lines, nested block and more lines.) Yes. Basically the same as having a block among text inside a block. Although I don't know what would happen with non-inheritable properties like background. *** I think this is clearly the key issue to decide in this round of discussions: flattened or nested. I think it is possible both ways but not necessarily easy. I noticed in the spec it says inline areas may have inline area children but its content rectangle and axamples seem a bit different from what we are talking about here. K K, I think it will necessarily be both, as your discussions are tending to show. If so, which is easier: generating flattened areas from trees, or generating trees from flattened areas? No contest. My notes on galleys, keeps and spaces may be relevant here. Incidentally, I have always been a bit surprised that the spec authors did not attempt a fully recursive definition within page viewports. It really is a page-oriented spec. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [REDESIGN] Line layout manager discussion
Discussion follows below. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Karen Lease Sent: April 29, 2002 5:39 PM To: [EMAIL PROTECTED] Subject: [REDESIGN] Line layout manager discussion Keiron Liddle wrote: So why flatten the inline layout managers? If we have an example like this: blockSome text basic-linka paragraph of textblockwith a block/blockand more text/basic-link and inline background=blueblue backgroundinline color=green green text blocka block/block more green/inline/inline/block The basic link produces/returns both inline areas and a block area, so it is not possible to say that the basic-link element or its layout manager would produce inline areas. So how should this be handled. If it is flattened things are easier. The layout manager can then keep range information like: starts link, ends link. I think this FO snippet is sufficiently complex as to be a good Gedankenexperiment. I prepared a PNG which illustrates the area tree as _I_ interpret the spec applying to this FO. You'll have to view the image in colour. I have taken liberties with WS, border colours, spaces, padding etc etc. I threw in one page break to make things interesting. Also, I have shown runs of texts as combined inlines, where we know in fact that they are really containers for a bunch of glyph areas. Here's some of the main principles I am keeping in mind: 1. An area must have its child areas all of the same type (inline or block); 2. No area may have more than one normal block area returned by the same fo:block; 3. No area may have more than one normal inline area returned by the same inline (fo:inline, fo:basic-link); 4. A block generates normal block areas. If a child FO returns a block area this becomes a direct child of one of those block areas. If a child returns a sequence of inline areas, these become children of line areas which are in turn children of a normal block area; 5. An inline generates normal inline areas. Each such may contain a sequence of inline areas or a single block area. Absolutely nobody else is going to agree 100% with my interpretation, but I think if we can hash this out it will allow us to really move forward with confidence. a) There are no block-level children of the top block, only inlines, so we know that the one or more block areas generated by the top-level block are going to contain line areas. Because of the page break there are 2 normal block areas generated by the top-level block; b) some text is simple - the inline goes neatly into the first line area as its first child; c) Now we hit the basic link. This generates one or more normal inlines, which are outlined in orange. The a paragraph of text is the first inline child of the first normal inline area generated by the basic-link; d) we hit the nested block. OK, this is where the anguish starts. :-) It produces at least one normal block area, by definition. I have given this a pale green background. This _cannot_ occupy the first normal inline area generated by the basic-link, because that already contains an inline area (rule 1). So it must be in a second normal inline area generated by the basic-link. By rule 3, the first line area may not contain 2 areas generated by the same inline, so that's why we terminate line aea 1 and start another; e) In the second line area (outlined in dark blue), we have the second normal inline area generated by the basic-link, outlined in orange. This contains a single block area generated by the nested block (rule 5). In order for the block area to handle the contained text (with a block) it must itself have a line area with inline children (one or more - I've shown one); f) we encounter and more text. The same argument applies as in 'd' - the second inline area generated by the basic link cannot accept the inline area this text results in because it already contains a block area. So, a third inline area gets generated by the basic link, and by rule 3, this results yet again in another line area; g) the third line area, now graced by the presence of the last normal inline generated by the basic-link (and its children), is able to handle more line areas, and so and and blue background and green text certainly are allowed. I chose to insert a line break after the green. I hope the colours help distinguish what is what - the inline child of the top-level block ends up creating 4 normal inline area which have blue backgrounds; h) the doubly-nested inline produces inline areas that in fact have a transparent background and so everything should be blue, but I thought this would lack clarity. The normal inline areas produced by the doubly-nested inline have a thicker brown border. The same argument applies to the block which is nested in _this_ inline; the combination of rules 1 and 3 require different line areas. Again, the normal block area generated by the doubly-nested block has a pale green background
Re: [REDESIGN] Line layout manager discussion
Arved, Firstly, thanks for taking the trouble to do this. Your diagrams make your argument beautifully clear, and facilitate discussion for everyone, even XSL spec novices. Even me, who struggles to follow text-only arguments. I haven't followed all of the posting yet, but one question has come up for me already. Look at basic-linka paragraph of text blockwith a block/block and more text/basic-link What about the restriction that a given area's children must all be of the one type (4.2.1 Area Types)? Doesn't that oblige us to wrap the block within an inline? Then that inline wrapper can sit in sequence with the inline-areas 't', 'e', 'x', 't', ' ', as indeed the basic-link inline-area already sits in sequence with 'S','o','m','e',' ','t','e','x','t',' '? What's your take on this? N.B. I have attached the SVG generated by Dia. I don't know what the quality is like, but if the quality of the generated PNG is anything to go by, probably not too good. If we can all get access to a reasonable SVG vector editor that will write PNGs, we will be able to pass the editable file around as well, which will greatly facilitate this sort of discussion. Any candidates for a linux-enabled SVG editor? Peter Arved Sandstrom wrote: ... a) There are no block-level children of the top block, only inlines, so we know that the one or more block areas generated by the top-level block are going to contain line areas. Because of the page break there are 2 normal block areas generated by the top-level block; b) some text is simple - the inline goes neatly into the first line area as its first child; c) Now we hit the basic link. This generates one or more normal inlines, which are outlined in orange. The a paragraph of text is the first inline child of the first normal inline area generated by the basic-link; d) we hit the nested block. OK, this is where the anguish starts. :-) It produces at least one normal block area, by definition. I have given this a pale green background. This _cannot_ occupy the first normal inline area generated by the basic-link, because that already contains an inline area (rule 1). So it must be in a second normal inline area generated by the basic-link. By rule 3, the first line area may not contain 2 areas generated by the same inline, so that's why we terminate line aea 1 and start another; ?xml version=1.0 standalone=no? !DOCTYPE svg PUBLIC -//W3C//DTD SVG 2802//EN http://www.w3.org/TR/2000/CR-SVG-2802/DTD/svg-2802.dtd; svg width=23cm height=11cm viewBox=1 1 23 11 text style=fill: #00; text-align: center; font-size: 0.8 x=10.75 y=2outer block line-area/text text style=fill: #00; text-align: center; font-size: 0.8 x=12.75 y=11.25basic-link inline-area/text text style=fill: #00; text-align: center; font-size: 0.8 x=5.5 y=10.25glyph inline-areas/text text style=fill: #00; text-align: center; font-size: 0.8 x=21 y=11inline inline-area/text text style=fill: #00; text-align: center; font-size: 0.8 x=20.25 y=2inner block block-area/text rect style=fill: #ff x=2 y=3.75 width=22 height=4.5/ rect style=stroke-width: 0.1; stroke: #0600ff x=2 y=3.75 width=22 height=4.5/ rect style=fill: #ff x=7.75 y=4.25 width=15.5 height=3.5/ rect style=stroke-width: 0.1; stroke: #f06500 x=7.75 y=4.25 width=15.5 height=3.5/ rect style=fill: #ff x=6.5 y=5.5 width=0.5 height=1/ rect style=stroke-width: 0.08; stroke: #00 x=6.5 y=5.5 width=0.5 height=1/ text style=fill: #00; text-align: center; font-size: 0.7 x=6.75 y=6.25/ rect style=fill: #ff x=2.75 y=5.5 width=0.5 height=1/ rect style=stroke-width: 0.08; stroke: #00 x=2.75 y=5.5 width=0.5 height=1/ text style=fill: #00; text-align: center; font-size: 0.7 x=3 y=6.25S/text rect style=fill: #ff x=3.5 y=5.5 width=0.5 height=1/ rect style=stroke-width: 0.08; stroke: #00 x=3.5 y=5.5 width=0.5 height=1/ text style=fill: #00; text-align: center; font-size: 0.7 x=3.75 y=6.25o/text text style=fill: #00; text-align: center; font-size: 0.7 x=4.5 y=6.25.../text rect style=fill: #ff x=5 y=5.5 width=0.5 height=1/ rect style=stroke-width: 0.08; stroke: #00 x=5 y=5.5 width=0.5 height=1/ text style=fill: #00; text-align: center; font-size: 0.7 x=5.25 y=6.25x/text rect style=fill: #ff x=5.75 y=5.5 width=0.5 height=1/ rect style=stroke-width: 0.08; stroke: #00 x=5.75 y=5.5 width=0.5 height=1/ text style=fill: #00; text-align: center; font-size: 0.7 x=6 y=6.25t/text rect style=fill: #ff x=14.25 y=5.5 width=0.5 height=1/ rect style=stroke-width: 0.08; stroke: #00 x=14.25 y=5.5 width=0.5 height=1/ rect style=fill: #ff x=8.25 y=5.5 width=0.5 height=1/ rect style=stroke-width: 0.08; stroke: #00 x=8.25 y=5.5 width=0.5 height=1/ text style=fill: #00; text-align: center; font-size: 0.7 x=8.5 y=6.25a/text rect style=fill: #ff x=11.25 y=5.5 width=0.5
[REDESIGN] Line layout manager discussion
Keiron, I thought it would be better to start a new thread. I've continued the discussion below. Keiron Liddle wrote: Hi Karen, Its seems that there are gotcha's no matter what direction we take. +1 :-) I will try to present the reasons behind the approach I am taking. I welcome your input and I will look at the code to see how your code works. It seems we need a set of tough cases that we need to be able to handle to be confident of the correct approach. Agreed. So why flatten the inline layout managers? If we have an example like this: blockSome text basic-linka paragraph of textblockwith a block/blockand more text/basic-link and inline background=blueblue backgroundinline color=green green text blocka block/block more green/inline/inline/block The basic link produces/returns both inline areas and a block area, so it is not possible to say that the basic-link element or its layout manager would produce inline areas. So how should this be handled. If it is flattened things are easier. The layout manager can then keep range information like: starts link, ends link. It's certainly true that mixing blocks in inlines, as the spec says is allowed, gets very complicated. I remember some discussion of this on the list a long while ago and I think we actually asked the XSL editors what kind of areas they imagined this generating, but never got an answer. If I understand your idea correctly, the layout areas you would generate from this example are the ones I would like to generate also. (Block area containing some lines, nested block, more lines, nested block and more lines.) I will work on a bit of pseudo-code showing how the nesting approach would do it (or not do it). Determining line breaks: blocktext on a hyphenated line with a colinline color=redour/inlineed word/block In this case the text layout manager cannot determine a break after col, only the line layout manager can work out a suitable break point or hyphenation. (I don't know what your code does but this is why I simply get areas from the text layout manager) Right, I know about this case. That's handled in status flags that I pass back in the BreakPoss object which say if it's really possible to break after the returned position. When a break represents the end of an FO's content (col for example) and it doesn't end on a space or some other potential line-end character, the flags is set to indicate that this isn't a legal breakpoint. So the Line (or Inline level) LM will keep asking for more BreakPoss until it gets one where it can break (after ed in your example). Then it will see if can fit that into the available space. If it can't, it will try to hyphenate coloured. I thought that through some while back but didn't actually write code. It has to collect the characters from all the layout managers which contributed to the word, whatever their level, do the hyphenation, and then figure out which LM was responsible for the part containing the hyphen. Obviously rather complicated, but this is one of those difficult test cases. For now, I didn't even commit the inline stacking LM, but it's basically a simplified version of LineBPLayoutManager. It never tries to figure out whether a BreakPoss returned by one of its child LM actually fits, it just wraps it with its own space requirements and returns that to its parent. 12. This is the idea of the range properties. I can see how putting everything in a single inline area could be useful as long as other things are easily transparent. I was thinking of getting this information from the inline layout managers so that the line layout manager can deal with it appropriately. OK, I figured I had overlooked something. I see you addressed this in your mail with start and end properties. Would it be fair to think of these as some kind of layout control characters at the text level? Since I started working on FOP, I've thought of lots of schemes to try to correctly handle the space information at different tree levels, especially in combination with conditional space, border and padding. I never came up with a good way of doing it using the flat model, but that doesn't mean there isn't one. I'll have to think through how these properties would be used and whether they will handle the hard test cases like a couple of levels of nested inlines with various space-start/space-end and borders. We'll basically have the same issues with block-level LM in any case, except that it's more common to nest at that level. Especially since users often tend to reflect the nesting of their original XML document in the FO they generate. *** I think this is clearly the key issue to decide in this round of discussions: flattened or nested. 3. Ideally the layout process should start as soon as the first block is ended (no matter how deep it is). So something like, when starting a block level element the layout manager is added to the parent, when a block level element is
