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

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