[docbook-apps] About figure references
Hello, I try to customize my figures legend. In french Figure x.yy should be on small caps and the legend it self should be in italic. So I took form Bob's book a customization code and I customize it again: xsl:template name=formal.object.heading xsl:param name=object select=./ xsl:param name=placement select='before'/ fo:block xsl:choose xsl:when test=$placement = 'before' xsl:attribute name=keep-with-next.within-columnalways/xsl:attribute /xsl:when xsl:otherwise xsl:attribute name=keep-with-previous.within-columnalways/xsl:attribute /xsl:otherwise /xsl:choose fo:inline xsl:use-attribute-sets=formal.label.properties font- variant=small-caps xsl:call-template name=gentext xsl:with-param name=key select=local-name($object)/ /xsl:call-template xsl:text /xsl:text xsl:apply-templates select=$object mode=label.markup xsl:text: /xsl:text /xsl:apply-templates /fo:inline fo:inline xsl:use-attribute-sets=formal.title.properties font- style=italic xsl:apply-templates select=$object mode=title.markup/ /fo:inline /fo:block /xsl:template It almost work but this part : xsl:apply-templates select=$object mode=label.markup xsl:text: /xsl:text /xsl:apply-templates generate an error : Description: Invalid element within xsl:apply-templates: Description: Element must only be used within a template body If I comment it, tho more errors, but I have no figure number. Did I have to define label.markup in my custom stylesheet ? Thanks in advance for you help, Jacques -- « Mac OS X Server à votre Service » est épuisé. Vous pouvez désormais l'acquérir en PDF http://www.foucry.net/Redaction/service/service.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[docbook-apps] [ANN] XMLmind XML Editor 3.7.0
XMLmind XMLmind is pleased to announce a new version of XMLmind XML Editor. _ XMLmind XML Editor Personal Edition 3.7.0 can be downloaded from http://www.xmlmind.com/xmleditor/download.shtml Professional Edition users, please upgrade using this form: http://www.xmlmind.com/store/download.php (The above form is usually accessed through http://www.xmlmind.com/xmleditor/upgrade.html.) _ v3.7.0 (November 15, 2007): * The DITA add-on for XMLmind XML Editor now fully supports the DITA DTD 1.1. It includes its own minimal copy of DITA Open Toolkit version 1.4. If you need this add-on, please install it using Options|Install Add-ons. * New Tools|Helper Application sub-menu. This menu contains entries allowing to use third-party applications to view or edit part or all of the document being edited. * New date/time picker dialog box. This dialog box is used by the Attribute Tool, the putAttribute and addAttribute commands, new form controls called date-time-picker, date-picker, time-picker. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[docbook-apps] Weird olink database error
In my travails to move a build system from xsltproc based to Saxon based, I've hit several snags where the output from xsltproc and Saxon are different using the exact same style sheets. I've been asking questions here, because I suspect the users here would have more familiarity with the complete toolset that users on other lists. If that is incorrect, I will redirect my questions to the more appropriate list. The latest snag I've hit is that when building the olink target data base using the xhtml chunking sheet set to only build the target database, Saxon adds a blank line followed by the XHTML DOCTYPE to the top of the file. I worked around this by switching to the html version of the style sheet, but since we generate the docs in xhtml, it would be better if I could use the xhtml version. Again, I'm using the same customization layer, just different XSLT processors. Style sheet version 1.73.1 with xsltproc is fine. Style sheet version 1.73.1 with Saxon creates extra stuff. Do I need to use the Saxon extensions to clear this up? Many Thanks for the help, Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [docbook-apps] Weird characters in generated HTML
David,
Thanks for the tip. I'll check the CSS for a bum style in the style
sheet. It is odd that simply swapping the XSLT processor generated such
different results.
Cheers,
Eric
-Original Message-
From: David Cramer [mailto:[EMAIL PROTECTED]
Sent: Friday, November 30, 2007 7:16 PM
To: Johnson, Eric; Barton Wright
Cc: docbook-apps
Subject: RE: [docbook-apps] Weird characters in generated HTML
a id=foo/ shouldn't be a problem (my docs are full of them...I do
generate xhtml and stay out of quirks mode, but I don't think that
matters here) unless you do something like a{ color: blue;
text-decoration: underline;} in your css. Then everything after a a
id=foo/ until the next time a closing /a tag is reached will be
blue. Do a[href]{ color: red; text-decoration: underline;} instead.
David
-Original Message-
From: Johnson, Eric [mailto:[EMAIL PROTECTED]
Sent: Friday, November 30, 2007 5:18 PM
To: Barton Wright; David Cramer
Cc: docbook-apps
Subject: RE: [docbook-apps] Weird characters in generated HTML
As far as I can tell it is all of the anchors. Not just the olink
ones.
I'm calling Saxon, with Xerces, from ant using the java task:
java classname=com.icl.saxon.StyleSheet
classpathref=xslt-classpath fork=true
sysproperty
key=javax.xml.parsers.DocumentBuilderFactory
value=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl/
sysproperty key=javax.xml.parsers.SAXParserFactory
value=org.apache.xerces.jaxp.SAXParserFactoryImpl/
sysproperty
key=org.apache.xerces.xni.parser.XMLParserConfiguration
value=org.apache.xerces.parsers.XIncludeParserConfiguration/
arg value=-x /
arg
value=org.apache.xml.resolver.tools.ResolvingXMLReader/
arg value=-y /
arg
value=org.apache.xml.resolver.tools.ResolvingXMLReader/
arg value=-r/
arg
value=org.apache.xml.resolver.tools.CatalogResolver/
arg value=-o/
arg value=output/toc.html/
arg value=${ROOT}.xml /
arg
value=${env.DBCK_HOME}/custom/fuse-xhtml-chunk.xsl /
arg value=target.database.document=../site.xml /
arg value=current.docid=${DOCID}/
/java
and using version 1.73.1 of the style sheets.
-Original Message-
From: Barton Wright [mailto:[EMAIL PROTECTED]
Sent: Friday, November 30, 2007 4:42 PM
To: Johnson, Eric; David Cramer
Cc: docbook-apps
Subject: RE: [docbook-apps] Weird characters in generated HTML
Hey Eric,
No, I definitely didn't customize anything about olinks when I was
there. :-)
We use Saxon and Xerces here, and olinks are generated normally in the
a id=foo/a format.
Can you be more explicit about which of your olinks are being
generated into the a id=foo / format? Is it all olinks or some? Is
it olinks and not links or xrefs?
BTW, expect Saxon processing to be significantly slower than xsltproc,
as little as 10% to 50% as fast as the equivalent xsltproc command.
But all the current development seems to be in the Saxon realm, and it
has better cross-platform support.
So there we are.
-Original Message-
From: Johnson, Eric [mailto:[EMAIL PROTECTED]
Sent: Friday, November 30, 2007 4:12 PM
To: David Cramer
Cc: docbook-apps
Subject: RE: [docbook-apps] Weird characters in generated HTML
I found the problem...
It seams that the java processors generate a id=foo / for anchors
and xsltproc generates a id=foo/a. Firefox and
IE7 don't like a id=foo /. I'm pretty sure the guy who originally
did our customization layer didn't change the olink stuff, but I could
be wrong.
Where would I look to figure out how to make the Java XSLT processors
do the right thing?
-Original Message-
From: David Cramer [mailto:[EMAIL PROTECTED]
Sent: Friday, November 30, 2007 3:01 PM
To: Johnson, Eric
Cc: docbook-apps
Subject: RE: [docbook-apps] Weird characters in generated HTML
Check for an empty a href=/ element immediately before the
everything's a link stuff starts. Then trace back to your docbook
source (or your customization layer) to find where the emtpy a
href=/ is coming from.
David
-Original Message-
From: Eric Johnson [mailto:[EMAIL PROTECTED]
Sent: Friday, November 30, 2007 1:30 PM
To: David Cramer
Cc: docbook-apps
Subject: RE: [docbook-apps] Weird characters in generated HTML
Thnaks, I should have seen that. That fixed the hatted A's, but I
still cannot figure out why all my content is being
rendered as links.
I haven't changed the source that I used when working with xsltproc.
On Fri, 2007-11-30 at 11:14 -0600, David Cramer wrote:
Take a look at
http://www.sagehill.net/docbookxsl/SpecialChars.html
(scroll down to Odd characters in HTML output).
David
-Original Message-
From: Eric Johnson [mailto:[EMAIL PROTECTED]
Sent: Friday, November 30, 2007 11:04 AM
RE: [docbook-apps] Weird characters in generated HTML
David,
The change to the CSS did the trick!! Thanks.
Cheers,
Eric
-Original Message-
From: David Cramer [mailto:[EMAIL PROTECTED]
Sent: Friday, November 30, 2007 7:16 PM
To: Johnson, Eric; Barton Wright
Cc: docbook-apps
Subject: RE: [docbook-apps] Weird characters in generated HTML
a id=foo/ shouldn't be a problem (my docs are full of them...I do
generate xhtml and stay out of quirks mode, but I don't think that
matters here) unless you do something like a{ color: blue;
text-decoration: underline;} in your css. Then everything after a a
id=foo/ until the next time a closing /a tag is reached will be
blue. Do a[href]{ color: red; text-decoration: underline;} instead.
David
-Original Message-
From: Johnson, Eric [mailto:[EMAIL PROTECTED]
Sent: Friday, November 30, 2007 5:18 PM
To: Barton Wright; David Cramer
Cc: docbook-apps
Subject: RE: [docbook-apps] Weird characters in generated HTML
As far as I can tell it is all of the anchors. Not just the olink
ones.
I'm calling Saxon, with Xerces, from ant using the java task:
java classname=com.icl.saxon.StyleSheet
classpathref=xslt-classpath fork=true
sysproperty
key=javax.xml.parsers.DocumentBuilderFactory
value=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl/
sysproperty key=javax.xml.parsers.SAXParserFactory
value=org.apache.xerces.jaxp.SAXParserFactoryImpl/
sysproperty
key=org.apache.xerces.xni.parser.XMLParserConfiguration
value=org.apache.xerces.parsers.XIncludeParserConfiguration/
arg value=-x /
arg
value=org.apache.xml.resolver.tools.ResolvingXMLReader/
arg value=-y /
arg
value=org.apache.xml.resolver.tools.ResolvingXMLReader/
arg value=-r/
arg
value=org.apache.xml.resolver.tools.CatalogResolver/
arg value=-o/
arg value=output/toc.html/
arg value=${ROOT}.xml /
arg
value=${env.DBCK_HOME}/custom/fuse-xhtml-chunk.xsl /
arg value=target.database.document=../site.xml /
arg value=current.docid=${DOCID}/
/java
and using version 1.73.1 of the style sheets.
-Original Message-
From: Barton Wright [mailto:[EMAIL PROTECTED]
Sent: Friday, November 30, 2007 4:42 PM
To: Johnson, Eric; David Cramer
Cc: docbook-apps
Subject: RE: [docbook-apps] Weird characters in generated HTML
Hey Eric,
No, I definitely didn't customize anything about olinks when I was
there. :-)
We use Saxon and Xerces here, and olinks are generated normally in the
a id=foo/a format.
Can you be more explicit about which of your olinks are being
generated into the a id=foo / format? Is it all olinks or some? Is
it olinks and not links or xrefs?
BTW, expect Saxon processing to be significantly slower than xsltproc,
as little as 10% to 50% as fast as the equivalent xsltproc command.
But all the current development seems to be in the Saxon realm, and it
has better cross-platform support.
So there we are.
-Original Message-
From: Johnson, Eric [mailto:[EMAIL PROTECTED]
Sent: Friday, November 30, 2007 4:12 PM
To: David Cramer
Cc: docbook-apps
Subject: RE: [docbook-apps] Weird characters in generated HTML
I found the problem...
It seams that the java processors generate a id=foo / for anchors
and xsltproc generates a id=foo/a. Firefox and
IE7 don't like a id=foo /. I'm pretty sure the guy who originally
did our customization layer didn't change the olink stuff, but I could
be wrong.
Where would I look to figure out how to make the Java XSLT processors
do the right thing?
-Original Message-
From: David Cramer [mailto:[EMAIL PROTECTED]
Sent: Friday, November 30, 2007 3:01 PM
To: Johnson, Eric
Cc: docbook-apps
Subject: RE: [docbook-apps] Weird characters in generated HTML
Check for an empty a href=/ element immediately before the
everything's a link stuff starts. Then trace back to your docbook
source (or your customization layer) to find where the emtpy a
href=/ is coming from.
David
-Original Message-
From: Eric Johnson [mailto:[EMAIL PROTECTED]
Sent: Friday, November 30, 2007 1:30 PM
To: David Cramer
Cc: docbook-apps
Subject: RE: [docbook-apps] Weird characters in generated HTML
Thnaks, I should have seen that. That fixed the hatted A's, but I
still cannot figure out why all my content is being
rendered as links.
I haven't changed the source that I used when working with xsltproc.
On Fri, 2007-11-30 at 11:14 -0600, David Cramer wrote:
Take a look at
http://www.sagehill.net/docbookxsl/SpecialChars.html
(scroll down to Odd characters in HTML output).
David
-Original Message-
From: Eric Johnson [mailto:[EMAIL PROTECTED]
Sent: Friday, November 30, 2007 11:04 AM
To: docbook-apps
Subject: [docbook-apps] Weird characters in generated HTML
Sorry for the
RE: [docbook-apps] Weird olink database error
Hi Eric, I suffer from the same problem but using the website XSL application. In this case Saxon issues a HTML DOCTYPE on the top of the file. I've posted the same question in this forum some weeks ago but I get no response at all. I hope you were more fortunate than me. Regards, Pedro -Mensaje original- De: Johnson, Eric [mailto:[EMAIL PROTECTED] Enviado el: lunes, 03 de diciembre de 2007 16:51 Para: docbook-apps Asunto: [docbook-apps] Weird olink database error In my travails to move a build system from xsltproc based to Saxon based, I've hit several snags where the output from xsltproc and Saxon are different using the exact same style sheets. I've been asking questions here, because I suspect the users here would have more familiarity with the complete toolset that users on other lists. If that is incorrect, I will redirect my questions to the more appropriate list. The latest snag I've hit is that when building the olink target data base using the xhtml chunking sheet set to only build the target database, Saxon adds a blank line followed by the XHTML DOCTYPE to the top of the file. I worked around this by switching to the html version of the style sheet, but since we generate the docs in xhtml, it would be better if I could use the xhtml version. Again, I'm using the same customization layer, just different XSLT processors. Style sheet version 1.73.1 with xsltproc is fine. Style sheet version 1.73.1 with Saxon creates extra stuff. Do I need to use the Saxon extensions to clear this up? Many Thanks for the help, Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.16.13/1167 - Release Date: 03/12/2007 12:20 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.16.13/1167 - Release Date: 03/12/2007 12:20 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [docbook-apps] Weird olink database error
The target database is an XML file, not an XHTML file, and should be generated as such for all of the final output types. Perhaps this is a bug in the style sheets? -Original Message- From: Dave Pawson [mailto:[EMAIL PROTECTED] Sent: Monday, December 03, 2007 2:24 PM To: Pedro Pastor Cc: docbook-apps@lists.oasis-open.org Subject: Re: [docbook-apps] Weird olink database error Pedro Pastor wrote: Hi Eric, I suffer from the same problem but using the website XSL application. In this case Saxon issues a HTML DOCTYPE on the top of the file. The latest snag I've hit is that when building the olink target data base using the xhtml chunking sheet set to only build the target database, Saxon adds a blank line followed by the XHTML DOCTYPE to the top of the file. Why is this an issue for xml processing? Is it wrong? http://saxon.sourceforge.net/saxon6.5.5/xsl-elements.html#xsl:output specifies the xslt output options. If you ask for xhtml output then Saxon gives it. If you ask for xml output then no doctype should be output. http://docbook.sourceforge.net/release/xsl/current/doc/html/chunking.htm l provides the docbook customization. regards -- Dave Pawson XSLT XSL-FO FAQ. http://www.dpawson.co.uk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docbook-apps] Weird olink database error
The only 'solution' I could come up with was to copy and edit the original xhtml/docbook.xsl to remove the doctype-public and doctype-system attributes from the xsl:output element in the stylesheet file. Then the customization layer imports this customized version. Bob Stayton Sagehill Enterprises [EMAIL PROTECTED] - Original Message - From: Mauritz Jeanson [EMAIL PROTECTED] To: 'Johnson, Eric' [EMAIL PROTECTED]; 'docbook-apps' docbook-apps@lists.oasis-open.org Sent: Monday, December 03, 2007 1:22 PM Subject: RE: [docbook-apps] Weird olink database error -Original Message- From: Johnson, Eric The latest snag I've hit is that when building the olink target data base using the xhtml chunking sheet set to only build the target database, Saxon adds a blank line followed by the XHTML DOCTYPE to the top of the file. I worked around this by switching to the html version of the style sheet, but since we generate the docs in xhtml, it would be better if I could use the xhtml version. This thread on XSL-list describes what I think is the root cause of the problem: http://www.biglist.com/lists/xsl-list/archives/200610/msg00026.html As you can see, there does not seem to be any solution. /MJ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
