--> This is bug that we, XMLmind, have added to the DocBook XSL stylesheets. In order to fix it, please:
[1] Download: --- http://www.pixware.fr/_download/patch_xsl/addon/config/docbook/xsl/fo/graphics.xsl (22879bytes, Tue Jun 15 10:25:03 AM CEST 2010) --- and replace <XSLUtility_install_dir>/addon/config/docbook/xsl/fo/graphics.xsl by the downloaded file. [2] Download: --- http://www.pixware.fr/_download/patch_xsl/addon/config/docbook5/xsl/fo/graphics.xsl (22983bytes, Tue Jun 15 10:49:07 AM CEST 2010) --- and replace <XSLUtility_install_dir>/addon/config/docbook5/xsl/fo/graphics.xsl by the downloaded file. According to our tests, this should solve your problem. --> Here I assume that your are using XMLmind XSL Utility, because this bug is not related to latest xfc.jar. It is related to the distribution of latest XMLmind XSL Utility. If you are using XMLmind XML Editor, please proceed as described above but replace <XSLUtility_install_dir>/ by <XXE_install_dir>/. Jackie Ferretti wrote: > > I just upgraded xcf from 4.3.2 to 4.4.0, and now some of my images are > broken in the RTF output. I realize this is related to the content-type > being removed from the fo in 4.4.0. But my questions is then, what is > the solution? How do I get images in my RTF document? > > Here is the docbook: > > <inlinemediaobject> > <imageobject> > <imagedata fileref="/images?id=ef31cfe00698e22b93b03e4971de936a" > format="GIF"/> > </imageobject> > <textobject> > <phrase>pareto-yield</phrase> > </textobject> > </inlinemediaobject> > > Here is the generated FO: > > <fo:external-graphic > src="url(/images?id=ef31cfe00698e22b93b03e4971de936a)" width="auto" > height="auto" content-width="auto" content-height="auto"/> > > I have a uri-resolver that changes the URL to: > > http://<server-name>:<port>/images;jsessionid=04F8996A80F2E5F857AE0E8681FBA9B0?id=ef31cfe00698e22b93b03e4971de936a > > The fo2rtf conversion produces the following warning: > > java.lang.Exception: failed to load image > "http://<server>:<port>/images;jsessionid=04F8996A80F2E5F857AE0E8681FBA9B0?id=ef31cfe00698e22b93b03e4971de936a": > 'image//images?id=ef31cfe00698e22b93b03e4971de936a', unsupported graphic > format (file:/path_to_fo_doc, line #4, column #1844) > > The funny thing is that the webserver does get the GET request for the > image, and returns the image with the appropriate content-type set to > image/gif. When it sees: --- <fo:external-graphic src="url(/images?id=ef31cfe00698e22b93b03e4971de936a)" width="auto" height="auto" content-width="auto" content-height="auto"/> --- XFC, whether 4.3.2 or 4.4, has no way to guess that the image has an "image/gif" content type. XFC *never* used the Content-Type header returned by the HTTP server for that. I've re-checked that. In the above case, content-type="image/gif" is really needed. > > Setting the default graphic extension parameter does not help either, > even if I change the Image servlet to strip the file extension before > the image lookup. Again, the Image servlet returns the requested image, > but the image is broken inside of the RTF file with failed to load image > error. > > <xsl:param name="graphic.default.extension" select="'gif'"/> > > I also tried appending a dummy query string parameter to the fileref > ending in .gif...but, that did not work either. > > <imagedata > fileref="/images?id=ef31cfe00698e22b93b03e4971de936a&name=name.gif" > format="GIF"/> > > java.lang.Exception: failed to load image > "http://<serve>:<port>/images;jsessionid=04F8996A80F2E5F857AE0E8681FBA9B0?id=ef31cfe00698e22b93b03e4971de936a&name=name.gif": > Unexpected block type 72! (file:path_to_fo_doc, line #4, column #1862) > -- XMLmind FO Converter Support List [email protected] http://www.xmlmind.com/mailman/listinfo/xfc-support
