Re: [Bug 32253] - Marker bugs
Hi, The NIST test suite has no example of an fo:block within an fo:inline element. Neither does the XSL spec have an example. Apparently the construction is not very popular. I have read through the XSL spec, sections 4.4. Block Areas, 4.5. Line Areas, 4.6. Inline Areas, and especially 4.7.2. Line building and 4.7.3. Inline building. See esp. items 1, 3, and 5 of the rules for the partitioning. I believe the following areas should be created: A block inside another block Normal text inner block normal text. creates: Block area -+-- Line area +-- Character areas | +-- Block area +-- possibly Line area etc. | +-- Line area +-- Character areas A block inside an inline inside a block Normal text inline text 1 inner block inline text 2 normal text. creates: Block area -+-- Line area +-- Character areas | +-- Inline area -- Character areas | +-- Line area +-- Inline area -- Block area +-- Line area etc. | +-- Line area +-- Inline area -- Character areas +-- Character areas The fo:inline creates three inline areas, one with the text 'inline text 1', one with the block area, and one with the text 'inline text 2'. The outer block arranges the inline areas from its PCDATA and those returned by its fo:inline child into lines. Note also that the inner block area behaves as a child of the inline area with respect to such traits as the border and the background traits. As a conclusion I believe InlineLM must be modified to handle the BPs returned by a block-area generating child. Perhaps it should wrap them in a Knuth Box of the appropriate width, or in a new class of Knuth Element, which LineLM would know that it should be placed on a line of its own. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
RE: [Bug 32253] - Marker bugs
> -Original Message- > From: Simon Pepping [mailto:[EMAIL PROTECTED] > > [Me:] > > which is then supposed to be rendered as two very > > large letters 'A' and 'B' with, for example, a story > > in very small letters in between. > > The layout you describe can be achieved using an inline-container, I > believe. > Yes! Of course. To be honest, I thought of this example only when I was just about done typing up the message with the thought that the XSL-FO Rec was IMHO making a conceptual error in allowing block-level elements nested inside inlines, but... > I believe the above is in fact a common layout pattern. It describes a > displayed equation in the middle of a paragraph. The second example > adds some layout characteristics, like specifying a different color, > font size, etc. ... to accommodate this, would indeed seem to be exactly *the* reason *why* it was allowed in the first place. Greetz, Andreas
Re: [Bug 32253] - Marker bugs
On Fri, Nov 19, 2004 at 06:22:35PM +0100, Luca Furini wrote: > A block inside another block > > Normal text inner block normal text. > > creates 3 different paragraphs: > - Normal text > - inner block > - normal text. > and each paragraph's layout is unrelated to the other paragraphs' layout > (there are 3 LineLM). The 'normal text' is not indented, which makes it a 'continuation paragraph'. > A block inside an inline inside a block > > Normal text inline text 1 > inner block inline text 2 normal > text. > > creates: > a) 3 different paragraphs too: > - Normal text inline text 1 > - inner block > - inline text 2 normal text. > or > b) a single paragraph with all the text: > - Normal text inline text 1 inner block inline text 2 normal text. > ??? > > I'd say a), but I'm not sure. > If this were true, there should be 3 different LineLMs. I would say so too. I think that is what the spec prescribes for fo:block. The fo:block is positioned w.r.t. the current reference area, not w.r.t. the containing fo:inline. That makes it very similar to the first example. I believe the above is in fact a common layout pattern. It describes a displayed equation in the middle of a paragraph. The second example adds some layout characteristics, like specifying a different color, font size, etc. > This is the LM tree at the moment: > > BlockLM1 > | > LineLM1 > | >-+- >||| > TextLM InlineLM TextLM > "Normal text" | "normal text." > | >-+- >||| > TextLM BlockLM2 TextLM > "inline text 1" | "inline text 2" > LineLM2 > | > TextLM > "inner block" > > LineLM1 tries to have get elements from all its chidren, and fails. > > But, even if it could be given the elements representing "inner block", it > could layout them wrongly, because of the block properties: the inner > block could have different alignment, borders, margins, indents, > > So, the LM tree could be: > > BlockLM1 > --+- > | || >LineLM BlockLM2 LineLM >--+--| -+- >| || | | > TextLM InlineLM LineLM InlineLMTextLM > "Normal text" || |"normal text." >|| | > TextLM TextLM TextLM >"inline text 1" "inner block" "inline text 2" > > This modified tree can be "easily" obtained from the previous one: > - the new BlockLM is created > - if the LM which should add it to its children list is an InlineLevelLM > or a LineLM, the new BlockLM is given to its parent, i.e. it will become a > child of the nearest BlockLM ancestor > - an instance of the LM which could not handle the new BlockLM (in the > example, InlineLM son of LineLM) must be created in order to handle inline > siblings of the inner fo:block. The third LineLM is not easy to program. Moreover, it has to know the requirement that it does not start with an indent. I think the first hierarchy is preferable and can be made to handle the situation as follows. The LineLM needs to be able to deal with paragraphs and blocks. InlineLM's getNextKnuthElements should signal the end of the paragraph (same as forced linefeed?) if it encounters a block-area generating child LM. The next call to it should call the child LM's getNextBreakPoss method, and return the BPs for the lines in the block. InlineLM's getNextKnuthElements would return KnuthElements and BPs. How can these return types be mixed? LineLM's getNextBreakPoss would collect the returned KnuthElements in paragraphs, and determine the BPs in it. It would store the BPs received from its children unmodified. The inner block would create its own areas, with proper alignment, borders, margins, indents, etc. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: [Bug 32253] - Marker bugs
On Fri, Nov 19, 2004 at 08:14:35PM +0100, Andreas L. Delmelle wrote: > > -Original Message- > Hi, > > My very first thought was a) too, but then again, I'm still wondering what > the intention is of allowing this sort of block-inline-block nesting in the > first place. > I'm unsure what the difference *should* be between the above and the case > where the inner block is *not* nested inside an fo:inline... Not much I think. An inline in a block is usually used to specify different properties for its content. > Since it is allowed by the spec: what is the intended effect of having a > block/list-block/table nested inside an inline? > > Maybe something like this makes it clearer: > > A > > > > > > B > > > which is then supposed to be rendered as two very large letters 'A' and 'B' > with, for example, a story in very small letters in between. (Although one > could argue that a similar effect can be achieved by a three column table > where the first and third column contain the two large letters, and the > second column contains the story...) I do not think that is the correct layout. It should be a large A on a line, followed by any text with which the inline would start (none in your example). Then the block would have its own full text width block area. Then there would be more lines with the ending text of the inline (none in your example) and a large B. The layout you describe can be achieved using an inline-container, I believe. > If this was the intention, then the proposed 'handing off the BlockLM to the > ancestor BlockLM' wouldn't work... :-( There may well be several ways in which the user can specify a certain layout. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
RE: [Bug 32253] - Marker bugs
> -Original Message- > From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED] > Just noticed a slight error... > Maybe something like this makes it clearer: > > A > > The smaller font-size should be added as a property to the inner block instead of to the inline.
RE: [Bug 32253] - Marker bugs
> -Original Message- > From: Luca Furini [mailto:[EMAIL PROTECTED] > Hi, > A block inside an inline inside a block > creates: > a) 3 different paragraphs too: > b) a single paragraph with all the text: > I'd say a), but I'm not sure. My very first thought was a) too, but then again, I'm still wondering what the intention is of allowing this sort of block-inline-block nesting in the first place. I'm unsure what the difference *should* be between the above and the case where the inner block is *not* nested inside an fo:inline... Since it is allowed by the spec: what is the intended effect of having a block/list-block/table nested inside an inline? Maybe something like this makes it clearer: A B which is then supposed to be rendered as two very large letters 'A' and 'B' with, for example, a story in very small letters in between. (Although one could argue that a similar effect can be achieved by a three column table where the first and third column contain the two large letters, and the second column contains the story...) If this was the intention, then the proposed 'handing off the BlockLM to the ancestor BlockLM' wouldn't work... :-( Greetz, Andreas
Re: [Bug 32253] - Marker bugs
Simon Pepping wrote: > Indeed. Something like ICLM is needed, which creates an inline area > containing the block areas. A block inside another block Normal text inner block normal text. creates 3 different paragraphs: - Normal text - inner block - normal text. and each paragraph's layout is unrelated to the other paragraphs' layout (there are 3 LineLM). A block inside an inline inside a block Normal text inline text 1 inner block inline text 2 normal text. creates: a) 3 different paragraphs too: - Normal text inline text 1 - inner block - inline text 2 normal text. or b) a single paragraph with all the text: - Normal text inline text 1 inner block inline text 2 normal text. ??? I'd say a), but I'm not sure. If this were true, there should be 3 different LineLMs. This is the LM tree at the moment: BlockLM1 | LineLM1 | -+- ||| TextLM InlineLM TextLM "Normal text" | "normal text." | -+- ||| TextLM BlockLM2 TextLM "inline text 1" | "inline text 2" LineLM2 | TextLM "inner block" LineLM1 tries to have get elements from all its chidren, and fails. But, even if it could be given the elements representing "inner block", it could layout them wrongly, because of the block properties: the inner block could have different alignment, borders, margins, indents, So, the LM tree could be: BlockLM1 --+- | || LineLM BlockLM2 LineLM --+--| -+- | || | | TextLM InlineLM LineLM InlineLMTextLM "Normal text" || |"normal text." || | TextLM TextLM TextLM "inline text 1" "inner block" "inline text 2" This modified tree can be "easily" obtained from the previous one: - the new BlockLM is created - if the LM which should add it to its children list is an InlineLevelLM or a LineLM, the new BlockLM is given to its parent, i.e. it will become a child of the nearest BlockLM ancestor - an instance of the LM which could not handle the new BlockLM (in the example, InlineLM son of LineLM) must be created in order to handle inline siblings of the inner fo:block. I hope this can help ... Regards, Luca
Re: [Bug 32253] - Marker bugs
On Wed, Nov 17, 2004 at 10:03:54PM +0100, Andreas L. Delmelle wrote: > > -Original Message- > > From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED] > > > > > That would definitely solve the second case, but still leaves the first. > > > > Hmm.. On second thought, that would ultimately depend on: > - the parent of fo:retrieve-marker > - the child of fo:marker > > if > > > > > > is combined with > > > ... > That is a good catch. > It boils down to the first case, so that seems to be the most important one > to solve. Indeed. Something like ICLM is needed, which creates an inline area containing the block areas. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
RE: [Bug 32253] - Marker bugs
> -Original Message- > From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED] > > That would definitely solve the second case, but still leaves the first. > Hmm.. On second thought, that would ultimately depend on: - the parent of fo:retrieve-marker - the child of fo:marker if is combined with ... It boils down to the first case, so that seems to be the most important one to solve. Greetz, Andreas
RE: [Bug 32253] - Marker bugs
> -Original Message- > From: Luca Furini [mailto:[EMAIL PROTECTED] > > > Simon Pepping wrote: Hi Luca / Simon, > > Marker extends FObjMixed, which adds InlineStackingLM. > I still have to really understand InlineStackingLM, I find it very > enigmatic! It generates inline areas, but it has LineLM as a subclass ... >From the javadoc description, I'm getting the impression that the FObjMixed class was conceived when FOText still subclassed FObj (--correct? In that case, is it still necessary?). In a nutshell, a stroll through the code shows that: The only two places where an InlineStackingLM is created are: - fop.fo.FObjMixed.addLayoutManager() - fop.layoutmgr.PageSequenceLM.getTitleArea() Now, there are eight classes extending FObjMixed: - fop.fo.flow.BidiOverride - fop.fo.flow.Block - fop.fo.flow.Inline - fop.fo.flow.Leader - fop.fo.flow.Marker - fop.fo.flow.RetrieveMarker - fop.fo.flow.Wrapper - fop.fo.pagination.Title WRT FObjMixed.addLM() these eight do the following: - BidiOverride overrides [*] - Block overrides, and adds a BlockLM instead - Inline overrides, and adds an InlineLM instead - Leader overrides, and adds a LeaderLM instead - Marker uses the superclass version - RetrieveMarker overrides and adds a RetrieveMarkerLM instead - Wrapper overrides and lets its children call addLM() (a neutral element) - Title uses the superclass version[**] [*] unsure what it does, but there's mention of moving the logic to BidiOverrideLM, so my best guess is that it would just add a BidiOverrideLM instead [**] actually, looks like it doesn't really use it at all --seems to be handled by PageSequenceLM.getTitleArea() I have, so far, confirmed two cases where trouble occurs: 1. fo:block->fo:inline->fo:block where the deeper fo:block causes a CCE because BlockLM does not implement InlineLevelLM 2. fo:block->fo:retrieve-marker + fo:marker where the retrieved marker causes a CCE because it adds an InlineStackingLM which does not implement InlineLevelLM ... > as a marker can only have children which could replace its > retrieve-marker, wouldn't it be better to have just: > > ... > | >parentLM >---+--- >| | > chldLM1 chldLM2 That would definitely solve the second case, but still leaves the first. Putting our heads together, we're going to get there, folks! Yes we are :-) Greetz, Andreas
Re: [Bug 32253] - Marker bugs
On Wed, Nov 17, 2004 at 02:25:02PM +0100, Luca Furini wrote: > Simon Pepping wrote: > > > Marker extends FObjMixed, which adds InlineStackingLM. This is a > > problem. In the new model there should be a strict separation between > > LMs implementing InlineLevelLM and those that do not. InlineStackingLM > > does not, and probably should not do. > > I still have to really understand InlineStackingLM, I find it very > enigmatic! It generates inline areas, but it has LineLM as a subclass ... I think it is only there as a common superclass of InlineLM and LineLM. No FO object should add this LM in its addLM method. Perhaps it should get a private constructor. Currently FObjMixed and BiDiOverride use it. > Maybe it should implement both getNextBreakPoss and getNextKnuthElements: > looking at the retrieve-marker's parent and / or at the marker's children > should be enough to decide whether to call the one or the other. > > Anyway, I was wondering whether it is really necessary to add a new LM. > > If the fo tree is > > fo:page-sequence > ---+--- > | | > fo:static-content fo:flow > | | > ... ... > | | > ret. marker's parentmarker's parent > | | > fo:retrieve-markerfo:marker > ---+--- > | | >chld1 chld2 > > at the moment, RetrieveMarkerLM tries to achieve this (in the LM tree): > > ... > | >parentLM > | > RetrieveMarkerLM > | > InlineStackingLM >---+--- >| | > chldLM1 chldLM2 > > but, as a marker can only have children which could replace its > retrieve-marker, wouldn't it be better to have just: > > ... > | >parentLM >---+--- >| | > chldLM1 chldLM2 I have been thinking along the same lines. fo:wrapper does a similar thing. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
RE: [Bug 32253] - Marker bugs
> -Original Message- > From: Simon Pepping [mailto:[EMAIL PROTECTED] Hi Simon, > ...Sorry for the inconvenience in the mean time. You must be joking! Inconvenience? Far from it. The remarks/additions so far have been very helpful. Nobody --ahem, certainly not me-- expects you to solve everything. Thanks for the pointers so far. Greetz, Andreas
Re: [Bug 32253] - Marker bugs
Simon Pepping wrote: > Marker extends FObjMixed, which adds InlineStackingLM. This is a > problem. In the new model there should be a strict separation between > LMs implementing InlineLevelLM and those that do not. InlineStackingLM > does not, and probably should not do. I still have to really understand InlineStackingLM, I find it very enigmatic! It generates inline areas, but it has LineLM as a subclass ... Maybe it should implement both getNextBreakPoss and getNextKnuthElements: looking at the retrieve-marker's parent and / or at the marker's children should be enough to decide whether to call the one or the other. Anyway, I was wondering whether it is really necessary to add a new LM. If the fo tree is fo:page-sequence ---+--- | | fo:static-content fo:flow | | ... ... | | ret. marker's parentmarker's parent | | fo:retrieve-markerfo:marker ---+--- | | chld1 chld2 at the moment, RetrieveMarkerLM tries to achieve this (in the LM tree): ... | parentLM | RetrieveMarkerLM | InlineStackingLM ---+--- | | chldLM1 chldLM2 but, as a marker can only have children which could replace its retrieve-marker, wouldn't it be better to have just: ... | parentLM ---+--- | | chldLM1 chldLM2 ? Regards, Luca
Re: [Bug 32253] - Marker bugs
> --- Additional Comments From [EMAIL PROTECTED] 2004-11-15 22:59 --- > ...due to the retrieved LM being an InlineStackingLM?? Where does that come > from? Shouldn't that be a TextLM? Marker extends FObjMixed, which adds InlineStackingLM. This is a problem. In the new model there should be a strict separation between LMs implementing InlineLevelLM and those that do not. InlineStackingLM does not, and probably should not do. The recently committed patch does raise a few questions. I think they are good questions, which need to be answered in order to implement a paragraph layout algorithm like Knuth's. Sorry for the inconvenience in the mean time. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: [Bug 32253] - Marker bugs
> --- Additional Comments From [EMAIL PROTECTED] 2004-11-15 22:53 --- > ...but this leads to yet another CCE, this time in > RetrieveMarkerLM.getNextKnuthElements() line 82 I figured that the InlineLevelLM methods would only be invoked if replaceLM is an InlineLevelLM, and otherwise getNextBreakPoss would be invoked. Apparently I am wrong, and this warrants more study than a quick solution. I do not have time to investigate this in more depth during this week. The same for the block-inline-block error. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl