Closed
Bug 192724
Opened 23 years ago
Closed 20 years ago
Automatic image resizing should use the PNG pHYs chunk
Categories
(Core Graveyard :: GFX, defect)
Tracking
(Not tracked)
RESOLVED
EXPIRED
People
(Reporter: Dave.Sparks, Assigned: kmcclusk)
References
()
Details
User-Agent: Mozilla/4.73 [en] (X11; I; SunOS 5.7 sun4u)
Build Identifier: 2003021008
I have a number of high-resolution images which are intended for printing, not
for display on the screen (low-resolution alternatives are provided). If the
link is left-clicked (instead of being right-clicked to download the image)
Mozilla 1.3b scales the image to fit the canvas, which is better than not
scaling the image at all but not as good as scaling the image to the the
intended physical dimensions as specified in the pHYs chunk of the image.
If Mozilla used the pHYs chunk to scale the image to the device resolution
(screen or printer) it would be much easier for the user to print the image at
the intended scale (which in this particular case is important).
The full set of images can be accessed via
http://www.sisyphus.demon.co.uk/POTOC/txt/2003-02-16.final.html , using the
[90] and [600] links near the bottom of the page. Note that after 16th February
2003 this page, and the images, will have served their purpose and will
eventually be deleted.
Reproducible: Always
Steps to Reproduce:
(with automatic image resizing enabled)
1. fetch http://www.sisyphus.demon.co.uk/POTOC/png/2003-02-16.desc-600.1.png
2. print the resulting page
1b. fetch http://www.sisyphus.demon.co.uk/POTOC/png/2003-02-16.desc-600.12.png
2b. print the resulting page
3. compare the output from (2) with the output from (2b)
Actual Results:
The two images were displayed and printed at different scales
Expected Results:
The two images should have been displayed and printed at the scale specified in
the images (the boxes should be 6mm square, give or take a fraction of a mm).
i don't know about this. as it is now, you can:
1. show pixels 1:1
2. scale entire image to fit in window
i'm not sure exactly what the pHYs chunk is, but it sounds like you want a
"resize to dpi" option which would make automatic image sizing handle images
with a pHYs chunk differently than those without. shouldn't auto-sizing always
scale to the window? with this, there could be a situation where the image is
shown at dpi, yet is still bigger than the window.
as for printing, i don't know how it works now, but maybe when printing images,
there should be an option to use the image's dpi, if it doesn't do that already.
Reporter | ||
Comment 2•22 years ago
|
||
I'd hope that anyone writing or maintaining code to render an image would take
the trouble to read the defintion of the file format, particularly when it's
freely available.
When an image is embedded in a page, the HTML has the opportunity to use height=
and width= attributes to force the image to be scaled to a specific size (in
screen pixels). In general, it's better to use an image editor to prepare an
image at the desired size, but if a page is optimized for printing, rather than
screen display, printer-resolution images can be used to produce better results
on the printer. If the <link rel="alternate" media="print" ...> tag is used IE
will automatically select the alternate page when 'print page' is used.
When a free-standing image is displayed, there's no way to determine how to
scale the image unless the image itself contains some indication of the intended
size on the physical medium. Absent such indication, it's reasonable to assume
that one image pixel should be mapped to one screen pixel, or (for large images)
to assume that they should be mapped to fit into the visible window. Having
made that assumption, it's reasonable to hold to it when printing the image so
that one image pixel is mapped to printer dots using a factor which leaves the
physical size of the image unchanged.
However, PNG images (and JPEG images) allow the image creator to record the
intended physical size of the image, and when his intention is plain there's no
need to make an assumption.
In the case I cited, the images are intended for printing, and the printed image
has to comply with a formal specification which constrains the physical
dimensions within narrow limits. The "intended size" isn't just an aesthetic
judgement, it's a formal requirement; and the image users care, very much, that
the requirement be met. They also care about readability in poor conditions, so
an anti-aliased screen-resolution image is not good enough.
I could of course embed the images in PDF or Word documents, but when the image
itself can contain a specification of the intended physical scale this shouldn't
be necessary.
My recommendation to the users was that they should download the images they
needed (most users would only want one or two) and insert them into a Word or
OpenOffice document for printing. Both Word and OpenOffice understand and
honour the pHYs chunk. A user with a browser that understood the pHYs chunk
could simply display and print the image. In an ideal world, I'd have been able
to use (say) target="_printer" in the link and clicking the link would have sent
the image, correctly scaled, directly to the printer (after user confirmation).
At bottom, this is an accessibility issue. Not all web resources are intended
primarily for screen display, and when they aren't it shouldn't be difficult to
use them as they are intended to be used.
Comment 3•21 years ago
|
||
I agree with the reporter. I was about to post the same bug before I dug around
and found this one. If an image carries physical size information with it, we
should scale the image appropriately. Mozilla already knows (or is configured
with) the display DPI, so it should be a fairly straightforward process to get
it scaled correctly.
For more information about PNG's "pHYs" chunk, see http://www.w3.org/TR/PNG/#11pHYs.
I disagree that image pixels, absent this information, should be mapped 1:1 to a
*printer*'s dot. It may be best to assume that rasterized graphics lacking any
sort of DPI hints should be assumed to be at something like 72 or 90dpi. Maybe
adopt W3C's convention for the CSS 'px' unit
(http://www.w3.org/TR/CSS2/syndata.html#length-units) and map each image pixel
to rectangle 1px by 1px.
Comment 4•21 years ago
|
||
Also, an image's physical DPI settings should not take precedence over HTML
'width' and 'height' attributes or CSS sizing properties. It's strictly a
fallback, as an alternative to current behavior of 1:1 image pixel to display
pixel (or scaled dot for printers).
Also see bug 102755
Comment 5•20 years ago
|
||
This is an automated message, with ID "auto-resolve01".
This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.
While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.
If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.
The latest beta releases can be obtained from:
Firefox: http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey: http://www.mozilla.org/projects/seamonkey/
Comment 6•20 years ago
|
||
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → EXPIRED
Updated•17 years ago
|
Product: Core → Core Graveyard
Comment 7•15 years ago
|
||
This bug is still valid.
You need to log in
before you can comment on or make changes to this bug.
Description
•