TTF to PCL5 soft font format 15, Glyphs Problem?

[tal6499]

Hi,

I have extracted glyf data from ttf.

After extracting glyf index from 'cmap' i just copied the whole glyf for char definition command (s#w.

I ve followed the method described here:

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

For extracting glyf id.


But nothing appears when i preveiw the PCL stream.

I tried PCLParaphernalia's analyzer but it crashes when i open my pcl file in it.

Attached is the PCLStream

 

[tal6499]

and here's the snapshot in Escapee.
highlighted is the only character i.e. 'a' that i created.

 

[DansDadUK]

The PCL Paraphernalia 'PRN File Analyse' tool (available via

http://www.pclparaphernalia.eu

) doesn't crash when analysing your .pcl file - it merely abandons processing of an invalid soft font header.

What it shows is:

(a) The GT segment in the soft font header is invalid (in particular, the table directory contains two entries (for tables 'hmtx' and 'maxp') which sets their end offset values beyond the boundary of the segment (which has been set with size 1116 data bytes, or 1120 bytes including the segment header type and size fields).

So the analyser abandons any further processing of the header - and this is just what the target printer will do as well, rendering the soft font download invalid.

(b) The structure of the character data (to be associated with code-point 97) appears to be valid, and the checksum is correct, although the 'Glyph ID' is 0, which I think (I'd need to look it up) is usually reserved for one of the special characters.
But this doesn't verify that the glyph data itself is valid - merely that the structure is OK.
... and as the font header is invalid, the character data will just be ignored by the printer.


You've also posted this question on the HP Community forum (see

http://h30499.www3.hp.com/t5/Printe...oft-font-format-15-Glyphs-Problem/m-p/5388829

) where I've replied (as user 'Chris H') with rather more detail and some further samples and modifications to your file.

 

[tal6499]

I just found that I 've placed two null bytes for sake of additional descriptor info. But only the min limit of descriptor info size is 2 bytes, these two null bytes are not required if you have no additional descriptor info.

I removed these two bytes. And after adjusting chksums and other sizes. Glyf ID that is 0 before due to these 2 nulls ,now recognized as 68 i.e.. Correct for 'a'.

I can see 'a' in Escapee preview now.
My glyf data was not invalid.
Now i am going to generalize this process for other characters also.

Attached is the final PCL for reference.

Thanks Chris for all the help.

 

[DansDadUK]

But:

(a) The data you are printing using the selected downloaded font still consists of two characters:
hex(00) - Null control code
hex(61) - character 'a'

(b) If I send (using 'lpr') the contents of your latest file to my local LaserJet 1320n printer, it locks up, and the panel lights indicate a 'Fatal error'.

 

[tal6499]

Hi,

Attached is my PCLStream with all glyfs.
You can try this file.


The problem I am facing now is:
File appears fine in Escapee 8.61.

But when I open it in Escapee 9.17F. All my glyfs(characters) convert to default Escapee font(Courier) when I hover any window over Escapee's Window.
Does it have to do anything with old PCL5 format of commands that i am using?

 

[tal6499]

I have also tried with 'lpr' on NRG SP8200DN. Printer doesn't lock up or any 'Fatal error'. But it doesn't print any Text on page in that downloaded font.
Escapee 8.61 displays font correctly but shows an error at its console on load.

"I/O error 183 on C:\DOCUME~1\(MYUNAME)\LOCALS~1\Temp\EETMP7831376.TTF
Symset 450U 10 cpi bold italic typeface 16901 ID=1 (no match) font M Times New BdIt, scaleable
"
(MYUNAME) refers to my user name.

Escapee indicate the font to be "BAD FONT" when i try to add the font's SFT.

 

[tal6499]

and PCLParaphernalia is showing no errors.

 

[DansDadUK]

If I get a chance later on today (I have visitors arriving soon), I'll have a look at your latest soft font (based on "Times New Bold Italic"?).

There is obviously still something wrong with your font conversion/generation mechanism.

 

[DansDadUK]

Just noticed that your soft font is still based on Arial, not Times New.

Could you try to generate one based on (say) "Arial Black", since some old code I've got which generates PCLETTO fonts won't work with my copy of 'Arial' (something to do with the total number of glyphs).

If you generate one based on "Arial Black", I'll do the same (perhaps this afternoon) and then compare the two generated fonts to look for differences.

 

[DansDadUK]

Several comments from quick look:

(1) You need to explain how Symbol Set 450U maps to Unicode.

(2) You've defined characters for character codes 0 -> 31; most fonts would NOT have these (control code) characters defined; and anyway the glyph IDs you've used are usually reserved for the .notdef, .null, .cr, .sp special characters.

(3) Linked to the first question; from a quick glance, the glyph IDs for character codes 32->255 seem to form a contiguous set; this is perhaps unlikely?

 

[tal6499]

attached is the one generated from Arial.TTF(simple ,not Arial Black):

http://www.mediafire.com/?wgshmdn4gubaan5

This is the structure of my files for reference:
--72 bytes header
--then GT segment(containing gdir,head,hhea,hmtx,maxo) follows
--NULL segment
--reserved,chksum

then char codes in following format:
--format(15)
--continuation(0)
--descriptor size (additional info size):min 2 bytes
--class(15)

I also notice distracted glyfs for some fonts attached is the sample snapshot for Arial Black.
--char data size
--glyf id
--true type glyf data
--reserved,chksum

Above mentioned format is according to HP PCL 5 reference manual

 

[tal6499]

I ve just extracted glyfs for 0-255 chars(only ascii).
Indices are extracted from cmap's Format 0 table where 1:1 mapping is there for 0->255 in glyfIDArray.
Then why i need to explain 450U mapping to Unicode?

Could you please elaborate comment(3) also?

 

[DansDadUK]

>> why i need to explain 450U mapping to Unicode?

I needed to know how you are mapping characters from the Unicode indices.

You mention use of 'cmap's Format 0 table'.

When I generated PCLETTO fonts, I didn't use this; the sub-tables I used were:

(a) Platform = 3 (Windows)

(b) Encoding = 0 (Symbol) or 1 (Unicode)

(c) Format = 4 (Segment mapping to delta values).

I can't remember, at present, why I thought it necessary to use this format (probably because I was following the HP-provided sample code for (equivalent) PCL XL fonts, which I mentioned in a previous topic/post).

 

[DansDadUK]

In your earlier post, you state:

"attached is the one generated from Arial.TTF(simple ,not Arial Black):

http://www.mediafire.com/?wgshmdn4gubaan5

"

This attachment seems to be exactly the same as the earlier one (

http://www.mediafire.com/?q7webbr129ne5n4

).

Are you not able to supply the "Arial Black" equivalent?


... and I don't understand what you mean by:

"I also notice distracted glyfs for some fonts attached is the sample snapshot for Arial Black".

The attachment (

http://www.mediafire.com/?2otx6g6qhcq8ki4

) just shows an EscapeE view of a print stream, which looks really strange (like a bad bitmap. or toner streaking).

 

[tal6499]

I needed only first 256 chars. Glyf indices are same in Format 0 & 4 subtable for first 256 chars. As far as my research is considered.
Please correct me if i am wrong!


"The attachment (

http://www.mediafire.com/?2otx6g6qhcq8ki4

) just shows an EscapeE view of a print stream, which looks really strange (like a bad bitmap. or toner streaking). "

What i meant was same that you are saying.

sorry about the disguised language I am using

You can now find both files in the attached zip for comparison.

 

[DansDadUK]

>> Glyf indices are same in Format 0 & 4 subtable for first 256 chars

You are probably correct.

The old executable code I've got which generates PCLETTO fonts doesn't seem to work very well on Windows 7 (my PC runs Windows 7 Pro 64-bit); it was originally written to run on Windows XP, and I am unable to go back to the source and modify it.

The executable will convert some fonts, but not "Arial" or "Times New Bold Italic", as per your samples.

It WILL convert (a subset of) "Arial Black", "Calibri" and "Courier New Bold Italic", so I've generated some .SFT sample fonts for these three donor TrueType fonts, although the generated PCLETTO fonts only contain characters ABCDE, and <space> and (for one of them) <null> and <CR> as well.

I'll (try to) attach these .SFT files (in a ZIP file); then you can try to generate the same, and compare your fonts with my samples.

 

[DansDadUK]

The sample files I've provided are just plain .SFT downloadable soft fonts, not self-contained print files.

To test print each of them (to printer, or to file), use each of then as the "<download soft font>" within the "Font Sample" tool of 'PCL Paraphernalia'.

 

[tal6499]

thanks,

I have compared your attached SFT's.
Is there any significance of using 'cvt','fpgm','prep' as subtables of GT ? Are they necessary?

And you have also used Symbol Set '0N'.
Can you please explain ?

 

[DansDadUK]

>> Is there any significance of using 'cvt','fpgm','prep' as subtables of GT ?
>> Are they necessary?

According to the "PCL6 Soft Font Download Specification" document:

The following tables are recognized by PCL XL 2.0:

Required:
· head
· maxp
· gdir (Empty table; placeholder)

Optional (Send them if they exist in the TrueType font file):
· cvt
· fpgm
· prep

Special Cases:
· hhea (Required if using Character Class 0)
· hmtx (Required if using Character Class 0)
· vhea (Required if doing vertical-rotated writing, using Character Class 0 or 1, and the table exists in the TrueType font file)
· vmtx (Required if doing vertical-rotated writing, using Character Class 0 or 1, and the table exists in the TrueType font file)

Although this specification is for PCL XL, the PCL5 soft font format is very similar, except for the headers and encapsulation, so I would expect to see the same tables, in the mandatory GT segment, in each type of font.



>> And you have also used Symbol Set '0N'.
>> Can you please explain ?

I've used this symbol set (ISO 8859-1 Latin 1) because it is a strict subset of the Unicode code-space,and hence uses a simple mapping between the symbol set code-points and the Unicode code-points which are used to index the characters in (non-Symbol) TrueType fonts.

i.e. code-points 0x00 -> 0xFF map to Unicode code-points U+0000 -> U+00FF.

So it is quite simple to extract the required glyph data, via the 'cmap' table (which maps glyph identifiers to Unicode code-points).

Of course, the value used in the font header can be anything you like (within the rules which govern symbol set identifiers), but as I've used set '0N' to extract the appropriate glyphs, I've used this value in the header as well, to indicate what mapping has been used.