The attached testfile uses symbolset SYMBOL (PCLid = 19M). There is a difference in printing characters in the range 0x90-0xaf (non-printable according to the symbolset). Artifex (both AFS and UFST) print these character as a space (i.e. having a width), HP printers have a width of 0 (zero) for these characters. I traced it down to the function is_printable(). pcs->map == 0 so the map_type = pcs->font->font_type (== 2) is used for the SYMBOLfont (which is selected when symbolset SYMBOL is specified). Then is_printable() returns true and in get_next_char() the pl_map_symbol() can't find the character in the font (i.e. it returns 0xffff) setting *pis_space = true
Created attachment 5185 [details] symbol.pcl pcl file selecting CGTimes and printing a line. Then selecting Symbolset SYMBOL and printing same line. Between 'Norris' and 'beard' on the second line, ghostpcl prints a space, and HP printers have no space.
I have reproduced this and find it odd, the expected behavior is a space. I'll check the implementor's guide for special cases with symbol fonts.
I am inclined to think this is an HP bug, it certainly does not follow the spec. If I use Zapf Dingbats in your example, I do get the predicted space character for the undefined characters, your test modified: <ESC>E<ESC>(14L<ESC>(s1p14v0s0b45101T09. There is no chin behind Chuck Norris\222beard. There is only another fist. Do you have other tests where undefined characters print like the symbol font example?
The SYMBOL font is set to font_type 2 (plft_8bit) because it is bound to symbolset SYMBOL (19M). However, this symbolset looks more like a plft_8bit_printable (32-127 + 160-255). See pllfont.c plulfont.c and pllrfont.c where the bound fonts font_type is set to plft_8bit.
Norbert this should be fixed in 10040, here is the log message, please reopen the bug if there are other related problems. r10040 | henrys | 2009-09-01 21:43:34 -0600 (Tue, 01 Sep 2009) | 8 lines Fixes 690206. Explicitly set font types in the resident font table. The symbol font was incorrectly classified with font type Bound, 8-bit (256 characters, All codes are printable except 0, 7-15, and 27) instead of Bound, 8-bit printable (192 characters, character codes 32-127 and 160-255 printable). Thanks to Norbert Janssen for discovering this problem.
Did you compile? You made the same mistake as I did with plulfont.c. Copy/Paste the line from pllfont.c But plulfont.c doesn/t have a residentp->font_type. Should be resident_table[j].font_type; Also don't forget pllrfont.c . It also sets the font_type
See previous comment #6
Also I think the Dingbats is a plft_8bit (not a plft_8bit_printable), because it also has characters in the 0x80-0x8d range according to the symbolset.
Oops, forget about comment #8.
> Did you compile? You made the same mistake as I did with plulfont.c. > Copy/Paste the line from pllfont.c But plulfont.c doesn/t have a > residentp->font_type. Should be resident_table[j].font_type; Great minds think alike... ;0) Fixed in 10042. > Also don't forget pllrfont.c It is targeted for deprecation and not currently used. I better let you close this bug.
closed.
Changing customer bugs that have been resolved more than a year ago to closed.