GhostPCL character chart?

[Brian K. White]

On 6/27/20 5:02 PM, Fairlight via Filepro-list wrote:
> On Sat, Jun 27, 2020 at 03:53:42PM -0400, Brian K. White via Filepro-list thus spoke:
>> I just tried the following on both an old and new box, and go the same
>> output in the pdf, a blank space for chr255
> Probably because 255 is the CP437 character for NBSP.
>
> https://en.wikipedia.org/wiki/Code_page_437#Character_set
>
> m->


Going further, changing the character set by a pcl code does produce 
printable characters for chr255 in other charsets.

For instance 'esc ( 0 N' selects Latin1 charset, and produces a y with 
two dot for me.

Here is a little gwbasic program to produce PCL to show all chars in a 
given characterset (selected by line 40)
You can re-write this in bash pretty easily.
http://www.piclist.com/techref/language/pcl/lj1616.htm

See line 40
That program uses esc(10U which is the same as the printer default 
"pc-8" aka cp437

And here is a list of other codes to try in place of "10U"
https://www.pclviewer.com/de/resources/pcl_symbolset.html

Note, this page shows lowercase letters like 10u instead of 10U.
PCL escape codes may be combined into a single escape sequence where it 
starts with a single escape character followed by any number of 
commands, and the way it knows when to end the escape processing is it 
terminate when it sees a capital letter.
So if the "10u" is the last code in a string (which is true if it's the 
only code in the string) it's capitalized.
If the "10u" is in the middle of a string, it's not capitalized. Look at 
line 50 of that program.
The way to parse that is the overall command is "ESC(s" followed by 
several options to "(s": 0p, 10h, 12v, 0s, 0b, 3T.
Those number-letter pairs could have been stacked in any order, and 
whichever comes last needs to be capitalized.

So on that list of other character set codes, Latin1 is shown as "0n" 
but if it's in it's own escape code, it's "0N"

So the bash echo test to show chr255 in Latin1 is:
echo -e "\033(0Nchr(255)=\"\0377\"\r" |pcl6 -dNOPAUSE -sDEVICE=pdfwrite 
-sOutputFile=/ptmp/latin1.pdf -

You could try other values from that page and copy this command line, 
and only change the "0N" (that's Zero N just to be clear).

And you can look for a code like that in your print code table.
Maybe the problem is it's missing from your print code table?

Maybe the output format includes an odd print code like 97 or something, 
maybe in the form itself, maybe in the init sequence in the F8 options, 
and maybe the .prt file has nothing in slot 97, but maybe the same prt 
file on the old server did?
Or the printer names changed and maybe the form is not getting the same 
.prt file it used to get. That can be affected by env variables like 
PFPRINTER or the contents of the fp config file.
Maybe the correct prt file does exist on the new system just not being 
used for this form in this context for some reason like a change to the 
environment or fp config file.

-- 
bkw