DO NOT REPLY [Bug 32253] - Marker bugs

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32253


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2004-12-07 21:12 ---
Removed RetrieveMarkerLM. The LMs of the marker children are attached in the LM
tree as the direct children of the LM of the parent of the RetrieveMarker.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: [Bug 32253] - Marker bugs

[Simon Pepping]

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

DO NOT REPLY [Bug 32253] - Marker bugs

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32253





--- Additional Comments From [EMAIL PROTECTED]  2004-11-30 21:23 ---
Committed a fix in Marker, which cures the ClassCastException in
Marker.rebind(). Now all markers lead to a ClassCastException in
RetrieveMarkerLM.getNextKnuthElements(), line 81. This should be cured by
removing the LMs for fo:marker and for fo:retrieve-marker:

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

(Luca Furini at fop-dev)


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

RE: [Bug 32253] - Marker bugs

[Andreas L. Delmelle]

> -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

[Simon Pepping]

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

[Simon Pepping]

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

[Andreas L. Delmelle]

> -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

[Andreas L. Delmelle]

> -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

[Luca Furini]

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

[Simon Pepping]

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

[Andreas L. Delmelle]

> -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

[Andreas L. Delmelle]

> -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

[Simon Pepping]

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

[Andreas L. Delmelle]

> -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

[Luca Furini]

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

[Simon Pepping]

> --- 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

[Simon Pepping]

> --- 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

DO NOT REPLY [Bug 32253] - Marker bugs

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32253





--- Additional Comments From [EMAIL PROTECTED]  2004-11-16 00:56 ---
Yes! I just *knew* there was a much more obvious way of testing that.

Thanks Glen (--still enjoying himself in Vegas, I presume?)


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 32253] - Marker bugs

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32253





--- Additional Comments From [EMAIL PROTECTED]  2004-11-16 00:45 ---
[Andreas]

>Then test:
>if( childNode.getClass().equals("class org.apache.fop.fo.FOText") )

Just using instanceof (i.e., childNode instanceof FOText) should be
sufficient--I implemented a similar change in fo.flow.Block when I switched text
nodes from FObj to FONode.

Thanks, (and sorry for the oversight--let me know if I can be of help here)
Glen

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 32253] - Marker bugs

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32253





--- 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?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 32253] - Marker bugs

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32253





--- Additional Comments From [EMAIL PROTECTED]  2004-11-15 22:53 ---
...but this leads to yet another CCE, this time in 
  RetrieveMarkerLM.getNextKnuthElements() line 82


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 32253] - Marker bugs

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32253





--- Additional Comments From [EMAIL PROTECTED]  2004-11-15 22:44 ---
On second thought... simply using:

if( childNode.getName() == null )

seems even better to test whether it's an FObj.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 32253] - Marker bugs

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32253





--- Additional Comments From [EMAIL PROTECTED]  2004-11-15 22:38 ---
Thanks for the assist, Simon.

I noticed the problem in Marker.rebind() as well... and was wondering

Since:
1. all FObjs are also FONodes
2. FOText has its own bind() method

maybe we could cast i.next() to FONode first, to check the base class:
FONode childNode = (FONode) i.next();

Then test:
if( childNode.getClass().equals("class org.apache.fop.fo.FOText") )

And based upon the result of that test, cast to either FObj or FOText...

Sound like a good idea, or would this be classified as 'sloppy'?
(Alternative could be to try-and-catch the ClassCastException, but IIRC this is 
considered bad practice...)

BTW: stumbled upon the Joerg's favourite dreadful nested 'block-inline-block' 
problem --which throws ClassCastExceptions in InlineLayoutManager

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 32253] - Marker bugs

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32253





--- Additional Comments From [EMAIL PROTECTED]  2004-11-15 22:06 ---
I implemented InlineLevelLM in RetrieveMarkerLM. That cures some of the
ClassCast Exceptions. The exceptions in Marker.rebind are due to the recent
change of FOText from FObj to FONode. That change has not yet been made in this
method.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 32253] - Marker bugs

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32253





--- Additional Comments From [EMAIL PROTECTED]  2004-11-15 20:30 ---
Created an attachment (id=13470)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=13470&action=view)
FO to demonstrate described problems


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.