empty image extension in latex conversion not adding pdf extension

[kcrisman]

At https://github.com/rbeezer/mathbook/blob/dev/xsl/pretext-latex.xsl#L8892 we have

    <xsl:text>\includegraphics[width=\linewidth]</xsl:text>
    <xsl:text>{</xsl:text>
    <xsl:value-of select="$external-directory"/>
    <xsl:value-of select="@source"/>
    <xsl:if test="not($extension)">
        <xsl:text>.pdf&#xa;</xsl:text>
    </xsl:if>
    <xsl:text>}&#xa;</xsl:text>

The newline/carriage return after pdf is spurious, but presumably (?) not a problem. However, for some reason the logic of the test is not working.

Replacing with <xsl:if test="$extension = ''"> works. Apparently there is a difference between null and empty strings in xsl, and substring-after (which gives this extension, eventually, from pretext-common.xsl) returns the empty string, not null.

Since the latex conversion presumably prefers pdf, and since other conversions may want empty extension in the source, this can cause problems in such situations where the source="Imagename" is used instead of source="Imagename.pdf".

[rbeezer]

Thanks! That is a distinction that has caught me out before, and I now avoid it, but clearly there are some remnants.

I should be able to fix this up in a day or two, AFK for a bit.

On July 20, 2021 2:05:33 PM PDT, kcrisman @.***> wrote:

At https://github.com/rbeezer/mathbook/blob/dev/xsl/pretext-latex.xsl#L8892 we have

   <xsl:text>\includegraphics[width=\linewidth]</xsl:text>
   <xsl:text>{</xsl:text>
   <xsl:value-of select="$external-directory"/>
   <xsl:value-of ***@***.***"/>
   <xsl:if test="not($extension)">
       <xsl:text>.pdf&#xa;</xsl:text>
   </xsl:if>
   <xsl:text>}&#xa;</xsl:text>

The newline/carriage return after pdf is spurious, but presumably (?) not a problem. However, for some reason the logic of the test is not working.

Replacing with <xsl:if test="$extension = ''"> works. Apparently there is a difference between null and empty strings in xsl, and substring-after (which gives this extension, eventually, from pretext-common.xsl) returns the empty string, not null.

Since the latex conversion presumably prefers pdf, and since other conversions may want empty extension in the source, this can cause problems in such situations where the source="Imagename" is used instead of source="Imagename.pdf".

[rbeezer]

Hah! I think (pdf)LaTeX must complete "extension-less" filenames by effectively adding ".pdf". This is tested routinely in the sample article, and has never failed that I'm aware of. (Search on "complete-graph".)

I guess two errors are counteracting each other. Fix coming up.

[rbeezer]

Nice catch! Since there was no manifestation of any real bug. But definitely needed fixing. I'd guess plain old LaTeX might not have been so happy? Anyway, fixed now at 3c21840d08491908cef9b3d6723fd50ed085e417.

Tests well with current sample article. Website update will need to wait a couple days.

[kcrisman]

Nice catch! Since there was no manifestation of any real bug. But definitely needed fixing.

Thanks. The way I found it was by using a not-technically-unauthorized combination of the image directories in the publisher file with images that had previously been ../images/imagename.pdf and that I had tried making ../images/imagename to prepare for any changes along those lines. So eventually it could have caught people, if for some reason there were dots in their image path for some reason before the extension (Image-attempt-2.3, perhaps?).

[rbeezer]

Aah, devious. Not sure how to prevent a spurious period like that. Except perhaps to have a whitelist of extensions to look for. Have to think on this one...

On July 20, 2021 6:19:34 PM PDT, kcrisman @.***> wrote:

Nice catch! Since there was no manifestation of any real bug. But definitely needed fixing.

Thanks. The way I found it was by using a not-technically-unauthorized combination of the image directories in the publisher file with images that had previously been ../images/imagename.pdf and that I had tried making ../images/imagename to prepare for any changes along those lines. So eventually it could have caught people, if for some reason there were dots in their image path for some reason before the extension (Image-attempt-2.3, perhaps?).