Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Crystal 9: Unicode and Special Characters 1

Status
Not open for further replies.

N11689

Programmer
Jan 29, 2002
113
0
0
US
We have a report that when printed, some of the characters come out garbled, but other field print just fine.

The garbled characters seem to happen when there are special characters in the text field (carriage return/line feeds, slashes, parentheses, etc.)

If we takes these text fields and create a formula and enter the text the same way (with the special characters) and place the formula on the report, the formula prints fine. There are no garbled characters.

Is there an explanation for this?

Is there anyway to turn off the Unicode support and just use ASCII characters?

Is there any Crystal Service Pak, Hot Fix, DLL that corrects this problem?

Thank you.
 
What connectivity are you using? For instance a common mistake is to not use a CR supplied ODBC driver, in which case problems may arise. Try changing it and see if that helps. There are monthly hotfixes at crystaldecisions.com

I don't understand why it would have a problem...

-k
 
We are using Microsoft OLE DB Provider for SQL Server to connect to the database.
 
NBudd,
I'm having similar problems. The reports look fine on the screen, but print garbled only on Windows 98/ME systems. So far only CR 9 reports, other PDF's print fine. It sounds like a CR Unicode problem, but I haven't found THE solution yet. Adobe suggests selecting to "Print As Image" under the Advanced button to see if it makes a difference. I also saw a reference to a UniCode driver (UNICOWS) on MS site (search for UniCode, select download: ML Layer for Unicode on Windows 95, 98, ...)

I'm waiting for a client to try this to see if it makes any difference.

Please let me know if you find anything.

Thanks.

Jeff Clark
 
I posted this on another thread as well, but it most likely applies here also.
-----------------------------------------------------------
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.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top