Hi all, As I said last week, i've been working on PNG inclusion, and I have reached the point where I have a 'proof of concept' that needs checking before I continue. Would somebody with an AR >= 6.0 please see if this file loads OK? http://tex.aanhet.net/context/png-test.pdf This is a compile of the suite of PNG test images, as seen on http://www.libpng.org/pub/png/pngsuite.html The one-pixel images do not work, but I expect that is a bug in the Reader (they look fine in the PDF source). I cannot test the pdf file myself, because AR on Linux does not accept 16-bit images yet, and I do not own any of the platforms that *are* supported by AR 6/7 (sigh). I really need to know if the file is ok, so I can change my C code from 'quick&dirty' to 'production' style. :-) And while at it, I have some technical questions as well: - The current code assumes that transparancy should always be used whenever it is a) present and b) the pdf version allows it (PDF-1.4). Is this reasonable? - There is a similar question for 16-bit color samples (PDF-1.5) - My current code uses 1.0 for the 'screen gamma' and 0.45455 (==1/2.2) for the 'assumed file gamma'. Do these 'gamma values' need parameterisation? - My code ignores bKGD (the default background color), because otherwise transparancy inclusion would be pointless. That is, unless someone would want to load a transparant PNG with the background applied but without transparancy? - I currently ignore all color management stuff in the PNG (cHRM, sRGB, iCCP chunks). I do not know enough about it at the moment, and I wonder if anybody is immediately interested anyway? Besides, color management would require other changes to pdftex as well, I assume? - (this is an unrelated question) I consider adding downsampling support for PNG images, but it would need a new primitive. Something like \pdfoptionimageresolution ? Greetings, Taco
Taco Hoekwater wrote:
- The current code assumes that transparancy should always be used whenever it is a) present and b) the pdf version allows it (PDF-1.4). Is this reasonable?
indeed
- There is a similar question for 16-bit color samples (PDF-1.5)
hm, more dangerous, although we may expect users to update their viewer
- My current code uses 1.0 for the 'screen gamma' and 0.45455 (==1/2.2) for the 'assumed file gamma'. Do these 'gamma values' need parameterisation?
if possible, yes
- My code ignores bKGD (the default background color), because otherwise transparancy inclusion would be pointless. That is, unless someone would want to load a transparant PNG with the background applied but without transparancy?
just ignore the bg color
- I currently ignore all color management stuff in the PNG (cHRM, sRGB, iCCP chunks). I do not know enough about it at the moment, and I wonder if anybody is immediately interested anyway? Besides, color management would require other changes to pdftex as well, I assume?
a next version of pdftex will provide overloading of the color dict so there is no need to handle it; it would probably badly interfere anyway
- (this is an unrelated question) I consider adding downsampling support for PNG images, but it would need a new primitive. Something like \pdfoptionimageresolution ?
plus \pdfoptionimageforcebw -) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
participants (2)
-
Hans Hagen
-
Taco Hoekwater