Possible font metrics issue with Arial under Windows 8.1, Windows 10

[czeslaw_czapla]

I develop reports in Crystal for a large Windows desktop application. (Our application ships with about 1300 standard reports developed in Crystal.) The application uses the Viewer provided by the Crystal runtime engine in order to display the reports.

I'm experiencing a text clipping problem in my reports as displayed in the Viewer.

The problem occurs when I run our application under Windows 8.1 or Windows 10, but not under Windows 7. Below is a pair of screen shots. The first shows the problem under Windows 10. The second shows the same report under Windows 7, where the symptom does not occur.

Windows 10:

Windows 7:

Interestingly, the problem seems to occur only when the text is right-aligned in the text box, and only when the text includes three or more '1' (numeral one) characters in sequence. You can see in the examples above that dummy SSN values that contain substring '111' exhibit the symptom; others do not. These dummy SSN values are field objects in the report. Likewise, you can see in the examples above that static text values (eg: '1112') that contain substring '111' exhibit the symptom; other static text objects do not (eg: '112'). I've tested with various string values, but have been able to cause the symptom reliably only when my string contains '111'.

The problem does not occur in the Crystal designer (on my Windows 7 development machine), only when the report is displayed in the runtime's Viewer (on a Windows 8 or Windows 10 machine). I'm sorry that I cannot say whether the problem would manifest in the Crystal designer under Windows 8.1 or 10; I can't test for that.

We distribute and use the following runtime engine with our application:

SAP Crystal Reports runtime engine for .NET Framework (32-bit), Version 13.0.10.1385

That version of the runtime engine was used for the screen shots above.

I've also tested with the latest runtime engine (13.0.17.2096) and the same symptom occurs, although it seems slightly less pronounced.

The font is Arial. I've also tested with Times New Roman, and the same symptom occurs although it is considerably less pronounced.

Both Arial and Times New Roman fonts were revised for the Windows 8 release. For instance, the version of Arial released with Windows 7 was v5.06; the version of Arial released with Windows 8 was v6.80. Arial is a default font for Windows, and thus has "locked font metrics" (see Fonts and text metrics (Windows)). Accordingly to the Microsoft page I've just cited, "because the reported values associated with these fonts are locked, there may be discrepancies between reported and actual font values." I read this as an indication that Arial (among other "locked" fonts) may report metrics about itself that are inaccurate given a history of revisions, redrawings, etc.

This report, like all standard reports in our application, is saved with the printer set to 'Microsoft XPS Document Writer', because that printer is generic and present on all Windows computers. (That generic setting precludes a lengthy timeout that would otherwise occur on a user's computer as it searches in vain for a printer that exists on my network (here at work) but not on the network in the user's workplace.) I've also tested by saving a different printer in the report (HP Officejet Pro 8600), and found that the symptom persisted.

I'm hoping that someone might have some insight into the cause of the problem and might be able to offer suggestions for a remedy.

To summarize my testing so far:

1. Problem occurs under Windows 8.1 or Window 10, but not Windows 7.

2. Problem manifests when a certain text string is used ('111').

3. Problem occurs whether the source object in the Crystal designer is variable (data field object) or static (text object).

4. Problem occurs in multiple versions of the runtime engine, including the latest.

5. Problem is particularly pronounced with Arial font.

6. Problem occurs for various printer designations in the Crystal file.

Thank you for your attention and assistance.

[former_member11696 · Accepted solution]

Hello,

Not surprising as you discovered the differences in the fonts themselves.

Likely due to usp10.dll that we use to format the fonts.

For the printer issue it should not be a problem in SP 17 and make sure you check on Dissociate, that way it will not look for that specific printer and only uses the setting from that family of printers.

Can you attach one of the reports that shows this? I'll test it also and see if I can find a work around.

To attach save the report with dummy data and then rename it to *.txt and use Advanced Editor to attach the report.

Curious if you have tried New Courier since it's space specific, each character uses the exact same amount of space.

Don

[czeslaw_czapla · Accepted solution]

Thank you for the reply, Don.

Per your suggestion, I performed a test by changing the font in the report to Courier New -- like Arial, a default font under Windows, also one with "locked font metrics" -- and found that it was non-symptomatic. Here is the non-symptomatic report output using Courier New, as displayed in the Viewer under Windows 10 (exactly where Arial would be symptomatic):

My next thought is to test with a non-fixed-width font (ie, something that is not monospaced in the way that Courier New is) that is not among the "locked font metrics" fonts.

Per your request, I'm attaching the report to this message. I've saved the report with dummy data that displays the symptom (the same data that appears in all my screen shots for this issue). I've changed the file extension from .rpt to .txt for purposes of attachment to this message.

In typography, I've learned, there is a specific glyph-level font metric known as "advance width" that indicates "the proper distance between the glyph's initial pen position and the next glyph's initial pen position" (https://en.wikipedia.org/wiki/Font). The main hypothesis that I've been entertaining is that the actual advance width for the '1' (numeral one) character in Arial changed between Windows 7 and Windows 8, but the reported advance width (what the font itself claims as the measurement) did not change (because Arial has "locked font metrics" and self-reports the same measurements regardless of any actual changes in, say, advance width). The hypothesis continues: Crystal's runtime engine takes Arial at its word regarding these self-reported metrics. Under Windows 7, what Arial reports is accurate; thus, Crystal is able to calculate the overall string length accurately and determine an accurate starting position for the left-most character. But under Windows 8 (after changes to Arial's actual metrics), what Arial reports is not accurate; thus, Crystal (using the reported metrics) is unable to make accurate calculations and placements.

Upon reflection, I've found that there is a fundamental weakness in this hypothesis: it fails to explain why the symptom begins to occur only when three '1' (numeral one) characters appear in sequence. If the problem is that the actual advance width for the '1' character differs from the reported advance width, then we should see a cumulative discrepancy that manifests itself in small measure even when only one '1' character is included in the string, and manifests itself in greater measure in a linear progression when additional '1' characters are included in the string in any position whatsoever (ie: not necessarily adjacent to one another).

Don, do you have any idea why the problem would manifest only when there are exactly three '1' characters in a row within the string?

PRMonthlyWagesForIL_Arial_with_data.txt.zip

[czeslaw_czapla · Accepted solution]

As promised, I've just tested the report with a non-fixed-width font (ie, a variable-width font) that is not among the "locked font metrics" fonts. I used Palatino Linotype. Here is the non-symptomatic report output using Palatino Linotype, as displayed in the Viewer under Windows 10 (exactly where Arial would be symptomatic):

So the problem appears not to be generalized to all variable-width fonts.

In further testing, I made an attempt to replace the Arial font file (arial.ttf) on my Windows 10 test machine with the earlier version of arial.ttf from my Windows 7 test machine (where the symptom does not manifest). The result was that report output remained symptomatic under Windows 10, even with the Windows 7 version of arial.ttf in place. Assuming that my effort to switch out the font file (ie, my test setup on the Windows 10 machine) was successful, this result suggests that the font file itself is not the source of the problem. (Possibly my test setup was faulty due to my unfamiliarity with font-file handling in Windows; if so, this would invalidate my test and conclusion.)

[former_member11696 · Accepted solution]

Thank you for the report.

I see the same thing on Windows 10.

This is not the first time We've seen issues with Arial and Times New Roman also.

The difference are as you suspect and not much we can do about it.

Our rendering engine is hardware and software dependent so in CR Designer we use GDI.dll to render the page for WIN32 C++ code. In CR for VS the Framework uses GDIPlus.dll and there are differences, and mostly nothing we can do about them.

I changed your report so it uses Arial MS Unicode and now I get the correct spacing and formatting:

We've logged these issues to R&D before and they always say it's differences between GDI and GDIPlus, we have no control over them since Microsoft owns the dll's.

The other potential dll that affects this is USP10.dll, ours is an older version 1.4 and this could be the source also, we are looking at updating it to the latest versions but it affects so much of our product we can't just upgrade it due to backward formatting issues.

The other part that can affect it is the printer being used, you could try different ones, it may help.

All I can say is use what works across all OS's for now.

Don

[czeslaw_czapla · Accepted solution]

Thank you, Don, for your testing efforts and clear explanations of the underlying technology. It is helpful to me (and our customers) to understand the likely causes and the constraints on possible solutions.

I've marked your last reply as the correct answer for this discussion.

[former_member11696 · Accepted solution]

You are welcome....

Too bad Arial is the first one in the list so it basically defaults to that one...

Don