Re: warning about ignored span attributes (was: problem with identity comparison in types inheriting from org.apache.fop.fo.FONode)

[Jeremias Maerki <de...@greenmail.ch>]

I've seen such a warning in another FO implementation and thought this
woud be a nice service for our users. I didn't give the implications
much thought. Should I remove the check?

On 26.06.2005 16:13:39 Glen Mazza wrote:
> BTW, Jeremias--the recent warning you added to the 
> code on ignoring an span attribute on an fo:static-content descendant.  
> Keep in mind, it may end up *not* being ignored for three reasons:  (1) 
> layout may someday allow fo:static-content to be redirected to the 
> fo:region-body (where span values become relevant), although FOP 
> currently raises an error when that occurs; (2) There are some XSL 
> functions which allow you to reference the property value on that FO; 
> and (3) the span attribute could be inherited by 
> fo:instream-foreign-object that an fo:block encloses.  Personally, I 
> think this warning is not really needed (it is a given from the spec 
> that multiple columns aren't supported in side regions), or would better 
> be placed in layout (query the span attribute from SCLM and complain if 
> not "1" or "all".)



Jeremias Maerki

Re: warning about ignored span attributes

[Jeremias Maerki <de...@greenmail.ch>]

You've convinced me. I'm goint to revert that change.

On 26.06.2005 18:22:30 Glen Mazza wrote:
> I would recommend its removal, but am OK with it if you wish to keep it in.
> 
> The warning message says: "Ignoring span attribute on <whatever> as it's 
> not a direct child of an fo:flow" 
> 
> But it doesn't need to be a direct child of an *fo:flow* in 
> particular--just a flow (fo:flow or fo:static-content).  The spec says 
> 7.20.4:  "This only has effect on areas returned by a flow; e.g. 
> block-areas generated by fo:block children of an fo:flow."  I think the 
> purpose of this 7.20.4 sentence to prohibit using the "span" attribute 
> for areas not returned by flows:  such as bookmarks, page sequence 
> titles, and the like.

I disagree here. I believe the 7.20.4 comment is to limit the use of
"span" to make the implementation easier. This way we can simply check
all child LMs in the FlowLM for "span" changes before the element lists
are generated. The restriction doesn't prohibit anything. It only says
where the property has no effect.

> Another issue is that the fo:blocks enclosing an fo:external-graphic may 
> have been generated by XSLT, and may end up having a "span" value of 
> "all" by default on all of them as a result (so that the graphic may 
> look the same whether being sent to either a multi-column 
> fo:region-body, a single-column fo:region-body, or a one-column 
> side-region.) Here, the user would fully expects "span" to be ignored 
> anyway for side regions.
> 
> Glen
> 
> 
> Jeremias Maerki wrote:
> 
> >I've seen such a warning in another FO implementation and thought this
> >woud be a nice service for our users. I didn't give the implications
> >much thought. Should I remove the check?
> >
> >On 26.06.2005 16:13:39 Glen Mazza wrote:
> >  
> >
> >>BTW, Jeremias--the recent warning you added to the 
> >>code on ignoring an span attribute on an fo:static-content descendant.  
> >>Keep in mind, it may end up *not* being ignored for three reasons:  (1) 
> >>layout may someday allow fo:static-content to be redirected to the 
> >>fo:region-body (where span values become relevant), although FOP 
> >>currently raises an error when that occurs; (2) There are some XSL 
> >>functions which allow you to reference the property value on that FO; 
> >>and (3) the span attribute could be inherited by 
> >>fo:instream-foreign-object that an fo:block encloses.  Personally, I 
> >>think this warning is not really needed (it is a given from the spec 
> >>that multiple columns aren't supported in side regions), or would better 
> >>be placed in layout (query the span attribute from SCLM and complain if 
> >>not "1" or "all".)
> >>    
> >>
> >
> >
> >
> >Jeremias Maerki
> >
> >
> >  
> >



Jeremias Maerki

Re: warning about ignored span attributes

[Glen Mazza <gm...@apache.org>]

I would recommend its removal, but am OK with it if you wish to keep it in.

The warning message says: "Ignoring span attribute on <whatever> as it's 
not a direct child of an fo:flow" 

But it doesn't need to be a direct child of an *fo:flow* in 
particular--just a flow (fo:flow or fo:static-content).  The spec says 
7.20.4:  "This only has effect on areas returned by a flow; e.g. 
block-areas generated by fo:block children of an fo:flow."  I think the 
purpose of this 7.20.4 sentence to prohibit using the "span" attribute 
for areas not returned by flows:  such as bookmarks, page sequence 
titles, and the like.

Another issue is that the fo:blocks enclosing an fo:external-graphic may 
have been generated by XSLT, and may end up having a "span" value of 
"all" by default on all of them as a result (so that the graphic may 
look the same whether being sent to either a multi-column 
fo:region-body, a single-column fo:region-body, or a one-column 
side-region.) Here, the user would fully expects "span" to be ignored 
anyway for side regions.

Glen


Jeremias Maerki wrote:

>I've seen such a warning in another FO implementation and thought this
>woud be a nice service for our users. I didn't give the implications
>much thought. Should I remove the check?
>
>On 26.06.2005 16:13:39 Glen Mazza wrote:
>  
>
>>BTW, Jeremias--the recent warning you added to the 
>>code on ignoring an span attribute on an fo:static-content descendant.  
>>Keep in mind, it may end up *not* being ignored for three reasons:  (1) 
>>layout may someday allow fo:static-content to be redirected to the 
>>fo:region-body (where span values become relevant), although FOP 
>>currently raises an error when that occurs; (2) There are some XSL 
>>functions which allow you to reference the property value on that FO; 
>>and (3) the span attribute could be inherited by 
>>fo:instream-foreign-object that an fo:block encloses.  Personally, I 
>>think this warning is not really needed (it is a given from the spec 
>>that multiple columns aren't supported in side regions), or would better 
>>be placed in layout (query the span attribute from SCLM and complain if 
>>not "1" or "all".)
>>    
>>
>
>
>
>Jeremias Maerki
>
>
>  
>