TrueType character glyph data 1

[templarrush]

Hi,

I'm trying to create a pcl viewer.
I got stuck with the TrueType Characters.

What exactly contains a character's glyph data?
How do I interpret this value?

I can't find much information in the "PCL 5e Technical Reference Manual"

Thanks in advance

 

[DansDadUK]

The glyph data within character descriptor/data in downloaded PCL Encapsulated TrueType Outline (PCLETTO) fonts is just a copy of the glyph data held in the 'donor' TrueType font.

See the specification at

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

which describes all of the tables in TrueType / OpenType fonts.

It's not a trivial task to interpret glyph data (I think you need an understanding of quadratic Beziers, etc.).

Better to look for library routines which can do this for you (i.e. rasterise a character at a given point size from the glyph data).
There are almost certainly some of these available for native TrueType fonts; I don't know how easily they can be adapted to work with extracts from PCLETTO fonts.

 

[templarrush]

Thanks for the fast reply.

I'm aware of the different tables in e TrueType file.

In the character descripter/date is a field "Glyph ID".
When I lookup that Glyph ID in the cmap table in the TrueType font tile, I can get the character code.

It would be much easier if there was a way to know the character code.

 

[DansDadUK]

>> ... It would be much easier if there was a way to know the character code ...

In PCLETTO fonts, the 'cmap' table is not one of the tables in the download, so you can't access any glyph->character mapping.

The character code to be associated with a particular glyph in a downloaded "PCL character definition" escape sequence (i.e. the character descriptor & data) is given by the preceding "PCL character code" escape sequence.

With many downloaded PCLETTO fonts, the PCL font is only a subset of the 'donor' TTF, and the character codes used are NOT the same as the original (Unicode) code-points.
You'll probably find that the 'symbol set' identifier in the font header is set to one of the 'custom' values.

This is usually the case with applications such as Word, which, in conjunction with the printer driver, dynamically construct a 'subset' font containing just the characters required by the document - but the character codes are also allocated dynamically, starting with (for PCL5) space (0x20) or (for PCL6) <NUL> (0x00) or perhaps <SOH> (0x01).
The codes are allocated according to the orderr of the required characters as encountered in the source document.

For example, in one document which contained "abcba", the (PCL5) generated characters would be associated with codes 0x20, 0x21, 0x22, 0x21, 0x20.

But for another document which contained "pqrqp", the generated characters would be associated with the same PCL character codes, although the glyph data would obviously be different.

I think that commercial PCL viewers will rasterise the provided glyph data (ignoring the PCL character code).
... and some of the viewers CAN extract the text as ASCII/Unicode code-points, but I think that they only do this for common fonts, and they do it by 'recognising' the individual glyph datas.

 

[templarrush]

Everything you said is true.

I will try to find a way to rasterize the glyph data

 

[DansDadUK]

Perhaps start by looking at some of the Microsoft API functions associated with fonts.

e.g. for GetGlyphOutline, see

http://msdn.microsoft.com/en-us/library/dd144891(v=vs.85).aspx

 

[templarrush]

I have the TrueType glyph data field of a character descripter for TrueType Fonts.

This is represented as decimal numbers
ex: 02092255237363320205664766311923...106401766432156631

I am able to render bitmapped characters (with different compression methods). Their description is simple. 1 for a printed dot, 0 for a blank dot.

It is really hard to interpret the same data for TrueType characters.

I've been searching a couple of days for different functions in Windows to be able to rasterize this data on a bitmap.


The function you gave is in C++, which I am not familiar with.
C# has a function with the same name, but requires a Font and a Glyph Index.

 

[DansDadUK]

>> ... C# has a function with the same name, but requires a Font and a Glyph Index ...

This is because it is intended for use with native & installed TrueType fonts on a Windows system.

I've never used it, and have no idea whether or not it could be adapted for your purposes.
I merely pointed it out as a starting point for your search for a mechanism to rasterise the TrueType data.

Bear in mind that other tables may come into play, especially at smaller font sizes (e.g. hinting details from fpgm table); I assume that the MS functions may do this automatically.