OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: DOCBOOK-APPS: 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-----


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC