This is the mail archive of the
docbook-apps@lists.oasis-open.org
mailing list .
Re: Getting revhistory/revision[1]/revnumber on atitlepage
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
/ Bob Stayton <bobs@caldera.com> was heard to say:
| On Wed, Jan 22, 2003 at 03:37:16PM -0600, David Cramer wrote:
|> Sigh. I still don't really understand the titlepage template system. I'm trying to get the first (in document order) revnumber onto the titlepage like so:
|>
|> <t:titlepage-content side="verso">
|> <releaseinfo fo:font-size="8pt"/>
|> <!-- Trying to get it to put only the revnumber for
|> the first revision in document order -->
|> <revhistory>
|> <revision predicate="[1]">
|> <revnumber fo:font-size="8pt"/>
|> </revision>
|> </revhistory>
You can do this:
<t:titlepage-content side="verso">
<releaseinfo fo:font-size="8pt"/>
<!-- Trying to get it to put only the revnumber for
the first revision in document order -->
<revhistory/>
...
And then add a template:
<xsl:template match="revhistory" mode="?book?.titlepage.verso.mode">
<!-- do whatever you want here, such as: -->
<xsl:apply-templates select="revision[1]/revnumber"/>
</xsl:template>
|> When I generate an xsl from this, it seems like it's
|> starting to do what I want, but not quite. There's no
|> template matching revision or revnumber in
|> book.title.page.verso.auto.mode. I would expect it to
|> create a template matching revision that in turn applies
|> templates to revnumber (and one matching revnumber that
|> puts the contents of revnumber in a fo:block with
|> font-size="8pt" in the output. The result is the same using
|> 1.59.2 and older titlepage.xsls.
It could work that way, but asking the template stuff to process ever
deeper levels would make it that much more complex.
| Well, that is how is *should* work, but that isn't
| how it currently *does* work. Child elements need to
| be placed inside <t:or> containers to work. In the
| case of authorgroup, for example:
|
| <authorgroup fo:space-before="2in">
| <t:or>
| <author/>
| <editor/>
| </t:or>
| </authorgroup>
|
| But in your case, it would be:
|
| <revhistory>
| <t:or>
| <revision predicate="[1]">
| <revnumber fo:font-size="8pt"/>
| </revision>
| </t:or>
| </revhistory>
|
| I don't know if the <revnumber> grandchild needs its
| own <t:or> container or not. I never tried that.
| You might experiment with it.
Grandchildren aren't processed.
| I looked at the code back in December and it looks like
| <t:or> is simply there to select children. So I suggested
| to Norm that it be removed, and just process the children as
| such. Unfortunately, I never found the time to implement
| the change.
Now that I look a little more closely, I see what t:or was for:
<para>Usually, the elements so named are empty. But it is possible to
make one level of selection within them. Suppose that you want to
process <literal>authorgroup</literal> elements on the title page, but
you want to select only proper authors, editors, or corporate authors,
not collaborators or other credited authors.</para>
<para>In that case, you can put a <literal>t:or</literal> group inside
the <literal>authorgroup</literal> element:
<screen><![CDATA[
<t:titlepage-contents side="recto">
<!-- other titlepage elements -->
<authorgroup>
<t:or>
<author/>
<editor/>
<corpauthor/>
</t:or>
</authorgroup>
<!-- other titlepage elements -->
</t:titlepage-contents>
]]></screen>
</para>
But in the absence of t:or, it might or might not make sense to
process all the children because what you really might want to do is
process the element.
Be seeing you,
norm
- --
Norman Walsh <ndw@nwalsh.com> | The hour which gives us life
http://www.oasis-open.org/docbook/ | begins to take it away.--Seneca
Chair, DocBook Technical Committee |
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>
iD8DBQE+L90OOyltUcwYWjsRAtRCAJ9OFhKXyvFgur9RnNpnQaaiDFYaPgCfbibP
KYPqBOW2fzdRtu9xAxoNPPQ=
=YVvN
-----END PGP SIGNATURE-----