RE: [docbook-apps] mediaobject with base64 encoded image data
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:b...@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 b...@sagehill.net - Original Message - From: Dominik Psenner dpsen...@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:titleSample/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-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
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. 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: ji...@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 -- signature.asc Description: OpenPGP digital signature
RE: [docbook-apps] mediaobject with base64 encoded image data
-Original Message- From: Jirka Kosek [mailto:ji...@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 - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] mediaobject with base64 encoded image data
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;
!-- no src attribute for inline SVG content --
/xsl:when
xsl:when test=mml:* xmlns:mml=http://www.w3.org/1998/Math/MathML;
!-- no src attribute for inline MathML content --
/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: ji...@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
--
signature.asc
Description: OpenPGP digital signature
RE: [docbook-apps] mediaobject with base64 encoded image data
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;
!-- no src attribute for inline SVG content --
/xsl:when
xsl:when test=mml:* xmlns:mml=http://www.w3.org/1998/Math/MathML;
!-- no src attribute for inline MathML content --
/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
-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
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 b...@sagehill.net - Original Message - From: Dominik Psenner dpsen...@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:titleSample/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-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
