Cart
[Home] [By Thread] [By Date] [Recent Entries]
At 2007-10-29 22:45 +0200, Khaled Aly wrote:
I've got this little problem of producing Fo ToC entries' hyper-links to their respective pages (or page positions). The DTD has no ID type attributes that could be used in the xslt based on their xml document element associations. You can create your own ID value for any node by using the generate-id() function. But reading on I see that you've already figured that out. They aren't random. By omitting an argument to generate-id() it is acting on the current node, and in both cases your current node is the same, so you are getting the same result. are paired to match for a number of page/section title elements, while they were created independently, but it works! Because you so very strategically (I'm sure!) ensured the same current node each time, it worked as needed. What I can't get to work is the use of fo:basic-link with an internal-destination attribute so that the page corresponding to a title can be reached by clicking its ToC title. I assigned the following value to the internal-destination attribute: <xsl:value-of select="child::node()/@id"/> (the subject fo:block is the only child). But the *.fo file comes with an empty id. That's what I get in proper fo positions: <fo:basic-link internal-destination=""/>. But XSLT instructions act on the source tree, not the result tree. You say "the subject fo:block is the only child", but that cannot be true because the XSL-FO is in your result tree ... the child axis is relative to the current node in the source tree. Is it that the @id is not known/generated at this early point of processing where the template being applied is the root, or is there something v. basic wrong with my xpath expression? I think you are just not thinking from the right perspective. You state you are at the root, but that isn't true if you are in the middle of processing a TOC entry for a descendent section construct. I hope I managed to describe this clearly as I couldn't find it v. practical to cite just the relevant code. It seems to me that this should be a typical issue with a standard solution. Just the implementations may be different. It is quite typical: do all the work in the TOC with your current node being the node that will subsequently be processed in the body, then when processing the body do the corresponding work with the same node as being current. Or, if not current in either case, addressable. Many thanks. ka The specification is written such that stylesheet writers don't need to know the internals. They are irrelevant to a portably-written stylesheet. towards resolving all template rules and generating the complete output tree? Some things are intuitively clear but some cases, may be like my above issue, cannot be guessed (at least as it seems to me!). The specification describes the functionality of all functions, including generate-id() ... I think it is just a matter of getting familiar with their use. You shouldn't have to know the internals at all. I don't even think about the internals, except perhaps keeping in mind stylesheet-writing optimizations that would enable tail-recursion to be used by the processor. I could find general descriptions to different xslt processing aspects, but failed to find a complete algorithm-like description that leaves little room for ambiguities. The spec has little room for ambiguities, as all the conforming processors are evidence. The internals are purposefully not specified so that innovation can prevail by processor writers. I hope this is helpful ... if you think you need to know the internals, then you probably just need practice to be more familiar with the behaviour of all of the function library. . . . . . . . . . . . Ken -- Comprehensive in-depth XSLT2/XSL-FO1.1 classes: Austin TX,Jan-2008 World-wide corporate, govt. & user group XML, XSL and UBL training RSS feeds: publicly-available developer resources and training G. Ken Holman mailto:gkholman@xxxxxxxxxxxxxxxxxxxx Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/ Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995) Male Cancer Awareness Jul'07 http://www.CraneSoftwrights.com/s/bc Legal business disclaimers: http://www.CraneSoftwrights.com/legal
|
