command issue with new USPS Imb barcode

[petdun]

Am currently printing bills to a tractor feed printer (LaserMatrix LM2405/LM2406). I am using Red Hat Linux and am programming in COBOL. Prior to sending the file to the printer, a file is sent to the printer with all the commands like paper size, primary and secondary font plus a macro for the PostNet barcode which is changing to the new Imb barcode. I use the "shift-in, shift-out" to toggle between primary and secondary fonts. I am using pcl5 commands to call the macro for the old barcode and this has been working great. The new barcode is causing much greif. The code I am using was designed by someone else (which I have inherited) and I am rather new to pcl5.

The issue is that once the new barcode prints, it won't "turn off". The command I am using for the macro is"^[&f11Y^[&f0X^[(s24782T^[&f1X^[&f10X^O". The command that has been working with the PostNet barcode is:"^[&f11Y^[&f0X^[)15Y^[)s1p12.0v0s0b0T^[&f1X^[&f10X^O". If I change the left parenthesis on the first command to a right parenthesis the printing is correct on the entire document except the Imb barcode does not print. The Imb barcode font is on an print-jet that is attached on the network cable - don't know if this has anything to do with my issue.

Any suggestions would be greatly appreciated.

 

[DansDadUK]

I don't have time to check this now, but here are quick analyses of your sequences (I've assumed that ^[ is your editor's representation of the Escape (<Esc>) character (0x1b), and that ^O represents the Shift-in (<SI>) character (0x0f)).

<Esc>&f11Y        Macro Control ID (identifer = 11)
<Esc>&f0X         Macro Control: Start Macro Definition
<Esc>(s24782T     Primary Font: Typeface (identifier = 24782)
<Esc>&f1X         Macro Control: Stop Macro Definition
<Esc>&f10X        Macro Control: Make Macro Permanent
<SI>              Shift-in: selects Primary font

<Esc>&f11Y        Macro Control ID (identifer = 11)
<Esc>&f0X         Macro Control: Start Macro Definition
<Esc>)15Y         Secondary Font: Symbol Set (identifier = 15Y)
<Esc>)s1p         Secondary Font: Spacing: Proportional
       12.0v      Secondary Font: Height (12.0 points)
       0s         Secondary Font: Style (Upright, solid)
       0b         Secondary Font: Stroke Weight: Medium
       0T         Secondary Font: Typeface (identifier = 0)
<Esc>&f1X         Macro Control: Stop Macro Definition
<Esc>&f10X        Macro Control: Make Macro Permanent
<SI>              Shift-in: selects Primary font

<Esc>&f11Y        Macro Control ID (identifer = 11)
<Esc>&f0X         Macro Control: Start Macro Definition
<Esc>)s24782T     Secondary Font: Typeface (identifier = 24782)
<Esc>&f1X         Macro Control: Stop Macro Definition
<Esc>&f10X        Macro Control: Make Macro Permanent
<SI>              Shift-in: selects Primary font

 

[jlasman]

I don't see anywhere in the code shown where you actually "shift out" to the seconday font with ^N.

That would explain why you don't get the barcode when you declare the barcode to be the secondary font. And if you have declared it as the primary font, you would only ever get the barcode font. So without seeing the entire pcl code, for me it's hard to say.

Jim Asman

http://www.spectracolorservices.com

 

[petdun]

DandDadUK, yes the ^[ is the escape character. From your interpetation of the code I am in agreement.

jlasman, I see my error that trying to use the barcode as a secondary font that I did in fact not send the shift-out command. I will give this a try the next time I have access to the printer (next week) as I am stuck at a different facility today.

I guess the point I am missing is why when using the barcode as a primary font and calling it that it does not turn-off - I don't see the command I am missing. I am putting here the entire file that is sent to the printer before the print file so that all can see the entire code for clarity and this is with the barcode font as a primary font (I had to put in the ">>" and split the lines becaue it would not word-wrap correctly):

^[&l8D^[&l330A^[(8U^[(s0p12.00h10.0v0s0b3T >>
^[)0O^[)s0p10.00h12.0v0s0b104T >>
^[&f10Y^[&f0X^[)0O^[)s0p10.00h12.0v0s0b104T^[&f1X^[&f10X >>
^[&f11Y^[&f0X^[(s24782T^[&f1X^[&f10X^O

My translation:
^[&18D = set to 8 lines per inch
^[&l330A = sets paper size - this is a 6" x 4 1/2" postcard
^[(8U = Romans-8 font, primary font
^[(s0p = primary font, fixed spacing
10.00h = primary font, 10.00 character per inch
10.0v = primary font, 10.0 height in points
0s = primary font, font stype = upright, solid
0b = primary font, font wight = medium, book or text
3T = primary font. font family - courier
^[)0O = shift-out
^[)s0p = secondary font, fixed spacing
10.00h = secondary font, 10.00 characters per inch
12.0v = secondary font, 12.0 heidht in points
0s = secondary font, font stype = upright, solid
0b = secondary font, font weight = medium, book or text
104T = secondayr font, OCR-A font
^[&f10Y = start marcro, macro-id = 10
^[&f0X = start macro
^[)0O^[)s0p10.00h12.0v0s0b104T = use secondary font - listed in detail above
^[&f1X = stop macro
^[&f10X = make macro permanent (last ID specified - this should make it go back to primary font?)
^[&f11Y = start macro, macro-id = 11
^[&f0X = start marco
^[(s24782T = primary font, Imb barcode
^[&f1X = stop macro
^[&f10X = make macro permanent (last ID specified - this should make it go back to primary font. In between secondary font (OCR-A) and the calling of the macro the document prints several lines using the primary font.
^O = ? - this is in the code, don't know why but this has aways worked before when using the PostNet barcode, using the PostNet barcode as a secondary font. Here is the code that is in production for the PostNet barcode -(^[&f11Y^[&f0X^[)15Y^[)s1p12.0v0s0b0T^[&f1X^[&f10X^O.

Thanks for your help and looking at this, it is greatly appreciated.

 

[jlasman]

OK, just some theory.

First you define both the primary and secondary fonts. Then issue

^O to print text with primary text text text

^N change to secondary to print barcode barcode data

^O switch back to primary to print more text etc.

Now your ^[(s24782T is an incomplete font definition. It only identifies the typeface you want. It may work out that you get it, but the typeface has the lowest priority in font selection. So if the current font is fixed pitch, and the font associated with ^(s24782T is proportional, you will NOT get what you are after.

The spacing, point size, stroke weight, and posture ALL trump the typeface in font selection. So it is safest to always issue a complete font definition.

Dansdad will give you the official scoop.



Jim Asman

http://www.spectracolorservices.com

 

[DansDadUK]

I agree with Jim's analysis of the problem, the pertinent points being that you don't appear to use Shift-Out (0x0e) anywhere to select the secondary font, and that you are using a mix of full and partial font selection sequences.

The following link provides a brief history of the PCL language, and links to the PCL Technical Reference manual, and also to other PCL5 & PJL manuals:

http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=bpl04568

Be aware that some of the manuals (in PDF format) are multi-megabyte downloads.

Part 1 of the PCL5 Technical Reference Manual includes a chapter on font selection; useful reading.

Here's an analysis of your last code snippet:

<Esc>&l8D         Line Spacing (8 lines-per-inch)
<Esc>&l330A       Page Size (330 = unknown/illegal value)
<Esc>(8U          Primary Font: Symbol Set (identifier = 8U)
<Esc>(s0p         Primary Font: Spacing: Fixed
       12.00h     Primary Font: Pitch (12.00 characters per inch)
       10.0v      Primary Font: Height (10.0 points)
       0s         Primary Font: Style (Upright, solid)
       0b         Primary Font: Stroke Weight: Medium
       3T         Primary Font: Typeface (identifier = 3)
<Esc>)0O          Secondary Font: Symbol Set (identifier = 0O)
<Esc>)s0p         Secondary Font: Spacing: Fixed
       10.00h     Secondary Font: Pitch (10.00 characters per inch)
       12.0v      Secondary Font: Height (12.0 points)
       0s         Secondary Font: Style (Upright, solid)
       0b         Secondary Font: Stroke Weight: Medium
       104T       Secondary Font: Typeface (identifier = 104)
<Esc>&f10Y        Macro Control ID (identifer = 10)
<Esc>&f0X         Macro Control: Start Macro Definition
<Esc>)0O          Secondary Font: Symbol Set (identifier = 0O)
<Esc>)s0p         Secondary Font: Spacing: Fixed
       10.00h     Secondary Font: Pitch (10.00 characters per inch)
       12.0v      Secondary Font: Height (12.0 points)
       0s         Secondary Font: Style (Upright, solid)
       0b         Secondary Font: Stroke Weight: Medium
       104T       Secondary Font: Typeface (identifier = 104)
<Esc>&f1X         Macro Control: Stop Macro Definition
<Esc>&f10X        Macro Control: Make Macro Permanent
<Esc>&f11Y        Macro Control ID (identifer = 11)
<Esc>&f0X         Macro Control: Start Macro Definition
<Esc>(s24782T     Primary Font: Typeface (identifier = 24782)
<Esc>&f1X         Macro Control: Stop Macro Definition
<Esc>&f10X        Macro Control: Make Macro Permanent
<SI>

Several points:

- I'm not familiar with the page size identifier (330) you use (it may be relatively new, or a 'special' for a particular printer?).

- I'm not familiar with symbol set 0O (i.e. the sequences <Esc>(s0O)
But you refer to them as Shift-In, which is just the <SI> character (0x0f), or (in 'vi' parlance) ^O - the preceding ^[) characters (representing <Esc> and the ")" character) may be something that you have inadvertently added?

If you ARE sending <Esc>[)0O to the printer, this may well affect font selection, since (as Jim has pointed out) the symbol set is the highest-priority characteristic in a set of font selection sequences.

 

[DansDadUK]

... and, of course, if this set of 'initialisation sequences' is "... sent to the printer before the print file ...", this presupposes that the 'print file' contains some PCL5 escape sequences to select/call/execute the macros, and <SI> and <SO> characters to switch between the primary and secondary fonts at pertinent points.

To really see what is going on, we'd need to see a 'capture' of the whole print stream (initialisation sequences + 'print file') output by your spooler/driver.

On Windows systems, this would be done by using the 'print to file' option in the Print dialogue.
I've no idea what the *n*x equivalent of this is; it certainly wasn't that easy when I last worked on unix (SVR4) systems - I think we had to modify the model script to add in a 'tee', or something like that.

 

[DansDadUK]

This link provides some advice on setting up CUPS to print-to-file (but it takes some wading through, like most *n*x help stuff, and it's geared towards MacOSX).

 

[petdun]

Thank you both for your input. When a print line is sent out to use the secondary font (OCR-A) imbedded in the print line is the shift-out, shift-in. The print line definition is:
01 st-line2.
05 filler pic x(25) value spaces.
05 sl2-curr-swr-amt pic $$$$,$$$.99- blank when zero.
05 filler picture x(05) value spaces.
05 sl2-doc-seq pic zzzzz.
05 filler pic x(4) value spaces.
05 filler pic x value x"0E".
05 sl2-scan-line.
10 filler pic x(2).
10 sl2-scan-district pic x.
10 sl2-scan-bill-id pic x(12).
10 sl2-scan-amt pic 9(6)v99.
10 sl2-scan-cr pic x(01).
10 filler pic x(06).
05 sl2-scan-check-line redefines sl2-scan-line.
10 filler pic x(2).
10 sl2-scan-digit pic 9 occurs 21 times.
10 sl2-scan-check pic 9.
10 filler pic x(06).
05 filler pic x value x"0F".
05 filler pic x(02).

The print line definition for the barcode which calls the macro for the barcode also has the shift-out/shift-in embedding is:
01 st-line13.
05 filler pic x(16) value space.
05 sl13-due-date pic xx/xx/xx.
05 filler pic x(10).
05 filler pic x value x"1B".
05 filler pic x(7) value "&f11y2X".
05 filler pic x value x"0E".
05 sl13-delivery-point-bar-code pic x(31).
05 filler pic x value x"0F".
05 filler pic x value x"1B".
05 filler pic x(7) value "&f10y2X".

On the page size (330), I am lost on this also and cannot find any paper size definition for this. All I know is that it works for the post card size forms that are being printed and they yave been printing on these printers this same form for more than 12 years.

jlasman - I do not know if the barcode is fixed pitch or not but i will treat it as if it were and go from there. I have stated before that this font is on a print-jet that is hooked-up to the incoming data line to the printer. The documentation that the print-jet company supplied says that all you have to do is put the "(s24782T" before the delivery-point-bar-code and it will print, which it does.

I will add the required code to make the font definition complete and see what happens.

DansDadUK - on the ")0O" I was wrong thinking that this was the shift-out - it is not. Shift-out/shift-in are handled on the actual print line. Where the "0O" came from I do not know and I have not found this symbol set in any documentation. All that I do know is that this has been working for a long time.

Thanks for the link to the hp pcl 5 documentation. I have been using some of the hp pcl 5 documentaion that is available. And thanks again for responding to my posts.

 

[petdun]

I did find the "0O" symbol set in document bpl13205.pdf which specifies this as the OCR-A font symbol set. I have been referencing documents bpl13205.pfd, pcl5comp.pdf and blp13210.pdf in my efforts to get this to print correcty.

On the incomplete font definition, I have changed the code to "^[s0p12.00h.0v0s0b^[(s24782T" so this should now be complete. I will post when I print this again - some time this week.

 

[DansDadUK]

It's been years since I've used COBOL, but from your snippets, the bar-code part is printed using something like:

<Esc>&f11y        Macro Control ID (identifer = 11)
       2X         Macro Control: Execute Macro
<SO>              Shift-Out selects Secondary font
... data ...      sl13-delivery-point-bar-code  pic x(31)
<SI>              Shift-In selects Primary font
<Esc>&f10y        Macro Control ID (identifer = 10)
       2X         Macro Control: Execute Macro

If you are only using the two fonts, you shouldn't need to keep executing the two macros - the Shift-In and Shift-Out control-code characters should be sufficient once you've executed each macro once; but if (as it perhaps appears from stitching together your various snippets) you select other fonts elsewhere, you will need to keep this mechanism.

... and you've also got <SI> and <SO> control codes surrounding your "scan line".

[As an aside: it would be much easier to see what is going on (all in one place) if you could capture the equivalent of a Windows driver 'print-to-file' output; surely *n*x systems should have some sort of 'one-click' mechanism to do this, rather than editing model scripts, or using "socket capture" intercept mechanisms?]


>> ... all you have to do is put the "(s24782T" before the delivery-point-bar-code and it will print, which it does ...

As Jim has already indicated, it WILL work if the bar-code font has the same "Spacing" characteristic (Fixed-Pitch or Proportionally-Spaced) as the currently-selected font; otherwise, it almost certainly won't.


>> ... on the ")0O" ...

When I said in a previous post that "... I'm not familiar with Symbol Set 0O ...", this is because it's not associated with any of the standard 'printer-resident' fonts available on most LaserJet printers.

It IS defined in the HP "PCL5 Comparison Guide" manual as "OCR-A".
Use of this symbol set implies that you have a font available with this symbol set (either on add-on hardware such as cartridge or DIMM, or as a downloaded soft font).

 

[DansDadUK]

It seems that you sent your last post as I was composing mine.

Your updated font-selection sequence is incorrect in several respects:

(a) The first part is missing the "(" character (which is part of the sequence 'root').

(b) I don't think it wise to select a point-size of ".0" (I'm not even sure it's valid), even if the font you are selecting is Fixed-Pitch Scalable (so doesn't need a point size characteristic).

(c) The "0b" should be "0B" as it is the last component of a combination sequence; or (as the two sequences have the same root), you could combine them as per below:

^[(s0p12.00h0s0b24782T

which interprets as:

<Esc>(s0p         Primary Font: Spacing: Fixed
       12.00h     Primary Font: Pitch (12.00 characters per inch)
       0s         Primary Font: Style (Upright, solid)
       0b         Primary Font: Stroke Weight: Medium
       24782T     Primary Font: Typeface (identifier = 24782)

 

[DansDadUK]

... and it is still not a 'complete' font-selection sequence, as it doesn't include the Symbol Set selection sequence, which is the highest-priority characteristic.

 

[jlasman]

Does your UNIX box write the output to a spool file before it goes to the printer?

If so, take the printer offline, "print" the job, and then grab a copy of the PCL code from the spool file. Also, what does the 'lp' command look like?


Jim Asman

http://www.spectracolorservices.com

 

[petdun]

DansDadUK - I called the company that manufactured the barcode printer jet and they have told me that there is no sybmol set for this barcode. I have been researching this on the the USPS (United States Postal Service) website as well and cannot find anything about a symbol set for this goofy font.

If I were using two fonts instead of three this would be easier but I need Romans-8, OCR-A and this new barcode and that is why I was trying to only change the one macro for this new barcode. I still cannot get the macro to work but below I explain my current solution.

Jlasman - yes the file goes out to spool which is from where we print the document. Our system has a proprietary spool file manager so the "lp" command is a bit different. The command is "p jn='999' form=10Xbill via=printer-name". Translated this means print job-number '999', use form 10Xbill for all formattiong and use printer 'xxx'. The 10Xbill is the code I presented on 5/11/12 at 10:37 - as I understand the way this spooler system was written is so that this file gets sent to the printer before the spooled print file is sent to the printer. The shift-out and shift-in toggle between the Romans-8 and OCR-A fonts. The macro called the PostNet barcode.

After digesting all of the comments I decided that I would go about this a different way and see if I could get it to work. Instead of using the form (10Xbill) with the macro, I changes the print line definitions in the COBOL program. That is the first line sent carries the lines/inch, page size and the default (Romans-8) font. Then when I need the OCR-A font I put the font commands in that print line. The line after the OCR-A font line goes back to Romans-8 so I send that command at the beginning of that print line for Romans-8 without the page size and lines/inch. When the Intelligent barcode line comes along, again I put the command in the line definition rather than call the macro.

I am testing on a different printer with this change and I am able to turn-off and turn-on the barcode and get the other fonts to work correctly. The print line definitions look rather ugly but it is working and with notes/comments in the program the next person should have an easier job trying to figure this out. Doing it this way will eliminate the need for the "forms = 10Xbill" command and I can change the "way" this is called by using jcl code to make the a straight forward "lp" command. Fingers crossed for the final testing.

I want to thank you all for your help on this. You helped me to better understand pcl. Your definitions of the code showed me what I was missing and some errors. With that I "played" with the code until I got the fonts to print correctly.

I will be testing on the production printer in the next couple of days and will leave a post as to how this went.

PS: Has anyone else had a problem with loggin in? I kept having an issue with McAfee stating that this site had malicious code and wouldn't let me in. Late in the day today I was finally able to log in without problems.

 

[DansDadUK]

>> ... they have told me that there is no sybmol set for this barcode ...

ALL PCL5 fonts are selected using a set of characteristics, the highest priority one being the symbol set.

... and ALL PCL5 fonts are either 'bound' to a fixed symbol set (defined in the header of the font, for soft fonts), or are 'unbound', which means that they can be used with one or more (pre-defined) symbol sets which match the 'character complement' defined within the font header.

An add-on bar-code font is probably unlikely to be unbound, it is much more likely that it is a 'bound' font.

 

[petdun]

Just an update. I installed the barcode printer jet to a newer HP laser printer so that I had access to the barcode font. Printing on the newer printer I was still having the same issues so I looked into the actual print file in hex and found that in many areas a hex null (x'00') was getting put into the file for some unknown reason.

If I removed the hex null values from the file, the file would print out correctly with the new barcode and would continue printing perfectly. It took me a while to find out that our screen-handler system has a run-time parameter to insert a hex null before any non-printable ascii character so I was able to find out where these hex null values were coming from. Before every escape sequence "1B" it would add the hex null value.

I just got done testing this on the older form-feed printer and it did not work. Now it will not print the barcode, but it does reset and print the next bill correctly (corrent fonts and font sizes) until the barcode. So one problem is solved but another new one appeared.

At this point of time I am pretty much convinced that the form-feed printer is just to old and can't handle all the pcl5 commands that it's documentation claims.

 

[DansDadUK]

I don't know why the <NUL> (0x00) bytes you refer to should affect your output, as they should just be ignored by the printer.

Where they would have an effect is if they were part of 'PCL Binary' sequences (e.g. raster image, or soft font download, or transparent print data) - but (from what we can glean from your partial snippets) this does not appear to be the case.

If you'd been able to supply a sample 'print stream capture' file for analysis, it would have highlighted the <NUL> bytes (not that they appear to be relevant on the information we do have) and perhaps other problems/inconsistencies.