From: Ronald Hayden (rhayden@apple.com)
Date: Fri Jul 25 2003 - 15:30:59 PDT
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
people...:)
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 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)
> 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: http://XMLGuild.info
> Male Breast Cancer Awareness http://www.CraneSoftwrights.com/f/bc
>
> -------------------
> (*) 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/tos.html
-------------------
(*) 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/tos.html
This archive was generated by hypermail 2.1.5 : Fri Jul 25 2003 - 15:32:18 PDT