Failure loading soft font from printer hard disk into printer ram, for use within PCL print job

[dansdaduk]

The PageWide Enterprise 556xh printer contains a hard disk which can be used for various functions; for example:

• Temporary storage of 'personal job' print jobs (for release by user at printer control panel).
• Permanent (non-volatile) storage of PCL macros.
• Permanent (non-volatile) storage of PCL fonts.

I've successfully tested the first two of these functions, but cannot get the third one (loading a soft font stored on the printer hard disk into printer ram for use within a PCL print job) to work.

The available documentation (which is admittedly rather sparse) is published within the following HP documents:

• PJL Technical Reference manual (ref bpl13208); this describes the various PJL File system commands, including the FSMKDIR and FSDOWNLOAD commands required to create the target directory, and download the soft font definition to the hard disk. 
• PCL Technical Reference Part 1 manual (ref bpl13210); this describes the standard PCL escape sequences, including those required to handle/manipulate macros and soft fonts within printer RAM.
• PCL5 Comparison Guide manual (ref bpl13206); this describes additional PCL escape sequences , including the (multi-purpose) 'Alphanumeric Id' sequence, which can be used to associate a soft font file on the hard disk with a numeric identifier used with the standard PCL soft font commands.   

[dansdaduk]

Tests etc.

• Create printer hard disk folders, using the PJL FSMKDIR commands; analysis of sample job:

  <Esc>%-12345X     Universal Exit Language (UEL)
  @PJL FSMKDIR NAME="0:\pcl"[0d][0a]
  @PJL FSMKDIR NAME="0:\pcl\fonts"[0d][0a]
  <Esc>%-12345X     Universal Exit Language (UEL)

• Download of sample PCL (format 20 resolution-specified bitmap) font; analysis of sample job:

  <Esc>%-12345X     Universal Exit Language (UEL)
  @PJL FSDOWNLOAD FORMAT:BINARY SIZE=5390 NAME="0:\pcl\fonts\SFPeg02"[0d][0a]
  <Esc>)s68W        Download Font Header (data length = 68)
  [ 68 bytes ]      
  <Esc>*c065E       Character Code (code-point = 065 (0x41))
  <Esc>(s592W       Download Character (data length = 592)
  [ 592 bytes ]     
  <Esc>*c066E       Character Code (code-point = 066 (0x42))
  . . .
  . . .
  <Esc>*c101E       Character Code (code-point = 101 (0x65))
  <Esc>(s387W       Download Character (data length = 387)
  [ 387 bytes ]     
  <Esc>%-12345X     Universal Exit Language (UEL)

• Printing the File Directory Page via the printer menu system shows that the directories and font file exist; note that the PJL logical disk ("0:") is relative to the "\PDL" folder on the "User data" storage area of the disk.

• Use of PJL status readback tools confirms that the folders and soft font file exist; upload of the font file (via FSUPLOAD) back to the host workstation yields a file which is identical to the original file downloaded, confirming that no corruption or unwanted encryption has taken place.

• Sending a test PCL print job to the device which (theoretically ) should associate the stored soft font file with a PCL soft font identifier, and enable seldction of the font within the job; analysis of a 'capture' of that test job shows the relevant sequences:

  . . .
  <Esc>*c52D        Assign Font ID Number (identifier = 52)
  <Esc>&n8W         Alphanumeric ID (data length = 8)
  [ 8 bytes ]       Alphanumeric ID data
                    [ 01 53 46 50 65 67 30 32 ]
                    Operation Code = 1 (0x01 = <SOH>): Associate current Font ID with String ID
                    String ID      = SFPeg02
  <Esc>(52X         Primary Font: Select by ID (identifier = 52)
  <Esc>*p2400x      Cursor Position Horizontal (2400 PCL units)
         900Y       Cursor Position Vertical   (900 PCL units)
  ABCDE abcde
  . . .

  But the "ABCDED abcde" data is printed using the previously selected font, not the soft font, implying that the load/associate operation has failed in some way.

• Sending a different test PCL print job to the device which downloads the original soft font to printer ram and associates it with a named alphanumeric identifier, then associate this with a PCL soft font identifier, and uses it shows that the soft font definition is valid,and that (theoretically) the 'asscoiuate' mechanism  is valid; analysis of a 'capture' of that test job shows the relevant sequences:

  <Esc>%-12345X     Universal Exit Language (UEL)
  @PJL Enter         Language = PCL[0d][0a]
  <Esc>E            Printer Reset
  <Esc>&n8W         Alphanumeric ID (data length = 8)
  [ 8 bytes ]       Alphanumeric ID data
                    Operation Code = 0 (0x00 = <NUL>): Set current Font ID to String ID
                    String ID      = SFPeg02
  <Esc>)s68W        Download Font Header (data length = 68)
  [ 68 bytes ]      
  <Esc>*c065E       Character Code (code-point = 065 (0x41))
  <Esc>(s592W       Download Character (data length = 592)
  [ 592 bytes ]     
  . . .
  . . .
  <Esc>*c101E       Character Code (code-point = 101 (0x65))
  <Esc>(s387W       Download Character (data length = 387)
  [ 387 bytes ]     
  <Esc>&u600D       Unit-of-Measure (600 PCL units per inch)
  . . .
  . . .
  <Esc>*c62D        Assign Font ID Number (identifier = 62)
  <Esc>&n8W         Alphanumeric ID (data length = 8)
  [ 8 bytes ]       Alphanumeric ID data
                    Operation Code = 1 (0x01 = <SOH>): Associate current Font ID with String ID
                    String ID      = SFPeg02
  <Esc>(62X         Primary Font: Select by ID (identifier = 62)
  <Esc>*p2400x      Cursor Position Horizontal (2400 PCL units)
         900Y       Cursor Position Vertical   (900 PCL units)
  ABCDE abcde
  . . .

  In this case, the "ABCDE abcde" data is printed using the downloaded soft font.

Copies of the various test files referenced above, and their analyses, are provided within the attached .zip file.

[dansdaduk]

Any ideas as to how to proceed?

Perhaps this printer does not expect the downloaded soft fonts to be held in the (logical) folder "0:\pcl\fonts"?

The official documention does not explicitly mention this folder, although other widely available documents do refer to it.

Some of these other documents refer to use instead of the (logical) folder "0:\fonts" - I've set up similar tests using this folder name, but with no more success.

... and tests making use of PCL macros stored on the hard disk, and loaded into ram using a similar mechanism, have the macros loaded into the (logical) folder "0:\pcl\macros" - and these tests work as expected.

As an aside, there are a number of fonts (Andale Mono, and various bar-code and OCR fonts) which a "PCL Font List" report from the printer shows as "Disk Resident Fonts" - I think that these were added via firmware upgrades - they're certainly not in any folders accessible to the PJL File System commands.

... and they don't have alphanumeric or numeric identifiers - what they do each have is the required PCL font selection sequence skeleton - perhaps they are stored somewhere with the equivalent of a pclResourceFile definition?

[dansdaduk]

I've tried a different approach, and used Web JetAdmin 10.4.101899 (10.4 SR2), on a Windows 10 Pro 64-bit (v 1607) workstation, to try to install and test (PCL5) fonts and macros  on the target PageWide Enterprise 556xh printer.

But with rather mixed results, and several crashes/reboots of the printer!

I'll document this in detail, in a separate question, in the next few days, but briefly:

• WJA accepted two simple PCL5 macros, held in .ovl files,  into the "repository".

• WJA accepted two simple PCL5 soft fonts of format 20 (resolution-specified bitmap), held in .sfp files, into its repository.

• WJA does not recognise a PCL5 soft font of format 16 (Universal), containing a PCLETTO format soft font and held in a .sft file, so it cannot be placed in the repository - I know that the soft font definition in this source file is valid.

• WJA was used to 'install' the two macros and the two accepted fonts.

• The install process added the macros in the \pcl\macros folder (created by the install process) on the printer's (logical) hard disk volume 0:, with the same names as the original source files.

• A file pclResoureFile is also created in this latter folder; it contains (coded) details of the macro names, with default identifiers, and of the installed fonts, with what looks like a coded represention of the Kind1 attributes of each font.

• Additional files (again with the same names as the original macro source files) were created in the \pcl\macros_info folder (created by the install process); these files appear to contain brief details of the relevant macro, with what is perhaps a 256-byte key value.

• A file pclResoureFile is also created in this latter folder ;it contains some brief descriptive text "pclRsourceFile - Resource Selection Criteria Association File downloader=HP Resource Manager" and what may be a 192-byte key value (but all zeros).

• The install process added the fonts in the \fonts folder (created by the install process) on the printer's (logical) hard disk volume 0:, with the same names as the original source files (although different sizes).

• Additional files (again with the same names as the original font source files) were created in the \fonts_info folder (created by the install process); these files appear to contain brief details of the relevant font, with what is perhaps a 256-byte key value.

• Attempts to use WJA to (test) Print one of the installed macros resulted in a page being printed, giving the name of the macro (but describing  it as "HP DSM Plug-In Font Test", but the macro itself was not printed!

• Attempts to use WJA to (test) Print one of the installed fonts resulted in error 49.4A.0A being reported on the printer, which then had to be rebooted to recover.

• Used a separate tool (Status Readback in PCL Paraphernalia), which uses the PJL FSUPLOAD command, to retrieve the files created, by WJA, on the printer's hard disk (which is how i was able to provide some of the details above).

• I could retrieve all of the  files created by WJA on the printer hard disk, except the font files created in the \fonts folder; any attempt to do so resulted in error 49.38.07 being reported on the printer, which then had to be rebooted to recover.

• So I  can't tell just what is in those 'installed' font files, or why they have different sizes to the original source files.

[dansdaduk]

Attached is a .zip file containing the various test files used in the tests described in my previous post about Web JetAdmin adding mass storage objects to the PageWide Enterprise 556xh printer.

Very briefly:

• Folder Object_src contains (within sub-folders Fonts and Macros) the original PCL5-format fonts and macros, together with some analyses. 

• Folder Object_prints contains PCL5 printer jobs (with analyses) which demonstrate use of the fonts and macros when downloaded into printer RAM (i.e.not using the printer hard disk); the jobs were generated using the Font Sample and Form Sample tools in the PCL Paraphernalia application (and the analyses created using the PRN File Analyse tool). 

• Folder Scans contains .jpg scans of the printouts produced by those jobs on the PageWide Enterprise 556xh printer.

• Folder Retrievals contains (within sub-folders) the contents of the various files created by the Web Jet Admin application on the printer hard disk, as retrieved using the Status Readback tool in PCL Paraphernalia; the tool could not retrieve the font files (the printer crashed with error 49.38.07 being reported).

• The sub-folder SaveFromRepository contains (within sub-folders Fonts and Macros) 'save to file' of the objects in the repository - these are essentially the PJL jobs generated by Web JetAdmin to create the files on the printer hard disk.

Analysis of the 'savefromrepository' font objects shows what WJA sent to the printer to install the fonts on the hard disk; this shows that:

• The font files are created on the hard disk in the \fonts folder (not the \pcl\fonts folder).

• The downloaded binary content of these files is quite different to the original source PCL5-format font files.

• The font header is very different, and appears to contain values which could be construed as offset values to 10-byte 'headers' Introducing the 'raster character data' describing the individual characters (this raster data appears to match that in the original fonts).

• These 10-byte headers appear to have replaced the 'character code' and 'download character data' PCL5 escape sequences, and the 'character data block header' and 'character descriptor' fields from the original PCL5 bitmap font character definitions. 

Given that the fonts are stored in the he \fonts folder, rather than the \pcl\fonts folder, and the file contents are not the same as the original font definitions, perhaps this suggests that the font definitions are intended for use by both PCL5 and PCL XL personalities (the font formats of these two Page Description Languages are quite similar, except for headers).

if so, this would imply that some other mechanism should come into play to convert these 'universal' definitions into the PCL5 or PCL XL formats (as appropriate to the current personality); if so:

• It doesn't appear to work with PCL5 (given the publicly-available documention on the PCL5 mechanism).

• It doesn't explain why WebJetAdmin itself, when requested to 'test' the fonts it downloaded, causes the printer to crash with error 49.4A.0A being reported on the printer. 

I realise that PCL5 is 'on the way out' (e.g. no PCL5 variant of the Universal Printer Driver with Windows 10), but printers still support this PDL (and will presumably continue to do so for some time, given the large number of third-party applications which still make use of it).

Given that his modern printer (and Web JetAdmin) don't appear to follow the original published descriptions regarding stored hard disk fonts, is there any available documentation which attempts to explain how to use the current 'mass storage' mechanism?

... and are the 49.xx.xx errors mentioned above due to bugs in the PageWide Enterprise 556xh firmware, or bugs in Web JetAdmin (or a combination of the two)?

[Hugh_Hood]

dansdaduk,

Nice work trying to document exactly how PJL handles these resources on the hard drive/simm/flash storage device.

I agree -- this information is hard to glean from the 'net. I've been finding bits and pieces of it in a few places.

As for fonts, it seems they should be stored in \fonts rather than \pcl\fonts.

I might suggest you repeat your Alphanumeric ID selection test after you have manually  stored your Type 16 .sft file to the \fonts folder. I have been using Type 15 fonts, but I don't see why the Universal Type 16 shouldn't work as well.

Thanks for detailing exactly what WebJetAdmin is doing these days. I almost think that it is doing things differently from how it used to do things.

Finally, it appears that the file 'pclResourceFile' should be present in the \pcl\macros folder, and it provides shortcuts to font and macro selection. I've only found documentation for it in a few places. This might be helpful, and is from the HP Document:

"HP LaserJet printers—CompactFlash® replaces flash/ROM
DIMMs in future HP LaserJet printers"

Appendix A – PCL resource file

A resource file is necessary in order to select disk-based fonts using the select-by-attribute feature of
PCL 5. The file must be a plain text file consisting of only ASCII characters. The file is line oriented,
meaning each line is self contained. Each line contains a series of tokens, with one or more of either
the space character (ASCII 32) or the horizontal tab character (ASCII 19) separating the tokens. A
line ends with the newline character(s). In the following description tokens are surrounded by angle
brackets (<>).

The first token on the line is a two-character number designating the selection type. There are three
selection types:

00 – Comment
All characters on a line beginning with the comment selection type are ignored. A comment may not
include any of the newline characters.

01 – Select macro by ID
This selection type is used to designate a macro ID number for a macro stored in a particular file. The
selection type is followed by two values:
<MacroID> ::= One or more of { 0 | .. | 9 }
<FileName> ::= File name string. Does not include the drive or the path.

02 – Select font by ID or attribute
This selection type is used to designate the font ID and the font attributes used to select a font stored in
a particular file. The information following the selection type token is formatted as follows:
<FontID> [<SymbolSet> <Style> <StrokeWeight> <Typeface>] <FileName>
All or none of the font attribute tokens must be present (shown above in between square brackets).
That is, if the <SymbolSet> value is omitted, so must be the <Style>, <StrokeWeight> and <Typeface>
tokens. These values contain all the information necessary for the PCL personality to select the font by
attribute. The information is encoded as a series of ASCII hex encoded values and is always exactly
14 characters long.

<FontID> ::= One or more of { 0 | .. | 9 }

<SymbolSet> ::= Two bytes in hexadecimal: 0000 | ... | FFFF

<Style> ::= Two bytes in hexadecimal: 0000 | ... | FFFF

<StrokeWeight> ::= One bytes in two’s compliment hexadecimal: 00 | … | FF (two’s compliment
notation must be used by the stroke weight is a signed quantity)

<Typeface> ::= Two bytes in hexadecimal: 0000 | ... | FFFF

<FileName> ::= File name string. Does not include the drive or the path.

Example
00 The following entry is for a macro
01 109 my_macro

00 The following entry is for a font
02 102 000000600020F3 my_font

--------------------------------------------------------------------------------------------------------

FWIW, I've been involved in a similar issue with GhostPCL. Here is the discussion:

Alphanumeric ID Command and GhostPCL

Again, thanks for your work. Please keep us posted and let's try (finally) to document this stuff and not have to rely on the black magic of WebJetAdmin.

[dansdaduk]

Hugh

Thanks for your input - the only response I've had!

The first few things I'd like to know answers to are:

• Am I doing it right - i.e. am I interpreting the (admittedly old) PCL and PJL documentation correctly, or not?
• If I am, it doesn't appear to work, so is this a bug in the printer firmware (perhaps affecting lots of models?), or is that the mechanism has changed, and no-one has bothered to document the new mechanism (at least, outside of HP)?
• Why does Web JetAdmin download a modified version of the original fonts (note that it only 'reads' .sfp or real .ttf fonts - so some sort of internal conversion is involved), and why does it crash the printer when attempting to test what it has just downloaded?

I don't want to use hard disk fonts in anger - I'm retired now (approaching 70), and just trying out various (admittedly rather obscure) mechanisms (so that I can possibly help others).

In some of my previous tests, I did manually store test a .sft font in both the 0:\pcl\fonts and the 0:\fonts folders - but neither appeared to be recognised (although the  font was recognised if just downloaded directly into RAM).

I realise that PCL5 is "on the way out" (as perhaps indicated by the lack of a PCL5 variant of the Universal Printer Driver from Windows 10 onwards), so this is perhaps why there has been little response, but I'd guess that there are still a lot of third-party software solutions which make use of PCL5.

... and what is the point of downloading fonts via Web JetAdmin if there is no documented method of using them?

... and I can't see how PCL6 (PCL XL) would make use of the fonts (even those downloaded via Web JetAdmin) unless it is just on the font name (which is how printer-resident fonts are normally selected in PCL XL - perhaps it would pick up on those stored in the 0:\fonts folder?). 

Of course, testing things out with PCL XL is rather more difficult, due to its binary structure, so that takes much more time to organise. 

I've previously seen the document regarding pclResourceFile, but don't yet see quite how relevant it is.

I'll have to look in detail at your GhostPCL thread when I get more time (hopefully in the coming week) - thanks for referencing this.

Chris

[dansdaduk]

Hugh

I've looked at the GhostPCL 'bug' that you've raised; I have a few questions:

• I'm not quite sure from the description whether or not you've successfully loaded a disk-resident font on a real LaserJet printer using the standard documented 'association' mechanism (if so, which model), or only managed to do it using your (rather clever) 'within a macro' circumvention. 

• As regards pclResourceFile font entries: as far as I can see, what this would do (if it works) is to allow the referenced font to be selected via (Kind) PCL font selection attributes (symbol set, weight, style, size, typeface, etc.) - what if these attributes don't match what is in the font header? - and this is anyway different to 'associating'  the file with a PCL font identifier.

• I'm not sure what you mean by your reference to "... the AlphaNumeric ID command is fully supported (except fort the '52' pclResourceFile function) ..."; are you implying that the Alphanumeric ID sequence supports an (undocumented) value of decimal 52 ("4") or hexadecimal '0x52' ("R")? If so, do you have a link to further details?

[Hugh_Hood]

Chris,

I'll get you a more detailed answer on the first point and second points when I have a little time, so I ask for you to bear with me on those.

On the third point, however, I've seen the '52' referenced in a couple of places on the web. Here is a link for you:

PCL Alphanumeric Command

The '52' is actually decimal 52 (or hex $44), and is plain ole ASCII '4'.

As you can see from that page I linked, the '52' Operation Code on the Alphanumeric ID command:

"Select a new resource association file. This operation allows the user to set the current PCL resource association file to a file name. The current registered associations are deleted and the associations specified in the new resource association file take effect."

BTW, on your second point, I'll go out on a limb and say that any attributes set with the pclResourceFile will override those that exist in the font header, but I'm just speculating at this point. I have yet to make my own pclResourceFile, as I believe that is what (at least the older versions anyway) WebJetAdmin (and its predecessors) did automatically.

Finally, you'll notice a link in that doc to more info on the pclResourceFile -- I tried to access it and the site wants some kind of password so I'm out of luck there.

I'm actually looking forward to experimenting with this stuff, especially if we're able to figure out all the voodoo involved.

Thanks for being interested. This isn't most folks' cup of tea!

Finally, thanks for PCLParphernalia -- what a great utility for PCL junkies.

Hugh

[Hugh_Hood]

Chris,

I've had some more time to re-examine the maddening issue of why selecting fonts downloaded to the "0:\fonts\" directory on a PCL 5 Laserjet's hard drive (or flash dimm in my case) doesn't seem to work without knowing whatever (publicly undocumented apparently) tricks are required in the downloaded font format itself (.sft / .sfs / .sfb / .ttf / type 15 / type 16 / etc...), and also in the particulars of the 'pclResourceFile'.

I appreciate the work you've already put in on this, and I've noticed you've fielded this same issue over the years on this and other forums.

Your detective work with the latest WebJetAdmin didn't seem to yield much fruit for us, but I do appreciate how you uploaded the files you retrieved so that we could try to understand what exactly is happening. In the end I just may have to set up some kind of virtual machine and run an older version of Windows with an older WebJetAdmin or the HP ResourceManager just to find out what the big secret is.

FWIW, when I get too intimate with specifying a font file in the pclResourceFile, I also get a printer error (49.4164) that requires a power-off restart. This error presents itself when I try to print a PCL font listing from the control panel after having modified the pclResourceFile to reference a font. What is it with these errors when we try to do this stuff? Moreover, nowhere could I find what error 49.164 meant.

This all occurs on a workhorse LJ 4050TN, from the heart of the PCL 5e era, and not some newer model where PCL 5 support is questionable. Selection of downloaded fonts SHOULD work, and judging from the number of venders who used to sell pre-written font DIMMs for this model, obviously does work.

You asked if I had previously gotten fonts stored in the 'fonts' directory to be selectable. And, I haven't, because I also use GhostPCL and it (until recently) didn't support that feature, so I came up with the 'font wrapped in a macro file' technique, and that worked on both a real LaserJet and also on GhostPCL.

But, I'd really like to get this working, as it's supposed to work. It just can't be that hard, and yet, it seems it is.

For my testing, I've taken a TrueType font and run it through your wonderful 'PCLParephenalia' soft font generate tool to produce a bound type 15 font. This font does work when downloaded within a print job, and also works with the 'font wrapped in a macro' technique. But, try as I may, I can't select it with either a pclResourceFile entry, nor via the traditional associate font ID with file name command.

I've tried changing the file extension several times, but that had no effect. I've tried removing the first (8) bytes from the .SFT soft font, but that had no effect.

Next, I'll try using the type 16 universal format (instead of type 15), and see if that works. Wish me luck.

BTW, in the pclResourceFile, there are (3) types of entries, each starting with '00' or '01' or '02'.

The '00' entry is just a comment.  Writing it has caused no problems with errors.

The '01' entry is to denote a macro file, and to assign an ID to it. Writing it has caused no problems with errors, and it does, if fact, allow one to select a macro by ID and then execute/call/overlay it, all with just (2) commands. That actually works, and is nice.

The '02' entry has been the problem child causing errors. Anytime I use it, I get the dreaded 49.4164 error.

I'll keep trying. In the meantime, if anyone reading this has a font dimm (or has success using hard disk fonts), please use Chris' tool to download both the pclResourceFile and the font so that we can reverse-engineer what needs to be done.