Bug 690393 - Add support for WinCharSetFFFF encoded TrueType fonts
Summary: Add support for WinCharSetFFFF encoded TrueType fonts
Status: CONFIRMED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: General (show other bugs)
Version: master
Hardware: All All
: P4 enhancement
Assignee: Ken Sharp
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-04-09 00:54 UTC by Ken Sharp
Modified: 2012-09-09 16:24 UTC (History)
1 user (show)

See Also:
Customer:
Word Size: ---


Attachments
WinCharSetFFFF-H (781 bytes, text/plain)
2009-04-09 01:02 UTC, Ken Sharp
Details
ToUnicode_32_0_R (4.81 KB, application/postscript)
2009-04-09 08:48 UTC, Ray Johnston
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ken Sharp 2009-04-09 00:54:39 UTC
The customer has created (using pdfwrite) a PDF file which contains MSGothic and
MSPGothic fonts encoded with the 'WinCharSetFFFF' encoding, but does *not*
contain the fonts.

The original fonts were MS TrueType fonts, and the customer would like to be
able to open and view the PDF file in GS using the msgothic.ttc font on the system.

This requires modifying cidfmap to load the TT font as a CIDFont, and the
addition of the WinCharSetFFFF-H and WinCharSerFFFF-V CMap files. Even then the
result is incorrect, because the mapping code->CID->GID does not work correctly.

It seems we need an entry in gs_ciddc.ps to map the WinCharSetFFFF into
'something else'. Need to fiond out the relationship between WinCharSetFFFF and
Unicode to make this work I believe.
Comment 1 Ken Sharp 2009-04-09 00:56:12 UTC
Created attachment 4908 [details]
bug690393.ps

Sample PostScript file.
Comment 2 Ken Sharp 2009-04-09 01:02:45 UTC
Created attachment 4909 [details]
WinCharSetFFFF-H

The horizontal CMap for WinCharSetFFFF, the vertical can be made simply by
changing the name and 'WMode' entries.
Comment 3 Ray Johnston 2009-04-09 08:47:38 UTC
Actually, as there is a 'GlyphNames2Unicode' defined in the input.ps, the
pdfwrite device currently _does_ know the Unicode and in fact uses the info
to create a 'ToUnicode' map in the font. I looked at the ToUnicode created
by Ghostscript pdfwrite and it does map to the correct Unicode code point,

Thus what is needed is a way to have the font rendering logic map the glyph
that it gets through the 'ToUnicode' map and then get this Unicode glyph from
the TT font. I think that it is possible, given Unicode to get the correct
glyph from a TT font.

For example, the first glyph displayed from the font in TemplateX_nofonts.pdf
<<  /BaseFont /MSPGothic-WinCharSetFFFF-H /ToUnicode 32 0 R 
    /Type /Font /Encoding /Identity-H /DescendantFonts [ 10 0 R ]
    /Subtype /Type0 
>>

is displayed using:

[  (-~) -0.63088 ... ] TJ

The code (-~) is 0x2d7e which maps through the ToUnicode map to 0x88fd which
is the correct glyph.

I will attach TemplateX_nofonts.pdf (yes, it has a bad xref 29 but ignore that)
and the extraxted object [ 32 0 ], the ToUnicode map.

Currently as far as I know, the PDF interpreter ignores the ToUnicode map.
One thing that is needed is to tell the logic that substitutes the MS-PGothic
font to use the ToUnicode info.

BTW, the cidfmap needs to map MSPGothic even though the normal name is 
MS-PGothic created by mkcidfm. The relevant cidfmap I needed to display the
TemplateX_nofonts.pdf was:

/MSPGothic << /FileType /TrueType /SubfontID 1 /CSI [(Japan1) 3] /Path
             (c:/windows/fonts/msgothic.ttc) >> ;
/MSGothic << /FileType /TrueType /SubfontID 0 /CSI [(Japan1) 3] /Path
             (c:/windows/fonts/msgothic.ttc) >> ;



Comment 4 Ray Johnston 2009-04-09 08:48:45 UTC
Created attachment 4910 [details]
ToUnicode_32_0_R

Extracted from TemplateX_nofonts.pdf
Comment 5 Ray Johnston 2009-04-09 08:49:35 UTC
Created attachment 4911 [details]
TemplateX_nofonts.pdf