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.
Opened by Darxus - 2010-08-08
Last edited by Christoph Lipka - 2013-02-09
FS#162 - Character 101 (0x65) not found in /usr/share/fonts/truetype/freefont/FreeSans.ttf (3.6 branch)
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.
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.
Hard to say anything without having the exact font file...
Problem exists with both of these font files.
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
Subtable 0.
Subtable 1.
Unrecognized CMAP format
Subtable 2.
Subtable 3.
Subtable 4.
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:
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?
It's a one-line change, so rather than build a new source archive, please just apply this patch:
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.