| Summary: | PNG's - warn if resolution can't be determined | ||
|---|---|---|---|
| Product: | XMLGraphicsCommons - Now in Jira | Reporter: | Jason Harrop <jason> |
| Component: | image codecs | Assignee: | XML Graphics Project Mailing List <general> |
| Status: | NEEDINFO --- | ||
| Severity: | enhancement | CC: | jason |
| Priority: | P3 | ||
| Version: | Trunk | ||
| Target Milestone: | -- | ||
| Hardware: | All | ||
| OS: | All | ||
I haven't taken this bug yet as I am still unsure about the proper solution. Currently: getDefaultResulution is called, result stored. Resultion of image is determined if possible, and overwrites default resolution. The problem: this happens in multiple different places (PNG is just one). A proper solution would handle all of them. We could add the warning to each case, but that would not make much sense. Instead, a common function should warn, which means: in each case: resolution = null; determine resolution from image; fallbackIfneeded(resolution) and fallbackifneeded would do: if resolution == null emit warning resolution = defaultResolution. The problem here: Other calculations, such as the image size, depend on the resultion being set beforehand. Each of the cases would need to be examined if the resultion could be safely set AFTER the other image info is parsed. Second issue: Not all image formats support resultion. minor issue: Some images support different x,y resolutions, this should also be taken into account. Max Sorry for being late here (being the original author of the thing). The issue here shows that someone was able to make use of the image loading framework outside the FOP context which makes me happy. Mission accomplished. ;-) As for the missing resolution information:
If using Toolkit.getDefaultToolkit().getScreenResolution() for the fallback resolution is a problem, you can always use your own implementation of the ImageContext interfaces. I'm also doing that in FOP where the default source resolution if configured in an XML file.
If it is important to be notified if an image resolution is missing, I think the most straight-forward solution is to introduce a listener interface which can be made available through the ImageContext. Something like the following maybe:
public interface ImageLoaderListener {
void notifyMissingImageResolution(Object source, String uri, String mime);
}
I can imagine that, in time, we may add additional features either to the listener or the Image(Session)Context.
Max noted different resolutions for X and Y. Some formats support that. Personally, I've never seen an image with different X and Y resolutions, yet. So if there's no need I wouldn't complicate things prematurely. That can always be easily added in a backwards-compatible way if it's really needed. At any rate, ImageInfo supports separate resolutions, just in case. But I don't believe it's needed for the fallback.
WDYT?
|
If, for a PNG image, ImageMagick's identify says: Resolution: 320x320 Units: Undefined <---------------- then ImageInfo will use a default value, using Toolkit.getDefaultToolkit().getScreenResolution(), which in my case is 160. Nothing wrong with that I suppose, but it would be helpful if a warning was logged or something, so you knew to fix the image. When PreloaderImageIO.preloadImage does: ImageIOUtil.extractResolution(iiometa, size); it is finding the Dimension child, but not "HorizontalPixelSize" or VerticalPixelSize (these are null).