RE: [docbook-apps] should simplesect be chunked?
So to maintain the current functionality of the stylesheets I'd need to add a processing instruction to all of the simplesect elements in all of my content? That seems like a lot of work. I'd still ask for simplesect chunking to be parameterized, but if if the community feels that simplesect should chunk like regular sections then so be it. -Original Message- From: David Cramer [mailto:[EMAIL PROTECTED] Sent: Mon 9/15/2008 6:28 PM To: Johnson, Eric; docbook-apps Subject: RE: [docbook-apps] should simplesect be chunked? I had noticed that simplesects don't chunk a while back when some of our writers wanted a way to create sections that don't chunk and simplesect seemed a possible answer. I was worried though that it was a bug that would be fixed someday :-) So I implemented ?dbhtml stop-chunking? to let writers control where chunking stops and that's now part of the xsls. I don't have strong feelings about simplesects chunking since we use the processing instruction. I can obviously understand the need for giving writers the option of creating sections that don't chunk. I do think that either simplescts should chunk or The Definitive Guide should be updated to indicate that the processing expectation is that they don't chunk (or it should be parameterized). The current processing instruction will stop the chunking of simplesects too btw. David -Original Message- From: Johnson, Eric [mailto:[EMAIL PROTECTED] Sent: Monday, September 15, 2008 1:28 PM To: docbook-apps Subject: RE: [docbook-apps] should simplesect be chunked? Bob, I do not disagree with your position in theory. I can see where there may be style guides that use simplesect in such a way as they would be long enough to warrant entire html pages. I don't think that having simplesect blocks being that long makes much sense however. We use simplesect as the only terminal section element. It is, in information mapping terms, a block. So a chapter would never only have sect1 elements breaking it up into sections. Such a chapter would use simplesect. If the simplesect blocks get big enough to warrant it, then the chapter would need to be broken up into sections - each of which contains a group of simplesect element. sect1-sect5 elements and section elements are not used as terminal sections. Since this is only one way of doing the mark-up using docbook and others will likely disagree with this approach, I don't think adding the capabilities to chunk simplesect is a bad idea. Perhaps simplesect chunking should have its own parameter for being turned on and off? That way people whose output depends on the current chunking algorithm for sections won't be messed up. Cheers, Eric -Original Message- From: Dave Pawson [mailto:[EMAIL PROTECTED] Sent: Monday, September 15, 2008 1:54 PM To: Bob Stayton Cc: DocBook Apps Subject: Re: [docbook-apps] should simplesect be chunked? Bob Stayton wrote: Hi, I don't think section level is the right criterium for excluding simplesect from chunking. A chapter can contain nothing but simplesect elements, making them equivalent to level1 sections. Currently such a chapter would be a single chunk, even if each simplesect was long, leading to a very long chunk. Also, in the chunking stylesheets, the level of section chunking is controlled by a stylesheet parameter. So you could have one chapter consisting of simplesects that is are not chunked, and another chapter consisting of single-level section elements, and only the latter chapter will be chunked. Too many what-if's there Bob. We can all make daft decisions when marking up. For Docbook, used sensibly, there's no need to chunk at simplesect level IMHO. 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[docbook-apps] RE: [docbook] RE: [docbook-apps] db 5 and Dita anyone?
+1 to DITA-like conref support. It would be nice to have a way to easily reuse pieces of content without having to import their containing element. There are many times I have had a chapter in a small book that I would like to have used as a section in a large book without importing the chapter section by section using xinclude. -Original Message- From: Fabrice (GMail) [mailto:[EMAIL PROTECTED] Sent: Friday, May 09, 2008 3:11 PM To: 'Dick Hamilton'; 'Dave Pawson'; [EMAIL PROTECTED] Cc: docbook-apps@lists.oasis-open.org Subject: [docbook] RE: [docbook-apps] db 5 and Dita anyone? IMHO, specialization would be an interesting feature to add, though targeted at advanced users. Since Docbook is explicitly designed for books, a large number of Docbook users should be able to achieve their goals with the current DTD/schema. My guess is that 10% to 20% of Docbook users would really benefit from it. More feedback on this from the community would help. I see more value in adding DITA-like conref support. Content re-use is one of the key benefits you get when moving to single-source. Adding a simple way for authors to re-use small piece of content in Docbook would make a big difference! Cheers Fabrice -Original Message- From: Dick Hamilton [mailto:[EMAIL PROTECTED] Sent: Thursday, May 01, 2008 10:53 AM To: 'Dave Pawson'; [EMAIL PROTECTED] Cc: docbook-apps@lists.oasis-open.org Subject: RE: [docbook-apps] db 5 and Dita anyone? Dave, You make a good point; I suspect Eliot is not familiar with Norm's article, DITA for DocBook (http://norman.walsh.name/2005/10/21/dita), which shows how to specialize DocBook, and provides a customization to the stylesheets to support specialization. I posted a reply to his blog entry suggesting he take a look at it and comment. The question this does raise is whether it makes sense to include a means of specialization as part of the standard. While I like the idea of being able to specialize, I'm sure that making it a normative part of the spec is not trivial, even if we simply formalize Norm's strategy. I'd be interested in hearing what others on the list think about formalizing specialization. To that end, I'm copying this to the docbook list, which is probably the best place for that discussion. Dick Hamilton http://rlhamilton.net -Original Message- From: Dave Pawson [mailto:[EMAIL PROTECTED] Sent: Saturday, April 19, 2008 2:25 AM To: Docbook Apps Subject: [docbook-apps] db 5 and Dita anyone? Eliot is running comments on DITA and docbook when choosing an XML vocabulary, concluding DITA is the best answer for any XML-based document-centric application I've seen. http://drmacros-xml-rants.blogspot.com/2008/04/choosing-xml-schema-docbo ok-or-dita.html His last para is interesting. why doesn't DocBook simply adopt DITA's specialization mechanism? It would cost DocBook almost nothing to add and add tremendous value. It would not require DocBook changing anything about its current markup design, except to possibly back-form some base types that are currently not explicit in DocBook but would be useful as a specialization base. But that would only make DocBook cleaner. I'm not a DITA user. It appears Eliot hasn't looked at db5 either. 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] - 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] ant and db5, xinclude and fo output
When I was setting up our Ant based tool chain I could not find a way to get
the Ant xslt task to support xinclude processing without doing two passes:
one to resolve the xincludes then one to process the content. Since we are also
using profiling that resulted in a three stage process (5 if we tagged on PDF
processing).
It seemed easier and faster to use Saxon from the java command.
-Original Message-
From: Tony Graham [mailto:[EMAIL PROTECTED]
Sent: Thu 4/10/2008 8:46 AM
To: docbook-apps@lists.oasis-open.org
Subject: Re: [docbook-apps] ant and db5, xinclude and fo output
On Thu, Apr 10 2008 11:36:06 +0100, [EMAIL PROTECTED] wrote:
My latest foray into ant:
...
target name=fo depends=init, clean.pdf
echoGenerate the fo output/echo
java classname=${xslt.processor.class}
fork=yes
dir=${in.dir}
failonerror=true
classpath refid=xslt.processor.classpath /
jvmarg
line=-Dorg.apache.xerces.xni.parser.XMLParserConfiguration=org.apache.xerces.parsers.XIncludeParserConfiguration/
jvmarg
line=-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl/
jvmarg
line=-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl/
arg line=-o ${out.fo.dir}/${main.fo.outfile}/
arg line=-l/
arg line=-x org.apache.xml.resolver.tools.ResolvingXMLReader/
arg line=-y org.apache.xml.resolver.tools.ResolvingXMLReader/
arg line=-r org.apache.xml.resolver.tools.CatalogResolver /
arg line=${in.dir}/${main.infile} ${main.fo.stylesheet} /
/java
/target
The Ant manual [1] recommends arg value=.../ rather than arg
line=.../. Doing so needs more elements, but it's safer to use.
Why are you using the java task rather than the xslt task? IMO,
using the xslt task makes using XML catalogs with Ant much easier.
You could also make a macro for the transformation so you wouldn't need
to repeat everything just to change three filenames.
...
It might be nicer to use xmllint to expand the includes and validate,
but I haven't figured out how to get ant to do that.
exec [2].
Regards,
Tony Graham [EMAIL PROTECTED]
Director W3C XSL FO SG Invited Expert
Menteith Consulting Ltd
XML, XSL and XSLT consulting, programming and training
Registered Office: 13 Kelly's Bay Beach, Skerries, Co. Dublin, Ireland
Registered in Ireland - No. 428599 http://www.menteithconsulting.com
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
xmlroff XSL Formatter http://xmlroff.org
xslide Emacs mode http://www.menteith.com/wiki/xslide
Unicode: A Primer urn:isbn:0-7645-4625-2
[1] http://ant.apache.org/manual/using.html#arg
[2] http://ant.apache.org/manual/CoreTasks/exec.html
I don't know why it's showing as beta since it was in earlier
versions of Ant than the Ant 1.7 currently documented at this URL.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[docbook-apps] Remark processing
Is remark intended to be printed when status is not set to draft? I'm using the 1.73.2 version of the stylesheets and the contents of remark show up even when I remove status=draft from my book.
[docbook-apps] xref vs. olink
I'm cross posting this from the docbook list... I'm wondering which is more appropriate for creating cross-references when working with modular content: xref or olink? xref has very well defined behavior, but causes validation errors in modules that have references to other modules. olink is tool chain specific, but doesn't have the validation problem. I'm working in an environment where section elements are the basic building blocks of the complete documents. I also need to be able to publish single chapters out of a book. We use docbook 4.5 and have the tool chain set to prefer internal olinks.
[docbook-apps] Getting Saxon XHTML to work
I'm trying to get Saxon to output XHTML. Following the instructions in Bob's book I added the Saxon extensions to my customization layer: ?xml version=1.0 encoding=UTF-8? xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xmlns:saxon=http://icl.com/saxon; xmlns=http://www.w3.org/1999/xhtml; version=1.0 xsl:import href=../lib/docbook-xsl/xhtml/chunk.xsl/ xsl:import href=ziona_all.xsl/ xsl:import href=ziona_html_all.xsl/ xsl:import href=ziona_html_multipart.xsl/ xsl:import href=ziona_html_break_on_section.xsl/ xsl:import href=ziona_html_wholebook.xsl/ xsl:import href=ziona_html_chunker.xsl/ xsl:import href=fuse_html_user_head_content.xsl/ xsl:import href=ziona_html_olinks_use.xsl/ xsl:import href=ziona_html_callouts_use.xsl/ xsl:import href=ziona_html_titlepage.xsl / xsl:import href=ziona_html_override_abstract.xsl / xsl:import href=fuse_footer_content.xsl/ xsl:output method=saxon:xhtml / /xsl:stylesheet However, it does not seem to have any effect at all on the output. What am I missing? Thanks, Eric J. - 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
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 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 stream of newby questions...
I got both Saxon and Xalan to work with XIncludes and
catalogs from
Ant.
However, all of my generated HTML, using either
processor, comes out
as a link
Using Xalan I also got a bunch of hatted A's (an A wearing a
^) where ever there is a hard space.
Using Saxon my target database file for olinks has a
space at the top.
Using xsltproc under Windows, with the same source and
customization
layer, this never happened.
Any ideas?
- 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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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 stream of newby questions... I got both Saxon and Xalan to work with XIncludes and catalogs from Ant. However, all of my generated HTML, using either processor, comes out as a link Using Xalan I also got a bunch of hatted A's (an A wearing a ^) where ever there is a hard space. Using Saxon my target database file for olinks has a space at the top. Using xsltproc under Windows, with the same source and customization layer, this never happened. Any ideas? - 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]
[docbook-apps] xinclude mod and catalogs
I want to use the xinclude.mod to allow modular files to validate in oxygen, but I do not want to get a bunch of warnings from xsltproc when I build my books. I tried to use a catalog to resolve the entity reference using: group xml:base=file:///c:/dcbk/custom/ system systemId=xinclude.mod uri=xinclude.mod / systemSuffix systemIdSuffix=xinclude.mod uri=xinclude.mod/ /group oXygen likes the systemSuffix entry and xmlcatalog likes the system entry. However, xsltproc and xmllint both refuse to resolve the entity and throw up warnings everytime... Any idea on what I've missed? Thanks, Eric J. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[docbook-apps] Lines for simplesect in pdf
Is there are quick way to add a line (in PDF) before each simplesect? TIA Eric J.
[docbook-apps] Separator line for simplesect
I would like to separate my simplesects by a line in my PDF output. Where would I start? Thanks, Eric
RE: [docbook-apps] Styling PDF output
Bob, Thanks for point me in the right direction. The body.start.indent will do most of what I want. I would like the simplesect titles and bridgeheads to float in the gap between the margin and the start of the text. From reading your book, it looks like I need to add a template for simplesect.titlepage to the customization layer to make that happen. Is this correct? Cheers, Eric From: Bob Stayton [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 04, 2007 7:52 PM To: Johnson, Eric; docbook-apps@lists.oasis-open.org Subject: Re: [docbook-apps] Styling PDF output Hi Eric, I think the DocBook XSL stylesheets do that by default. The body.start.indent parameter indents everything, except those elements with a start-indent=0pt property. All section heads, including simplesect and bridgeheads get that property, so they are not indented along with everything else. Or perhaps I'm not understanding your requirements. Bob Stayton Sagehill Enterprises DocBook Consulting [EMAIL PROTECTED] - Original Message - From: Johnson, Eric mailto:[EMAIL PROTECTED] To: docbook-apps@lists.oasis-open.org Sent: Friday, August 31, 2007 6:51 AM Subject: [docbook-apps] Styling PDF output I want to style the pages in my PDF output so that the paragraph text has a left side gap. I also want simplesect tiles and bridge heads to appear in the gap. I'm not sure what I need to modify to make that happen. Any help would be greatly appreciated. Cheers, Eric J.
[docbook-apps] Help on FOP styling
What are some good sources of information on formatting the appearance of PDFs generated from the FOP output of Docbook XSLT?
[docbook-apps] Styling PDF output
I want to style the pages in my PDF output so that the paragraph text has a left side gap. I also want simplesect tiles and bridge heads to appear in the gap. I'm not sure what I need to modify to make that happen. Any help would be greatly appreciated. Cheers, Eric J.
RE: [docbook-apps] To Rene Hache, Larry Garfield, Bob Stayton, Jirka Kosek - About a former XHTML accessiblity project
Chris is correct. Is the XHTML perfect or modern? Perhaps not. Does it produce useable, accessible output? Yes. The output we've managed to get from it for IONA's documentation looks very nice and is very workable. If people are so down on the output perhaps they could put some of their ideas into action... The people who developed and maintain the style sheets deserve both some slack and our appreciation. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Chiasson Sent: Tuesday, May 15, 2007 10:17 AM To: Nicolas RAINARD Cc: docbook-apps@lists.oasis-open.org Subject: Re: [docbook-apps] To Rene Hache, Larry Garfield, Bob Stayton, Jirka Kosek - About a former XHTML accessiblity project I want to defend the stylesheet writers: XSLT is, IMO, a functional programming language based largely on pattern matching. The source document trees can take many different forms and contain a variety of structures, while there are also many different output forms (for starters: fo, html/xhtml single/chunked). So, in this XSLT language, the stylesheet writers have to write a multi-input multi-output program and manage all the interactions of their transformations. This is not so easy to do, especially in one's spare time. I think we should give them slack. Are the embedded tables killing us? No. Is the output highly accessible already? Yes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [docbook-apps] Docbook Editors
There is XML Mind which is pretty good and does have a free version. The only drawback is that they do not support text entities. You can also check out Serna. It is good, but can be very slow. Both are WYSIWYG. -Original Message- From: Paul Hewlett [mailto:[EMAIL PROTECTED] Sent: Monday, May 14, 2007 11:02 AM To: docbook-apps@lists.oasis-open.org Subject: Re: [docbook-apps] Docbook Editors On Monday 14 May 2007 15:01, Eitan Zabari wrote: Hello, I would like to use an editor for writing Docbook, preferably WYSIWYG. I used to write Latex with GVIM (non-wysiwyg), but trying to do the same for Docbook XML is too much overhead, code wise. Which editors are used with Docbook? Can anyone please recommend? Are there free editors? Are there commercial editors that are good? I use Quanta Plus which has a docbook mode although it is not WYSIWYG. I also would like a better editor ... Paul -- Paul Hewlett Technical Director Global Call Center Solutions Ltd, 2nd Floor, Milnerton Mall Cnr Loxton Koeberg Roads, 7435 Milnerton www.gccs.co.za Tel: +27 86 111 3433 Fax: +27 86 111 3520 Cel: +27 76 072 7906 Gizmo: 1 747 659 6171 - 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] Re: how to upgrade docbook-xml properly w.r.t. nxml-mode - /usr/share/emacs/site-lisp/nxml-mode/schema/*.rnc
What I do is a bit of a pain, but it works I just reset the schema location to point at what ever *.rnc file I need to validate the document against. The pain is that you must do it for each document you open at least once. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, May 10, 2007 9:11 AM To: docbook-apps@lists.oasis-open.org Subject: [docbook-apps] Re: how to upgrade docbook-xml properly w.r.t. nxml-mode - /usr/share/emacs/site-lisp/nxml-mode/schema/*.rnc JMT == jmt [EMAIL PROTECTED] writes: JMT Hi, list ! JMT I use emacs + nxml mode in Debian ; this package still uses the Docbook JMT schema from V4.2, so I replaced to the original schema by the schema for JMT V5.0RC3. My nxml-mode installation keeps emacs mode and specifically docbook related files (*.rnc - RELAG NG compact syntax) here: /usr/share/emacs/site-lisp/nxml-mode/schema/ So you are telling us, you took files from /usr/share/xml/docbook/schema/rng/5.0CR3/ and made them available to emacs nxml-mode, are you? JMT Works like a charm, Does that mean regarding to editing in nxml-mode or regarding to creating HTML or PDF? Do you really make use of new features in nxml-mode, i.e. features of 5.0, that were not already available in 4.2? JMT except that introducing a xml:id for person unvalidates the JMT document. I guess every new feature will unvalidate the document, as long as the new and right *.rnc files are not properly made available to nxml-mode. And how that is carried out -- maybe there is somebody else to tell us how to do that, I mean to give us a recipe of how to upgrade docbook-xml properly w.r.t. nxml-mode - /usr/share/emacs/site-lisp/nxml-mode/schema/*.rnc. Actually I would like to see, that the *.rnc files in /usr/share/emacs/site-lisp/nxml-mode/schema/ get removed and nxml-mode gets set up to make use of the *.rnc files in /usr/share/xml/docbook/schema/rng/5.0CR3/ or whatever new or old version one wants to make use of. Obviously your paths may vary, mine are from a mixture of SUSE 10.1 through 10.3alpha... and I actually assume, they are file system standard compliant, but who knows ... - 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] Re: how to upgrade docbook-xml properly w.r.t.nxml-mode - /usr/share/emacs/site-lisp/nxml-mode/schema/*.rnc
I didn't think of that:( Thanks for the tip!! -Original Message- From: Markus Hoenicka [mailto:[EMAIL PROTECTED] Sent: Thursday, May 10, 2007 10:12 AM To: docbook-apps@lists.oasis-open.org Subject: RE: [docbook-apps] Re: how to upgrade docbook-xml properly w.r.t.nxml-mode - /usr/share/emacs/site-lisp/nxml-mode/schema/*.rnc Quoting Johnson, Eric [EMAIL PROTECTED]: What I do is a bit of a pain, but it works I just reset the schema location to point at what ever *.rnc file I need to validate the document against. The pain is that you must do it for each document you open at least once. Why don't you put that schema location into your ~/schemas.xml file? This would allow Emacs to open all DocBook files with that schema file. regards, Markus -- Markus Hoenicka [EMAIL PROTECTED] (Spam-protected email: replace the quadrupeds with mhoenicka) http://www.mhoenicka.de - 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] Reusing section where a chapter should be - and the reverse
I too have run into the same problem and resorted to using xincludes to import all of the required paragraphs... It works but it is a pain. -Original Message- From: Peter Desjardins [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 10, 2007 11:52 AM To: David Cramer (Tech Pubs); docbook-apps@lists.oasis-open.org Subject: RE: [docbook-apps] Reusing section where a chapter should be - and the reverse That xpointer did work perfectly. Thank you! This may be a question for the docbook list but is this a common problem encountered when reusing content? I've run into it many times when making short excerpts of material in larger technical references. Now I have a working solution so I'm happy. XMLMind won't accept the syntax of the xpointer but since I'm actually writing the content in other documents it doesn't matter. Peter Desjardins -Original Message- From: David Cramer (Tech Pubs) [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 10, 2007 09:39 To: Peter Desjardins; docbook-apps@lists.oasis-open.org Subject: RE: [docbook-apps] Reusing section where a chapter should be - and the reverse Try this: chapter xi:include href=docbook-file-containing-the-modular-content.xml xmlns:xi=http://www.w3.org/2001/XInclude; xpointer=xpointer(//[EMAIL PROTECTED]'IdOfTheSectionElement']/*)/ /chapter David Reading Chapter 22. Modular DocBook files in DocBook XSL led me to believe that the following xi:include could solve the problem for me. I expect it to include every child element of a section element in the chapter element. chapter xi:include href=docbook-file-containing-the-modular-content.xml xmlns:xi=http://www.w3.org/2001/XInclude; xpointer=element(IdOfTheSectionElement/*) / /chapter But the xi:include fails. I use xmllint to resolve xi:includes. It gives the following errors: docbook-file-that-is-including.xml:11: element include: XInclude error : XPointer evaluation failed: #element(IdOfTheSectionElement/*) docbook-file-that-is-including.xml:11: element include: XInclude error : could not load docbook-file-containing-the-modular-content.xml, and no fallback was found Is my xpointer syntax incorrect? Other xi:includes from the same source file resolved without any trouble (they include entire elements). Is there a better way to reuse section and chapter elements in each other's hierarchical places? In case it matters, here's my xmllint version: $ xmllint --version xmllint: using libxml version 20626 compiled with: Threads Tree Output Push Reader Patterns Writer SAXv1 FTP HTTP DTDValid HTML Legacy C14N Catalog XPath XPointer XInclude Iconv ISO8859X Unicode Regexps Automata Expr Schemas Schematron Modules Debug Thanks for your help! Peter Desjardins - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
