Coloring and printing issues

[stegeler]

Hi everyone!

We have some issues with coloring when we are printing pdf files.
When it comes to printing, some of our computers add a slight blue tinge to our plans. This only appears on a few pdf-files. Mostly everything works fine.
Also, if we are printing a 'proper' pdf-file again with pdf-xchange standard, the metioned computers will add a blue tinge to the new pdf-file, too.

You can already see wether a pdf-file is working or not in the printing-preview-window:

Re-installing the Tracker-Products and cleaning the registry didn't work. We then double-checked all settings, they are excatly the same. Also the printer/plotter is the same.
But we have different computer-systems. The issue appears on a laptop and also on desktop computer. Both are still running under windows 7.
Upgrading to Windows 10 is not an option for us right now.

I attached some files:
- comparison.jpg - comparison of two printing-preview-windows from two different computers
- site plan normal.pdf
- site plan blue tinge.pdf

Excuse me for my bad english, i hope you still understand our problem
Regards,
Sven

[Dimitar - Tracker Supp]

Hello Sven,

Welcome to our forum.

Could you please try to change the Driver Mode to XPS, and see if it has some influence on your problem.
This could be done under the PDF-XChange Standard -> Printing Preferences:

Best regards.

[RMan]

I believe this is when they are printing to hardcopy printers from the Editor, not printing to the PDF driver that the problem happens. We have a customer complaining about the same thing with grayscale drawings.

[TrackerSupp-Daniel]

I don't believe they are from physical printing, The document was created with the Standard printer, not the Core API, which is what is reported when a document is created from a scan.

Stegeler, Could you let us know if stefan's suggestion worked?

[stegeler]

Hey Guys!

Seems like we´re getting closer to the problem.

I´ll answer your questions step by step:

@Dimitar:
We changed the Driver Mode to XPS, which worked for PDF-Xchange Standard. We´re now able to 'print' pdf-files with PDF-Xchange Standard without a blue tinge but with kind of different colors. They appear to be more stronger, especially yellow colors. I guess this soltution isn't final, but at least we´re able to print proper pdf-files again.
With this solution we´re still not able to plot the already mentioned pdf-files with our plotter (hardcopy) - there´s still a blue tinge.

@RMan:
it´s happening both ways. Printing via PDF-Xchange Standard or via hardcopy. We now also have these problems with greyscale drawings or even simple .pdf-textfiles.

@TrackerSupp-Daniel:
as mentioned above stefan's suggestion only worked for printing via PDF-Xchange Standard.

We also did some research by ourselves:

1. All computers with the blue tinge issue are connected to the same type of monitor 'Samsung 2494HM'. Maybe there´s something wrong with the monitor-drivers?
2. We compared the color management options. Changing one of the options in Working Spaces had no affect. But when we are changing the Conversion Options Engine from 'Little CMS' to 'Microsoft ICM' one of the computers is able to print normal. I attached some files from this computer:
'yellow.png' shows the printer-dialog-box with 'Microsoft ICM' settings, 'blue.png' the one with 'Little CMS' settings.

[Timur Born]

This is connected to X-Change's problematic color management. Both physical prints and prints to X-Change PDF drivers suffer from this. The problem is connected to the displays connected to the problematic PCs, or rather their corresponding color profiles (likely non sRGB). Switching to Microsoft ICM can appear to solve the problem, but it's no full solution. Your best bet may be to remove the display color profile from Windows' own color profile settings and thus claim it to be a plain sRGB display.

Here is what I wrote in another thread concerning X-Change Standard:

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 (GS) 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

And here is what I posted concerning Editor's color management issues, which seem to be connected to what the XS printer driver does. This also includes a comparison of LCMS vs. MICM.

Switching from Auto (CMYK) to RGB does not exactly solve the problem. While the "haze" vanishes the image becomes too saturated, the same as Viewer using sRGB working space. (Viewer saturates even more when the DELL U3014 working space is used.)

This image also demonstrates that Microsoft ICM is only a partial solution, because its colors are less (micro)contrasty and slightly off compared to Adobe's output. Still better than the hazy LCMS version, though.

In short: If I need correct color profiling in PDF files then I do not use the X-Change printer driver, but one of the many Ghostscript based ones (Adobe works, too, but it's expensive).

[RMan]

I believe the problem is that the Editor is using the display device context to generate the output rather than the printer device context.

You also have to watch things because Printer Drivers can also have a color profile associated with them which might change the color that is actually sent to them to what they output. In Adobe PDF Printer Driver if you do the Printing Preferences->Adobe PDF Settings and then use the Edit Button next to the Default Settings it will open another dialog. Click on the Color and probably change the "Convert All Colors to sRGB" to "Leave Color Unchanged". Then save and name the settings and make sure you are using those when printing from the PDF-XChange Editor.

In this post I outlined the steps I was testing which showed that by changing the color profile in the Editor that the output changes also which it shouldn't. But it also changes to the Adobe PDF driver. But if you export to bmp then the color profile settings don't appear to make a difference. The same if you do the Print As Image option.

viewtopic.php?f=62&t=25721&p=122593#p122593

[TrackerSupp-Daniel]

Hi Rman, Timur, Stegeler,
The dev team just spoke with me on these matters, it seems we are aiming for a driver 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.
So the 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!

[Timur Born]

Great news. I can live with my workarounds until then. Thanks for getting back to us.

[TrackerSupp-Daniel]

No prob, I do like to try and avoid bothering the Devs whenever I can, they work in mysterious ways and I don't want to interrupt it!

[RMan]

Daniel,

This isn't a driver problem, it's a problem in the Editor's Printing Code itself from what I'm seeing. Especially when you can click on the Print As Image and see the colors change in the preview it's a big problem.

If they can't fix it the short term fix would be to in the print routines set it to the correct color profile, plot, then reset the profile back to the original setting.

You might get some screen flicker and such but it's a whole hell of a lot better than the alternative of giving people hardcopy plots that are the wrong color. Especially when it's causing thinks like clients logos to print in the wrong color or when something that is supposed to be plotting in grayscale comes out blue.

It's probably more prevalent in our industry because of the use of large monitors and color profiles for exact color representation on the screen.

[TrackerSupp-Daniel]

Hi RMan,

Rest assured that they are two problems tied together, and when one is fixed, so will the other. If the same problem is occurring in one piece of our suite, and we fix, we make sure that it works the same way in the other pieces.

[stegeler]

Great news that there will be a fix in the upcoming builds!

I want to thank you guys in advance for giving us so many solutions this fast! I hope one of them will work!

Also i want to excuse myself that i´m responding so late bc i was on vacation... I´ll keep in touch with you and tell you which of the solutions worked.
Regards

[Tracker Supp-Stefan]

[RMan]

That is awesome to hear. Thank the team for me as this will make a bunch of clients happy and hopefully they will stop bugging me.

[Tracker Supp-Stefan]

Thank you guys all for the kind words!

The new build is just a few days away now - we are in the final testing stages and will have the new build asap!

Regards,
Stefan

[frittenfred]

Hi everyone, I've been a happy, occasional user of PDF-Xchange Editor 3.0 since I bought a license some years ago. I mostly use this handy tool for trimming bookmarks and altering some settings for the initial view. Today I used it to insert some watermarks, and also that first seemed to work well. However, as I realized too late, the saving procedure after the watermarking had changed the color space of the images in the file: In the non-watermarked document, even after saving it with PDF-X-Change, all colors had remained bright RGB as I had received it from the creation software. But after watermarking, it all faded to palish CMYK-like appearance.
- Is there a chance of preventing the XCE from groping existing pictures when adding watermarks?
Thanks and best regards, Rolf

[TrackerSupp-Daniel]

Hi Rolf,
Grouping of the images like that should not happen to begin with, could you send us the before and after files for inspection?
If they are of sensitive nature, please send them to Support@tracker-software.com

[frittenfred]

Hi Daniel, thanks for your very fast reply. As they are indeed somewhat sensitive, I'll send the two files by e-mail.

[TrackerSupp-Daniel]

Hello frittenfred,
Ive received your email and send a reply with detailed instructions, than you for letting us help out!

[stegeler]

Your best bet may be to remove the display color profile from Windows' own color profile settings and thus claim it to be a plain sRGB display.

So we just removed the original 'Samsung 2494HM' coloring profile and it worked! All computers are able to plot again (hardcopy and PDF-XChange Standart). Thank you guys!

Sometimes the best solution can also be the easiest one!

Regards

[Tracker Supp-Stefan]

Glad to hear that stegeler!

Cheers,
Stefan

[Timur Born]

Of course this workaround is only useful if you don't need said display color profile for other work. But it's better than nothing. Acrobat Pro offers several advanced color profiling options over its free Reader version and over Editor. But once Editor is fixed the combination of Editor and Reader should get you a long way without having to pay the expensive price of Acrobat Pro.

[Tracker Supp-Stefan]

Thanks for the feedback Timur,

Yes - the proposed deletion of colour profiles is just a workaround and not the final solution to the problem. But it is what we can offer for the moment until we get the colour handling working properly with custom colour profiles present on the machine!

Regards,
Stefan

[RMan]

So it looks like in the new build it is not fixed or am I missing something?

If I have a PDF with color say 83,187,187 in it the only way you can get a printout using that color is if you use the Monitor RGB - Pro Photo RGB color profile which then doesn't display in the proper color on users monitors.

As I suggested before the solution is simple in the short term. You just remove the color profiles when users are printing. Yes you might get a color change and flash on the display but it sure beats users complaining that the PDF is printing in the wrong color.


Here's the VB6 code you can add into the OnEvent to handle the color value at least that seams to be working on mine so you can pass it onto your programmers.

Code: Select all

Private p_oldColorManagementColor as String



Private Sub AxPXV_Control1_OnEvent(ByVal nEventID As Long, ByVal pEvent As PDFXEditCtl.IEvent, ByVal pFrom As 0)
    Dim evtID As Long
    Dim evt As PDFXEditCtl.IEvent
    If pEvent.ID = AxPXV_Control1.Inst.Str2ID("e.document.beforePrint") Then
        p_oldColorManagementColor = AxPXV_Control1.Inst.Settings.Item("PageRendering.ColorManagement.Custom").GetString("RGB", "")
        Call AxPXV_Control1.Inst.Settings.Item("PageRendering.ColorManagement.Custom").SetString("RGB", "")
        evtID = AxPXV_Control1.Inst.Str2ID("e.document.invalidatePages", False)
        Set evt = AxPXV_Control1.Inst.EventServer.CreateNewEvent(evtID)
        If Not evt Is Nothing Then
            Call AxPXV_Control1.Inst.EventServer.FireEvent(evt, AxPXV_Control1.Inst.ActiveDoc)
        End If
        Call AxPXV_Control1.Inst.FireAppPrefsChanged(PXV_AppPrefsChanges.PXV_AppPrefsChange_ColorMan)
    ElseIf pEvent.ID = AxPXV_Control1.Inst.Str2ID("e.document.afterPrint") Then
        If Len(p_oldColorManagementColor) > 1 Then
            Call AxPXV_Control1.Inst.Settings.Item("PageRendering.ColorManagement.Custom").SetString("RGB", p_oldColorManagementColor)
            evtID = AxPXV_Control1.Inst.Str2ID("e.document.invalidatePages", False)
            Set evt = AxPXV_Control1.Inst.EventServer.CreateNewEvent(evtID)
            If Not evt Is Nothing Then
                Call AxPXV_Control1.Inst.EventServer.FireEvent(evt, AxPXV_Control1.Inst.ActiveDoc)
            End If
            Call AxPXV_Control1.Inst.FireAppPrefsChanged(PXV_AppPrefsChanges.PXV_AppPrefsChange_ColorMan)
        End If
    End If
End Sub

[TrackerSupp-Daniel]

Hi RMan,
Sorry, but as I had mentioned above,

Hi Rman, Timur, Stegeler,
The dev team just spoke with me on these matters, it seems we are aiming for a driver 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.
So the 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!

Thank you for the code though, Ill see if the devs want this. But I don't think making the Editor Change the system display whenever it is in use is a great idea...

[RMan]

Sorry I misunderstood the replies and thought you guys had found a fix for this release.

I think it's a solution worth implementing short term instead of waiting another 2 to 6 months for it to be fixed so hopefully your programmers use the idea and fix it for all users. Graphic Design Professionals, Architects, Engineers, they all need exact color reproduction for print output. There is a huge difference in their world between a blue and a bluish gray color.

Luckily it looks like I can fix it for our customer base in the short term.

Your programmers are far more talented than I am so I'm sure they can overlay a static image of the Editor window if need be so the users don't even see the color change on screen during the print process. But for our clients having a color change on the screen only to have it redrawn back to the correct color on the screen isn't nearly as bad as output which doesn't match their color specifications.

[TrackerSupp-Daniel]

Indeed,
Sorry for the delay, we do try to roll these kinds of fixes as soon as we have them in place.
So while I cannot give any guarantee it will be soon, it is coming in the future

And thank you again for the suggestion!

[Timur Born]

Pretty please implement an option to *disable* Editor's color management until you finally fix it for good. We users of wide gamut displays currently have to jump through several hoops to either get somewhat properly saturated screen display or proper printing. It is much easier to do this in Acrobat Reader, because it offers the default option to "Let Printer determine colors".

Here is Editor's printing output when a wide gamut display Windows color profile is installed. There is visible clipping of color information due to over-saturation done by Editor's color management.

This is what it should look like instead. This can be achieved by either removing the display color profile from Windows color management or by forcing Editor to use sRGB. The former comes at the expense of other software not getting the display profile information, the latter comes at the expense of Editor displaying all color strongly subdued (de-saturated) on screen. So both workarounds are rather inconvenient.

Disclaimer, the original image is a product image of the Komar "Melli Mello Jema" wallpaper, inserted as image in Editor, printed and scanned via HP LJ Pro 500 Color.