A while back we removed Apple Roman encoding support. This broke
symbol fonts (Wingdings, etc) because those fonts come with two
cmaps:
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":
http://www.kostis.net/charsets/symbol.htm
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:
https://bugs.freedesktop.org/show_bug.cgi?id=58641
Now I see PUA mappings reported for Wingdings.
This also fixes:
Bug 48947 - Drop the non-Unicode cmap support gradually
https://bugs.freedesktop.org/show_bug.cgi?id=48947
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.
All color fonts are designed to be scaled, even if they only have
bitmap strikes. Client is responsible to scale the bitmaps. This
is in constrast to non-color strikes...
Clients can still use FC_OUTLINE to distinguish bitmap vs outline
fonts. Previously FC_OUTLINE and FC_SCALABLE always had the same
value. Now FC_SCALABLE is set to (FC_OUTLINE || FC_COLOR).
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=87122
This reverts commit a5a384c5ff.
I don't remember what I had in mind for "We will use this property later.", but
the change was wrong. If a font pattern doesn't have any value for element,
it must be interpretted as "it matches any value perfectly. And "perfectly"
must have a score of 0 for that to happen.
This was actually affecting bitmap fonts (in a bad way), as the change made
an outline font to always be preferred over a (otherwise equal) bitmap font,
even for the exact size of the bitmap font. That probably was never noticed
by anyone, but with the font range support this has become clear (and worked
around by Akira). To clean that up, I'm reverting this so I can land the
rest of patches for bug 80873.
https://bugs.freedesktop.org/show_bug.cgi?id=80873#c10
Previously, if the patten didn't request, eg, style, then the style
and stylelang were fully copied from the font, even though the pattern
had a stylelang. Eg:
$ fc-match 'Apple Color Emoji:stylelang=en'
Apple Color Emoji.ttf: "Apple Color Emoji" "標準體"
This change both fixes that and makes the code much more readable. Now:
$ fc-match 'Apple Color Emoji:stylelang=en'
Apple Color Emoji.ttf: "Apple Color Emoji" "Regular"
iconv support was turned off by default in f30a5d76.
Some fonts, like Apple Color Emoji, only have their English
name in a MacRoman entry. As such, decode MacRoman ourselves.
Previous format was unusable. New format is ranges of hex values.
To choose space character and Latin capital letters for example:
$ fc-pattern ':charset=20 41-5a'
Pattern has 1 elts (size 16)
charset:
0000: 00000000 00000001 07fffffe 00000000 00000000 00000000 00000000 00000000
(s)
It was added without proper measurement and a fuzzy possible
use-case (font servers) in mind, but reality check shows that
this significantly slows down caching. As such, deprecate it
and do NOT compute hash during caching.
Makes caching two to three times faster (ignoring the 2 second
delay in fc-cache).
This is more robust but introduces a small change in behavior:
For .pcf.gz fonts, the new code calculates the hash of the uncompressed
font data whereas the original code was calculating the hash of the
compressed data.
No big deal IMO.
FcTypeVoid is likely to happen when 'lang' and 'charset'
is deleted by 'delete' or 'delete_all' mode in edit.
Without this change, any modification on them are simply
ignored.
This is useful to make a lot of changes, particularly
when one wants to add a few and delete a lot say.
This feature requires the FreeType 2.5.1 or later at the build time.
Besides <range> element allows <double> elements with this changes.
This may breaks the cache but not bumping in this change sets at this moment.
please be aware if you want to try it and run fc-cache before/after to
avoid the weird thing against it.
Akira TAGOH
Behdad Esfahbod