I'm trying to print a USPS FIM. A FIM-A example is at the below url. They are 9 characters wide, 16 cpi, 5/8" (per Google, 45 points) tall. Horizontally they are coming out perfect, but they are only 1/8" tall. I'm sending "~(s16h45V" (where ~ is escape) followed by a 9 character string composed of 0xDD (left half block) and 0x20 (space). I just started working with PCL yesterday, so hopefully I'm just doing something stupid.
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 Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Stretch font vertically 2
- Thread starter Pascal666
- Start date
You will have to tell us about the barcode font you are using. Is it a Truetype or bitmap font? PCL as such does NOT permit stretching the font only in one direction or the other. It sounds as though something else is going on like the dpi or somesuch. What is the PCL code that the font people say you are supposed to use to activate the font?
Jim Asman
Jim Asman
- Thread starter
- #3
I'm using whatever font is the default on an HP LaserJet 4000 (I send "~(3@" a bit before this). I was unable to find a specific FIM font. The default 0xDD (left half block) and 0x20 (space) work perfectly horizontally, so I was hoping not to have to create one, but I did not realize PCL was unable to stretch fonts.
- Thread starter
- #4
The method you have adopted (printing the same data on successive lines, with line-spacing set to achieve a zero-leading) is what I would have recommended.
Unless (as was implied by Jim Asman's comment) the font you are using has special (non-standard) 'parameters' to adjust relative height, the only alternative would probably be to obtain a different font which more closely matched your requirements.
Unless (as was implied by Jim Asman's comment) the font you are using has special (non-standard) 'parameters' to adjust relative height, the only alternative would probably be to obtain a different font which more closely matched your requirements.
Save yourself a lot of grief and purchase a FIM font. There is no FIM built into the LJ4000. It would seem that you are simply using graphic symbol from a specific symbol set and then trying to scale the font to achieve the height. I think it unlikely that the bar itself would have the correct caliper as well. When the new postnet barcodes that handled the zipcode etc. came out a few years ago, the USPS had free fonts you could download. The fonts only contained 4 characters IIRC, but the effort was in assembling the print string.
I believe the FIM has only 4-6 "characters" which the font authors will have mapped to specific keyboard keys, for example, maybe A-F.
Given the closely defined structure, it really begs for a simple bitmap font that takes care of the geometry for you. I don't know if there are any special hoops you have to go through in assembling the print string such as a checksum(s) or what have you. I am sure the USPS will have specification you can download and study. Once you do some reading on this you will probably see the folly in you present course.
Jim Asman
I believe the FIM has only 4-6 "characters" which the font authors will have mapped to specific keyboard keys, for example, maybe A-F.
Given the closely defined structure, it really begs for a simple bitmap font that takes care of the geometry for you. I don't know if there are any special hoops you have to go through in assembling the print string such as a checksum(s) or what have you. I am sure the USPS will have specification you can download and study. Once you do some reading on this you will probably see the folly in you present course.
Jim Asman
If you only need to do one of these, you could simple draw the bars using PCL rectangle commands, not using a font at all. Of course it would be up to you to position the individual bars appropriately.
I don't know if your local post office can/will do a test scan the barcode for you. You sure don't want to print 100,000 business reply cards only to find out you barcode is invalid.
Jim Asman
I don't know if your local post office can/will do a test scan the barcode for you. You sure don't want to print 100,000 business reply cards only to find out you barcode is invalid.
Jim Asman
Pasacl666,
Disregard my previous posts. I realize now that fim A is a fixed barcode. So you can easily draw the bars with pcl commands.
Jim Asman
Disregard my previous posts. I realize now that fim A is a fixed barcode. So you can easily draw the bars with pcl commands.
Jim Asman
-
1
- #9
Disregard my previous posts. I realize now that fim A is a fixed barcode. So you can easily draw the bars with pcl commands. Let's try this again. Attached is a pcl file that should print a fim A
barcode.
Print it, review the code, and modify the parameters. Come back with any questions. This is done with a 600dpi environment.
Jim Asman
barcode.
Print it, review the code, and modify the parameters. Come back with any questions. This is done with a 600dpi environment.
Jim Asman
-
1
- #10
I didn't understand the reference to "0xDD (left half block)" at first, until I realised that the "Left Half Block" character (Unicode code-point U+258C) is mapped to hexadecimal DD (decimal 221) in some of the old DOS code-pages (such as CP 437 - "DOS Latin US" - I think that this is the equivalent of the PCL symbol set 10U "PC-8 CP437" - so this is how the questioner got the character printed using an ordinary text font).
Such old DOS coded character sets are not generally used within modern Windows (except perhaps for 'command-prompt' sessions?), or *n*x systems, so 0xDD will rarely display as a "Left Half Block" in Windows - it will usually show as "Latin Capital Y With Acute".
I agree with Jim on his alternative approach, using PCL 'rectangles'; here is an analysis of the code snippet, which may help if it is necessary to "modify the parameters":
Such old DOS coded character sets are not generally used within modern Windows (except perhaps for 'command-prompt' sessions?), or *n*x systems, so 0xDD will rarely display as a "Left Half Block" in Windows - it will usually show as "Latin Capital Y With Acute".
I agree with Jim on his alternative approach, using PCL 'rectangles'; here is an analysis of the code snippet, which may help if it is necessary to "modify the parameters":
Code:
Offset: dec Type Sequence Description
----------- --------------------- ---------------- ----------------------------------------------------
0000000000 PCL Simple <Esc>E Printer Reset
0000000002 PCL Parameterised <Esc>&l2a Page Size: Letter
0000000007 0o Orientation: Portrait
0000000009 6d Line Spacing (6 lines-per-inch)
0000000011 0e Top Margin (0 lines)
0000000013 66F Text Length (66 lines)
0000000016 PCL Parameterised <Esc>&u600D Unit-of-Measure (600 PCL units per inch)
0000000023 PCL Parameterised <Esc>*p2200x Cursor Position Horizontal (2200 PCL units)
0000000031 1000Y Cursor Position Vertical (1000 PCL units)
0000000036 PCL Parameterised <Esc>&l0C Vertical Motion Index (0/48 inches)
0000000041 PCL Control Code 0x0a <LF>: Line Feed
0000000042 PCL Parameterised <Esc>*c18a Rectangle Size Horizontal (18 PCL units)
0000000048 376b Rectangle Size Vertical (376 PCL units)
0000000052 0P Fill Rectangular Area: Solid Area
0000000054 PCL Control Code 0x0a <LF>: Line Feed
0000000055 PCL Parameterised <Esc>*p+38X Cursor Position Horizontal (+38 PCL units)
0000000062 PCL Control Code 0x0a <LF>: Line Feed
0000000063 PCL Parameterised <Esc>*c18a Rectangle Size Horizontal (18 PCL units)
0000000069 376b Rectangle Size Vertical (376 PCL units)
0000000073 0P Fill Rectangular Area: Solid Area
0000000075 PCL Control Code 0x0a <LF>: Line Feed
0000000076 PCL Parameterised <Esc>*p+38X Cursor Position Horizontal (+38 PCL units)
0000000083 PCL Control Code 0x0a <LF>: Line Feed
0000000084 PCL Parameterised <Esc>*p+38X Cursor Position Horizontal (+38 PCL units)
0000000091 PCL Parameterised <Esc>*p+38X Cursor Position Horizontal (+38 PCL units)
0000000098 PCL Control Code 0x0a <LF>: Line Feed
0000000099 PCL Parameterised <Esc>*c18a Rectangle Size Horizontal (18 PCL units)
0000000105 376b Rectangle Size Vertical (376 PCL units)
0000000109 0P Fill Rectangular Area: Solid Area
0000000111 PCL Control Code 0x0a <LF>: Line Feed
0000000112 PCL Parameterised <Esc>*p+38X Cursor Position Horizontal (+38 PCL units)
0000000119 PCL Control Code 0x0a <LF>: Line Feed
0000000120 PCL Parameterised <Esc>*p+38X Cursor Position Horizontal (+38 PCL units)
0000000127 PCL Parameterised <Esc>*p+38X Cursor Position Horizontal (+38 PCL units)
0000000134 PCL Control Code 0x0a <LF>: Line Feed
0000000135 PCL Parameterised <Esc>*c18a Rectangle Size Horizontal (18 PCL units)
0000000141 376b Rectangle Size Vertical (376 PCL units)
0000000145 0P Fill Rectangular Area: Solid Area
0000000147 PCL Control Code 0x0a <LF>: Line Feed
0000000148 PCL Parameterised <Esc>*p+38X Cursor Position Horizontal (+38 PCL units)
0000000155 PCL Control Code 0x0a <LF>: Line Feed
0000000156 PCL Parameterised <Esc>*c18a Rectangle Size Horizontal (18 PCL units)
0000000162 376b Rectangle Size Vertical (376 PCL units)
0000000166 0P Fill Rectangular Area: Solid Area
0000000168 PCL Control Code 0x0a <LF>: Line Feed
0000000169 PCL Parameterised <Esc>*p+38X Cursor Position Horizontal (+38 PCL units)
0000000176 PCL Control Code 0x0a <LF>: Line Feed
0000000177 PCL Simple <Esc>E Printer Reset
0000000179 PCL Control Code 0x0a <LF>: Line Feed- Thread starter
- #11
Thank you. I will review that file and see if I can figure it out. My immediate concern would be portability. By using the default font, I believe the printer automatically scales it for 300 or 600 dpi and rotates it for portrait or landscape. From your description, it does not sound like your suggestion does the same.
I also have no idea what the advantage would be. The way I did it uses 78 bytes, whereas the way you suggest is 175 bytes. I'm just too new to PCL to know best practices and what to avoid, but I'm always happy to learn new things.
Although FIM A is a fixed barcode, there are five different FIM barcodes, A through E. A FIM is basically 9 bits. The 9 positions of the barcode are either space or bar. All bars are identical.
The four character (ADFT) font you are thinking of is for the Intelligent Mail barcode (formerly known as the 4-State Customer Barcode) that replaced POSTNET and PLANET. I completed the IMb part before starting on FIM. I did review the USPS font, but it does not conform to the IMb specification as closely as I would like and is fairly bloated. For example, the specification shows Ascenders and Descenders as the same size (in inches), while in the sample font they are not. The specification shows a T:AD:F ratio of 1:2:3. Their font uses 15
29|30):44. So I created a new IMb font. Their font is 526 bytes in PCL, mine is 203 bytes and conforms to the IMb specification more closely. This allows more room for error in the printing process. Their font uses up much of that margin itself.
I also have no idea what the advantage would be. The way I did it uses 78 bytes, whereas the way you suggest is 175 bytes. I'm just too new to PCL to know best practices and what to avoid, but I'm always happy to learn new things.
Although FIM A is a fixed barcode, there are five different FIM barcodes, A through E. A FIM is basically 9 bits. The 9 positions of the barcode are either space or bar. All bars are identical.
The four character (ADFT) font you are thinking of is for the Intelligent Mail barcode (formerly known as the 4-State Customer Barcode) that replaced POSTNET and PLANET. I completed the IMb part before starting on FIM. I did review the USPS font, but it does not conform to the IMb specification as closely as I would like and is fairly bloated. For example, the specification shows Ascenders and Descenders as the same size (in inches), while in the sample font they are not. The specification shows a T:AD:F ratio of 1:2:3. Their font uses 15
29|30):44. So I created a new IMb font. Their font is 526 bytes in PCL, mine is 203 bytes and conforms to the IMb specification more closely. This allows more room for error in the printing process. Their font uses up much of that margin itself.- Thread starter
- #12
Thank you for that excellent analysis DansDadUK. Is the program you used to generate that listing publicly available?
Yes, perhaps I'm showing my age a bit. I still spend most of my day at a command prompt (DOS, Linux, Cisco, etc.) I never quite wrapped my head around code-pages or Unicode. I still think in ASCII.
I also found a nice list of PCL Symbol Sets at . 0L maps to PCL Line Draw-7 and appears to be part of the default PCL symbol set. Clicking on that listing gives a nice symbol list at which lists "$DD U258C Left half block" at the bottom of page 2.
Perhaps marking hexadecimal numbers with 0x is an old programmer convention, but I noticed that your Sequence column uses it and it is fairly well represented on Google:
Yes, perhaps I'm showing my age a bit. I still spend most of my day at a command prompt (DOS, Linux, Cisco, etc.) I never quite wrapped my head around code-pages or Unicode. I still think in ASCII.
I also found a nice list of PCL Symbol Sets at . 0L maps to PCL Line Draw-7 and appears to be part of the default PCL symbol set. Clicking on that listing gives a nice symbol list at which lists "$DD U258C Left half block" at the bottom of page 2.
Perhaps marking hexadecimal numbers with 0x is an old programmer convention, but I noticed that your Sequence column uses it and it is fairly well represented on Google:
Pascall666,
It is trivial to make a landscape version of these PCL codes. I can make one if you want. I chose to use 600 dpi so you could get closer to the fim spec.
Given the tight tolerances of the bar width in the fim spec, you have to be concerned about being able to accurately draw the bar, and that is further complicated by how the toner may spread through the fusing process. That is why I mentioned earlier about being able to get a trial scan to verify the barcode.
Jim Asman
It is trivial to make a landscape version of these PCL codes. I can make one if you want. I chose to use 600 dpi so you could get closer to the fim spec.
Given the tight tolerances of the bar width in the fim spec, you have to be concerned about being able to accurately draw the bar, and that is further complicated by how the toner may spread through the fusing process. That is why I mentioned earlier about being able to get a trial scan to verify the barcode.
Jim Asman
Note that in the sample file, the 0x0a linefeed characters are there for clarity but have no affect on the printing as the line spacing was set to 0. <esc>&l0C
Jim Asman
Jim Asman
@Pascal666:
>> ... Is the program you used to generate that listing publicly available? ...
The PRN File Analyse tool in the PCL Paraphernalia application, available via [URL unfurl="true"]http://www.pclparaphernalia.eu[/url]
>> ... 0L maps to PCL Line Draw-7 and appears to be part of the default PCL symbol set ...
As far as I'm aware, few (if any) modern LaserJet printers offer the 0L symbol set with any of the printer-resident unbound fonts.
The default symbol set used to be 8U (HP Roman-8); I'm not sure that this is still the case.
I always change the default on my printers to either symbol set 0N (ISO-8859-1 Latin-1), which maps exactly to the characters defined in plane 0, row 0 of the Unicode character set, or to symbol set 19U (Windows Latin-1 (CP1252)), which is a superset of 0N where the reserved C1 control-code range (0x80 -> 0x9F) are replaced by various graphic characters (such as the Euro sign).
But neither of these character sets contain much in the way of 'line draw' characters.
>> ... Is the program you used to generate that listing publicly available? ...
The PRN File Analyse tool in the PCL Paraphernalia application, available via [URL unfurl="true"]http://www.pclparaphernalia.eu[/url]
>> ... 0L maps to PCL Line Draw-7 and appears to be part of the default PCL symbol set ...
As far as I'm aware, few (if any) modern LaserJet printers offer the 0L symbol set with any of the printer-resident unbound fonts.
The default symbol set used to be 8U (HP Roman-8); I'm not sure that this is still the case.
I always change the default on my printers to either symbol set 0N (ISO-8859-1 Latin-1), which maps exactly to the characters defined in plane 0, row 0 of the Unicode character set, or to symbol set 19U (Windows Latin-1 (CP1252)), which is a superset of 0N where the reserved C1 control-code range (0x80 -> 0x9F) are replaced by various graphic characters (such as the Euro sign).
But neither of these character sets contain much in the way of 'line draw' characters.
- Status
Similar threads
- Locked
- Question
- Locked
- Question