I have a Barcode font that uses x'40' for printable data and not as a normal space. But the x'40' data is not printing. It is still being treated as ordinary spaces.
I tried changing the codepage for the font to say that x'40' was not the Variable Space Character, but then DCF rejected the codepage.
What can I do to get my barcode data to print correctly?
Subject: PMR 9315E,194 Printing barcodes with data at x'40'
Eureka! I think I've got it.
I sent you some files I was playing with that seem to solve the problem
without any changes to DCF.
I used FONT2FF and FF2FONT to alter the T1GI0395 codepage. DCF really
only cares about hex 40 and 41 being special on INPUT.
This customer needs to produce output with hex 40 in the datastream so a
printable graphic can be used for it.
The secret for getting hex 40's to be character data was to have 2
copies of the codepage, one for DCF and another for PSF, and to "hide"
the hex 40's in the data from Script.
In the codepage I let DCF see for formatting, the CPC was set like this:
CPC DEF=SP010000 VAL=1 PRT=0 INC=0 VSC=4040 VSF=1
But once the LIST3820 had been generated, I let PSF send another version
along with the LIST3820. That version had this:
CPC DEF=SP010000 VAL=1 PRT=0 INC=0 VSC=4141 VSF=1
This meant that PSF would use 41 for spaces instead of 40's. I think I
could use any codepoint I wanted there.
Both versions of the codepage had 40 and 41 redefined as printable
characters. I could print 41's if 40 was the VSC, and I could print
40's if 41 was the VSC. If a different character was the VSC in the
codepage I send to PSF, then I could print both 40's and 41's.
GCID=LA010000 VAL=0 PRT=0 INC=0 CP=40 <---lowercase "a"
GCID=LA020000 VAL=0 PRT=0 INC=0 CP=41 <---uppercase "A"
The trick inside the Script source file was to use .ti and .tr and .dc
correctly.
.tr $ 40
.ti 40 $
This is a test to see what happens to hex 40 characters.
.ti
.dc rb off
This¦is a¦test¦to¦see¦what¦happens¦to hex¦'41'¦required¦blanks.¦¦¦
.tr
Explanation:
The first <.tr $ 40> will translate $ codepoints into 40's for output.
The .tr must come first. Once the <.ti 40 $> is in effect you can't
really use blanks.
The <.ti 40 $> translates all hex 40's to $ before any other Script
processing, so we don't treat them special in the text.
The <.ti> following the text restores the default translation for input.
You must do this immediately after the data with the character 40's
or you won't be able to process any other text or control words
normally.
The <.dc rb off> allows hex 41 to be treated as normal text and not a
special character. The next text line has one hex 40 following "is".
All the rest of the blanks in that sentence are really hex 41's. You
can see this if you use "hex c" command in Browse.
The final <.tr> restores the default translation for output.
Conclusion:
To process hex 41 as ordinary text it seems we only need .dc rb off.
To process hex 40 as ordinary text we sort of "go around" Script by
translating the input to something else before processing, and then
translating the "something else" back to hex 40 for output.
The redefinition of the hex 40 and 41 codepoints in the codepage
doesn't matter to Script. We just need a codepage with x'4040' in
the VSC field of the CPC for Script to process it, and we need another
copy of the codepage with something else in the VSC field to get PSF
to treat the 40's as ordinary text.
Last updated: 95/12/14 17:50:01