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] | [List Home]


Subject: Re: [docbook-apps] Finding out if an element is processed as part of an xref text


Hi Stefan,
The stylesheet templates try to keep track of the context for processing a title, but it seems it does not go down far enough to reach the inlines within a title.

An xref is resolved by determining the element type of the target and getting a text template for it from the l10n gentext machinery (for an xref to section, the English default is "the section called %t"). Then it calls 'substitute-markup' (located in common/gentext.xsl), which parses that text template and replaces %t with the title text for the section. When it calls 'substitute-markup', it passes the template param purpose="xref". So far, so good.

In 'substitute-markup', it processes the section title in mode="title.markup" without passing $purpose, saves the result into a param named 'title', and then applies templates to the section in mode="insert.title.markup", passing both $title and $purpose as template params. But this title is already 'cooked' without your changes.

The mode="insert.title.markup" (in fo/xref.xsl) looks like this:

<xsl:template match="*" mode="insert.title.markup">
  <xsl:param name="purpose"/>
  <xsl:param name="xrefstyle"/>
  <xsl:param name="title"/>

  <xsl:choose>
    <xsl:when test="$purpose = 'xref'">
      <xsl:copy-of select="$title"/>
    </xsl:when>
    <xsl:otherwise>
      <xsl:copy-of select="$title"/>
    </xsl:otherwise>
  </xsl:choose>
</xsl:template>

At this point, the context element is still the target section, and $purpose is set to 'xref'. If you customize this template in the first xsl:choose clause, you can change only the behavior when xref is used.

You should ignore the $title param that is passed in, and reprocess the context element to format its title the way you want it to. You can replace mode="title.markup" with a custom mode that passes along $purpose. Then $purpose can be passed further down into processing the inlines. But you'll need to customize the template for any inline you want to use so it accepts a $purpose param so it can act on it.

Let me know if you need further clarification.

Bob Stayton
Sagehill Enterprises
bobs@sagehill.net

On 7/23/2014 12:03 PM, Stefan Knorr wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi again,

so... we are trying to create nice-looking PDF documents with nice
fonts that are displayed with matching x-heights (i. e. when mixing
different fonts on the same line, the height of the lowercase letters
should always be the same). We need a solution that works with FOP
(and XEP) which has led to me manually having to find out factors to
multiply font sizes with... and now it works, mostly.

We are using the usual three different fonts:
+ "Serif" for running text
+ "Sans" for titles and ToC
+ "Mono" for code examples, command, etc.

When adding another font within the running text, as needs to be done
for e.g. commands in a para, I am using em units. FO output could e.g. be:
     <fo:block font-size="12pt">
       This was a DocBook para with a
       <fo:inline font-size="0.89em">command</fo:inline>
       in it.
     </fo:block>

Since titles are usually in the sans-serif font, but running text is in
the serif font, I need different em sizes for each to make the mono font
appear well-adjusted in either.

However, there is an issue with xrefs: they are generally displayed in a
serif font, but usually reference a title. Sometimes that title contains
a monospaced elements like a command. But when I process that monospaced
element, I can't see that I am processing it for a xref.

I tried using no.anchors.mode to determine whether I was within an xref
but that seems to be set for every title now, somehow (not sure if my
code was always faulty or this is something that has changed with a
DocBook update).

Any ideas on how resolve this?


Thanks in advance,

Stefan.


- --
SUSE LINUX Products GmbH, Maxfeldstraße 5, D-90409 Nürnberg
Geschäftsführer: Jeff Hawn, Jennifer Guild, Felix Imendörffer
HRB 16746 (Amtsgericht Nürnberg)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlPQBvUACgkQ5AP3bIqhlM2mAwD/cBppihbbtF4cvG4zzYQ5JVWm
vDxDidQxFyZM4SX70gMBAK3+oWm3oI/XZ8uArUkJomg49EsVyTMW/EdPHqhyrfNB
=If38
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org





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