dita4publishers / org.dita4publishers.common.xslt

Provides XSLT modules and function libraries appropriate for any Open Toolkit transform. Primarily supports the D4P map-driven processing framework.

org.dita4publishers.common.xslt

Provides XSLT modules and function libraries appropriate for any Open Toolkit transform. Primarily supports the D4P map-driven processing framework.

Depends on the org.dita-community-common.xslt plugin https://github.com/dita-community/org.dita-community.common.xslt

org.dita4publishers.common.xslt's Issues

Remove DOCTYPE decls from SVG, other XML

When copying SVG or other XML-based graphics, remove DOCTYPE decls (EPUB, in particular, does not allow SVGs with DOCTYPE decls).

Node creation in href-fixup changes base-uri, which later causes df:resolveTopicElementRef() to fail

This is related to issue #10 from the dita4publishers issue tracker (dita4publishers/dita4publishers#10). DITA element nodes get re-created in href-fixup mode, which changes their URI. This means that in the default/normal processing mode for HTML transforms (those that use href-fixup) resolution of xrefs cannot succeed with df:resolveTopicElementRef() (a workaround could have been to pass in the topicref as the relevant context element to the function). This will be solved by using the xml:base attribute to preserve the original node URI. This affects the following plugins:
kindle, html5, html2, epub

href-fixup mode does not account for links resulting from keyref-only elements

Given an element like <term keyref="some-gloss-entry"/> the href fixup process is not applied so the URL in the generated result does not reflect the location of the result file when the file organization strategy is single-dir

href-fixup mode does not handle link elements

Need to handle link elements in the same way as xref elements.

Generated graphic copy ANT script fails for graphics with spaces in filenames

So you've got this in your DITA:

<image href="../images/testing%20FP%20JPG-1.jpg"/>

This results in the following in the copy-graphics.xml file:

  <copy toFile="/path/to/images/testing FP JPG-1.jpg"
        overwrite="yes">
     <fileset dir="/path/to/output/images">
        <include name="testing%20FP%20JPG-1.jpg"/>
     </fileset>
  </copy>

Which, in turn, gives you (or, at least, me, on OSX)

BUILD FAILED
/path/to/build_transtype-html2.xml:149: The following error occurred while executing this line:
/path/to/build_transtype-html2.xml:155: The following error occurred while executing this line:
/path/to/copy-graphics.xml:132: Cannot perform operation from directory to file.

I think the fix is to change graphicMap2AntCopyScript.xsl to wrap the file name used in the <include> in relpath:toFile(), like so:

<include name="{relpath:toFile(relpath:getName(@input-url), $platform)}"/>

At least, that seems to work for me. I'll submit a pull request shortly.

outer image and graphic map

The graphic map does seems not support ‘outer’ images. I mean that if an image is in a sibling directory than the ditamap parent directory, the resolved path is wrong.

I found in the generated list that up levels is a property available that seems to provide the ‘real’ parent directory information. The path in the image.list seems show path related to this parent directory.

An example

Map

fr-ca/system/map.ditamap

Images located in

en-ca/system/assets/images/image.jpg

the final path is resolved to

fr-ca/system/fr-ca/system/assets/images/image.jpg

The image.list provides this information, when resolving an image

en-ca/system/assets/images/image.jpg

I found this ant property uplevels, also available in dita.list which seems to provide the missing information, which is in this case:
uplevels = ../../

I am not sure if I can use it.

What do you think about this ?

Map-to-graphic-map: handle image list processing does not handle uplevels correctly

The OT run under Windows provides the uplevels parameter as a Windows path component not a URL component.

The handleImageListFile template needs to convert the uplevels value to a URL component.

map-to-graphic-map does not ignore topicrefs within chunking topicrefs

Correct map2graphicMap.xsl to

  <xsl:template mode="generate-graphic-map get-graphic-refs"
                match="*[df:isTopicRef(.)]
                             [not(@scope = ('external', 'peer'))]
                             [not(df:inChunk(.))]"
    >

Refactor match="gmap:graphic-map-item" mode="generate-copy-targets" to make extension easier

This template generates three separate Ant targets. Each target should be generated it its own mode so that they can be more easily overridden.

Enable override of graphic map generation processing

The template <xsl:template match="*[df:class(., 'map/map')]" mode="generate-graphic-map"> in map2graphicMap.xsl uses a for-each loop to process the graphic references collected earlier in the template.

It should apply templates to the graphic references in order to enable customization of the generation of graphic map entries in the final graphic map.

Need to do the same thing for the image list file handling.

Map graphics declared only on keydefs

Graphics that are declared on key-defining topicrefs but not referenced using image or object elements should also produce graphic map entries.

Account for peer and external scopes in handling topicrefs

Support OT 3.x renamed graphic files

Use the $job variable to dereference rewritten graphic filenames to their source file location:

<xsl:value-of select="key('jobFile', @href, $job)/@src"/>