Question & Answer
Question
How can I use fonts to create bar codes in a DCF document?
Cause
Problems with bar code data at code point 0x40 being replaced by blank space.
Answer
Some people like to use fonts to produce bar codes with Document Composition Facility (DCF) SCRIPT/VS. You can use fonts, but you need to be careful if you want to have printable data at hex code points 0x40 or 0x41. These represent the blank and "required blank" to Script/VS and they are normally replaced by positioning commands to justify text.
The following is a question from a customer regarding this and the answer is a procedure to use.
*** QUESTION ***
I have a Barcode font that uses 0x40 for printable data and not as a normal space. But the 0x40 data is not printing when using DCF. It is still being treated as ordinary spaces.
I tried changing the code page for the font to say that 0x40 was not the Variable Space Character, but then DCF rejected the code page.
What can I do to get my barcode data to print correctly?
*** ANSWER ***
DCF requires a code page that uses 0x40 as the Variable Space Character (VSC). To get 0x40 to print as text data, you need to use translation to use another code point and two versions of the code page. DCF uses one with 0x40 as the VSC, and Print Services Facility (PSF) uses a copy with another code point, 0x41 for example, as the VSC.
You can use the FONT2FF and FF2FONT tools to alter a code page, for example T1GI0395. You would want to use the appropriate code page for your bar code font. These tools are available with the Advanced Function Printing (AFP) Font Collection for Workstations 5648-B45 or try to use a hex editor. The following assumes that you have the tools.
DCF really only cares about hex 40 and 41 being special on INPUT. Hex 40 is the normal blank character and hex 41 is the "required blank" character. You need to prevent DCF from replacing the 0x40 with a move instruction for spacing. That way the 0x40 remains in the datastream as a code point which can be assigned to a printable character.
The secret for getting hex 40's to be printable character data is to have 2 copies of the code page. DCF uses one with 0x40 for the VSC, and PSF uses one with 0x41 for the VSC. We hide the hex 40's in the data from Script so it does not replace them with positioning commands.
In the code page DCF uses for formatting, the CPC uses 40 for the VSC.
CPC DEF=SP010000 VAL=1 PRT=0 INC=0 VSC=4040 VSF=1
In the code page PSF uses for printing, the CPC uses 41 for the VSC.
CPC DEF=SP010000 VAL=1 PRT=0 INC=0 VSC=4141 VSF=1
Both versions of the code page had 40 and 41 redefined as printable characters. It can print 41's if 40 was the VSC, and it can print 40's if 41 was the VSC. If a different character was the VSC in the code page I used by 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"
Note: The example includes embedded characters which may cause problems for programs like Homepage Reader.
The trick inside the Script source file is 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 $ code points into 40's for output.
The .tr must come first. Once the <.ti 40 $> is in effect, you can't 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. We chose $ as an example. If your output also requires real $ characters, then select another unused code point.
The <.ti> following the text restores the default translation for input. Do this immediately after the data containing the 40's or DCF won't be able to process any other text or control words normally. In this example, we use normal text, but the same idea applies to using bar code fonts.
The <.dc rb off> causes DCF to treat hex 41 as normal text and not a special character. The next text line has one hex 40 following "is". All other blanks in that sentence are really hex 41's. You can see this if you display it in hex.
The final <.tr> restores the default translation for output.
Conclusion
To process hex 41 as ordinary text it seems we only need the command ".dc rb off".
To process hex 40 as ordinary text we sort of "go around" Script by translating the input 0x40 to another code point before processing, and then translating the chosen code point back to hex 40 for output.
The definition of the hex 40 and 41 code points in the code page as printable characters does not matter to DCF. DCF just requires a code page with 0x4040 in the VSC field of the CPC for Script to process it. PSF needs another copy of the code page with something else in the VSC field to treat the hex 40 as ordinary text.
DCF can also produce older formats of bar codes by using a profile, DSMBPROF, and two tags, :bardef and :barcode. See the DCF Bar Code User's Guide, found on the DCF 1.4.0 bookshelf. See the link given below.
Those tags create bar codes by using graphic rules instead of fonts.
DCF can also include Bar Code Object Content Architecture (BCOCA) objects by using the .do (define object) and .io (include object) Script commands.
Related Information
Was this topic helpful?
Document Information
Modified date:
17 June 2018
UID
isg3P1000684