Inside ExpPrint 6.2 Changes

A customer recently suggested that it’d be much better if ExpPrint could produce stand-alone HTML files so that anyone with a suitable modern web browser could see the same presentation without needing ExpPrint installed. Since this was something I’d always intended to have (but hadn’t found how to do it), I thought I’d have another look into it.

There were 2 aspects that prevented the HTML files being stand-alone:

1. The HTML file linked to the chosen style files (CSS) in the normal manner:

<link href="path/filename.css" rel="stylesheet" type="text/css">

Since the path to the css files were to the ExpPrint installation directory, anyone without the same css files in the same location on their machine would not be seeing the styles that you’d chosen. They would only see the basic presentation of the HTML that their browser provided.

2. If you has chosen the “Special Folder Indicators – Graphics” style option, to show graphic images for the zip, shared directories, and symbolic links, these also were implemented as linked PNG files in the ExpPrint installation directory.

One solution to the issues would have been to copy all the linked CSS and PNG files into the same location as the HTML output, however that would have meant that you’d have needed to remember to copy the HTML file, CSS, and PNG files together – not a neat solution by any stretch of the imagination!

Solution to the CSS linking

ExpPrint converts its collected listing information from XML to either HTML (detailed table or multi-column layout formats), or CSV using XSLT (Extensible Stylesheet Language Transformations). I was aware that you can inline XML documents from the XSLT transformation but unfortunately CSS files aren’t XML documents, so that doesn’t work. After some searching I discovered the trick that I now use to make the CSS files appear as XML documents.

The only downside to this solution is that any CSS files need to be top and tailed with cryptic code like this:

<!--/*--><root><![CDATA[

Your normal CSS here...

]]></root><!--*/-->

The changes in the XSLT were simple. Previously the code to add the CSS file references was:

       <!--Insert any CSS file parameters-->

        <xsl:if test="$gCssFile != ''">

          <xsl:for-each select="$gCssFile/CSSFiles/CSSFileName">

            <link>

              <xsl:attribute name="rel">stylesheet</xsl:attribute>

              <xsl:attribute name="type">text/css</xsl:attribute>

              <xsl:attribute name="href">

                <xsl:value-of select="."/>

              </xsl:attribute>

            </link>

          </xsl:for-each>

        </xsl:if>

and it’s now:

        <!--Insert any CSS file parameters-->

        <xsl:if test="$gCssFile != ''">

          <style type="text/css">

            <xsl:for-each select="$gCssFile/CSSFiles/CSSFileName">

              <xsl:value-of select="document(.)"

                            disable-output-escaping="yes" />

            </xsl:for-each>

          </style>

        </xsl:if>

 

Solution to the Graphics linking

The solution for inlining the graphics is widely supported – and that is to use data URLs rather than file URLs.

In the “Special Folder Indicators – Graphics” CSS file, the code used to be like this:

    content: url(file:zip.png);

It’s now like this:

    content: url(data:image/png;base64,iVBORw.………………….);

where the long cryptic data is the base64 encoding of the PNG graphic. If you have your own graphics files that you need to inline, there are online tools that will do this for you.

Since the graphic data only occurs once in the CSS file, it doesn’t bloat the resultant HTML file regardless of how many times the graphic appears in the listing.

 

So, overall, the changes to produce stand-alone HTML have been pretty simple. I wish I’d done it sooner!