Hi Bob, Thanks for the info. For now I used the suggested fix in my customizing layer so I should be fine.
Best regards, Lars Am 17.02.2014 18:09 schrieb "Bob Stayton" <b...@sagehill.net>: > Hi Lars, > Yes, a release is planned for the near future, but I cannot give you a > date. We are in the process of converting the SVN tree over to the > namespaced version of the XSL files (which are currently generated from the > non-namespaced version), and that's a pretty big change. All new features > and fixes checked in will be included in that release. > > Bob Stayton > Sagehill Enterprises > b...@sagehill.net > > On 2/17/2014 6:42 AM, Lars Vogel wrote: > >> Hi, >> >> I just ran into the same issue describe in this email conversation(from >> May >> 2013). Looks to me that there was no new release of the XSL sheets since >> May 2013 (according to >> http://sourceforge.net/projects/docbook/files/docbook-xsl/) is this >> planned >> for the near future? >> >> Best regards, Lars >> >> >> >> >> 2013-04-03 19:04 GMT+02:00 Bob Stayton <b...@sagehill.net>: >> >> It is a bug in the epub/docbook.xsl stylesheet file. This template: >>> >>> <xsl:template match="d:author|d:corpauthor" mode="opf.metadata"> >>> >>> creates the dc:creator element and tries to add an attribute named >>> "opf:file-as" by calling the template named 'person.name.last-first'. >>> However, that template generates an HTML <span> element, and you cannot >>> put >>> an element into an attribute value. The solution is to take the text >>> value >>> of the that template call: >>> >>> <xsl:template match="d:author|d:corpauthor" mode="opf.metadata"> >>> <xsl:variable name="n"> >>> <xsl:call-template name="person.name"> >>> <xsl:with-param name="node" select="."/> >>> </xsl:call-template> >>> </xsl:variable> >>> <xsl:element name="dc:creator"> >>> <xsl:attribute name="opf:file-as"> >>> <xsl:variable name="attvalue"> >>> <xsl:call-template name="person.name.last-first"> >>> <xsl:with-param name="node" select="."/> >>> </xsl:call-template> >>> </xsl:variable> >>> <xsl:value-of select="$attvalue"/> >>> </xsl:attribute> >>> <xsl:value-of select="normalize-space(string($n))"/> >>> </xsl:element> >>> </xsl:template> >>> >>> I'll fix this in the source, and you can use this in your customization >>> layer. >>> >>> Bob Stayton >>> Sagehill Enterprises >>> b...@sagehill.net >>> >>> *From:* Marcel Tromp <mtromp.docb...@gmail.com> >>> *Sent:* Tuesday, April 02, 2013 1:40 PM >>> *To:* Bob Stayton <b...@sagehill.net> >>> *Cc:* docbook-apps <docbook-apps@lists.oasis-open.org> >>> *Subject:* Re: [docbook-apps] Epub and Saxon >>> >>> It is the author element in info that triggers the problem: >>> <author> >>> <personname> >>> <firstname>Marcel</firstname> >>> <surname>Tromp</surname> >>> </personname> >>> </author> >>> If I use an empty authorgroup, no errors are generated. The error I >>> showed >>> before is generated twice: once for firstname, once for lastname. >>> >>> MT >>> -- >>> >>> >>> On Tue, Apr 2, 2013 at 8:56 AM, Bob Stayton <b...@sagehill.net> wrote: >>> >>> Hi Marcel, >>>> Can you determine exactly which element in info is triggering that >>>> error? Perhaps comment out all but one element at a time? >>>> >>>> Bob Stayton >>>> Sagehill Enterprises >>>> b...@sagehill.net >>>> >>>> *From:* Marcel Tromp <mtromp.docb...@gmail.com> >>>> *Sent:* Monday, April 01, 2013 1:11 PM >>>> *To:* docbook-apps <docbook-apps@lists.oasis-open.org> >>>> *Subject:* [docbook-apps] Epub and Saxon >>>> >>>> Hi, >>>> >>>> I am setting up flow to generate epub using 1.78.1, but will use Saxon >>>> instead of xsltproc. >>>> >>>> With xsltproc, document converts without any warnings/errors, but Saxon >>>> throws recoverable errors: >>>> >>>> Recoverable error >>>> at xsl:attribute on line 211 of >>>> file://work/mtools/docbook-xsl-ns/dev/xhtml-1_1/inline.xsl: >>>> Cannot write an attribute node when no element start tag is open >>>> Writing OEBPS/content.opf >>>> This seems to be caused by adding the author data to content.opf in line >>>> 260 of epub/docbook.xsl: >>>> >>>> <xsl:apply-templates select="/*/*[contains(name(.), 'info')]/*" >>>> mode="opf.metadata"/> >>>> Although the generated file seems ok, the error output will be >>>> problematic/confusing for users. >>>> >>>> Is there a way to suppress these errors, or even better, prevent them >>>> from happing? >>>> >>>> MT >>>> -- >>>> >>>> >>>> >>> >>> >>
