Crystal 9: Faxing problem with Windows NT (v4.0.0.1381 SP6) 1

[N11689]

We use Omtool's FaxSr software to fax some of our Crystal reports.

One of our customers (who we distribute Crystal runtime files to so they can run our reports) has several clients on NT machines where the faxes they send are completely cryptic/garbled.

These users are on Windows NT (V4.0.0.1381 SP6) and are using the Digital LN03R ScriptPrinter (driver DCLN03R1.DLL, driver version 4.01)

We have tested here on two different Windows NT machines also on V4.0.0.1381 SP6 and using the Digital LN03R ScriptPrinter with driver driver DCLN03R1.DLL, driver version 4.01. We cannot duplicate the problem. We have also tested on Windows 98, Windows 2000 and Windows XP...still no problem. Text prints correctly. Our faxes are not cryptic or garbled.

We had the user print the report directly to this post script printer (this creates a PostScript file). We then used a PostScript converter program to open the PostScript file.

The actual PostScript file that is created is cryptic. So, it appears Crystal 9 is 'garbling' the text/fonts.

Has anyone experienced this problem? With NT machines? Any insight would be greatly appreciated.

 

[Lochbel]

It was completely unrelated to faxing and text but we had some difficulty with NT machines that was a result of COMCAT.DLL conflict problem.

There is literature on this in the CD KB.

Lochbel

 

[N11689]

We had the user download a newer adobe postscript print driver (AdobePSGenericPostScriptPrinter), and this seemed to work.

But, it doesn't make sense that the old driver would work on one NT machine, but not the other. It must be a combination of print driver and something else on the NT machine that would cause the cryptic/garbled text.

If anyone knows what might interfere with a print driver, please let me know.

 

[Reebo99]

This could be related.

We had a problem where one of our fonts (r_ansi) was fine in CR8.5 but when we went to CR9 the text was totally garbled.

A call to Crystal and 6 months of investigation from them turned up nothing, even though there is still a problem.

I'm sure this was down to the Unicode support which comes with CR9.

Reebo
UK

 

[N11689]

Some co-workers of mine have done some research and this is what we've found thus far:

When our customer first had this problem, they found an article indicating a problem with Unicode and the print driver. Unicode is a newer standard that defines which number represents which character. It supersedes the older ASCII character set that we are used to using but uses the same codes for ASCII characters so it is upward compatible. Crystal added support for Unicode in Crystal 9. They also added embedded fonts where the font used when creating the report is embedded in the report so that even if the destination PC printing the report doesn't have that font installed, it can use the font for the life of the report. With all Windows printing (Crystal, Word, etc.), the font you use is not necessarily the one that the printer will use. This depends on the font family selected (for example, Arial) and the codepage used. We're not experts on codepages, but they further define the specific character set used when printing. If the printer has that font family and codepage, you're all set, if not, it will replace it with whatever it thinks is closest. It is not clear how much substition occurs at the printer and how much in the print driver.

So what is really happening is not a Unicode problem but a font substitution problem. Specifically, the problem is with TrueType fonts. These are the fonts that Microsoft helped develop to provide better WYSIWYG printing. However, if you look at articles both on the Microsoft site and on the Crystal site, many printing problems are attributed to TrueType fonts. Microsoft and Adobe (creator of the earlier Type 1 fonts originally used by Postscript printers) have now jointly come up with a standard called OpenType. What is happening is that the TrueType Arial that we use is getting replaced when printed. This has always occurred (which is why we see different results on different printers/print drivers) but we never ended up with garbled text. We think this may have to do with the Unicode change which impacts the codepage. There now is a different substitution happening. We still believe that there is a bug in Crystal since not all Arial fields print incorrectly and some fields print partially correct and partially messed up. This seems like a Crystal problem in how they are passing font and codepage information to the print driver.

We found another problem ... that printing from the same PC to the same printer under two different usernames yielded two different results. The privileged (Administrator) user printed incorrectly. We discovered that printer test pages printed under the two different usernames also appeared subtly different in that they had the same content but used a different font. After a little research (see Microsoft article #222???), we found out that TrueType fonts seemed to have a history of printing incorrectly. One of the solutions was a setting on some print drivers that allow you to pass TrueType fonts to the printer as bitmaps. Since they have already been translated to pictures before the printer gets them, there is no opportunity for the font to be replaced by an incorrect font. It turns out that this setting is off for privileged users and on (but not changeable for some reason) for non-privileged users. Changing it to on for the privileged user caused the test page and report to print correctly with the same font as the non-privileged user. You can get to this setting on an HPLJ6 by right-mouse clicking on the printer, selecting "Printer Preferences" or "Document Defaults" depending on the operating system, clicking on the Advanced button and setting the setting. As an FYI, we have also had a problem for several years printing bulleted lists from Word to the HPLJ6 printer. This setting corrected this problem as well! Note that the problem started occurring when someone changed the print driver from a PCL5 print driver to a PCL6 driver. Also, we modified the .RPT file to a Type 1 Arial (instead of a TrueType Arial) and it also printed correctly, regardless of the bitmap setting above.

All of this leads where??? It prints partially garbled, Service Pack fixes the problem (but we don't know because we can't test if it does it all the time). Changing the printer setting to replace the font with bitmaps works but not all users can get to the setting, we don't know if all print drivers have such a setting and we don't know what it does to performance. Updated print drivers or replacing PCL6 with PCL5 may also fix the problem. Will changing fonts from a TrueType font to either Type 1 or OpenType make a difference on all printers? Don't know... you'll have to test.

 

[vaks009]

Hi NBudd:
In your original post you have mentioned
"We had the user print the report directly to this post script printer (this creates a PostScript file). We then used a PostScript converter program to open the PostScript file."

Can you please tell me how the user is creating a postscript file and what kind of converter program is used to open Postscript file?

regards,
vaks

 

[N11689]

The post script print driver creates the post script file and we use FaxSr by Omtool to open the post script file.

 

[vaks009]

thanks NBudd.
-vaks