[NTG-pdftex] Re: PNG features

Taco Hoekwater taco at elvenkind.com
Sun Jul 10 10:54:29 CEST 2005

Hi Pawel,

The main problem was not in your input: during the merge of pngextra.ch,
the last change entry was not carried over to the main change file.

To be precise, this bit is missing:

@p procedure check_and_set_pdfoptionpdfminorversion;
@p procedure check_and_set_pdfoptionpdfminorversion;
  fixed_gamma             := fix_int(pdf_gamma, 0, 1000000);
  fixed_image_gamma       := fix_int(pdf_image_gamma, 0, 1000000);
  fixed_image_hicolor     := fix_int(pdf_option_pdf_image_hicolor, 0, 1);
  fixed_image_apply_gamma := fix_int(pdf_option_image_apply_gamma, 0, 1);

Because of that, you always ended up with the compile-time defaults.
Martin, can you look into this please?

The minor problem is that the primitives behave like \pdfminorversion:
they are document-global and should be set before any typesetting is
done (the reason for that is that querying the image info and actually
reading the image data are disjunct processes in pdftex). This should
have been make clear in my documentation, I'm sorry.

Greetings, Taco

Pawel Jackowski wrote:
> Hi Taco,
> i've a problem with advanced PNG handling in pdfTeX-1.30-rc2. The 
> attachement contains a sample with 16-bit PNG. As expected, 
> /BitsPerComponent is 16 or 8, if the version of PDF is 1.5 or less than 
> 1.5. Thats OK. But \pdfimagehicolor seems to be ignored. Regardless the 
> value of \pdfimagehicolor, if \pdfminorversion is greater than 4, images 
> are always loaded in 16-bit mode. Is it normal behaviour? If so, what is 
> the usage \pdfimagehicolor?
> The second problem is that I can't see any effects of applying gamma 
> correction (also in the attachement). I always get (PNG copy) in log 
> file, regardless \pdfimageapplygamma valuse.
> Any clue what I'm doing wrong?
> Greetings,

More information about the ntg-pdftex mailing list