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

    Jonathan Dagresta
    RWS Group/
    XPP Development

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

Reply Children
No Data