[
https://issues.apache.org/jira/browse/FOP-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17498955#comment-17498955
]
J Frank edited comment on FOP-3022 at 2/28/22, 8:26 PM:
--------------------------------------------------------
I re-produced the issues and found it is not able to load the raw image in
PreloaderRawPNG class, it reads src header which is not in the required format
and then ImageManager class throws the error, as you have provided in the
description.
also what I have observed is PreloaderRawPNG reads from cache instead of
provided URI; Have you checked whether cache format is correct or not and why
cache is being read, also while reading cache header is invalid.
Can you cross check PNG RAWdata?
was (Author: jagruti.fr...@gmail.com):
I re-produced the issues and found it is not able to load the raw image in
PreloaderRawPNG class, it reads src header which is not in the required format
and then ImageManager class throws the error, as you have provided in the
description.
also what I have observed is PreloaderRawPNG reads from cache instead of
provided URI; Have you checked whether cache format is correct or not and why
cache is being read?
> Embedded PNG and PNG with relative path: No ImagePreloader found
> ----------------------------------------------------------------
>
> Key: FOP-3022
> URL: https://issues.apache.org/jira/browse/FOP-3022
> Project: FOP
> Issue Type: Bug
> Components: image/png
> Affects Versions: 2.6
> Reporter: Johannes
> Priority: Major
> Attachments: content.xml, fo.xsl
>
>
> A PDF with an embedded PNG and another PNG with a relative URL does not
> contain either of these images (as it worked before in FOP version 2.3).
> This is the error reported in the debug trace:
> Image not available. URI:
> data:image/png;base64,0000C3E449BA11000000000000000000F33319879C248B7149B918E031DA9E37336F93FA7DE2500F377C435E31F7DCE86730D41D33A8.
> Reason: org.apache.xmlgraphics.image.loader.ImageException: The file format
> is not supported. No ImagePreloader found for
> data:image/png;base64,0000C3E449BA11000000000000000000F33319879C248B7149B918E031DA9E37336F93FA7DE2500F377C435E31F7DCE86730D41D33A8
> (No context info available)
> org.apache.xmlgraphics.image.loader.ImageException: The file format is not
> supported. No ImagePreloader found for
> data:image/png;base64,0000C3E449BA11000000000000000000F33319879C248B7149B918E031DA9E37336F93FA7DE2500F377C435E31F7DCE86730D41D33A8
> Result of debugging (using FOP 2.6 sources):
> * FOUserAgent.resolveURI creates a StreamSource from the PNG. The resource
> URI is correctly resolved (i.e. the StreamSource has an InputStream on the
> PNG) but the method sets an invalid systemId (the base URI of the resource
> resolver, which points to the config file, cfg.xml in our case)
> * AbstractImageSessionContext.newSource (from xmlgraphics-commons-2.6;
> instantiated in the FOUserAgent constructor) uses the fallbackResolver for
> any StreamSource.
> * AbstractImageSessionContext.UnrestrictedFallbackResolver.createSource
> quietly closes the InputStream of the StreamSource and requests the systemId
> from ImageIO instead (code comment: "We let the OS' file system cache do the
> caching for us --> lower Java memory consumption, probably no speed loss")
> Thus it opens a stream on the cfg.xml instead of the image
> * Consequentually, PreloaderRawPNG doesn't feel responsible for the wrong
> PNG because it doesn't start with the PNG signature
> (PNGConstants.PNG_SIGNATURE) - which is caused by reading a completely
> different file than the PNG
> Same behaviour also for another PNG included with a simple relative file URL
> (<fo:external-graphic src="url('subdir/myimage.png')" /> hardcoded in the
> XSL).
> The issue is reproducible as well when running the generation standalone from
> the command line (using -xml, -xsl and -pdf options).
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
