PDF XChange Forum

The Color Management -> Grayscale setting only offers two options on my system: Black & White and Gray Gamma 2.2.

Black & White is not B/W at all, but a visibly lighter gray compared to Gray Gamma 2.2. Gray Gamma 2.2 is slighter darker than Adobe Reader DC's rendering. This is not a problem, but I wondered if there are other gamma options planed?

It is not a gamma options, but a list of available Gray color profiles on your machine.
The Editor itself provides only "Gray Gamma 2.2" profile. The "Black & White" comes from your "c:\Windows\System32\spool\drivers\color" folder.

So is it to be expected that the provided profile renders slightly different (darker) gray tones than Adobe Reader?

If the difference is 1-2 points (of 255), I can say it is expected.
In other cases, would be helpful if you can provide the document where you experience the issue and your Editor's settings.

Turns out that this is not a sole issue of Editor, but also of the X-Change Standard printer driver embedding a wrong/unnecessary color profile. The latter of which then is misinterpreted by Editor regardless of Color Management settings or active monitor profile at the time of printing or viewing (Dell U3014 wide gamut vs. sRGB).

I did some tests using an image of 256 gray steps.

- Printed via Primo (Ghostscript) all 256 gray steps are properly displayed in both Editor and Reader.
- Printed via X-Change Standard using the "Gray Gamma 2.2" profile in Editor the darkest gradations are swallowed towards black. For example, 15/15/15 comes out as 6/6/6.
- Viewing the XS file via Reader results in proper gradations.

Furthermore I stumbled over the following issues while doing these tests:

- Editor uses image smoothing (anti-aliasing) while exporting to image(s), even when the "Image Smoothing" option is turned off in Page Display -> Rendering. There doesn't seem to be an option to turn that off.
- X-Change Standard on "Auto" compression uses JPG compression for the solid area filled image, leading to both to artifacts and larger size. It should choose FLATE instead.
- X-Change Standard produces very visible JPG artifacts even at 100% compression setting, even though this particular image should not show any such artifacts at 97-100% regardless of sub-sampling options (tested via Faststone Image viewer).

Hi Timur,

As per my post in your other topic:

Unfortunately the developers that need to look into this are on holiday for the next two weeks. I'll do my best to get some movement on this topic as soon as they're back.

Sincere apologies for the delay!

Sorry

Timur Born wrote:- Editor uses image smoothing (anti-aliasing) while exporting to image(s), even when the "Image Smoothing" option is turned off in Page Display -> Rendering. There doesn't seem to be an option to turn that off.

This also happens when the "Edit Image using" function is used.

Any feedback on this yet?

Turns out that this is not a sole issue of Editor, but also of the X-Change Standard printer driver embedding a wrong/unnecessary color profile. The latter of which then is misinterpreted by Editor regardless of Color Management settings or active monitor profile at the time of printing or viewing (Dell U3014 wide gamut vs. sRGB).

Which color profile was associated with PDF-XChange Standard printer? The Editor uses printer's profile on printing instead of profiles specified in its settings if the printer has own profile.

I did some tests using an image of 256 gray steps.

- Printed via Primo (Ghostscript) all 256 gray steps are properly displayed in both Editor and Reader.
- Printed via X-Change Standard using the "Gray Gamma 2.2" profile in Editor the darkest gradations are swallowed towards black. For example, 15/15/15 comes out as 6/6/6.
- Viewing the XS file via Reader results in proper gradations.

Can you provide us with your sample? Just to be sure we are using the same test data.

Furthermore I stumbled over the following issues while doing these tests:

- Editor uses image smoothing (anti-aliasing) while exporting to image(s), even when the "Image Smoothing" option is turned off in Page Display -> Rendering. There doesn't seem to be an option to turn that off.

We know about this issue and it will be fixed soon.

- X-Change Standard on "Auto" compression uses JPG compression for the solid area filled image, leading to both to artifacts and larger size. It should choose FLATE instead.

It was done because detection of the best compression is quite a time consuming, and at the moment "Auto" selects JPEG, but it may be changed in the future.

- X-Change Standard produces very visible JPG artifacts even at 100% compression setting, even though this particular image should not show any such artifacts at 97-100% regardless of sub-sampling options (tested via Faststone Image viewer).

We will try to improve our JPEG codec.

Ivan - Tracker Software wrote:Which color profile was associated with PDF-XChange Standard printer? The Editor uses printer's profile on printing instead of profiles specified in its settings if the printer has own profile.

I did not change X-Change's profile after installation, which means no profile is set, aka sRGB. I printed the files using Adobe Reader and the file produced by XS shows proper gradations when viewed by Adobe Reader. Whatever profile XS embeds during printing, it is interpreted differently by Editor than what Ghostscript produces and than what Reader interprets.

Reader -> XS -> Editor = Wrong color
Reader -> XS -> Reader = Correct color
Reader -> GS -> Editor = Correct color
Reader -> GS -> Reader = Correct color

Can you provide us with your sample? Just to be sure we are using the same test data.

Sure, the PNG is appended.

We will try to improve our JPEG codec.

Overall your compression seems too strong in relation to the percentage being set by the user. I assume that you also use YCbCr + sub-sampling, but the problem is with the compression level (block artifacts) compared to what other JPG codecs (Faststone image viewer) produce at the same percentage setting.

Hi Timur,

Ivan has asked me to make a ticket for this issue - so here it is:
#4026: Editor 322.7 Issues with Greyscale when printing to the driver.
We will let you know as soon as there are any further news on this!

Regards,
Stefan

The name of the ticket sounds quite misleading, but let's see what comes out of it. Thank you.

Has this been worked on?

Not yet Timur,
We've been much more focused on getting XFA forms working correctly, and as such have not put much focus into Color management in recent builds.
Have a good day!

Thanks for the information. I will have to keep using Adobe Reader for printing to RGB printers then.

Alright, Sorry to keep you waiting, hopefully it will be touched on sooner than later.

I understand, but it's still a bit strange that I have to use Ghostscript based freeware to print to PDF in correct colors (and Type 1 fonts), even though I paid for a third party PDF printer driver.

Hi timur,
I've copied my reply from another thread here as it is relevant to this color/greyscale issue as well.

The dev team just spoke with me on these matters, it seems we are aiming for a color fix sometime about 2 or 3 big build releases from now, so hopefully build 326 or 327. Sadly they also confirmed the fixes will not be in the 325 build coming at the beginning of april.
Sor earliest we can hope for is about june this year, possibly the build after that though.
I am sorry for the lengthy wait, but at least now we know it is coming!