Revision 8795 can't laod TT as a CID font.
Test file t.ps :
/Ryumin-Light /CIDFont findresource 10 saclefont setfont
100 100 moveto
The file lib/cidfmap :
/Ryumin-Light << /FileType /TrueType /Path (F:/AFPL/MLC2/PROB0003-
688058/batang.ttc) /SubfontID 0 /CSI [(Japan1) 1] >> ;
The file batang.ttc is from Windows/Fonts of Vista 64, rather I think the
Windows version isn't relevant.
Command line :
..\..\gs-hd\bin\gswin32c.exe -IF:\AFPL\gs-hd\lib;f:\afpl\fonts -r72 -dBATCH -
d/DEBUG -dEPSFitPage t.ps
Fails with /invalidfont in --.buildcidfont--
Revision 8198 dowesn't fail in same environment.
Please check recent changes to TT font loader.
Upgrading the priority for regression bug, and because another P2 bug depends
on this one.
Yes, this is a regression but it was introduced a while ago:
r8228 | mpsuzuki | 2007-09-05 03:54:54 -0400 (Wed, 05 Sep 2007) | 35 lines
Fix (TT fonts) : Suppress loading trailing data after chosen cmap subtable.
This result was obtained using a different font. Please attach your
font to the bug report.
Created attachment 4117 [details]
Attaching the font packed with WinZIP.
Setting P1 blocker because it is similar to 689976. I'm working on both.
Created attachment 4240 [details]
A suggested patch to HEAD is being tested. Sorry it is generated with fc.exe
because Cygwin doesn't work on Vista 64.
Created attachment 4241 [details]
Leo's patch in the standard diff format.
I agree with the proposed changes, confirm that the patch works, and
see no regressions in local testing.
Patch to HEAD :
I reopen this bug because we still fail loading OTFs from Vista. The test case
is attachment 3073 [details] from the bug 689304 and a cidfmap file which I'll attach.
Created attachment 4427 [details]
cidfmap to reproduce the problem.
Created attachment 4428 [details]
The font from Vista.
Created attachment 4429 [details]
The 2nd font.
I missed to reopen it on 2008-09-25, so doing now.
Assigning to myself for a faster resolution because Alex is busy.
Oops, that OTF font doesn't include TT data. It includes a CFF instead. So
it's a different bug. I opened a new bug 690110 for that case. Restoring
the "resolved fixed" state for this bug.