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] Html: suppressing separate titlepage for book/article


Hi Donna,
As you discovered, customizations of  the chunk stylesheets sometimes
produce unexpected results.  There is an explanation for what you saw, which
I provide below if you want the details.

But your customization won't do what you want anyway.  You copied the
template with match="set|book|part|article|..." from chunk-code.xsl to your
customization layer, and then removed article from the list of matches.  I
think you expected article to no longer be chunked if it didn't match in
that template.  But all you did was remove article from any template match
in your customization.  Since the processor didn't find a match on article
there, it then falls back through the imports looking for a match on
article.  And it will find it in the original
match="set|book|part|article|..." in chunk-code.xsl.  So your customization
will have no effect on article, exactly the opposite of what you intended.

Instead, you need to match on article and specify different behavior.
Unfortunately, you won't be able to use apply-imports, because that would
use the most recently imported match on article, which would again be
match="set|book|part|article|...".  What you wish you could do is specify
"apply-imports two import levels back", in order to skip the chunking
version and get the match on article in the original unchunked template (in
html/component.xsl).  But you can't do that in XSLT.

So you will need to copy the original match="article" template from
html/component.xsl to your customization layer.  Then you will get unchunked
behavior for article.

Effectively, that is what happened when you edited the original
chunk-code.xsl template.  By removing the match on article in
match="set|book|part|..." in the original chunk-code.xsl, the processor had
to fall back to the original match="article" in component.xsl, thereby
giving you unchunked behavior.

*If* the original match="article" template in component.xsl also had a
name="article" attribute, then your customization layer could just call it
by name.  That skips over the import process and gets directly to the
unchunked article template.  But it isn't named, so you cannot do it that
way.

Now the explanation of the missing output when you tried your customization.
You can skip this if you don't want all the gory details about how imports
work.

When you processed with your customization, you actually generated the HTML
chunks with the correct filenames and headers, but you saw that the content
of each file was missing.  If you had watched the process messages, you
would have seen that each element that matched in your customized template
was being processed *twice*.  The first time it generated a correct HTML
file, but the second one was empty and overwrote the first.

Here is the sequence of steps that occurred for, say, a chapter element.
You might want to look at the original templates to follow this.

1.  The processor finds a match on chapter in your customization template.
Your template calls the template named process-chunk-element.

2.  The process-chunk-element is in html/chunk-code.xsl. Because this
template was called by name, the "current template" match is still the one
from your customization.  The "current template" is the one from which
imports are selected.  The process-chunk-element template fills a variable
named "content" by using apply-imports.  The idea is to import the original
unchunked chapter template to process the chapter's title, paras, etc. and
put it into the "content" variable.  Then the process-chunk-element opens a
new file and writes that content to the file. That's the way it works in the
stock stylesheets.

3.  But when the processor goes looking for an import that matches on
chapter, it is looking at imports relative to your customization layer.  It
finds the template with match="set|book|part|article|chapter|..." in
chunk-code.xsl, because that is imported by your stylesheet.

4.  That original template in turn calls process-chunk-element by name
again.  There is only one process-chunk-element, in chunk-code.xsl.

5.   So then the second invocation of the process-chunk-code template does
apply-imports again.  But this time the "current template" starting point is
the match="set|book|part|article..." template in chunk-code.xsl.  When it
does apply-imports relative to that import level, it finds the unchunked
match="chapter" template in html/component.xsl.  That generates the HTML for
the chapter title and paragraphs and puts that into the "content" variable
as it is supposed to.

6.  Then process-chunk-element opens a new file and write the content out to
that file.  So far so good.

7.  When that second invocation of process-chunk-element returns, it is not
returning any content because it wrote it out to the file.  So the first
invocation of process-chunk-element gets nothing into its content variable.
But it still goes ahead and creates a chunk file (of the same name) and
writes the empty content to that file.  That empty version overwrites the
one that had the content.  So that is why you see the double messages about
writing those chunk files, and why they have no content.

I hope this helps you understand how this stuff works.

Bob Stayton
Sagehill Enterprises
DocBook Consulting
bobs@sagehill.net


----- Original Message ----- 
From: "Donna Robinson" <donna@terpsichore.ws>
To: <docbook-apps@lists.oasis-open.org>; "Michael Smith" <smith@xml-doc.org>
Sent: Thursday, December 01, 2005 7:18 AM
Subject: Re: [docbook-apps] Html: suppressing separate titlepage for
book/article


> Michael,
>
> > If you can edit the stylesheets directly, you only need to
> > make a one-line change:
>
> That worked a charm - exactly what I wanted.
>
> I have been working on the basis of using a customised layer, which didn't
> work at all.
>
> But - I'd like to know why it didn't.  I assume that the order in which
the
> stylesheets get imported is important, so why can't I do something like
this:
>
> <?xml version="1.0"?> <!-- -*- sgml -*- -->
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
> version="1.0">
> <xsl:import
>
href="http://docbook.sourceforge.net/release/xsl/current/html/docbook.xsl"/>
> <xsl:import
>
href="http://docbook.sourceforge.net/release/xsl/current/html/chunk-common.x
sl"/>
> <xsl:import
>
href="http://docbook.sourceforge.net/release/xsl/current/html/manifest.xsl"/
>
> <xsl:import
>
href="http://docbook.sourceforge.net/release/xsl/current/html/chunk-code.xsl
"/>
>
> <xsl:import href="my-chunk-code.xsl"/>
> ...
> </xsl:stylesheet>
>
> and have 'my-chunk-code.xsl' contain just this:
>
> <!-- Dec. 1 2005: edited to removed 'article' and 'refentry -->
> <!-- so that no separate titlepage gets generated -->
> <xsl:template match="set|book|part|preface|chapter|appendix
>                      |reference
>                      |book/glossary|article/glossary|part/glossary
>
|book/bibliography|article/bibliography|part/bibliography
>                      |colophon">
>   <xsl:choose>
>     <xsl:when test="$onechunk != 0 and parent::*">
>       <xsl:apply-imports/>
>     </xsl:when>
>     <xsl:otherwise>
>       <xsl:call-template name="process-chunk-element"/>
>     </xsl:otherwise>
>   </xsl:choose>
> </xsl:template>
>
> To my mind, this _should_ work - but in fact what I get is: nothing!
> No pages at all :(
>
> Regards,
>
> Donna
>
> -- 
> There is not a shred of evidence to suggest
> that life should be taken seriously
>
> ---------------------------------------------------------------------
> 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]