[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: DOCBOOK-APPS: Getting revhistory/revision[1]/revnumber on atitlepage
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> > <title > named-template="book.verso.title" > fo:font-size="8pt" > fo:font-weight="normal" > fo:font-family="Times Roman"/> > <pubdate > fo:font-size="8pt"/> > <legalnotice > fo:font-size="8pt" > fo:space-before="4.5in"/> > <copyright > fo:space-before="1em" > fo:font-size="8pt" > break-after="page"/> > </t:titlepage-content> > > 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. > > Am I on the right track and just missing something? Or is > this not how it's supposed to work? 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. 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. -- Bob Stayton 400 Encinal Street Publications Architect Santa Cruz, CA 95060 Technical Publications voice: (831) 427-7796 The SCO Group fax: (831) 429-1887 email: bobs@sco.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC