Help generating CID fonts

Josh_F
Josh_F Posts: 52
in Technique and Theory
Hey everyone,

I have a client asking about having a licensed font delivered instead as a CID font, as they are running a piece of old software that requires an Identity H Encoded CID font.

Since CID fonts contain 16-bit glyph sets like Unicode, is there any simple way of converted already mastered .otf/.ttf files to a CID font? Or does this need to be done at an earlier stage in the mastering process?

If the latter, is there any way to insure my font that is being generated from Fontlab 5 will be a CID/Identity H Encoded font? 

My understanding is that Big-5 and Shift-JIS based encoding for Chinese and Japanese will be CID fonts, but is there any Western/Latin codepages that will create a CID font?

Thanks!

Comments

  • Georg Seifert
    Georg Seifert Posts: 674
    There are some tutorials from Ken Lunde on the Adobe CJK blog: https://blogs.adobe.com/CCJKType/
    If you don't need to follow any particular ROS, you just use Identify-0. If you can use Glyphs.app (*), you just need to add the ROS and export as OTF and the rest will be done automatically. 

    *) I’m the developer of Glyphs.
  • Hin-Tak Leung
    Hin-Tak Leung Posts: 363
    edited June 2017
    It just crossed my mind that you should know there are two different interpretations/usages of Identity H encoding. When it happens inside an embedded font in a pdf, it often means the cid/gid is just the unicode value, so that extracting the encoding vector becomes direct unicode text. However, in standalone fonts, these days, actually it means "coz I said so" custom ending. Adobe are not consistent themselves. Their opentype CFF fonts - source CJK - uses the latter interpretation, to pack as many glyphs as possible inside. Acrobat reader and many of the open-source pdf readers/writers use the former interpretation for subsetted embedded fonts ( again, for text extraction - I.e. Cut and paste from a pdf) .

    You probably should ask your client which one they mean :-).
  • Josh_F
    Josh_F Posts: 52
    Awesome, thanks everyone.
  • lunde
    lunde Posts: 2
    The Identity-H encoding is used to refer to glyphs by their CIDs regardless of their ROS (Registry, Ordering, and Supplement). Per the PDF Language Reference Manual, it maps two-byte character codes ranging from 0 to 65,535 to the same two-byte CID value, interpreted high-order byte first. It has nothing to do with a mapping from Unicode. That mapping is handled via explicit Unicode mappings, or via a ToUnicode mapping table, which maps said Identity-H CIDs to meaningful Unicode values.
  • Hin-Tak Leung
    Hin-Tak Leung Posts: 363
    edited June 2017
    @lunde - please consider weighting in at this issue I filed a few days ago, about fontforge miss-processing Adobe Source CJK : 
    https://github.com/fontforge/fontforge/issues/3084

    Because fontforge insists that Adobe-Identity-H is direct map to unicode.

    As far as I see, the Identity-H usage in Source CJK is just "I said so" custom packed encoding...

    Some people like to think Adobe-Identity-H is Adobe-UCS-UCS2(?)...
  • lunde
    lunde Posts: 2
    I weighed in on fontforge Issue #3084.
  • Hin-Tak Leung
    Hin-Tak Leung Posts: 363
    Thanks. I looked at the dvipdfmx code history... Unfortunately back in 2002 they did something of that sort, and they were not the only one, as I remembered some e-mails with them at the time. 

Categories