Summary: | Simplify FC_FOUNDRY processing? | ||
---|---|---|---|
Product: | fontconfig | Reporter: | Behdad Esfahbod <freedesktop> |
Component: | library | Assignee: | Akira TAGOH <akira> |
Status: | RESOLVED FIXED | QA Contact: | Behdad Esfahbod <freedesktop> |
Severity: | normal | ||
Priority: | medium | CC: | akira, fontconfig-bugs, freedesktop |
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Behdad Esfahbod
2015-01-21 21:52:43 UTC
*** Bug 88680 has been marked as a duplicate of this bug. *** and how about adding another properties according to hour-byte tag in the configuration? is it maybe easier to maintain and extend as needed in each distros instead of updating the table and rebuild? FcNoticeFoundry expects to see the non-four-byte tags. if we prefer to have four-byte tag as FC_FOUNDRY, we still maintain another table to convert it to four byte right? I'd rather we simplify code. I don't think anyone seriously uses this FC_FOUNDRY value, so regressing it is ok in my opinion. just roughly googled FC_FOUNDRY and see how many customers use it. not sure how seriously changing the behavior of it affects to applications though, it will affects to UX at least since there are applications that uses it. we may need to do it carefully and slowly. Can you list a few examples? I have a hard time imagining existing users of this. http://quesoglc.svn.sourceforge.net/viewvc/quesoglc/trunk/quesoglc/src/omaster.c?revision=867&view=markup http://code.qt.io/cgit/qt/qtbase.git/tree/src/platformsupport/fontdatabases/fontconfig/qfontconfigdatabase.cpp https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/master/entry/plasma-desktop/kcms/kfontinst/lib/Fc.cpp maybe trivial though it may looks different to users perhaps. My gut feeling is that no one will notice. :D Getting rid of FcNoticeFoundry seems not a good idea. in case it is used in the code path, the foundry looks like: foundry: "Copyright (c) 1989, 1991 Adobe Systems Incorporated. All Rights Reserved.Utopia is a registered trademark of Adobe Systems Incorporated."(s) it isn't what we expect. (In reply to Akira TAGOH from comment #9) > Getting rid of FcNoticeFoundry seems not a good idea. in case it is used in > the code path, the foundry looks like: > foundry: "Copyright (c) 1989, 1991 Adobe Systems Incorporated. All Rights > Reserved.Utopia is a registered trademark of Adobe Systems Incorporated."(s) > > it isn't what we expect. Humm. I thought it looks for strings like Adobe and assigns "Adobe"... (In reply to Behdad Esfahbod from comment #10) > (In reply to Akira TAGOH from comment #9) > > Getting rid of FcNoticeFoundry seems not a good idea. in case it is used in > > the code path, the foundry looks like: > > foundry: "Copyright (c) 1989, 1991 Adobe Systems Incorporated. All Rights > > Reserved.Utopia is a registered trademark of Adobe Systems Incorporated."(s) > > > > it isn't what we expect. > > Humm. I thought it looks for strings like Adobe and assigns "Adobe"... right. so FcNoticeFoundry assigns "Adobe" instead of the above copyright notice in that case. let me show you some examples we fail on picking up foundries without FcNoticeFoundry. there are two code paths acquire the information through FcNoticeFoundry. one is from TT_NAME_ID_{TRADEMARK,MANUFACTURE} and one is FT_Get_PS_Font_Info. the former one fails on google-crosextra-caladea and lyx say. later one is Type1 fonts and some PCF fonts. apparently we need to keep maintaining FcNoticeFoundry at least for them. (In reply to Akira TAGOH from comment #11) > the former one fails on google-crosextra-caladea and lyx say. Oh, wait. this isn't true. those has "unknown" even now. proposed changes here: http://cgit.freedesktop.org/~tagoh/fontconfig/commit/?h=bz88679 Looks good to me. Please send a note to the list after you push this out, so we know if people rely on it. I remember SuSE used to prepend foundry to family name, mostly to differentiate various Fixed bitmap fonts IIRC. committed into git. |
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.