POV-Ray

The Persistence of Vision Raytracer (POV-Ray).

This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.

Tasklist

FS#162 - Character 101 (0x65) not found in /usr/share/fonts/truetype/freefont/FreeSans.ttf (3.6 branch)

Attached to Project: POV-Ray
Opened by Darxus (Darxus) - Sunday, 08 August 2010, 18:56 GMT
Last edited by Christoph Lipka (clipka) - Saturday, 09 February 2013, 10:42 GMT
Task Type Definite Bug
Category Backend → Geometric Primitives
Status Closed
Assigned To No-one
Operating System All
Severity Low
Priority Normal
Reported Version 3.6
Due in Version 3.70 beta 39
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

The text object isn’t working with /usr/share/fonts/truetype/freefont/FreeSans.ttf. Used to work - taken from an old .pov file of mine.

Rebuilt from
http://www.povray.org/redirect/www.povray.org/ftp/pub/povray/Official/Unix/povray-3.6.tar.bz2

$ povray +ifonttest.pov +ofonttest.png

Persistence of Vision™ Ray Tracer Version 3.6.1 (g++ 4.4.3 @
x86_64-unknown-linux-gnu)
This is an unofficial version compiled by:
darxus [at] chaosreignscom

.....

File: fonttest.pov Line: 8
Parse Warning: Character 101 (0×65) not found in /usr/share/fonts/truetype/freefont/FreeSans.ttf
File: fonttest.pov Line: 8
Parse Warning: Character 115 (0×73) not found in /usr/share/fonts/truetype/freefont/FreeSans.ttf



Verification that the problem is not in the .ttf file, this works (imagemagick):

convert -background lightblue -fill blue -pointsize 48 -font
/usr/share/fonts/truetype/freefont/FreeSans.ttf label:test fonttest.png

Problem verified when compiled from source on Ubuntu Lucid. Also exists in Ubuntu binaries from Lucid and Hardy.

This task depends upon

Closed by  Christoph Lipka (clipka)
Saturday, 09 February 2013, 10:42 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed in 3.7 branch as of beta 39; still open in the 3.6 branch, but chances that there'll ever be a 3.65 are pretty slim, so I consider this case closed for good.
Comment by Thorsten Fröhlich (thorsten) - Sunday, 08 August 2010, 19:07 GMT

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

Comment by Darxus (Darxus) - Sunday, 08 August 2010, 19:13 GMT

Problem exists with both of these font files.

Comment by Darxus (Darxus) - Sunday, 08 August 2010, 19:17 GMT

Thorsten: Did the attached .pov work for you?

Comment by Christoph Lipka (clipka) - Sunday, 08 August 2010, 19:47 GMT

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

Comment by Thorsten Fröhlich (thorsten) - Sunday, 08 August 2010, 19:52 GMT

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

Comment by Thorsten Fröhlich (thorsten) - Sunday, 08 August 2010, 20:06 GMT

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

Comment by Christoph Lipka (clipka) - Sunday, 08 August 2010, 20:24 GMT

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.

Comment by Christoph Lipka (clipka) - Sunday, 08 August 2010, 20:35 GMT
  • Field changed: Status (Assigned → Investigating)
  • Field changed: Category (Other → Geometric Primitives)
  • Field changed: Due in Version (Undecided → 3.70 beta 39)
  • Field changed: Percent Complete (0% → 50%)
  • Assignment removed

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

Comment by Darxus (Darxus) - Sunday, 08 August 2010, 21:53 GMT

Where can I grab the updated source?

Comment by Chris Cason (chrisc) - Monday, 09 August 2010, 12:52 GMT
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) ;
Comment by Darxus (Darxus) - Monday, 09 August 2010, 17:17 GMT

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

Comment by Thorsten Fröhlich (thorsten) - Monday, 09 August 2010, 20:25 GMT

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

Comment by Darxus (Darxus) - Tuesday, 23 August 2011, 14:29 GMT

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?

Comment by Christoph Lipka (clipka) - Thursday, 25 August 2011, 15:05 GMT

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

Comment by Darxus (Darxus) - Thursday, 25 August 2011, 15:45 GMT

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?

Comment by Christoph Lipka (clipka) - Thursday, 25 August 2011, 15:51 GMT

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.

Comment by Darxus (Darxus) - Thursday, 25 August 2011, 15:56 GMT

Sounds good, thanks for the responses.

Loading...