[docbook-apps] Fop failing with illicit table
Hello, I am facing the infamous error: "A table-cell is spanning more rows than available in its parent element." When trying to convert DocBook to PDF using FOP. It is a big document with many tables, and looking for the culprit is tedious. Has anyone faced this issue, and found a way to detect the issue? A "simple" XPath would do I guess? Cheers, -- *NeoDoc* *Camille Bégnis* cami...@neodoc.fr Tél: +33 (0)4.42.52.24.20 5, rue de la Touloubre 13770 Venelles France http://www.neodoc.fr/
Re: [docbook-apps] Fop failing with illicit table
Hi Camille, On 15 Nov 2013, at 10:24, Camille Bégnis wrote: > Hello, > > I am facing the infamous error: > "A table-cell is spanning more rows than available in its parent element." > When trying to convert DocBook to PDF using FOP. > It is a big document with many tables, and looking for the culprit is > tedious. > That would make it an illegal CALS table - according to the OASIS CALS specs. > Has anyone faced this issue, and found a way to detect the issue? > A "simple" XPath would do I guess? > I've created some schematron and done a blog post on CALS validity: http://code.google.com/p/cals-table-schematron/ http://blogs.deltaxml.com/2013/08/08/cals-table-validity/ (I do have an update I want to get some time to work on - I want to try out David Carlisle's suggestion to address the phases/progressive-validation issue - which is more of a schematron issue) Cheers, Nigel -- Nigel Whitaker, Software Architect, DeltaXML Ltd. "Experts in information change" nigel.whita...@deltaxml.com http://www.deltaxml.com +44 1684 869035 Registered in England: 02528681 Reg. Office: Monsell House, WR8 0QN, UK
Re: [docbook-apps] Fop failing with illicit table
On 11/15/2013 04:24 AM, Camille Bégnis wrote: > I am facing the infamous error: > "A table-cell is spanning more rows than available in its parent element." > When trying to convert DocBook to PDF using FOP. > It is a big document with many tables, and looking for the culprit is > tedious. > > Has anyone faced this issue, and found a way to detect the issue? > A "simple" XPath would do I guess? If the message comes from fop, open the .fo file in Oxygen and hit Validate. Regards, David - 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] generate.citerefentry.link customization not emitting refentrytitle contents in XSL-NS stylesheets
Hi Jon, You said DocBook 5, so I think you need to add the namespace prefix to the element name: -- Bob Stayton Sagehill Enterprises b...@sagehill.net On 11/8/2013 3:56 AM, Jon Leech wrote: I've got a Docbook 5 page including glDepthRange and a stylesheet customization of ...xsl-ns/current/xhtml5/onechunk.xsl including select="refentrytitle"/>.xhtml When I process this with e.g. xsltproc testref.xsl testref.xml the generate.citerefentry.link template is run, but does not emit the contents in testref.xhtml. I expect to see class="citerefentry">class="refentrytitle">glDepthRange but in fact get ...href=".xhtml"... Did something change about the way this template should be coded between the XSL and XSL-NS stylesheets? When I change the stylesheet in testref.xsl to the old ...release/xsl/current/xhtml5/onechunk.xsl, the generated link comes out correctly. This is using the the 1.78.1 releases of both XSL and XSL-NS, as packaged by Debian. 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
