PCL soft font problem 2

[sb9]

Hi all,

I have a question regarding PCL soft fonts. We are developers of an application, that prints to PCL5 printers directly, i.e. without using the printer driver. This application is also using PCL soft fonts. Most soft fonts have been converted from TTF.

While this generally works fine for years, we are currently having a problem with a new PCL soft font. This special soft font is an Open Type font. We converted it to PCL in the same way as the TTF fonts before. The font works fine on two PCL printers (HP 2055, Lexmark 610). Unfortunatly it prints no spaces on two other printers (HP 4250, HP 4515), which makes the font unusable for us. Any other character seems to be ok, only the space is missing.

I looked into the font file with a hex editor, and it looks fine at the point where the blank is defined (i.e. it contains <ESC>*c32E<ESC>(s10W... ).

Does anyone have an idea why the font prints no blanks on several printers while it does on others?



Best regards,



Stefan

 

[DansDadUK]

>> Does anyone have an idea why the font prints no blanks on several
>> printers while it does on others?

No - just a few comments.

Assuming that the downloaded font is in PCL Encapsulated TrueType Outline (PCLETTO) format, with <Esc>(s10W, the download character data length is 10 bytes.
But this means that no actual glyph data is present; i.e. the character download will probably be:

byte 0 0x0f (15) format
byte 1 0x00 (00) continuation
byte 2 0x02 (02) descriptor size
byte 3 0x0f (15) class
byte 4 0x00 (00) }
byte 5 0x04 (00) } character data size (inc. header)
byte 6 0x00 (00) }
byte 7 0x03 (00) } glyph ID
byte 8 0x00 (00) reserved byte
byte 9 0xf9 (249) checksum byte

What controls the width of the character is what is held in the relevant entry in the hmtx (Horizontal Metrics) table within the GT (Global TrueType) segment within the downloaded font header; this table provides 'advance width' and 'left side bearing' values for each glyph.

What this doesn't explain is why "... font works fine ..." on some printers.

I have in the back of my mind some thought that the SPACE character is sometimes treated as a control code character, so perhaps (especially as the glyph data is effectively null) the printer uses the Galley Character (the only one, or the one relevant for the ASCII code range) as the character.
... and if this Galley Character doesn't exist, or does exist but has a small advance width, then perhaps this might begin to explain the difference?

 

[DansDadUK]

Oops; I left some of the values as zero rather than as the decimal equivalent of the hexadecimal value; it should have been:

byte 0 0x0f (15) format
byte 1 0x00 (00) continuation
byte 2 0x02 (02) descriptor size
byte 3 0x0f (15) class
byte 4 0x00 (00) }
byte 5 0x04 (04) } character data size (inc. header)
byte 6 0x00 (00) }
byte 7 0x03 (03) } glyph ID
byte 8 0x00 (00) reserved byte
byte 9 0xf9 (249) checksum byte

 

[DansDadUK]

What do you get if you remove the definition of the space character from the font? i.e. remove:

<esc>*c32E<esc>(s10W

and the next 10 bytes (the character data) following that sequence.

Do you get a different character printed?
With most fonts, the standard Galley Character is usually either blank, or an unfilled rectangle.

 

[sb9]

Hi,

if I remove the space character from the font as you described, there's no space being printed on all of our test printers, including those printers, that printed the space before.
The first tests with my font did not include the space character, and no space was printed at all. This is why I actually added the space character to the font.

The space character in my font looks similar to that one that you posted, with one difference: glyph id is 0x04, so the checksum is 0xf8. I already made some tests with glyph id 0x03 and checksum 0xf9, because some of our other soft fonts are having those values too. The result was: no blanks on all of our printers.
Do you think that glyph id 0x04 might be a problem? There's no other character with that glyph id and the following characters have the subsequent ids 0x05, 0x06 and so on.

Thanks in advance, Stefan

 

[DansDadUK]

When you say "... no blanks on all of our printers ...", can we assume that you mean that none of the printers 'printed' anything (or rather, none of them advanced the horizontal 'cursor') when space characters were expected?


As regards special glyphs, the recommendations in the original (Apple) TrueType specification were apparently:

Glyph 0: .notdef (missing character); normally used as default Galley Character.

Glyph 1: .null; has no contours and zero advance width.

Glyph 2: non-marking-return; has no contours but positive advance width.

Glyph 3: space (and no-break-space); has no contours but positive advance width.

I can't find these recommendations in the current OpenType specification (

http://www.microsoft.com/typography/otspec/default.htm

), but they're probably there, somewhere.

But it still doesn't explain your symptoms.

Is the donor OpenType font (from which your PCLETTO font was generated) a private one, or a common, publicly-available one?
If the latter, which font?

 

[DansDadUK]

>> The first tests with my font did not include the space character, and no space was printed at all.
>> This is why I actually added the space character to the font.

On re-reading this, I'm not sure just what you've done; did you:

(a) add the space character to the donor OpenType font, then generate the PCLETTO font from this updated .OTF font?

or:

(b) just insert the <esc>*c32E<esc>(s10W + 10 data bytes into the already generated PCLETTO font?

 

[sb9]

'no blanks on all of our printers' means that the printer does not advance the horizontal cursor when printing a space. It prints any character correctly, but no space, e.g. if you send

Hello forum

to the printer, the printed page looks like

Helloforum

Unfortunatly the OTF font is not public available, so that I cannot post it here.

 

[DansDadUK]

... and I've now found the relevant page (see

http://www.microsoft.com/typography/otspec/recom.htm

)in the OpenType specification regarding the first four glyphs in fonts.

It recommends that (amongst others), character U+0020 (i.e. the space character) should be mapped to a glyph with "no contours and a positive advance width".

The recommendation is that glyph 3 be used for this purpose.

 

[sb9]

> On re-reading this, I'm not sure just what you've done; did you:
>
> (a) add the space character to the donor OpenType font, then generate the PCLETTO font from this updated .OTF font?
>
> or:

> (b) just insert the <esc>*c32E<esc>(s10W + 10 data bytes into the already generated PCLETTO font?

None of this. We have a tool that converts the OTF/TTF font with the following steps:

1. Install the OTF/TTF under Windows
2. Create a Windows printer, that prints to a file using a PCL5 driver
3. Print a single character to that printer, using the OTF/TTF font
4. Repeat the last step for any character, that shall be contained in the PCLETTO font
5. This results in a couple of output files, one file for each single character
6. The last step is to combine all of those files to the PCLETTO font

What I meant with 'adding the space character' to the font is that I generated a printer output file for the space character in step 4. My first attempts didn't do this.

 

[DansDadUK]

Another thought:

What happens if you use the donor .OTF font with a small, simple Microsoft Word document (e.g. one just containing your "Hello forum" text), and print this (using the LaserJet 4250 PCL5 driver) to the LJ 4250?

Assuming this DOES print the spaces, then we may be able to ascertain something by examining and analysing the print stream generated by Word+driver.

So repeat the print, but select the 'Print to File' option in order to direct the print stream to a .PRN file (name of your choosing).

You could then post that file somewhere for analysis - it would only include a subset of the original .OTF font, and that would be encapsulated anyway, so no-one could reconstruct the .OTF font from it.
Unlike some other forums, Tek-Tips doesn't allow attachments directly, you have to just post a link to a publicly-available file somewhere else.

 

[DansDadUK]

I think that your last post was being composed as about the same time as my last post, and they've 'crossed-over', so you've already answered part of the question I posed there.

i.e. the LJ 4250 (?) driver generated the PCL character data, associated (eventually) with code-point 32, which included a reference to glyph 4.

However, it may still be interesting to see what is generated for the suggested text string "Hello forum", rather than what was generated in separate files for distinct individual characters.

 

[jlasman]

I have never seen where a TrueType pcl font created by a windows driver has a chr(32) glyph. I always thought that there was a 'horizontal motion' field in the header that supplied the spacing advance.


Jim Asman

http://www.spectracolorservices.com

 

[sb9]

> I have never seen where a TrueType pcl font created by a
> windows driver has a chr(32) glyph. I always thought that
> there was a 'horizontal motion' field in the header that
> supplied the spacing advance.

Which field in the font header could that be? I didn't find an according field for header type 15 (TrueType)

 

[sb9]

I'll try to generate an output for 'Hello forum', but I won't manage to do this today

 

[DansDadUK]

Jim

Most PCLETTO fonts that I've seen DO include character data (referencing glyph ID = 3) associated with code-point 32.

What you may be referring to (and what I alluded to in my initial reply) is a note in the "Soft Font Creation" chapter in the "PCL 5 Technical Reference Manual" which states:

"Note: For a proportional font, the width “printed” for a control code Space is determined by the pitch value, unless an HMI command is received following the selection of the font."

But I think (not sure) that this may only apply to Bitmap (non-scalable) fonts, since the Pitch value in PCLETTO fonts is used to hold the "master design space width".

This comment, of course, may point to a circumvention: after selecting the downloaded font, set HMI to a value commensurate with the selected height (assuming it to be a proportionally-spaced scalable font), before printing anything (especially the space character), as perhaps the 'pitch' value in the font header is incorrect?

Chris

 

[DansDadUK]

>> I'll try to generate an output for 'Hello forum', but I won't manage to do this today

I'll look out for that tomorrow (GMT time-zone?).

Analysis will show us what is in the generated font header descriptor, and character data; this will (hopefully) give us some more clues.

 

[sb9]

Success! With your tip I was able to correct the problem!
Thank you very much, guys!

The problem with my font was a pitch value of 0.
I modified th that value to 0xFB, furthermore I removed the definition of the space character, and voila: the LaserJet 4250 prints spaces as well as the Lexmark!

Thank you very much for your help, it would have taken a long long time to solve the problem on my own.

Best Regards,

Stefan

 

[DansDadUK]

Stefan

Good that you've got it working.

If you have other problems and want to do your own analysis of print streams, use the 'PRN File Analyse' tool in the (free) 'PCL Paraphernalia' application, which you can download via the 'Downloads' page of site

http://www.pclparaphernalia.eu

The application requires the .NET 4.0 runtime.

Chris

p.s. what is your application?

 

[sb9]

Chris,

I already used PCL Paraphernalia for analyzing my font before creating this thread, but it didn't show any problems in the font. Currently (being at home) I don't know if it displayed the pitch width of 0, but without knowing the importance of that field, there would have been no reason for me to change it.

Our application receives host input data and prints labels for instance for supermarket shelves from that data. Beneath PCL printers it supports several label printers (e.g. Zebra, Intermec, ...) as well as Postscript.

Once again thank you very much for your help!

Stefan