Summary: | Handling whitespace in aliases | ||
---|---|---|---|
Product: | fontconfig | Reporter: | Behdad Esfahbod <freedesktop> |
Component: | conf | Assignee: | Akira TAGOH <akira> |
Status: | RESOLVED FIXED | QA Contact: | Behdad Esfahbod <freedesktop> |
Severity: | normal | ||
Priority: | medium | CC: | akira, bugs.freedesktop, cloos, dirtyepic, eric225125, fontconfig-bugs, freedesktop, hib, martin, mcepl, pva, vuntz |
Version: | 2.4 | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Behdad Esfahbod
2008-12-16 22:44:28 UTC
This is an example of the more general issue that <alias>s are matched to patterns' <fontname>s literally, but actual fonts' names are matched with whitespace ignored. Ie, if the font is installed, these: :; fc-match DejaVuSansMono :; fc-match 'DejaVu Sans Mono' give the same result. But to use aliases you need to have all possibilities accounted for in the conf. It is also related to the issue that libs like poppler pass PS names to fontconfig whereas fontconfig caches the full names. (For Type1 fc caches the /FullName, poppler passes the /FontName; for sfnts poppler passes the TT_NAME_ID_PS_NAME, which fc explicitly ignores: #if 0 case TT_NAME_ID_PS_NAME: case TT_NAME_ID_UNIQUE_ID: #endif ) Ah I see. Good point. We prolly need a new comparison operator for the config file that compares ignoring case and blanks. Then we can update all the config files to use that. (In reply to comment #3) > We prolly need a new comparison operator for the config file that compares > ignoring case and blanks. Then we can update all the config files to use that. That may be one issue, but isn't necessary going to help with PS-names. e.g. NimbusSansL-Regu is never going to match a full name or family name. PS-names and family names are really quite different. (In reply to comment #4) > (In reply to comment #3) > > We prolly need a new comparison operator for the config file that compares > > ignoring case and blanks. Then we can update all the config files to use that. > > That may be one issue, but isn't necessary going to help with PS-names. > e.g. NimbusSansL-Regu is never going to match a full name or family name. > PS-names and family names are really quite different. Right. PS-names are a different issue and that's bug 18095. Retitling again. Note that fc-list also doesn't ignore whitespace when matching. *** Bug 23152 has been marked as a duplicate of this bug. *** The problem with the ZapfDingbats alias is still present in fontconfig-2.8. If the larger issue of whitespace isn't going to be addressed soon can we add the ZapfDingbats bit in the meantime? Does anyone have any comments on the proposed patch I posted to the mailing list a couple of weeks ago (<m3r5mwt1wj.fsf@lugabout.jhcloos.org> and its followup)? (In reply to comment #10) > Does anyone have any comments on the proposed patch I posted to the mailing > list a couple of weeks ago (<m3r5mwt1wj.fsf@lugabout.jhcloos.org> and its > followup)? I've decided to include a workaround patch for this issue so far because I want to give priority releasing new version since there hasn't seen for awhile. I'll have a look at your patch once new release is out. (In reply to comment #10) > Does anyone have any comments on the proposed patch I posted to the mailing > list a couple of weeks ago (<m3r5mwt1wj.fsf@lugabout.jhcloos.org> and its > followup)? Well, that might be good start to work on Bug#18095 though, I'm not sure how it helps for this since this is to handle the white spaces in the family name on alias. (In reply to comment #3) > We prolly need a new comparison operator for the config file that compares > ignoring case and blanks. Then we can update all the config files to use that. I'd vote this idea. we could force using FcStrCmpIgnoreBlanksAndCase() for family but is there any cases one strictly needs to check the white spaces in the string? otherwise can we simply use it for string too? the proposed fixes for this: http://cgit.freedesktop.org/~tagoh/fontconfig/commit/?h=bz19128 I guess there may be the better operator name though. please test it. hope I'm not missing anything else. thanks. FcStrCmpIgnoreBlanksAndCase() ignores the blanks in any places anyway. so that will says "Co urier" and "C o u r i e r" is same. should we just skips the blanks when the next character is only capitalized? Not really sure. Lets go for less complexity. Okay. we can fix it later as needed. I still wonder if "eq_case_blanks" is really better name for operator. there are another idea when I thought of. it is to make the case-sensitivity and ignoring blanks optional. <test name="family" compare="eq" case-sensitivity="false" ignore-blanks="true"> ... </test> the concern is, it's only effective for string. but that may be ok since fontconfig implicitly adjusts the behavior against the operator in even current implementation. e.g. FcOpContains and FcOpListing is equal to FcOpEqual for integer and float. and it would be capable to add another rule for skip blanks like: <test name="family" ignore-blanks="only_when_capitalized"> not sure if we really want to do that in the future, but maybe good to have scalability in its syntax. another advantage on this idea would be compatibility with the older release. it behaves differently but still can share them. another try: http://cgit.freedesktop.org/~tagoh/fontconfig/commit/?h=bz19128-2 That looks better now. any volunteers for testing are welcome. Merged into master. |
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.