Missing many characters in xyview Table Display only when Figure EPS image precedes Table in XPP 9.4.1

We upgraded our dev and test servers from 9.2.2 to 9.4.1. 

Our tables and figures are in pickups and are ordered by the sequence they are called out in the text. The sequence could be Table 1, Table 2, Table 3, Figure 1, Table 4 or the sequence could be Figure 1, Table 1, Table 2, Figure 2, Figure 3. 

During testing of the upgrade, we discovered that in the xyview and in page text mode, when a figure precedes the first table, all the characters in the table do not display as shown below. 

Screenshot of Trados Studio showing Table 1 with missing characters in the 'Consensus classification' column.

If we move the figure after the first table, close the file, and reopen it, all tables display with all characters as shown below. 

Screenshot of Trados Studio displaying Table 1 with all characters visible after reordering the figure and table sequence.

In articles where the first Table is cited before the first figure, there is not problem with the display. 

The figures are EPS images. 

If we delete the graphic block (eps image) in the Figure and leave the other parts, all characters display.  

Screenshot of Trados Studio with Figure 1 displaying estimated serogroup distribution, no visible errors.

All characters always visible in the line editor. All characters are always visible in the PDF.

The problem occurs whether we use Exceed 15, Exceed Turbo X, or MobaXterm. 

The problem occurs when the file is opened on a Mac and on a PC. 

This does not happen in 9.2.2. 

We are running RHEL 7.9 on dev, test, and prod. 

We have been working with RWS technical support to resolve this but they can't reproduce it on their system.

We are going to test with the 9.4.0 version of xyview, compose, and place_ads executables and possibly later releases but that's all we've got. 

Has anyone else seen this type of behavior? Any thoughts for a solution? 

Thank you,
Jaye Mize

Director, Content Production Systems

JAMA NetworkTm

330 N Wabash Ave, Ste 39300, Chicago, IL 60611

T 312-464-4712  M 719-431-2462

jamanetwork.com



Generated Image Alt-Text
[edited by: Trados AI at 5:26 AM (GMT 0) on 5 Mar 2024]
emoji
Parents
  • 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).

Reply
  • 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).

Children
No Data