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
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
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
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
Arnd, I just tried the 642 build, and it does export SVG. Unfortunatley, it does not import. Peter Arnd Beißner wrote: >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. > > > - 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]
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
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
> -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, 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
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: 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
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
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
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
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
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, 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
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
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
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
> -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
On 2002.05.03 04:56 Peter B. West wrote: > 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? I'm not subrscibed either. Looking at the archives it seems most discussions are about xslt. 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. It seems to me that the spec writers are not as involved as they should be. I just ran the spec through FOP. It seems to work okay (along with a number of unimplemented features and large memory usage). - 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
Karen, Comments below. Karen Lease wrote: >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. 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. > >- > >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. >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! > It's not just curious, it's contradictory. I have come around to Arved way of thinking on the behaviour of blocks in inline-areas, but the only way that I can see to do it is to change the relevant part of 4.7.3 to read: An inline-level formatting object F which constructs one or more inline-areas does so by placing normal inline-areas *and/or normal block areas* and/or anchor inline-areas returned to F by its child formatting objects as children of inline-areas which it generates. 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 will be guaranteed by the partitioning arrangements of 4.7.3. The difference from 4.7.2 will be that these blocks will be wrapped in an inline-area generated by the fo:inline, which will in turn be wrapped in a line-area, exactly as per Arved's diagram. However, as far as I can tell, this last level of wrapping is done by the parent fo:block in the process of laying out the inline-areas that are being returned by the the fo:inline. The decision to return a separate inline-area wrapping a block-area is made entirely by the fo:inline (or fo:basic-link). By the time the block gets to the parent block for layout, it is an inline area, and the only reason it is laid out in its own line-area is the constraint (from 6.6.7 fo-inline) that "no area may have more than one normal child area returned by the same fo:inline formatting object." The same constraint applies to fo:basic-link. 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? >As Keiron says, if the spec writers had been clearer, we wouldn't have >to spend hours chasing our tails like this! > Or, alternatively, if they would clarify these questions in a timely manner. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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, 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. 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. - 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. 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! 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 > > > Name: complex_block.png >complex_block.pngType: PNG Image (image/png) > 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
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]
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: > > > > > > Some text a paragraph of textwith a > > > blockand more text and > background="blue">blue > > > background green text a block > more > > > green > > > > > > 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. Th
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
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 > > a paragraph of text with a block and more > text > > 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]
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 a paragraph of text with a block and more text 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; > > http://www.w3.org/TR/2000/CR-SVG-2802/DTD/svg-2802.dtd";> outer block line-area basic-link inline-area glyph inline-areas inline inline-area inner block block-area S o ... x t a r a p a ... x t Block details . - 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:
> >
> > Some text a paragraph of textwith a
> > blockand more text and background="blue">blue
> > background green text a block more
> > green
> >
> > 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;
_If_ there were blocks nested inside the
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
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]
