summaryrefslogtreecommitdiff
path: root/src/fcmatch.c
Commit message (Collapse)AuthorAgeFilesLines
* Fix score estimation for postscriptnameAkira TAGOH2021-10-081-3/+5
| | | | | | | | | | | | Before this fix: $ fc-match :postscriptname=LiberationSans LiberationSansNarrow.ttf: "Liberation Sans Narrow" "Regular" After this fix: $ fc-match :postscriptname=LiberationSans LiberationSans-Regular.ttf: "Liberation Sans" "Regular" See https://bugzilla.redhat.com/show_bug.cgi?id=1946871
* Reflect matching results to binding in FcPatternAkira TAGOH2021-08-241-21/+81
| | | | | | | This change allows applications to see what property was matched perfectly and help to filter out for their needs. Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/294
* Do not set different score to non-string valuesAkira TAGOH2021-07-081-1/+1
| | | | | | | | | Non-string values in a cache is supposed to choose one from them. Due to the change of da1c9f7a, there was a regression on scoring for matching functions. So reverting the behavior for evaluating non-string values to the previous one. Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/286
* Fix score evaluation for multiple values in propertiesAkira TAGOH2021-06-281-1/+1
| | | | | | | | | | | | | | | | | | | | Sometimes fonts has multiple values in family and sub-family in order to unify other variants into one. they basically make difference in sub-family though, they also still have standalone family and sub-family. in that case, sub-family is likely to be Regular. fontconfig couldn't recognize the difference between :family=Foo:style=Regular and :family=Foo Caption:style=Regular for example because fontconfig didn't give different score on matching result for the position of multiple values in a cache. Thus, when querying a font like :family=Foo:style=Regular may results :family=Foo Caption:style=Regular. (see the test case for more details) To fix this situation, giving different score according to the position of multiple values in a cache as well as the position of multiple values in a query. Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/283
* Remove abort from FcCompareSize.Ben Wagner2020-12-071-1/+0
| | | | | | | | | There doesn't appear to be a good reason to abort when 'v1' has type FcTypeRange. If there does turn out to be a good reason for this then it should be better documented and the code for handling this case removed. At worst it seems -1 should be returned as it is for other unknown types. It is possible this is left over debug code from the initial implementation.
* Fixup: Handle patterns without familyMatthias Clasen2020-08-251-17/+20
| | | | Pointed out by Akira Tagoh.
* Speed up FcCompareLang and FcCompareBoolMatthias Clasen2020-08-251-12/+10
| | | | Avoid FcCanonicalize here too.
* Speed up fonthashint matchingMatthias Clasen2020-08-251-6/+13
| | | | | | | | | | | | | | | | When we don't need to differentiate between weak and strong, we can exit the loop in FcCompareValueList once we found a best match. This change helps reducing the amount of list walking we do for fonthashint, where careless config files end up creating lists with ~100 booleans :( We don't want to walk all those to the end, over and over again. We are already special-casing family, and the only other case where weak != strong, PostScript names, doesn't have long lists of values, so the limitation to weak == strong doesn't matter much in practice.
* Use a hash table for family matchingMatthias Clasen2020-08-251-5/+134
| | | | | | | | | | | | | | | | | | | | | | With the way typical font configurations look, matching the lists of families is the bottleneck for both FcFontMatch and FcFontSort. After installing the Noto fonts on my system, an innocent match pattern like "Cantarell 14" turns into a monster with a list of 300 family names after calling FcConfigSubstitute(). With this setup, every FcFontSort call takes 80-100 ms, which is entirely incompatible with using FcFontSort for anything interactive. And many font choosers render every font in itself, causing on average one FcFontSort call per font. On my system, it takes more than 20 seconds to open the GTK font chooser dialog, with frequent stalls when scrolling. This patch special-cases font families and replaces the list walking for comparison with a hash table lookup. With this patch, the FcFontSort time goes to ~10ms per call. Which is still not good enough for calling it dozens of times when scrolling, but a significant improvement.
* Add FC_ORDER property into cacheAkira TAGOH2020-05-251-0/+1
| | | | | | | | | | "fontversion" used to be modified to sort out fonts as a technique. But that lost the original purpose to do the version control between releases. This change adds the dedicated property into the cache. Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/226
* Use FcConfigReference/Destroy appropriately instead of FcConfigGetCurrentAkira TAGOH2019-11-011-25/+23
| | | | | | This may improves to be MT-safe. Reported at https://bugs.chromium.org/p/chromium/issues/detail?id=1004254
* Affect FC_FONT_HAS_HINT property to score on matcherAkira TAGOH2019-08-091-0/+1
|
* Fix possibly dereferencing a null pointerAkira TAGOH2018-07-191-5/+8
|
* Cache: Rewrite relocated paths in earlierAlexander Larsson2018-05-251-34/+0
| | | | | | | | | | | | | | | | This changes the rewriting of the FC_FILE values for relocated caches to an earlier stage while reading the cache. This is better, because it means all APIs will report the rewritten paths, not just the once that use the list apis. We do this by detecting the relocated case and duplicating the FcPattern and FcPatternElm in an cache allocation (which will die with the cache) and then reusing the FcValueLists from the cache. This means that in the rewritten case we will use some more memory, but not the full size of the cache. In a test here I had 800k of relocated caches, but ~200k of wasted on duplicating the objects. This should fix https://bugs.freedesktop.org/show_bug.cgi?id=106618
* Fix -Wstringop-truncation warningAkira TAGOH2018-05-251-5/+4
|
* Put back accidentally removed codeBehdad Esfahbod2017-12-201-0/+2
|
* Let pattern FC_FONT_VARIATIONS override standard axis variationsBehdad Esfahbod2017-12-191-9/+11
| | | | Ie. flip the merge order.
* Set font-variations settings for standard axes in variable fontsBehdad Esfahbod2017-12-191-2/+52
| | | | | | | This is the last piece of the puzzle for variable-font support in fontconfig. This takes care of automatically setting the variation settings when user requests a weight / width / size that has variation in the matched font.
* Remove a debug abort()Behdad Esfahbod2017-12-181-1/+0
| | | | Ouch!
* Try to get current instance of FcConfig as far as possibleAkira TAGOH2017-12-191-0/+2
|
* Don't crashBehdad Esfahbod2017-12-181-1/+1
| | | | | Not proper fix necessarily. But fixes this crash: https://bugs.freedesktop.org/show_bug.cgi?id=101889#c81
* Don't call FcStat when the alias has already been addedAkira TAGOH2017-11-201-25/+22
| | | | Similar changes to 3a3d6ea applies to fclist and fcmatch.
* abstract hash table functionsAkira TAGOH2017-11-201-2/+3
|
* Replace the original path to the new oneAkira TAGOH2017-11-201-0/+2
|
* Replace the font path in FcPattern to what it is actually located.Akira TAGOH2017-11-201-0/+32
|
* Add FcDontCare value to FcBoolBehdad Esfahbod2017-09-201-2/+6
| | | | | This can be used for FC_VARIABLE=FcDontCare for example, to opt into getting variable fonts for clients that support using them.
* Add separate match compare function for sizeBehdad Esfahbod2017-09-201-0/+50
| | | | | | Has two distinctions from FcCompareRange(): 1. As best value, it returns query pattern size, even if it's out of font range, 2. Implements semi-closed interval, as that's what OS/2 v5 table defines
* In RenderPrepare(), handle ranges smartlyBehdad Esfahbod2017-09-201-14/+37
| | | | | | | | If font claims to support range [100,900], and request is for [250], then return [250] in "rendered" pattern. Previously was returning [100,900]. This is desirable for varfonts weight and width, but probably not for size. Will roll back size to return request size always, for non-empty ranges.
* [varfonts] Add FC_VARIABLEBehdad Esfahbod2017-09-201-0/+1
| | | | For now, we mark all fonts as non-variable.
* Rewrite FcCompareRange()Behdad Esfahbod2017-09-201-19/+20
| | | | Much simpler now.
* Rename FcCompareSizeRange() to FcCompareRange()Behdad Esfahbod2017-09-201-2/+2
|
* Remove FcCompareSize()Behdad Esfahbod2017-09-201-34/+0
| | | | | | | Use FcCompareNumber(). The FcCompareSize() returns 0 ("perfect match") if v2 is zero. I cannot think of a use-case for this. The code has been there from initial commit in 2002. I suppose back then Keith had a use for size=0 to mean scalable or something. Anyway, remove and see.
* Add one more debugging option to see transformation on font-matchingAkira TAGOH2015-06-081-0/+41
| | | | | | | | | | | just setting FC_MATCH=3 shows a lot of information and hard to keep on track for informamtion which is really necessary to see. to use this more effectively, added FC_DBG_MATCH_FILTER to see for what one really want to see. it takes a comma-separated-list of object names. If you want to see family name only, try like this: FC_DBG_MATCH_FILTER=family FC_DEBUG=4096 fc-match debugging output will be filtered out and see family only in the result.
* Simplify FcRangeBehdad Esfahbod2015-05-271-1/+1
|
* Add su[pport for symbol fontsBehdad Esfahbod2015-05-181-0/+1
| | | | | | | | | | | | | Adds FC_SYMBOL. This affects fonts having a cmap with platform 3 encoding 0. We now map their glyphs from the PUA area to the Latin1 area. See thread "Webdings and other MS symbol fonts don't display" on the mailing list. Test before/after with: $ pango-view --markup --text='<span fallback="false">&#xd7;&#xf0d7;</span>' --font=Wingdings
* Add FC_COLORBehdad Esfahbod2014-12-141-0/+1
| | | | | | Only adds "color" to pattern if FreeType version supports color. Based on patch from Jungshik Shin.
* Revert "[fcmatch] When matching, reserve score 0 for when elements don't exist"Behdad Esfahbod2014-08-201-1/+1
| | | | | | | | | | | | | | | | | | This reverts commit a5a384c5ffb479e095092c2aaedd406f8785280a. 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
* Improve / cleanup namelang matchingBehdad Esfahbod2014-07-241-22/+23
| | | | | | | | | | | | | | 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"
* Fixup previous commitBehdad Esfahbod2014-07-061-12/+0
|
* Remove HASH from matching prioritiesBehdad Esfahbod2014-07-061-1/+0
| | | | We deprecated FC_HASH, so doesn't make sense to sort on it.
* CommentsBehdad Esfahbod2014-07-061-0/+6
|
* Bug 71287 - size specific design selection support in OS/2 table version 5Akira TAGOH2014-03-261-0/+45
| | | | | | | | | | 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.
* Bug 72380 - Never drop first font when trimmingBehdad Esfahbod2013-12-091-2/+3
| | | | | | | | | | | | | | | | | | | Let me show it with an example. Currently: $ fc-match symbol symbol.ttf: "Symbol" "Regular" $ fc-match symbol --sort | head -n 1 Symbol.pfb: "Symbol" "Regular" $ fc-match symbol --sort --all | head -n 1 symbol.ttf: "Symbol" "Regular" I want to make sure the above three commands all return the same font. Ie. I want to make sure FcFontMatch() always returns the first font from FcFontSort(). As such, never trim first font.
* Copy all values from the font to the pattern if the pattern doesn't have the ↵Akira TAGOH2013-09-181-2/+4
| | | | element
* Bug 16818 - fontformat in match pattern is not respected?Akira TAGOH2013-08-141-0/+1
|
* Bug 67845 - Match on FC_SCALABLEAkira TAGOH2013-08-071-0/+1
|
* Bug 63922 - FcFreeTypeQueryFace fails on postscripts fonts loaded from memoryAkira TAGOH2013-05-161-9/+21
| | | | | | Workaround to not failing even when the hash is unable to generate from fonts. This change also contains to ignore the case if the hash isn't in either both patterns.
* Use the glob matching for filenameAkira TAGOH2013-05-081-4/+2
| | | | | | | Regex is expensive to compare filenames. we already have the glob matching and it works enough in this case. Prior to this change, renaming FcConfigGlobMatch() to FcStrGlobMatch() and moving to fcstr.c
* Bug 62980 - matching native fonts with even :lang=enAkira TAGOH2013-04-011-16/+7
| | | | | Fix the matcher modified by 4eab908c8679a797ac7016b77a93ee41bb11b0fc to deal with both strong and weak of FC_LANG as the same location in the score
* Bug 38737 - Wishlist: support FC_POSTSCRIPT_NAMEAkira TAGOH2013-03-211-0/+21
| | | | | | Add the PostScript name into the cache and the matcher. Scoring the better font against the PostScript name by the forward-matching.
View Lorry Controller Status