penguins_rule
asked on
USPS intelligent mail barcode font
This is a continuation of my question http://www.experts-exchang e.com/ques tions/2868 7949/USPS- imb-barcod e-for-HP-l aser-print er-on-linu x-needed.h tml
I tried to print the example uspsFontsNonAFP-1.40.0\prf iles\hp\in put-US23HP .pcl on a HP laserjet 4100 and also a HP 1320n. Both of them seem to receive the file (the lcd screen says processing) but nothing prints.
I am running Redhat Enterprise Linux 6.4, and using raw mode on the printer.
I need to be able to use the embedded font to create a pcl file on disk.
I tried to print the example uspsFontsNonAFP-1.40.0\prf
I am running Redhat Enterprise Linux 6.4, and using raw mode on the printer.
I need to be able to use the embedded font to create a pcl file on disk.
As I noted in one of my replies to the other question you referenced, the .pcl file contains:
But I don't think that either of these would explain why "nothing prints", especially as on your LJ 1320n nothing prints, whilst my LJ 1320n printer prints ASCII text and a USPS bar-code as shown in my previous post.
So I suspect that the problem is something to do with how you "print the example".
All I've done is effectively copy (in binary mode) the content of the referenced file direct to the printer port.
In *n*x terms, I suppose that this would be a cat of the file to the /dev/xxxx device (if that is allowed?).
I also suspect that the <NUL> bytes might cause a problem in the *n*x world.
At least one invalid PCL escape sequence (which will theoretically just be ignored by the printer).
A block of <NUL> (hexadecimal 00) bytes; these will also theoretically be ignored by the printer.
But I don't think that either of these would explain why "nothing prints", especially as on your LJ 1320n nothing prints, whilst my LJ 1320n printer prints ASCII text and a USPS bar-code as shown in my previous post.
So I suspect that the problem is something to do with how you "print the example".
All I've done is effectively copy (in binary mode) the content of the referenced file direct to the printer port.
In *n*x terms, I suppose that this would be a cat of the file to the /dev/xxxx device (if that is allowed?).
I also suspect that the <NUL> bytes might cause a problem in the *n*x world.
Nothing to do with your question, but (for completeness) the difference in text size of the output on LJ 1320n and LJ M475dn printers is because :
Hence the pitch selected is that set as default on the target device - this has obviously been set differently on my two printers.
The font selection sequence specifies that a fixed-pitch (rather than proportionally-spaced) font is required.
Specifies a font height value - this is ignored for a fixed-pitch font.
Does not specify a font pitch value - if one were present, it would influence the scalable size of the selected fixed-pitch font.
Hence the pitch selected is that set as default on the target device - this has obviously been set differently on my two printers.
>> ... I need to be able to use the embedded font to create a pcl file on disk ...
I don't really know what you are asking here: the fonts (albeit of a 'deprecated' format) are already within font files, and within the print-ready sample files.
I don't really know what you are asking here: the fonts (albeit of a 'deprecated' format) are already within font files, and within the print-ready sample files.
ASKER
my laser printers are on the network. I do not know how to write directly to them.
I tried to use PuTTY to do pass through printing to a third printer which can do PCL5. It successfully printed the barcode, but the first line is
Inc. nnnnnnnn (a lot of n's)
I tried to use PuTTY to do pass through printing to a third printer which can do PCL5. It successfully printed the barcode, but the first line is
Inc. nnnnnnnn (a lot of n's)
I've no knowledge of PuTTY (from the name, presumably some archaic interface originally intended for use with TeleTypewriters - I worked with them, connected to a mainframe, in the early 1970s!).
On a Windows system, I'd use 'lpr' to write to port 515 on the printer (I think *n*x lpr diverts via scheduler and script though, so would probably modify/corrupt the raw data).
Or use TCP 'socket' mechanism to write to port 9100.
No idea why you got 'nnnn' on your other printer - not in the data (the first line contains "0304008345307400406716101 936856", as shown in my scan above), so again implies some modification/corruption of the raw data.
On a Windows system, I'd use 'lpr' to write to port 515 on the printer (I think *n*x lpr diverts via scheduler and script though, so would probably modify/corrupt the raw data).
Or use TCP 'socket' mechanism to write to port 9100.
No idea why you got 'nnnn' on your other printer - not in the data (the first line contains "0304008345307400406716101
As I see it, the question to be asked is essentially:
How do I send the content of a binary file (containing printer-ready data and print control sequences) direct to a (suitable) printer, from a *n*x (specifically Redhat Enterprise Linux 6.4) environment, without the content of the file being modified or added to?
How do I send the content of a binary file (containing printer-ready data and print control sequences) direct to a (suitable) printer, from a *n*x (specifically Redhat Enterprise Linux 6.4) environment, without the content of the file being modified or added to?
ASKER
i have other files containing HP Pcl code printing with no problems. This is the first time i am trying to send a soft font.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
... and attached is another analysis (showing the 0x00 bytes) of the input-US23HP.pcl file; it is more verbose than the analysis provided in the other question thread.
input-US23HP.pcl_analysis_verbose.txt
input-US23HP.pcl_analysis_verbose.txt
I also sent the content to a LaserJet Pro 400 Colour MFP M475dn printer, and what was printed was very similar, albeit with the ASCII text portion at a slightly smaller size (possibly because the font selection specifies typeface = 3, which does not match exactly any resident font on either printer, so font substitution comes into play).