[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 http://www.w3.org/TR/MathML2/dtd/mathml2.dtd";> %mathml; ]> http://docbook.org/ns/docbook"; version="5.0" xml:id="glTexImage1D"> 1991-2006 Silicon Graphics, Inc. glTexImage1D specify a one-dimensional texture image void glTexImage1D GLenum target Parameters aterm text Description GL_RED Base Internal Formats Base Internal Format RGBA, Depth and Stencil Values Internal Components GL_DEPTH_COMPONENT Depth D GL_DEPTH_STENCIL Depth, Stencil D, S GL_RED Red R GL_RG Red, Green R, G GL_RGB Red, Green, Blue R, G, B GL_RGBA Red, Green, Blue, Alpha R, G, B, A http://www.w3.org/TR/MathML2/dtd/mathml2.dtd";> %mathml; ]> http://docbook.org/ns/docbook"; version="5.0" xml:id="glTexImage1D"> 1991-2006 Silicon Graphics, Inc. glTexImage1D specify a one-dimensional texture image void glTexImage1D GLenum target Parameters aterm text Description GL_RED http://www.w3.org/2001/XInclude"; href="baseformattable.xml"/> Base Internal Formats Base Internal Format RGBA, Depth and Stencil Values Internal Components GL_DEPTH_COMPONENT Depth D GL_DEPTH_STENCIL Depth, Stencil D, S GL_RED Red R GL_RG Red, Green R, G GL_RGB Red, Green, Blue R, G, B GL_RGBA Red, Green, Blue, Alpha R, G, B, A - 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] 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 element -- that way you get whatever quotes are most appropriate for the target language automatically in your output. (generously snipped...) > v/ > 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"
Sent: Friday, October 25, 2013 11:01 AM
To:
Cc: "Wood Nick" ; "Bob Stayton"
; "Mark Craig"
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:
>
>
>
> external-destination="url({concat($mybeg,'#dest=',$myend)})"
> xsl:use-attribute-sets="olink.properties">
>
>
>
> 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 1in the POM
>> is the same as 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 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
>> mailto:b...@sagehill.net>> wrote: Hi Mark,
>> Can you clarify one point for me? When 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
>> 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.net
>>
>> From: Mark Craig
>> Sent: Thursday, October 24, 2013 6:00 AM
>> To: Wood Nick ; DocBook
>> Apps Subject: Re:
>> [docbook-apps]
>> Olinks in PDF missing valid destination?
>>
>> By the way,
>>
>> When I want to resolve olinks between PDF documents, it looks like I
>> also need 1.
>>
>> Otherwise external-destinations are not properly resolved (though
>> according to Olink debug messages they are resolved).
>>
>> Again, I'm seeing this behavior with 1.76.1.
>>
>> Regards,
>> Mark
>>
>>
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: 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 element. But I also found that when processing with the xhtml5 stylesheet instead of xhtml, that 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 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" Sent: Monday, October 28, 2013 4:37 AM To: 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 element -- that way you get whatever quotes are most appropriate for the target language automatically in your output. (generously snipped...) v/=20 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: use one that specifies only the title for a book toc: book title 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. mode="title.markup"> Bob Stayton Sagehill Enterprises b...@sagehill.net -- From: "Erik Leunissen" Sent: Monday, October 28, 2013 2:08 PM To: 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" Sent: Monday, October 28, 2013 3:34 AM To: 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
