Bug 48947 - Drop the non-Unicode cmap support gradually
Summary: Drop the non-Unicode cmap support gradually
Alias: None
Product: fontconfig
Classification: Unclassified
Component: library (show other bugs)
Version: 2.9
Hardware: Other All
: low normal
Assignee: fontconfig-bugs
QA Contact: Behdad Esfahbod
Depends on:
Reported: 2012-04-19 20:00 UTC by Akira TAGOH
Modified: 2015-01-22 02:55 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Note You need to log in before you can comment on or make changes to this bug.
Description Akira TAGOH 2012-04-19 20:00:21 UTC
It has been over 10 years since 21st century started. that may be time to drop the non-Unicode cmap support anytime soon. however it's hard to figure out how many people still use those fonts and easy to imagine their complaint if we drop it asap. so maybe a good idea to drop it gradually.
Comment 1 Behdad Esfahbod 2015-01-21 21:42:31 UTC
I think we are already done with this?
Comment 2 Behdad Esfahbod 2015-01-21 22:26:58 UTC
commit d6d5adeb7940c0d0beb86489c2a1c2ce59e5c044
Author: Behdad Esfahbod <behdad@behdad.org>
Date:   Wed Jan 21 14:13:36 2015 -0800

    Fix symbol cmap handling
    A while back we removed Apple Roman encoding support.  This broke
    symbol fonts (Wingdings, etc) because those fonts come with two
      1) platform=1,encoding=0, aka Apple Roman, which maps identity,
      2) platform=3,encoding=0, aka MS Symbol font
    Now, the reason the Apple Roman removal "broke" these fonts is
    obvious, and for the better: these fonts were mapping ASCII and
    other Latin chars to symbols.
    The reason the fonts didn't work anymore, however, is that we were
    mishandling the MS symbol-font cmaps.  In their modern incarnation
    they are like regular non-symbol-font cmap that map PUA codepoints
    to symbols.  We want to expose those as such.  Hence, this change
    just removes the special-handling for that.
    Now, the reason this confusion happened, if I was to guess, is either
    that FreeType docs are wrong saying that FT_ENCODING_MS_SYMBOL is
    the "Microsoft Symbol encoding, used to encode mathematical symbols":
    or maybe it started that way, but turned into also mapping MS symbol-
    font cmaps, which is a completely different thing.  At any rate, I
    don't know if there are any fonts that use this thing these days, but
    the code here didn't seem to produce charset for any font.  By now I'm
    convinced that this change is the Right Thing to do.  The MS Symbol
    thing was called AdobeSymbol in our code by the way.
    This fixes the much-reported bug that windings, etc are not usable
    with recent fontconfig:
    Now I see PUA mappings reported for Wingdings.
    This also fixes:
    Bug 48947 - Drop the non-Unicode cmap support gradually
    since the AdobeSymbol was the last non-Unicode cmap we were
    trying to parse (very incorrectly).
    Lots of code around this change can be simplified.  I'll push those
    out (including removing the table itself) in subsequent changes.
Comment 3 Akira TAGOH 2015-01-22 02:48:47 UTC
Great work. thanks!
Comment 4 Behdad Esfahbod 2015-01-22 02:55:56 UTC
Took a while to get here, but I'm very happy with the result.  Thank you also, it was team work over many years :).

Hopefully not many bad fonts abuse the symbol-font cmap...

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.