DO NOT REPLY [Bug 29124] - New line breaking algorithm

[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=29124

New line breaking algorithm





--- Additional Comments From [EMAIL PROTECTED]  2004-08-27 19:29 ---
Luca,

The build failed. That is probably due to this line in the patch:

cvs server: I know nothing about layoutmgr/LeafNodeLaoyutManager.java

Simon

validateChildNode prevents extensions.

[Finn Bock]

Glen
I think that the new validateChildNode() methods are too strict in 
response to extension elements. My guess is that the validation should 
only occur when one fo namespace element is added to another fo element.

For instance, Block.validateChildNode() doesn't allow any of my 
extension elements as children.

regards,
finn

Re: validateChildNode prevents extensions.

[Glen Mazza]

Hello Finn,

[BTW, before I get to this topic, as you've probably
noticed by now I've finished removing the
AddLMVisitor.  In the process, I also created about
eight new layout manager classes, pulling out the
layout business logic that used to be in AddLMVisitor.
 As a result, the maker system you were suggesting
should be MUCH smaller to implement now--probably can
be kept in one class similar to [1].  Would you agree?
 If so, if you still like your suggestion--I don't
care either way--feel free to add such a maker system
in anytime--Simon also was preferring your design.]


--- Finn Bock <[EMAIL PROTECTED]> wrote:

> Glen
> 
> I think that the new validateChildNode() methods are
> too strict in 
> response to extension elements. 

Extension elements are handled within
validateChildNode() just like regular formatting
objects, such as e.g. fox:bookmarks in fo:root [2].  

We appear to have two categories of extension
elements:

1.) (svg and MathML for example):  These are
dynamically loadable extension elements that are (1)
children of fo-instream-foreign-object and (2) don't
affect layout, renderers, the area tree, etc.  (i.e.,
*no* change to FOP source code is needed in order for
these elements to work.)  FOP, in fo.FOTreeBuilder,
already has a couple of hooks for run-time discovery
and loading of such extension elements.

For these types of extension elements,
validateChildNode() doesn't hurt anything.  The vCN()
in fo-instream-foreign object just enforces, per the
spec, that there is only one child, and that it is in
a non-XSL namespace.

2.)  (fox:bookmarks, fox:outline, etc.)  These are
non-runtime-loadable extension elements that work
directly with formatting objects and whose output must
be coded within FOP proper.  (fox:bookmarks, for
example, include logic in area.AreaTreeHandler,
PDFRenderer perhaps, and additional code in the PDF
library.) Adding these elements requires not just
adding an extension element class but additional code
in layout/renderers/area objects, etc.  

For these extension elements, they have to be
validated just like the XSL FO's do:  you have to
determine which nodes can have these extension
elements as children, their location, cardinality,
etc., etc.  So for these elements, you will probably
need to subclass/rewrite the vCNs() of parents which
may have them.  (Of course, once the element is
directly incorporated into FOP, subclassing will no
longer be needed.)

But this shouldn't be a problem, because you have to
modify the renderers, layout, and/or area objects
source code anyway for the extension element to work. 
It's not like you are losing dynamic run-time
loadability here, and generally a vCN() does not add
much more to the work you have to do.  (Actually,
vCN() tends to reduce coding complexity of work
downstream.)

> My guess is that the
> validation should 
> only occur when one fo namespace element is added to
> another fo element.
> 

I don't think you mean that completely--that's too
loose.  We should be leery of a system that would
allow, say, svg:rect to be a child of fo:block.  FOP
just wouldn't be solid that way, and who would want to
maintain the Bugzilla list that would result from
that? ;)

The benefits of vCN() is to (1) stop problems at the
source, prior to creating the node, rather than risk
many Bugzilla and FOP-User ML messages of subtle
NPE/CCE problems that would otherwise occur
downstream, and (2) reduce the amount of sometimes
duplicative error checking distracting the business
logic downstream, and (3) provide a uniform
error-messaging system.  

> For instance, Block.validateChildNode() doesn't
> allow any of my 
> extension elements as children.
> 

Yes, you will need to modify it for your new element. 
But first you have to (1) define which parents your
element is good for, and (2) where they need to be
located among those parent's children.  The fact that
vCN() forces one to stop first and define these things
is IMO actually a Good Thing, and would have to be
done anyway should the element be eventually
incorporated into FOP.

(BTW, for extension elements that are valid in
multiple places, take a look at our isBlockItem(),
isInlineItem() and isNeutralItem() in [3]--you may be
able to just place your extension elements there if
they are valid in the same places that the elements
defined there are.)

Sorry for the long post.

Glen

[1]
http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/fo/FOElementMapping.java?rev=1.8&view=auto

[2]
http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/fo/pagination/Root.java?annotate=1.23#100

[3]
http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/fo/FObj.java?annotate=1.69#462