No, Bart. It means I identified and compared 1000+ files in the folders that tend to contain site customizations. Not all of them needed special attention... most just need moving from the old application tree to the new one. But there are plenty of files that need individual attention/reconciliation so as to not overwrite newer functionality delivered with a newer build of XPP. 

For those interested in this thread, we were finally able to reproduce the problem with the customer sample on our system at RWS.

The missing factor was that a View DPI setting (of 72) was being used (set in the im config file for the Image Library being used for the images).

And other factors that caused the xyview display problem to only occur with some EPS images is that the problem only occurs when:

1. the image uses the same font(s) that are being used in the regular text on the page and
2. the font(s) are embedded in the image and
3. the image occurs before any regular text on the page using the same fonts.

Apparently there is some very weird interaction occurring between the (same) font(s) being defined in the generated low-res EPS version of the original image and the regular text in those same font(s) occurring later on the page.

It's early on, but analysis seems to indicate that the GS command being run to generate the low-res EPS image is subsetting the fonts in the generated low-res image. Then the fact that subsetted font definitions occur first is preventing (or interfering with) the GS display engine properly downloading the full font definition into the PS being processed. That results in characters in the regular text, that were not included in the font subset used in the image, displaying as blank (not surprising since those font glyphs are then not available to the engine).

Workaround: At least for us at RWS (not customer-verified yet), if we didn't use (or deleted) any View DPI setting then we don't see the display problem with the customer sample.

We're hopeful that we have an idea on what to change in the GS command being run to generate the low-res IPS image in order to prevent this problem from happening.

I did change "72" to "none" in the View DPI field of the im_config file in our 9.4.1 dev and test environments and it did resolve the problem. 

I then made the same change in our 9.2.2 production system around 1:30 pm today to see how the system would behave, specifically if that change significantly affected the speed of pages being displayed. I told the users I was making a change and to let me know if they had any performance problems. No one complained. 

Another update, Jaye.

I forgot to mention last time that we also set up your sample on one of our XPP 9.2 systems, including having View DPI set, and we did see the xyview display problem.

So, it was somewhat of a mystery as to why you were not seeing the problem on your XPP 9.2.2 systems.

But now I know why. On our system we were running the latest hotfix (pre-patch 9.2.3) version of the xyview that you do not have.

It turns out that after the 9.2.2 SP was released (the last SP for 9.2), it was discovered that creating lo-res images for View DPI was completely broken.

With the 9.2.0 release we moved to a new GS 921 version of Ghostscript, and didn't realize that changes that had been made in GS made the GS command we ran to create lo-res images always fail.

The way the XPP code works, when a low-res image cannot be successfully made (because the command to make it fails) XPP creates a zero-length low-res image file (generated lo-res images live in the .xycache subfolder of the Image Library folder of the same name as the original image). That's done so that XPP doesn't continually try to run the same command over and over again that's just going to fail. When such a zero-length file is found in the .xycache folder, the xyview (always) just uses the master image.

However, that effectively means that if using XPP 9.2.0/9.2.1/9.2.2 (and not latest hotfixes to 9.2.2 for the fix) View DPI is completely broken (unless there are good old up-to-date low-res image files that were created while using an earlier release of XPP). Bug still existed in 9.3.0 release, but was also fixed in 9.3.1 SP and then 9.4.0 core release.

That would also explain why when you removed the View DPI settings on your 9.2.2 systems, your operators did not notice any change in performance, since effectively View DPI is "broken" on your 9.2 systems (at least with any "new" jobs).

If you were to poke around in your .xycache folders on your 9.2 systems, most likely they will find a lot of zero-length files (at least in any "new" jobs).