Bug 50492 - Mapping of glyphs in the private area of TTF symbol fonts is only done if cmapRangeOffsets is not zero
Summary: Mapping of glyphs in the private area of TTF symbol fonts is only done if cma...
Status: CLOSED WONTFIX
Alias: None
Product: Fop - Now in Jira
Classification: Unclassified
Component: fonts (show other bugs)
Version: 1.0
Hardware: PC Windows XP
: P3 normal
Target Milestone: ---
Assignee: fop-dev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-17 03:03 UTC by az7070
Modified: 2012-04-30 00:17 UTC (History)
0 users


Attachments
Short program to show that the glyph is not avaiable (2.58 KB, text/x-java-source)
2012-04-12 10:03 UTC, az7070 		Details
Small example fo-file (757 bytes, application/octet-stream)
2012-04-12 10:04 UTC, az7070 		Details
Generated pdf-file from fopglyphs.fo (8.39 KB, application/download)
2012-04-12 10:04 UTC, az7070 		Details
log-output during the generation (740 bytes, application/octet-stream)
2012-04-12 10:05 UTC, az7070 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description az7070 2010-12-17 03:03:07 UTC 
In the current version of org.apache.fop.fonts.truetype.TTFFile, method readUnicodeCmap, there is a workaround to map the glyphs of TTF symbol fonts from the private area to the ascii range:

if (encodingID == 0 && j >= 0xF020 && j <= 0xF0FF) {
 //Experimental: Mapping 0xF020-0xF0FF to 0x0020-0x00FF
 //Tested with Wingdings and Symbol TTF fonts which map their
 //glyphs in the region 0xF020-0xF0FF.
 int mapped = j - 0xF000;
...

but this workaround is only applied in the case of
if (cmapRangeOffsets[i] != 0 && j != 65535) 
...

This mapping should also be done in the else case. There are several symbol fonts (e.g. Wingdings 2 v1.55, Wingdings 3 v1.55) where cmapRangeOffsets[i] == 0.
Comment 1 Glenn Adams 2012-04-07 01:44:01 UTC 
resetting P2 open bugs to P3 pending further review
Comment 2 Glenn Adams 2012-04-08 04:51:01 UTC 
please provide (1) minimal input FO file, (2) PDF output file, (3) all console output
Comment 3 az7070 2012-04-12 10:03:06 UTC 
Created attachment 28590 [details]
Short program to show that the glyph is not avaiable
Comment 4 az7070 2012-04-12 10:04:04 UTC 
Created attachment 28591 [details]
Small example fo-file
Comment 5 az7070 2012-04-12 10:04:43 UTC 
Created attachment 28592 [details]
Generated pdf-file from fopglyphs.fo
Comment 6 az7070 2012-04-12 10:05:11 UTC 
Created attachment 28593 [details]
log-output during the generation
Comment 7 Glenn Adams 2012-04-21 04:08:27 UTC 
using the Unicode code point U+0052 LATIN CAPITAL LETTER R to mean anything other than LATIN CAPITAL LETTER R is a violation of both XSL-FO and Unicode semantics; in order to prevent such mis-use, I have removed [1] the experimental feature ("workaround") added in [2];

[1] http://svn.apache.org/viewvc?view=revision&revision=1328579
[2] http://svn.apache.org/viewvc?view=revision&revision=891181

if a user wishes to map a character in a symbol font that does not have an assigned Unicode code point, then they must use a private use character provided the font manufacturer provides a cmap entry for that private use code point;

if there is no assigned private use code point, then, until a more general mechanism is added to FOP, e.g., adding the ability to augment cmap entries for specific fonts using the fop configuration file, then glyphs that have no assigned Unicode code point or private use mapping will remain inaccessible, in which case you should contact the font supplier to request the addition of such a mapping;
Comment 8 Glenn Adams 2012-04-30 00:14:53 UTC 
batch transition resolved+wontfix to closed+wontfix
Comment 9 Glenn Adams 2012-04-30 00:17:18 UTC 
batch transition resolved+wontfix to closed+wontfix; if you believe this remains a bug and can demonstrate it with appropriate input FO file and output PDF file (as applicable), then you may reopen