Using Windows 95, POV-Ray version 3.0 as well as 3.1, I get error
messages when trying to use a particular TrueType font:

"Character XX not found" (XX being the ASCII number of the character)
All the characters in each line of text are defined in this font, and no
other programs have trouble using the font except for POV-Ray. They are
not high-ASCII characters; most of them are uppercase or lowercase
letters.
Now here's the stinger: This font is homemade. It was made with a tool
called Softy, which doesn't allow some additional data (offset/size for
superscripts, subscripts, etc., etc.) to be defined. Other fonts that
*do* work have additional table entries that I suspect are expected by
POV-Ray to be there.

The irony of this bug is that if a character is not found, a capital A
from the font is shown in its place. ("A" is the third glyph in the
font.) However, if "A" is included in the text, I am told "Character 65
(0x41) not found in font ....", despite the fact that it still displays
just fine. Obviously POV-Ray is having no trouble reading the glyph
table, but it can't read the character map for anything; not in this
font, anyway.

I can provide a copy of the font in question upon request.

Additional (but irrelevant) information about my system: I am running a
Pentium 166 (why yes, it *is* slow) with 32MB of RAM. (The font file is
under 10K in size, so memory is not a concern.) There are several
gigabytes of free hard disk space.

My guess about this bug is that POV-Ray is looking for a part of the
font file that doesn't need to exist in order to have a working font.
(However, if anyone can tell me what's still missing, and what I can do
to add that information to the font, I'd be most grateful.) It should be
able to check the character map without trouble, but something is
throwing it off.
It should be noted again that this font file works perfectly in all
other applications; only in POV-Ray have I had a problem with it.

Thanks in advance for any help or advice that can be offered regarding
this bug.

Lummox JR

Post a reply to this message

On Wed, 03 Feb 1999 14:10:14 -0500, Lummox JR <Lum### [at] aolcom> wrote:
>Using Windows 95, POV-Ray version 3.0 as well as 3.1, I get error
>messages when trying to use a particular TrueType font:
>
>"Character XX not found" (XX being the ASCII number of the character)
>All the characters in each line of text are defined in this font, and no
>other programs have trouble using the font except for POV-Ray. They are
>not high-ASCII characters; most of them are uppercase or lowercase
>letters.
...
>I can provide a copy of the font in question upon request.

If you can email it to me at par### [at] my-dejanewscom, I'll take a 
look at it and see why POV doesn't like it.

Post a reply to this message

On Wed, 03 Feb 1999 14:10:14 -0500, Lummox JR <Lum### [at] aolcom> wrote:
>Using Windows 95, POV-Ray version 3.0 as well as 3.1, I get error
>messages when trying to use a particular TrueType font:
>
>"Character XX not found" (XX being the ASCII number of the character)
>All the characters in each line of text are defined in this font, and no
>other programs have trouble using the font except for POV-Ray. They are
>not high-ASCII characters; most of them are uppercase or lowercase
>letters.
>Now here's the stinger: This font is homemade. It was made with a tool
>called Softy, which doesn't allow some additional data (offset/size for
>superscripts, subscripts, etc., etc.) to be defined. Other fonts that
>*do* work have additional table entries that I suspect are expected by
>POV-Ray to be there.

...

>My guess about this bug is that POV-Ray is looking for a part of the
>font file that doesn't need to exist in order to have a working font.
>(However, if anyone can tell me what's still missing, and what I can do
>to add that information to the font, I'd be most grateful.) It should be
>able to check the character map without trouble, but something is
>throwing it off.

The character map is in fact the problem:

; TrueType v1.0 Dump Program - v1.60, Jul 10 1995, rrt, dra, gch, ddb, lcp
; Copyright (C) 1991 ZSoft Corporation. All rights reserved.
; Portions Copyright (C) 1991-1995 Microsoft Corporation. All rights reserved.

; Dumping file 'lummox.ttf'

.
.
.

'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
.
.
.

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.  

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.

Post a reply to this message

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

On Thu, 04 Feb 1999 12:45:22 -0600, Thorsten Froehlich 
	<fro### [at] charliecnsiitedu> wrote:

>> 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.

Well, a platformID of 2 (ISO) would still be ordered...  I agree, though, 
that getting rid of the mac cmap subtable, if the software allows it, makes 
the most sense, if it can't be made to behave correctly.  By the way, I
didn't mean to imply that anything related to this is a bug in POV.  The
font is clearly broken.  I also note that the array may actually be present
in the font in question, but then the length field is incorrect.

Post a reply to this message

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

> Well, a platformID of 2 (ISO) would still be ordered...  I agree, though,
> that getting rid of the mac cmap subtable, if the software allows it, makes
> the most sense, if it can't be made to behave correctly.  By the way, I

Yes, you are right, the POV-Ray code might work then.

> didn't mean to imply that anything related to this is a bug in POV.

Yes, I understood, I just wanted to explain why it works in Windows but not
in POV-Ray.


     Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: Tho### [at] csicom

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://www.povray.org

Post a reply to this message

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
> 
> 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.
> 
> 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.

Yep, that was it. I don't know why Softy didn't save a proper cmap, but
it was indeed wrong. The parameters for it were all wrong; the length
for the cmap was in there, but not in the right place. The offset was
wrong, the format was wrong, and the table was blank.
Not knowing any easy way to get rid of it, I simply changed it. The only
thing I could think to do was to look up the correct format (from the
info I found online) and insert some semi-valid data around the bad
data. I put in all the glyphs I needed to, etc., and now POV-Ray has no
problem with it. I didn't dare change the length of the table to format
it correctly, though; I know how, but the adjustments would have been a
nightmare.

Thanks for all your help on this.

Lummox JR

Post a reply to this message