[docbook-apps] Should xmllint successfully validate docbook 5 containing XIncludes?
I'm trying to validate some documents generated by the db4-upgrade.xsl from existing (validating) db4 documents. Validating the resulting db5 results in mysterious errors that don't seem to correspond to actual problems. Eventually I figured out that if I inlined content that had originally been XIncluded, the errors went away. The especially mystifying part is that the reported errors are in parts of the document having nothing to do with the apparently offending xi:include element. Should I expect xmllint to operate properly with XIncludes? xmllint doesn't have any problems validating the original db4 documents, which also contain XIncludes, so it seems to be somehow related to db5, but I'm out of my depth at this point. I've attached a (relatively) minimal case below; valid.xml inlines the file, invalid.xml instead XIncludes it. Running xmllint --noout --xinclude --relaxng http://docbook.org/xml/5.0/rng/docbook.rng valid.xml invalid.xml results in valid.xml validates invalid.xml:27: element variablelist: Relax-NG validity error : Expecting element example, got variablelist invalid.xml:37: element variablelist: Relax-NG validity error : Element refsection has extra content: variablelist invalid.xml:34: element refsection: Relax-NG validity error : Element refentry has extra content: refsection invalid.xml fails to validate but the xi:include element in invalid.xml doesn't occur until line 48, well after the reported errors. I attempted using jing on these documents to try and see if this behavior is an xmllint-specific problem, but it appears to just hang up forever (not the case with other schema and documents I've used jing on). Are there any other validators I should be trying on Debian 7? Thanks, Jon Leech !DOCTYPE refentry [ !ENTITY % mathml PUBLIC -//W3C//DTD MathML 2.0//EN http://www.w3.org/TR/MathML2/dtd/mathml2.dtd; %mathml; ] refentry xmlns=http://docbook.org/ns/docbook; version=5.0 xml:id=glTexImage1D info copyright year1991-2006/year holderSilicon Graphics, Inc./holder /copyright /info refnamediv refnameglTexImage1D/refname refpurposespecify a one-dimensional texture image/refpurpose /refnamediv refsynopsisdiv funcsynopsis funcprototype funcdefvoid functionglTexImage1D/function/funcdef paramdefGLenum parametertarget/parameter/paramdef /funcprototype /funcsynopsis /refsynopsisdiv refsection xml:id=parametersinfotitleParameters/title/info variablelist varlistentry termaterm/term listitemparatext/para/listitem /varlistentry /variablelist /refsection refsection xml:id=descriptioninfotitleDescription/title/info para /para variablelist varlistentry termconstantGL_RED/constant/term listitem para /para /listitem /varlistentry /variablelist para /para !-- valid.xml includes the contents of baseformattable.xml inline -- para table frame=topbotinfotitleBase Internal Formats/title/info tgroup cols=3 align=left colspec align=left/ colspec align=left/ colspec align=left/ thead row entry rowsep=1 align=leftemphasis role=bold Base Internal Format /emphasis/entry entry rowsep=1 align=leftemphasis role=bold RGBA, Depth and Stencil Values /emphasis/entry entry rowsep=1 align=leftemphasis role=bold Internal Components /emphasis/entry /row /thead tbody row entryconstantGL_DEPTH_COMPONENT/constant/entry entryDepth/entry entryD/entry /row row entryconstantGL_DEPTH_STENCIL/constant/entry entryDepth, Stencil/entry entryD, S/entry /row row entryconstantGL_RED/constant/entry entryRed/entry entryR/entry /row row entryconstantGL_RG/constant/entry entryRed, Green/entry entryR, G/entry /row row entryconstantGL_RGB/constant/entry entryRed, Green, Blue/entry entryR, G, B/entry /row row entryconstantGL_RGBA/constant/entry entryRed, Green, Blue, Alpha/entry entryR, G, B, A/entry /row /tbody /tgroup /table /para /refsection /refentry !DOCTYPE refentry [ !ENTITY % mathml PUBLIC -//W3C//DTD MathML 2.0//EN http://www.w3.org/TR/MathML2/dtd/mathml2.dtd; %mathml; ] refentry xmlns=http://docbook.org/ns/docbook; version=5.0 xml:id=glTexImage1D info copyright year1991-2006/year holderSilicon Graphics,
Re: [docbook-apps] smart quotes are acting stupid in Firefox IE; why?
Hi Robert, On Fr, 2013-10-25 at 22:23 -0500, Robert Nagle wrote: As you know, MS Word automatically changes quotes to smart quotes and so my docbook source in Oxygen editor includes smart quotes and not normal quotes. I think the best way to generate quotes in DocBook is using the quote element -- that way you get whatever quotes are most appropriate for the target language automatically in your output. (generously snipped...) ?xml version=1.0 encoding=UTF-8 standalone=no? v/ meta http-equiv=Content-Type content=text/html; charset=UTF-8 / It's not really the same -- your Wordpress instance uses the meta element while your DocBook processor writes it in the XML declaration. Seeing as only one of the two works, browsers probably need the the meta element version. Stefan. -- SUSE LINUX GmbH, Maxfeldstraße 5, D-90409 Nürnberg Geschäftsführer: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 21284 (AG Nürnberg) signature.asc Description: This is a digitally signed message part
RE: [docbook-apps] Olinks in PDF missing valid destination?
Hi Bob, List,
I don't know if this a new thread or a continuation of what has been discussed
below. I set up some olinks on a set of very simple documents for testing
purposes (only transformed to pdf at this stage) and they were working fine.
However, I have now incorporated olinks into some larger documents and the pdf
output is not as anticipated; in that following the occurrence of an xref
element, no heading or para text is displayed for the remainder of that chapter
- I do get the gentext of the first and subsequent cross-references and I do
still get heading numbers, bullets, etc. When I remove either the olink or the
xref the document renders as expected. I did think that it may have been a
problem in my customization layer but I get the same results with the standard
1.72.0 stylesheets. I also tested with the link element, when the link is an
empty element I get the same problem, when the link element contains text, I do
not.
As mentioned previously, I am using docbkx-tools 2.0.14 and FOP 1.0 with the
1.72.0 stylesheets. I appreciate the issue may be with my tool chain and not
the stylesheets and I have searched the web for other instances of this
occurrence but cannot find any, I was wondering if you or anyone else in the
community had observed such behavior and could provide a fix.
Regards
Nick
-Original Message-
From: Bob Stayton [mailto:b...@sagehill.net]
Sent: Saturday, October 26, 2013 1:16 AM
To: Alexey Neyman; docbook-apps@lists.oasis-open.org
Cc: Wood Nick; Mark Craig
Subject: Re: [docbook-apps] Olinks in PDF missing valid destination?
Excellent, thanks for tracking that down and providing the fix.
Bob Stayton
Sagehill Enterprises
b...@sagehill.net
--
From: Alexey Neyman sti...@att.net
Sent: Friday, October 25, 2013 11:01 AM
To: docbook-apps@lists.oasis-open.org
Cc: Wood Nick nick.w...@ncia.nato.int; Bob Stayton
b...@sagehill.net; Mark Craig mark.cr...@gmail.com
Subject: Re: [docbook-apps] Olinks in PDF missing valid destination?
Hi Bob,
Looks like the stylesheets could produce invalid link url(#dest=) if
$fop1.extensions=1 and $insert.olink.pdf.frag=0. In that case,
make.olink.href template generates a string without '#something'
anchor. The code in olink template in fo/xref.xsl then tries to parse
this string as follows and
fails:
xsl:variable name=mybeg select=substring-before($href,'#')/
xsl:variable name=myend select=substring-after($href,'#')/
fo:basic-link
external-destination=url({concat($mybeg,'#dest=',$myend)})
xsl:use-attribute-sets=olink.properties
xsl:copy-of select=$hottext/
/fo:basic-link
If the $href does not contain #, both $mybeg and $myend would be
empty, leading to invalid URL '#dest='. Fix committed in r9825.
Regards,
Alexey.
On Friday, October 25, 2013 12:37:54 am Wood Nick wrote:
Hi Bob,
I am using docbkx-tools 2.0.14 with the 1.72.0 stylesheets. You are
correct, setting insertOlinkPdfFrag1/insertOlinkPdfFragin the POM
is the same as param name=insert.olink.pdf.frag select=1/ in
the stylesheet. I am using FOP 1.0 (we run Nexus behind a firewall
and so updates are a challenge) which does not appear to support
fragment identifiers. From your response below I assume FOP 1.1 does?
Regards
Nick
From: Mark Craig [mailto:mark.cr...@gmail.com]
Sent: Thursday, October 24, 2013 8:52 PM
To: Bob Stayton
Cc: Wood Nick; DocBook Apps
Subject: Re: [docbook-apps] Olinks in PDF missing valid destination?
Hi Bob,
What I observed with insertOlinkPdfFrag left undefined -- I'm
assuming that means insert.olink.pdf.frag is 0 -- I was getting
external-destination=url(#dest=) in the .fo. No file name, no fragment.
I think docbkx-tools 2.0.14 is picking up version 1.76.1 stylesheets.
What
I didn't do is get the stylesheets and try without docbkx-tools.
Regards,
Mark
On Thu, Oct 24, 2013 at 7:46 PM, Bob Stayton
b...@sagehill.netmailto:b...@sagehill.net wrote: Hi Mark,
Can you clarify one point for me? When insertOlinkPdfFrag is not set
to
1, does not properly resolved mean the link can open the other PDF
document but not scroll to the proper location, or does it not open
the other PDF at all? I would expect the former.
I'm not a user of docbkx-tools, but I presume setting
insertOlinkPdfFrag is the same as setting the DocBook XSL
stylesheet parameter named 'insert.olink.pdf.frag', right? That
parameter's default value should probably be 1, now that all XSL-FO
processors support the fragment identifiers.
Bob Stayton
Sagehill Enterprises
b...@sagehill.netmailto:b...@sagehill.net
From: Mark Craigmailto:mark.cr...@gmail.com
Sent: Thursday, October 24, 2013 6:00 AM
To: Wood Nickmailto:nick.w...@ncia.nato.int ; DocBook
Appsmailto:docbook-apps@lists.oasis-open.org Subject: Re:
[docbook-apps]
Olinks in PDF missing valid destination?
By the way,
When I want to resolve olinks between PDF
Re: [docbook-apps] smart quotes are acting stupid in Firefox IE; why?
Hi, I looked into this some more. Seeing strange characters in DocBook XHTML output usually means the browser thinks the file has iso-8859-1 encoding instead of the UTF-8 encoding that is the DocBook XHTML default. It is the case that browsers should read either the encoding attribute of the XML declaration in the output file (which DocBook XSL does set), or this meta element: meta http-equiv=Content-Type content=text/html; charset=UTF-8 / The DocBook xhtml stylesheet does not have to output this meta element because the XSLT processors automatically insert it in each output file in the head element. But I also found that when processing with the xhtml5 stylesheet instead of xhtml, that meta element is *not* output automatically (and the epub3 stylesheet is based on xhtml5). I thought that was odd, since the xhtml5 stylesheet imports from the xhtml directory. By experimentation, I found that the crucial difference is that the xhtml5 stylesheet does not set the doctype attributes in the xsl:output element, because the XHTML5 standard does not support a DTD. Apparently xsltproc and Saxon relied on the doctype attributes to generate that encoding meta element. I tried putting that meta element in the epub3 output files, but epubcheck version 3 objected. It should be ok in XHMTL5 output intended for browsing, but not for EPUB3. But EPUB3 readers don't need it, so I think you will have to live with the odd characters when browsing the epub3 output with those HTML browsers. Bob Stayton Sagehill Enterprises b...@sagehill.net -- From: Stefan Knorr skn...@suse.de Sent: Monday, October 28, 2013 4:37 AM To: docbook-apps@lists.oasis-open.org Subject: Re: [docbook-apps] smart quotes are acting stupid in Firefox IE; why? Hi Robert, On Fr, 2013-10-25 at 22:23 -0500, Robert Nagle wrote: As you know, MS Word automatically changes quotes to smart quotes and so = my docbook source in Oxygen editor includes smart quotes and not normal quotes. I think the best way to generate quotes in DocBook is using the quote element -- that way you get whatever quotes are most appropriate for the target language automatically in your output. (generously snipped...) ?xml version=3D1.0 encoding=3DUTF-8 standalone=3Dno? v/=20 meta http-equiv=3DContent-Type content=3Dtext/html; charset=3DUTF-8 / It's not really the same -- your Wordpress instance uses the meta element while your DocBook processor writes it in the XML declaration. Seeing as only one of the two works, browsers probably need the the meta element version. Stefan. - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
[docbook-apps] Title of a toc, when toc is generated at a user-specified position
When choosing to place the TOC of a book after the book's preface, it appears that one loses[*] the TOC's generated title as a side-effect. That is, when following the recipe in this URL: https://lists.oasis-open.org/archives/docbook-apps/200705/msg00023.html What's the best approach to make this TOC have a title nonetheless? Thanks in advance, Erik Leunissen (xsltproc - fop1.1 - pdf) -- [1] Adding a title to toc in the xml source makes the toc element non-empty, which effectively disables the process.empty.source.toc parameter. - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Title of a toc, when toc is generated at a user-specified position
Hi Erik, Setting a completely empty 'generate.toc' param is a little too much it seems. Instead of: xsl:param name=generate.toc/ use one that specifies only the title for a book toc: xsl:param name=generate.toc book title /xsl:param That will generate the title for the relocated toc, with one glitch. If you are using the default 'header.content' template for your page headers, you will get a couple of warning messages about Request for title That's because the header template is trying to process the toc element (which has its own page sequence) to get a title for the header. But the stylesheet is missing a template matching on toc in mode=title.markup. The following template fixes that problem, and I will add it to the next release. xsl:template mode=title.markup match=toc xsl:param name=allow-anchors select=0/ xsl:param name=verbose select=1/ xsl:choose xsl:when test=title|info/title xsl:apply-templates select=(title|info/title)[1] mode=title.markup xsl:with-param name=allow-anchors select=$allow-anchors/ /xsl:apply-templates /xsl:when xsl:otherwise xsl:call-template name=gentext xsl:with-param name=key select='TableofContents'/ /xsl:call-template /xsl:otherwise /xsl:choose /xsl:template Bob Stayton Sagehill Enterprises b...@sagehill.net -- From: Erik Leunissen e.leunis...@hccnet.nl Sent: Monday, October 28, 2013 2:08 PM To: docbook-apps@lists.oasis-open.org Subject: [docbook-apps] Title of a toc, when toc is generated at a user-specified position When choosing to place the TOC of a book after the book's preface, it appears that one loses[*] the TOC's generated title as a side-effect. That is, when following the recipe in this URL: https://lists.oasis-open.org/archives/docbook-apps/200705/msg00023.html What's the best approach to make this TOC have a title nonetheless? Thanks in advance, Erik Leunissen (xsltproc - fop1.1 - pdf) -- [1] Adding a title to toc in the xml source makes the toc element non-empty, which effectively disables the process.empty.source.toc parameter. - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Should xmllint successfully validate docbook 5 containing XIncludes?
The short answer is no, xmllint does not successfully validate DocBook 5 documents that are in fact valid. I normally use Jing to validate DocBook 5. I've not seen it hang like you have. Bob Stayton Sagehill Enterprises b...@sagehill.net -- From: Jon Leech j...@alumni.caltech.edu Sent: Monday, October 28, 2013 3:34 AM To: docbook-apps@lists.oasis-open.org Subject: [docbook-apps] Should xmllint successfully validate docbook 5 containing XIncludes? I'm trying to validate some documents generated by the db4-upgrade.xsl from existing (validating) db4 documents. Validating the resulting db5 results in mysterious errors that don't seem to correspond to actual problems. Eventually I figured out that if I inlined content that had originally been XIncluded, the errors went away. The especially mystifying part is that the reported errors are in parts of the document having nothing to do with the apparently offending xi:include element. Should I expect xmllint to operate properly with XIncludes? xmllint doesn't have any problems validating the original db4 documents, which also contain XIncludes, so it seems to be somehow related to db5, but I'm out of my depth at this point. I've attached a (relatively) minimal case below; valid.xml inlines the file, invalid.xml instead XIncludes it. Running xmllint --noout --xinclude --relaxng http://docbook.org/xml/5.0/rng/docbook.rng valid.xml invalid.xml results in valid.xml validates invalid.xml:27: element variablelist: Relax-NG validity error : Expecting element example, got variablelist invalid.xml:37: element variablelist: Relax-NG validity error : Element refsection has extra content: variablelist invalid.xml:34: element refsection: Relax-NG validity error : Element refentry has extra content: refsection invalid.xml fails to validate but the xi:include element in invalid.xml doesn't occur until line 48, well after the reported errors. I attempted using jing on these documents to try and see if this behavior is an xmllint-specific problem, but it appears to just hang up forever (not the case with other schema and documents I've used jing on). Are there any other validators I should be trying on Debian 7? Thanks, Jon Leech - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
