Re: [xep-support] keep-with-next for fo:wrapper?

From: Ronald Hayden (
Date: Fri Jul 25 2003 - 15:30:59 PDT

  • Next message: Kurt Werle (Consultant) PGRD: "[xep-support] render hanging"

    Thanks for the suggestion -- as I recall I originally used fo:block for
    this, but found that it did generate vertical space (even though empty)
    in certain cases, particularly in white-space-preserved environments.
    This was problematic enough that we cast around until discovering that
    a fo:wrapper would work as a link destination and truly didn't create
    any additional space on the page.

    To get into the arcane stuff that drives this:

    For simplicity and to separate code from formatting, we don't use the
    traditional XSLT approach for translating from XML to FO. Instead, we
    walk the XML tree and apply a simple mapping table, in the form of:

            Element => <opening_mapping>
            _Element => <closing_mapping>

    We use this system for both HTML and FO generation, combined with a
    template model driven by the Perl-based Petal module, and have found it
    to be much preferable to teaching our designers how to code in XSLT.
    It's not uncommon for an element to have an id that needs to be linked
    to in the TOC or Index, but to have no mapping, or to have a mapping
    that contains several HTML or FO elements. For example, a Function
    element has no mapping (its child elements have all the content), but
    the Function needs to be linked to and indexed.

    Given this, we don't have a trivial way to insert the id for an element
    into the stream when transforming the XML. There may be no resulting
    HTML/FO element to insert the id into, or there are multiple elements
    and we don't know which one should get the id. Wanting to avoid a
    requirement for the designer to specify in every mapping where the id
    goes, instead we lay down an anchor element in HTML or a fo:wrapper in
    FO that contains the necessary id.

    This has worked quite well in the past year for everything but the
    current situation: In the case of a Function, if the fo:wrapper placed
    for the function gets separated from the content for the function
    across pages, then links jump to the wrong page.

    There's more to the reasons behind all this, but I'll try to spare

    All that said, if we could either get the fo:wrapper to keep-with-next,
    or find another element that truly generates no extra space but can use
    both id and keep-with-next, our problem will be solved.

      -- Ron

    On Friday, July 25, 2003, at 2:32 PM, G. Ken Holman wrote:

    > At 2003-07-25 13:30 -0700, Ronald Hayden wrote:
    >> For reasons too arcane to get into, in our system for purposes of
    >> linking we tend to have to put the id for an element in a fo:wrapper
    >> that precedes the element, like so:
    >> <fo:wrapper id="my_element_id"/>
    > My understanding of XSL-FO is that the above is ineffectual ... I
    > understand the wrapper does not generate any areas and is merely an
    > artifact for use in the formatting object tree. It's only
    > responsibility is to be a repository of inheritable properties and
    > while id= is allowed to be specified only because id= can be specified
    > on every object, that is not inherited and has no effect in the area
    > tree.
    > Therefore, an empty <wrapper> element is, I believe (and teach my
    > students), a no-operation.
    > In its place given your example, I would use an empty <fo:block
    > id="my_element_id"/> for correctness, as this adds an area of no
    > dimension to the area tree and gives that area the identifier value.
    > Now something has actually been placed in the area tree.
    >> <fo:block>The actual element.</fo:block>
    >> This approach solves many problems for us...
    > Really? That surprises me, but I'll accept your analysis.
    >> but it presents a new problem: If the text being rendered in the
    >> fo:block in this case causes a page break to occur, the block gets
    >> separated from the associated wrapper, which causes links to jump
    >> people to the "wrong" page, and for page numbers in cross-references
    >> to be off-by-one. This occurs more often than you might think.
    >> I'd like to ensure that the wrapper stays with the block...I tried:
    >> <fo:wrapper id="my_element_id" keep-with-next.within-page="always" />
    >> But it doesn't appear to work.
    > Perhaps because there is no area in the area tree created by the empty
    > wrapper, but then I don't understand why the id would work for you as
    > you report.
    >> Any suggestions for how I can keep these two elements together?
    > Perhaps try using a <block> instead of a <wrapper>.
    > I hope this helps.
    > .......................... Ken
    > --
    > Upcoming hands-on courses: in-house corporate training available;
    > North America public: XSL-FO Aug 4,2003; XSLT/XPath Aug 12, 2003
    > G. Ken Holman
    > Crane Softwrights Ltd.
    > Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995)
    > ISBN 0-13-065196-6 Definitive XSLT and XPath
    > ISBN 0-13-140374-5 Definitive XSL-FO
    > ISBN 1-894049-08-X Practical Transformation Using XSLT and XPath
    > ISBN 1-894049-11-X Practical Formatting Using XSL-FO
    > Member of the XML Guild of Practitioners:
    > Male Breast Cancer Awareness
    > -------------------
    > (*) To unsubscribe, send a message with words 'unsubscribe xep-support'
    > in the body of the message to from the address
    > you are subscribed from.
    > (*) By using the Service, you expressly agree to these Terms of
    > Service

    (*) To unsubscribe, send a message with words 'unsubscribe xep-support'
    in the body of the message to from the address
    you are subscribed from.
    (*) By using the Service, you expressly agree to these Terms of Service

    This archive was generated by hypermail 2.1.5 : Fri Jul 25 2003 - 15:32:18 PDT