| I haven’t addressed the fo templates yet. I probably won’t be able to get to it once August hits, so will try to address them this week.
Yes, the stylesheets do try to put the Dublin Core elements and attributes in the HTML <meta> tags:
<!-- Dublin Core metadata -->
<xsl:template name="head.content.abstract" >
<xsl:param name="node" select="." />
<xsl:variable name="info"
select="(d:articleinfo |d:bookinfo |d:prefaceinfo |d:chapterinfo |d:appendixinfo |d:sectioninfo |d:sect1info |d:sect2info |d:sect3info |d:sect4info |d:sect5info |d:referenceinfo |d:refentryinfo |d:partinfo |d:info |d:docinfo)[1]" />
<xsl:if test="$info and $info/d:abstract" >
<meta name="description" >
<xsl:attribute name="content" >
<xsl:for-each select="$info/d:abstract[1]/*" >
<xsl:value-of select="normalize-space(.)" />
<xsl:if test="position() < last()" >
<xsl:text> </xsl:text>
</xsl:if>
</xsl:for-each>
</xsl:attribute>
</meta>
</xsl:if>
<link rel="schema.DC" href=" http://purl.org/dc/terms/" />
<xsl:if test="$info and $info/dc:*" >
<xsl:for-each select="$info/dc:*" >
<meta>
<xsl:attribute name="name" >DC.<xsl:value-of select="local-name(.)" /></xsl:attribute>
<xsl:attribute name="content" ><xsl:value-of select="normalize-space(.)" /></xsl:attribute>
</meta>
</xsl:for-each>
</xsl:if>
</xsl:template>
Also, I have started to add this in the FO as well: … <xsl:call-template name="user.pagemasters" />
</fo:layout-master-set>
<xsl:if test="//d:info/dc:*" >
<fo:declarations>
<x:xmpmeta xmlns:x="adobe:ns:meta/" >
<rdf:RDF xmlns:rdf=" http://www.w3.org/1999/02/22-rdf-syntax-ns#" >
<rdf:Description rdf:about="" xmlns:dc=" http://purl.org/dc/elements/1.1/" >
<!-- Dublin Core properties go here -->
<xsl:copy-of select="//d:info/dc:*" />
</rdf:Description>
<rdf:Description rdf:about="" xmlns:xmp=" http://ns.adobe.com/xap/1.0/" >
<!-- XMP properties go here -->
<xmp:CreatorTool>
<xsl:value-of select="substring-before(., '{DISTRONAME-VERSION}')" />
<xsl:value-of select="concat($DistroName, '-', $VERSION)" />
<xsl:value-of select="substring-after(., '{DISTRONAME-VERSION}')" />
<xsl:text> </xsl:text>
</xmp:CreatorTool>
</rdf:Description>
</rdf:RDF>
</x:xmpmeta>
</fo:declarations>
</xsl:if>
</xsl:template>
Thanks and best regards,
--Scott
Scott Hudson | PELCO by Schneider Electric | United States | Standards & Information Architect
Phone: +1 970 282 1952 | Mobile: +1 720 369 2433 | Email: scott.hudson@schneider-electric.com
Good. That means we would only need to add the templates to the html directory and the fo directory. All the other output types are generated from them. Some of the others might need some tweaks, but we should try the snapshots with html and fo first, and then we can test the other outputs. Do you have fo templates for the Publishers elements yet? Also, are the default Publishers stylesheets doing anything with the Dublin Core elements and attributes? Bob Stayton Sagehill Enterprises bobs@sagehill.netOn 7/23/2014 9:43 AM, Hudson, Scott wrote: Hi Bob,
I favor the second option as well. The templates would only trigger if
the publishers elements were present. I think this makes it easier to
distribute and render.
AFAIK, there are no modifications to any content models (other than
excluding technical elements). The exclusions would be handled at the
schema level when validating the document, so should not affect
stylesheet processing.
Thanks and best regards,
--Scott
*Scott Hudson* | /PELCO/***by Schneider Electric* | *United States *|
*Standards & Information Architect**
Phone:*+1 970 282 1952 | *Mobile:*+1 720 369 2433 |
*Email:*_scott.hudson@schneider-electric.com_
*Sites:*pdn.pelco.com <http://pdn.pelco.com> , partnerfirst.pelco.com
<http://partnerfirst.pelco.com>
On Jul 23, 2014, at 10:38 AM, Bob Stayton <bobs@sagehill.net
<mailto:bobs@sagehill.net>> wrote:
Hi Scott,
I thought a bit about how to integrate Publishers into the DocBook XSL
distro. I think there are two approaches:
1. Create a Publishers customization layer for each output.
2. Integrate the Publishers elements into the base stylesheets.
The first choice would continue what we started with epub3, but extend
it to all the DocBook XSL output types, of which there are many.
These would likely be packaged separately from the stock stylesheets,
because they would parallel the existing directory structure. A user
would install both if they needed to process Publishers documents.
The second choice adds templates for the new Publishers elements to
the base stylesheets. There would be no customizations or separate
files for Publishers. Rather, the collection of templates in DocBook
XSL would be extended to include Publishers. Because XSL is driven by
the elements being processed, such templates would only be used by
Publishers documents. A single distro handles all.
I favor the second choice because it eliminates extra packages and
simplifies ongoing maintenance. It would also make personal
customizations easier for our users.
The question is, will this work? I've looked at the Publishers schema
and stylesheet, and I think supersetting DocBook XSL would work,
because Publishers mostly adds elements and attributes (add new
templates) or removes elements (ignore existing templates). Does
Publishers *alter* any content models in a way that such a scheme
could not work? Or if it does, is there sufficient context to allow
@match attributes to handle the differences?
Bob Stayton
Sagehill Enterprises
bobs@sagehill.net <mailto:bobs@sagehill.net>
On 7/17/2014 3:01 PM, Hudson, Scott wrote:
You are the best, Bob!
Thanks so much for taking the time on this.
How do you want to handle adding these to the DocBook XSL tree? Would
you prefer to contribute them? I don’t really want to break anything,
since I don’t usually work in the DocBook XSL repo. I guess we still
need to address xsl:fo, too…
Thanks and best regards,
--Scott
*Scott Hudson* | /PELCO/***by Schneider Electric* | *United States *|
*Standards & Information Architect**
Phone:*+1 970 282 1952 | *Mobile:*+1 720 369 2433 |
*Email:*_scott.hudson@schneider-electric.com_
*Sites:*pdn.pelco.com <http://pdn.pelco.com> , partnerfirst.pelco.com
<http://partnerfirst.pelco.com>
On Jul 17, 2014, at 3:54 PM, Bob Stayton <bobs@sagehill.net
<mailto:bobs@sagehill.net>> wrote:
Hi Scott,
I took your publishers.xhtml.xsl stylesheet and made it into a
customization for epub3 output. The main issue is managing import
precedence, because the chunking process uses xsl:apply-imports to
switch from chunking behavior to formating behavior.
The attached zip file has the custom stylesheets, sample output, a
sample Makefile, and a README that explains it. I copy the README
below.
Bob Stayton
Sagehill Enterprises
bobs@sagehill.net <mailto:bobs@sagehill.net>
README
DocBook Publishers EPUB3 customization
---------------------------------------
17 July 2014
Bob Stayton
Sagehill Enterprises
bobs@sagehill.net
This archive contains a customization of the DocBook Epub3 stylesheet
for use with the DocBook Publishers schema.
coriolan.xml - DocBook 5 input file with publisher
elements
publishers-chunk-epub3.xsl - Stylesheet to generate epub3 output.
publishers-elements-epub3.xsl - Imported by publishers-chunk-epub3.xsl
Makefile.publishers - Makefile showing processing steps.
coriolan - Sample output directory.
coriolan.epub - Sample output epub file.
Notes
------------
Customizing any of the DocBook chunking stylesheets
requires care to maintain proper import precedence.
To generate chunked epub3 output, process the sample input file
with the publishers-chunk-epub3.xsl stylesheet. You will
have to modify the xsl:import statements so it can import the
stock DocBook files.
The publishers-chunk-epub3.xsl stylesheet does not contain any
custom templates, except those that would customize the chunking
behavior, which is rare. None are needed here.
The publishers-chunk-epub3.xsl stylesheet imports the templates
that format the content within each chunk. In this case, it
imports the file publishers-elements-epub3.xsl.
I moved your custom templates into publishers-elements-epub3.xsl.
That file also imports the stock xhtml5/docbook.xsl, which
elevates xhtml to xhtml5, and imports the stcok
epub3/epub3-element-mods.xsl which elevates xhtml5 to epub3.
Again, you'll need to change the xsl:import paths.
These imports are followed by the templates that customize
elements for the Publishers schema.
I changed three of your templates to replace <div remap= > with <div
class= > because remap is not a valid XHTML attribute, and
epubcheck complained. I wasn't sure if you intended to output
remap there.
The Makefile I include here is mostly to demonstrate the commands
I used to generate the coriolan.epub file. It should work for
you too if you adjust the CLASSPATH and other command paths.
Basically it does three things:
1. Process the input document with publishers-chunk-epub3.xsl.
2. Run a zip process to generate the .epub file.
3. Run epubcheck on the result.
The coriolan.epub file that I generated opens and displays
properly in Calibre. But it still does not pass epubcheck-3.0.
That will require some more investigation.
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud
service.
______________________________________________________________________<publishers-epub3-2014-07-17.zip>
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
______________________________________________________________________
______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. ______________________________________________________________________
|