[xep-support] Any advantage of fo:wrapper as opposed to fo:inline

[G. Ken Holman]

At 2006-04-23 22:06 -0500, Louis Meigret wrote:
>Is there any advantage of using fo:wrapper instead of fo:inline ? 
>Faster ? Lighter ?

The XSL-FO processing model has a crucially-important step called 
"refinement" that determines from the properties of the formatting 
object tree which traits are to be used in the refined object tree.

A stylesheet writer strategically places inheritable-property 
specifications in the formatting object tree so that these traits are 
where they are desired in the refined tree.

I see the wrapper element merely as a housekeeping construct for 
generating branches in the formatting object tree to give the 
stylesheet writer branches on which properties can hang where the use 
of formatting objects doesn't do so.  Indeed, the wrapper provides 
this service explicitly in <multi-properties> formatting object, as 
well as implicitly anywhere in flow where the stylesheet writer needs 
to hang inherited properties.

I initially used to use <wrapper> instead of <inline> but now 
exclusively use <inline> because I couldn't always remember which 
properties where inherited and which were not.  For example, it 
doesn't make sense to use baseline-shift= on <wrapper> because the 
wrapper doesn't produce any areas and baseline-shift= is not 
inherited.  By always using <inline>, I know all of my property 
settings will be respected.

So I just use <inline> for all of my inline property settings, and I 
use <wrapper> when I need a branch in the FO tree above a bunch of 
blocks (though sometimes I'll use <block> ... without any real rules of thumb).

I gather there was some debate in the committee as to whether id= on 
the wrapper should or should not create anything in the area tree, 
and I feel it should not but I understand the committee has decided 
that it should.  The spec says that wrapper does not produce any 
areas, so why would an id= on a wrapper have any effect in the area 
tree?  Apparently this was not so obvious to many users.

As for the weight or speed of using <wrapper>, since the refinement 
step of the processing model will toss any inapplicable traits from 
formatting objects and inherit any applicable traits ... there would 
be nothing left in wrapper when refinement is done, since wrapper 
doesn't produce any areas.

Note that questions of performance related to the processing model 
are moot as XSL-FO processors are *not* required to implement the 
processing model as defined ... they are allowed to implement any 
processing model they wish, provided the end result is *as if* they 
had implemented the processing model as defined.

I hope this helps.

. . . . . . . . . . . . Ken

--
Registration open for XSLT/XSL-FO training: Wash.,DC 2006-06-12/16
Also for XSLT/XSL-FO training:    Minneapolis, MN 2006-07-31/08-04
Also for XML/XSLT/XSL-FO training:Birmingham,England 2006-05-22/25
Also for XSLT/XSL-FO training:    Copenhagen,Denmark 2006-05-08/11
World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman                 mailto:gkholman at CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/f/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/f/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal

-------------------
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to majordomo at renderx.com from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/terms-of-service.html