docbook-apps

Hi,
That customization looks fine to me. What XSL-FO processor are you using?

Bob Stayton
Sagehill Enterprises
bobs@sagehill.net


----- Original Message -----
From: "Dominik Psenner" <dpsenner@gmail.com>
To: <docbook-apps@lists.oasis-open.org>
Sent: Monday, April 02, 2012 12:30 AM
Subject: [docbook-apps] mediaobject with base64 encoded image data


> Good morning,
>
> We plan to XSL transform a dynamically generated docbook including images to
> FO and subsequently process that to PDF. Therefore I'm digging only in the
> docbook to FO stylesheets. While investigating that we had the idea to
> base64 encode images and include them in the docbook because it enables us
> to bypass image caching while generating PDF on the fly. To include a base64
> image I had the idea to write it as:
>
> -- quote --
> <docbook:figure>
> <docbook:title>Sample</docbook:title>
> <docbook:mediaobject>
> <docbook:imageobject>
> <fo:external-graphic src="data:image/jpeg;base64,XYZ"
> width="auto" height="auto" content-width="auto" content-height="auto"
> content-type="content-type:image/jpeg" />
> </docbook:imageobject>
> </docbook:mediaobject>
> </docbook:figure>
> -- /quote --
>
> But unfortunately the stylesheet (1.75.2 release) would wrap that within a
> <fo:instream-foreign-object /> and that causes the FO processor to fail
> including the base64 encoded image.
>
> Therefore I changed the docbook xsl stylesheet (based on the 1.75.2 release)
> in the file fo/graphics.xsl slightly:
>
> -- diffquote --
> <xsl:template match="imageobject">
> <xsl:choose>
> <xsl:when test="imagedata">
> <xsl:apply-templates select="imagedata"/>
> </xsl:when>
> + <xsl:when test="fo:external-graphic">
> + <xsl:apply-templates mode="copy-all" />
> + </xsl:when>
> <xsl:otherwise>
> <fo:instream-foreign-object>
> <xsl:apply-templates mode="copy-all"/>
> </fo:instream-foreign-object>
> </xsl:otherwise>
> </xsl:choose>
> </xsl:template>
> -- /diffquote --
>
> This patch drops the <fo:instream-foreign-object /> tag when encountering
> <fo:external-graphic />.
>
> Does this patch break other things? Would you guys do it somehow different?
>
> Cheers,
> Dominik
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org
>
>
>

Hi Bob,

thanks for the feedback. I looked into 4 alternatives:

1) IBEX
At the moment our choice because it's relatively cheap, fast and even
though it produces quite large PDF files (double size in respect to
the Antenna House implementation) it is not a KO criteria for IBEX.
2) Antenna House
This is the most expensive option. We won't spend that much unless we
run into serious trouble with IBEX (bugs, etc..).
3) FO.NET
Did not pass all tests and is poorly supported - well - it is free. :-)
4) FOP
This would be my favourite, but unfortunately we cannot depend
on a java application.

Going back to the customization, you wouldn't do the previously mentioned
customization differently, would you?

I'm asking because I also thought about integrating base64-encoded imagedata
better into docbook by:

1) either creating a fresh new attribute like "src" on the <imagedata /> tag
that could be passed on to the respective FO attribute "src" in the tag
<fo:external-graphic />.

2) or parsing the "fileref" attribute and don't wrap it in "url()" if it
starts with "imagedata".

Both 1) and 2) feel much more like the "right" solution that could also
become a patch that could be applied on the next release of the docbook
stylesheets. What do you think about that?

Cheers,
Dominik

>-----Original Message-----
>From: Bob Stayton [mailto:bobs@sagehill.net]
>Sent: Monday, April 02, 2012 6:39 PM
>To: Dominik Psenner; docbook-apps@lists.oasis-open.org
>Subject: Re: [docbook-apps] mediaobject with base64 encoded image data
>
>Hi,
>That customization looks fine to me. What XSL-FO processor are you using?
>
>Bob Stayton
>Sagehill Enterprises
>bobs@sagehill.net
>
>
>----- Original Message -----
>From: "Dominik Psenner" <dpsenner@gmail.com>
>To: <docbook-apps@lists.oasis-open.org>
>Sent: Monday, April 02, 2012 12:30 AM
>Subject: [docbook-apps] mediaobject with base64 encoded image data
>
>
>> Good morning,
>>
>> We plan to XSL transform a dynamically generated docbook including images
>to
>> FO and subsequently process that to PDF. Therefore I'm digging only in
>the
>> docbook to FO stylesheets. While investigating that we had the idea to
>> base64 encode images and include them in the docbook because it enables
>us
>> to bypass image caching while generating PDF on the fly. To include a
>base64
>> image I had the idea to write it as:
>>
>> -- quote --
>> <docbook:figure>
>> <docbook:title>Sample</docbook:title>
>> <docbook:mediaobject>
>> <docbook:imageobject>
>> <fo:external-graphic src="data:image/jpeg;base64,XYZ"
>> width="auto" height="auto" content-width="auto" content-height="auto"
>> content-type="content-type:image/jpeg" />
>> </docbook:imageobject>
>> </docbook:mediaobject>
>> </docbook:figure>
>> -- /quote --
>>
>> But unfortunately the stylesheet (1.75.2 release) would wrap that within
>a
>> <fo:instream-foreign-object /> and that causes the FO processor to fail
>> including the base64 encoded image.
>>
>> Therefore I changed the docbook xsl stylesheet (based on the 1.75.2
>release)
>> in the file fo/graphics.xsl slightly:
>>
>> -- diffquote --
>> <xsl:template match="imageobject">
>> <xsl:choose>
>> <xsl:when test="imagedata">
>> <xsl:apply-templates select="imagedata"/>
>> </xsl:when>
>> + <xsl:when test="fo:external-graphic">
>> + <xsl:apply-templates mode="copy-all" />
>> + </xsl:when>
>> <xsl:otherwise>
>> <fo:instream-foreign-object>
>> <xsl:apply-templates mode="copy-all"/>
>> </fo:instream-foreign-object>
>> </xsl:otherwise>
>> </xsl:choose>
>> </xsl:template>
>> -- /diffquote --
>>
>> This patch drops the <fo:instream-foreign-object /> tag when encountering
>> <fo:external-graphic />.
>>
>> Does this patch break other things? Would you guys do it somehow
>different?
>>
>> Cheers,
>> Dominik
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
>> For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org
>>
>>
>>

On 3.4.2012 8:38, Dominik Psenner wrote:

> I'm asking because I also thought about integrating base64-encoded imagedata
> better into docbook by:
>
> 1) either creating a fresh new attribute like "src" on the <imagedata /> tag
> that could be passed on to the respective FO attribute "src" in the tag
> <fo:external-graphic />.
>
> 2) or parsing the "fileref" attribute and don't wrap it in "url()" if it
> starts with "imagedata".

There is no need to change anything on DocBook side to support this.
Simply put data: into fileref attribute. There migh be needed some small
changes in XSL stylesheets in order to skip usual file path massaging.
Also I think that even data: should be wrapped in url() otherwise it
would be non-conforming to XSL-FO spec.

Jirka

--
------------------------------------------------------------------
Jirka Kosek e-mail: jirka@kosek.cz http://xmlguru.cz
------------------------------------------------------------------
Professional XML consulting and training services
DocBook customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member
------------------------------------------------------------------

>-----Original Message-----
>From: Jirka Kosek [mailto:jirka@kosek.cz]
>Sent: Tuesday, April 03, 2012 9:43 AM
>To: Dominik Psenner
>Cc: 'Bob Stayton'; docbook-apps@lists.oasis-open.org
>Subject: Re: [docbook-apps] mediaobject with base64 encoded image data
>
>On 3.4.2012 8:38, Dominik Psenner wrote:
>
>> I'm asking because I also thought about integrating base64-encoded
>imagedata
>> better into docbook by:
>>
>> 1) either creating a fresh new attribute like "src" on the <imagedata />
>tag
>> that could be passed on to the respective FO attribute "src" in the tag
>> <fo:external-graphic />.
>>
>> 2) or parsing the "fileref" attribute and don't wrap it in "url()" if it
>> starts with "imagedata".
>
>There is no need to change anything on DocBook side to support this.
>Simply put data: into fileref attribute.

That doesn't work together with the IBEX processor because "data:.." is
wrapped into "url(data:..)" and then the processor treats "data:.." as an
url, which it is not and thus the image is not rendered as the data of the
image can't be retrieved from the path "data:.." unless it exists by
coincidence.

>There migh be needed some small
>changes in XSL stylesheets in order to skip usual file path massaging.

That would be the template named "fo-external-image" in graphics.xsl, isn't
it?

>Also I think that even data: should be wrapped in url() otherwise it
>would be non-conforming to XSL-FO spec.

At least the implemented IBEX interpretation of the XSL-FO spec doesn't
behave like that.

Cheers,
Dominik

On 3.4.2012 13:35, Dominik Psenner wrote:

>> There is no need to change anything on DocBook side to support this.
>> Simply put data: into fileref attribute.
>
> That doesn't work together with the IBEX processor because "data:.." is
> wrapped into "url(data:..)" and then the processor treats "data:.." as an
> url, which it is not and thus the image is not rendered as the data of the
> image can't be retrieved from the path "data:.." unless it exists by
> coincidence.

But data: is URL, see http://www.ietf.org/rfc/rfc2397

If IBEX can handle this, then it is clearly IBEX bug.

>> There migh be needed some small
>> changes in XSL stylesheets in order to skip usual file path massaging.
>
> That would be the template named "fo-external-image" in graphics.xsl, isn't
> it?

No, it's

<xsl:template name="image.src">
<xsl:param name="filename"/>

<xsl:choose>
<xsl:when test="svg:*" xmlns:svg="http://www.w3.org/2000/svg">

</xsl:when>
<xsl:when test="mml:*" xmlns:mml="http://www.w3.org/1998/Math/MathML">

</xsl:when>
<xsl:otherwise>
<xsl:call-template name="fo-external-image">
<xsl:with-param name="filename">
<xsl:if test="$img.src.path != '' and
not(starts-with($filename, '/')) and
not(contains($filename, '://'))">
<xsl:value-of select="$img.src.path"/>
</xsl:if>
<xsl:value-of select="$filename"/>
</xsl:with-param>
</xsl:call-template>
</xsl:otherwise>
</xsl:choose>
</xsl:template>

Test should be added not to prepend img.src.path when $filename starts
with data:

Also there are other places where extension functions to measure image
are invoked. They probably need some modification as well.

>> Also I think that even data: should be wrapped in url() otherwise it
>> would be non-conforming to XSL-FO spec.
>
> At least the implemented IBEX interpretation of the XSL-FO spec doesn't
> behave like that.

It's not only IBEX, you can modify existing template and compensate for
IBEX as well:

<xsl:template name="fo-external-image">
<xsl:param name="filename"/>

<xsl:choose>
<xsl:when test="$passivetex.extensions != 0
or $fop.extensions != 0">
<xsl:value-of select="$filename"/>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="concat('url(', $filename, ')')"/>
</xsl:otherwise>
</xsl:choose>
</xsl:template>

Just add $ibex.extension and omit url() if it is set to 1.

Jirka

--
------------------------------------------------------------------
Jirka Kosek e-mail: jirka@kosek.cz http://xmlguru.cz
------------------------------------------------------------------
Professional XML consulting and training services
DocBook customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member
------------------------------------------------------------------

>>> There is no need to change anything on DocBook side to support this.
>>> Simply put data: into fileref attribute.
>>
>> That doesn't work together with the IBEX processor because "data:.." is
>> wrapped into "url(data:..)" and then the processor treats "data:.." as an
>> url, which it is not and thus the image is not rendered as the data of
>the
>> image can't be retrieved from the path "data:.." unless it exists by
>> coincidence.
>
>But data: is URL, see http://www.ietf.org/rfc/rfc2397

I see. I'm going to ask them a few stupid questions. :-)

>If IBEX can handle this, then it is clearly IBEX bug.
>
>>> There migh be needed some small
>>> changes in XSL stylesheets in order to skip usual file path massaging.
>>
>> That would be the template named "fo-external-image" in graphics.xsl,
>isn't
>> it?
>
>No, it's
>
><xsl:template name="image.src">
> <xsl:param name="filename"/>
>
> <xsl:choose>
> <xsl:when test="svg:*" xmlns:svg="http://www.w3.org/2000/svg">
>
> </xsl:when>
> <xsl:when test="mml:*" xmlns:mml="http://www.w3.org/1998/Math/MathML">
>
> </xsl:when>
> <xsl:otherwise>
> <xsl:call-template name="fo-external-image">
> <xsl:with-param name="filename">
> <xsl:if test="$img.src.path != '' and
> not(starts-with($filename, '/')) and
> not(contains($filename, '://'))">
> <xsl:value-of select="$img.src.path"/>
> </xsl:if>
> <xsl:value-of select="$filename"/>
> </xsl:with-param>
> </xsl:call-template>
> </xsl:otherwise>
> </xsl:choose>
></xsl:template>
>
>Test should be added not to prepend img.src.path when $filename starts
>with data:
>
>Also there are other places where extension functions to measure image
>are invoked. They probably need some modification as well.
>
>>> Also I think that even data: should be wrapped in url() otherwise it
>>> would be non-conforming to XSL-FO spec.
>>
>> At least the implemented IBEX interpretation of the XSL-FO spec doesn't
>> behave like that.
>
>It's not only IBEX, you can modify existing template and compensate for
>IBEX as well:
>
><xsl:template name="fo-external-image">
> <xsl:param name="filename"/>
>
> <xsl:choose>
> <xsl:when test="$passivetex.extensions != 0
> or $fop.extensions != 0">
> <xsl:value-of select="$filename"/>
> </xsl:when>
> <xsl:otherwise>
> <xsl:value-of select="concat('url(', $filename, ')')"/>
> </xsl:otherwise>
> </xsl:choose>
></xsl:template>
>
>Just add $ibex.extension and omit url() if it is set to 1.

Thanks a lot for the clarifications. Now I understand why there's this test.
For now I won't dive into further modifications to compensate the errors of
others. :-) But I will keep this in mind as another possible solution.

Cheers,
Dominik