transpect / epubtools Goto Github PK

Saxon 10 has become more rigorous in enforcing this rule. Workarounds such as slash duplication (<xsl:result-document href="{replace(base-uri(), '/(debug|chunks)/', '//$1/')}"> in insert-individual-css-link.xsl) do not work any more.

There is a typo preventing having the toc after the cover in opf spine.

Change line 1262 in epubtools/modules/html-splitter/xsl/html-splitter.xsl line
from
<meta name="sequence" content="($epub-config/types/@nav-spine-pos, 1.5)[1]"/>
to
<meta name="sequence" content="{($epub-config/types/@nav-spine-pos, 1.5)[1]}"/>
i.e. missing {} in @content.

Hi,
in the generated nav list the li/@href is missing the html-prefix resulting in invalid epubs.

Patch:
in epubtools/modules/html-splitter/xsl/html-splitter.xsl, line 1318 use the following corrected template

<xsl:template name="page-list-nav-inner"> <nav epub:type="page-list" id="page-list-navigation" hidden="hidden"> <ol> <xsl:for-each select="$pgl/html:page[normalize-space(@name)]"> <li> <!-- GB patch: added $html-prefix --> <a href="{concat($html-prefix, @href)}" srcpath="pgl_{generate-id()}"> <xsl:value-of select="@name"/> </a> </li> </xsl:for-each> </ol> </nav> </xsl:template>

Currently the css-handling parameter trigger the css handling even when its value is "unchanged" and therefore the epub generation fails in case of css parsing errors.

Would it be possible to completely skip the css parsing when css-handling="unchanged" and copy over in the generated epub whatever css files are in the sources (ideally inserting also the relevant manifest entries) ?

This would help also with valid but complex css as the css parsing is quite slow.

In heading-conf.rnc:

    ## If there is content before the first splitting point,
    ##           it will be referred to by the toc as 'Frontmatter' or, if present, the
    ##           value of generated-frontmatter-title. If generated-frontmatter-title 
    ##           is the empty string (or whitespace-only), the toc entry will be left out.

Where can I specify this generated-frontmatter-title?
In epub-config.xml?

BTW, ‘Frontmatter’ is not an ideal default, according to my dictionary the spelling is ‘Front matter’.

Since in this case it will be most likely will be used in title case, I would go for the default: ‘Front Matter’. I would have made a pull request, but I’ve seen this value used in various places and was afraid to break things…

Cheers,

In my example there are some h1 elements that are splitted at. Additionally two paragraphs containing the class »TOC1« contain contents that shall be displayed in NCX. I wanted to allow a conditional split on those. If I use the conditional-split element in the heading-conf.xml, the hierarchy level in NCX becomes lower than if I use the unconditional-split element.
At first I thought there was a problem with concurrent classes because another class (»abgesenkt«) that is defined as conditional-split also occurs on the mentioned paras. But that didn't seem to be the problem.

https://subversion.le-tex.de/customers/hanser/bel/content/hanser/CHV/26009/tei