In article <36b9ae2e.0@news.povray.org> , par### [at] my-dejanewscom (Ron 
Parker) wrote:

> 'cmap' Table - Character To Index Map
> -------------------------------------
> Size = 408 bytes
>   'cmap' version:  0
>   numTables:       2
>
> Subtable  1.   Platform ID:   1
>                Specific ID:   0
>                'cmap' Offset: 0x00000014
>        ->Format: 0 : Byte encoding table
>   Length:  0
>   Version: 0

The TrueType standard says that a cmap for platform id 1 and encoding 0
should have format 0, _and_ format 0 is defined to have an array with 256
glyphs. If this is not the case the TTF file does not comply to the standard
:-(

Also this is about OpenType (basically a superset of TrueType), here are the
details:
<http://www.adobe.com/supportservice/devrelations/opentype/cmap.htm>

>
> This is the charmap POV wants to read (it looks for a platform ID of
> 1 or 3, apparently, using the first one it finds.) However, this charmap
> is useless: it doesn't have any entries, so by default maps every character
> to glyph zero, though I have some doubts as to whether POV even properly
> reads "short" tables.

Yes, there are certain strange things happening inside the code (some
hard-coded stuff) :-)

With the current version most Mac and Windows fonts work simply because most
Win fonts don't seem to have a cmap for platform id 1 and encoding 0 or the
one they have is valid. This way most font work, however, the core code
cannot know the "right" cmap table for a platform because it cannot access
platform specific code.
As there are still problems with some fonts for both, Windows and Mac
format, some changes in the code are required to know which cmap is
preferred. A quick and very dirty Windows only patch would be to replace the
line "if ((ffile->platformID != cmapEntry.platformID) && (1 !=
cmapEntry.platformID))" in function "ProcessCharMap" in truetype.c with "if
(ffile->platformID != cmapEntry.platformID)".
This is for example done by the Unicode patch at
<http://www.geocities.com/SiliconValley/Network/4453/unipatch/>, but be
aware that it breakes all non platform 3 encoding 1 fonts because in
function "OpenFontFile" in truetype.c this is *hard-coded*!
As this breaks all non Windows fonts this is a bug, but it is not easy to
fix for all platforms at once :-(   I am working on it...

> If you can, make sure your software creates a proper cmap for platform 1,
> specific 0, format 0.  If your software can't export a proper cmap, you
> might have a problem.  A little hex editing to change the platform ID on
> this bad cmap would do the trick with POV, but I don't know at what offset
> within the file that information is stored.

However, this is dangerous as the TrueType standard says that the cmaps have
to be ordered...
Based on the OpenType spec link above it should be possible to remove this
cmap, and then all should work fine.


    Thorsten

Post a reply to this message