POV-Ray

Hard to say anything without having the exact font file...

Problem exists with both of these font files.

   FreeSans.ttf (449.6 KiB)
   FreeSerif.ttf (1.23 MiB)

Thorsten: Did the attached .pov work for you?

While I can't confirm the error messages with POV-Ray 3.6.2 or 3.7.0.beta.38 (Windows x64 versions), I do see issues with both versions: With this font, the text "Hello" renders as "$_66_", where "_" denotes an empty rectangle (probably the "can't-find-this-character" fallback glyph).

There appears to be a consistent pattern behind this, which might give a clue about the root cause: "H" and "l" are codepoints 0x0048 and 0x006C (even), "e" and "o" are codepoints 0x0065 and 0x006F (odd), and "$" and "6" are codepoints 0x0024 and 0x0036 (i.e. off by a factor of two).

The font seems to use UCS-4 tables in addition to UCS-2 tables. I am not sure POV-Ray can handle fonts with UCS-4 tables, as iirc they were introduced as an OpenType extension. here are the cmaps from ttfdump. Still there is a 3 / 1 table (subtable 3) we should handle. Try setting 'charset utf8' in the global settings block, this changes the search order for font tables. Due to POV-Ray's pick-first approach to cmap tables, with this font it will pick the subtable 2, which might be missing the desired characters.

A dump of the cmap tables for future reference in this bug:

'cmap' Table - Character to Glyph Index Mapping Table

 'cmap' version: 0
 number of encoding: 5

Subtable 0.

	 PlatformID:  0
	 EcodingID:   3
	 'cmap' Offset: 0x0000002c
	 Length:    1744
	 Version:      0
	 Format 4 - Segment mapping to delta values
	 segCount:	 216
	 searchRange:	 256
	 entrySelector:	 7
	 rangeShift:	 176
	 

Subtable 1.

	 PlatformID:  0
	 EcodingID:   4
	 'cmap' Offset: 0x000006fc
	 Length:       0
	 Version:      0

Unrecognized CMAP format

Subtable 2.

	 PlatformID:  1
	 EcodingID:   0
	 'cmap' Offset: 0x0000115c
	 Length:     522
	 Version:      0
	 Format 6 - Trimmed table mapping
	 First Code: 0x0000
	 Entry Count: 256

Subtable 3.

	 PlatformID:  3
	 EcodingID:   1
	 'cmap' Offset: 0x0000002c
	 Length:    1744
	 Version:      0
	 Format 4 - Segment mapping to delta values
	 segCount:	 216
	 searchRange:	 256
	 entrySelector:	 7
	 rangeShift:	 176

Subtable 4.

	 PlatformID:  3
	 EcodingID:  10
	 'cmap' Offset: 0x000006fc
	 Length:       0
	 Version:      0

Unrecognized CMAP format

Regarding Christoph's comment: There are indeed tables with offsets multiplied by a factor of two. I guess stepping through ProcessCharMap for the offending characters will quickly reveal what is happening and if it is POV-Ray or the font not matching specs. The trouble with this font is that it is an OpenType font, which extends TrueType by things like UCS-4 Unicode support, which POV-Ray was not designed to handle (because our font code pre-dates the OpenType spec).

The problem appears to be a bug in POV-Ray's handling of glyph table format 6, which the font makes use of:

		ffile->fp->seekg ((int)(search_char - firstCode), POV_SEEK_CUR) ;
		glyph_index = READUSHORT(ffile->fp);

The second line indicates that the glyph table entries are 16-bit unsigned integer, but the seek doesn't fit. Instead, it perfectly fits the symptoms.

Since I have no much doubt that the code is bogus, I'll submit a fix, presuming that this table format is pretty uncommon and has never been tested before.

Fixed with change #5097 for the 3.7 branch. Someone volunteering for backporting the fix to the 3.6 codebase?

Where can I grab the updated source?

Where can I grab the updated source?

It's a one-line change, so rather than build a new source archive, please just apply this patch:

==== //depot/povray/smp/source/backend/shape/truetype.cpp#34 (ktext) ====

27,29c27,29
<  * $Revision: #33 $
<  * $Change: 5091 $
<  * $DateTime: 2010/08/06 11:17:18 $
---
>  * $Revision: #34 $
>  * $Change: 5097 $
>  * $DateTime: 2010/08/08 16:31:04 $
1828c1828
< 		ffile->fp->seekg ((int)(search_char - firstCode), POV_SEEK_CUR) ;
---
> 		ffile->fp->seekg (((int)(search_char - firstCode))*2, POV_SEEK_CUR) ;

Patch works beautifully for me (against 3.6.1), thanks.

BTW, it's annoying that which lies.

$ which povray
/usr/local/bin/povray
$ povray +ifonttest.pov +ofonttest.png
bash: /usr/bin/povray: No such file or directory

It should be noted that global_settings { charset utf8 } does indeed work around this bug for the supplied fonts.

Thanks again (got notified this was just marked 100% complete).

Reading through the comments it occurred to me to ask: Should povray be modified to throw a warning when it comes across font tables it doesn't know how to handle? "The font seems to use UCS-4 tables in addition to UCS-2 tables. I am not sure POV-Ray can handle fonts with UCS-4 tables...." Without knowledge of UCS-4 tables, could a useful warning (or error) message have been given?

In case of additional glyph tables that POV-Ray doesn't know about, those are simply ignored (and AFAIK a warning is issued when POV-Ray doesn't find any glyph table format it knows).

But should a warning also be given if a glyph table that POV-Ray doesn't know is found, even if one that it does know is found?

No; new glyph table types are just "added value" to TTF processors that happen to understand them; as long as there are usable fallback tables it's no problem to use those.

Sounds good, thanks for the responses.