Created attachment 32111 [details] A sample program to demonstrate the situation The problem described below showed up on Mandriva Cooker with fontconfig 2.8.0 packages installed from Mandriva repositories. Consider the following scenario. First, a pattern 'p1' is created and then processed with FcConfigSubstitute() and FcDefaultSubstitute(). Second, FcFontMatch() is called for p1. According to the developer's reference, it should return a pattern (let it be 'p2') corresponding to a font found by fontconfig library that most closely matches p1. So far so good. Third, FcFontMatch() is now called for p2. One could expect that this time the function will return a pattern (let it be 'p3') equivalent to p2. Indeed, p2 corresponds to some existing font with the parameters that fontconfig library has already determined. So it makes sense that the pattern most closely matching p2 should have the same contents as p2. Sometimes, however, it is not the case: the last pattern (p3) differs from p2: "globaladvance" element is "FcFalse" in p3 but "FcTrue" in p2, same for "hinting" element. That is, the pattern that fontconfig library considers a better match for p2 than p2 itself, has some elements with the values different from those in p2, which is strange. The attached sample program demonstrates the situation. The problem did not show up with fontconfig 2.8.0 built from source on Mandriva Cooker, it reproduces only with installation from rpm built from Mandriva repository. They seem not to patch the source code of fontconfig library while building the rpms, only font configuration files are patched. So it is not clear now what triggers the problem and where it is.
While what you describe is indeed inconsistent, there is no place in the API or other docs that says passing the output of FcFontMatch() as its own input must result in the same pattern. I do want to investigate a bit though.
Does this still persist? need more details how to reproduce this. e.g. what the font matched in p2 and p3 and what locale you are running on etc.
(In reply to comment #2) > Does this still persist? need more details how to reproduce this. e.g. what the > font matched in p2 and p3 and what locale you are running on etc. Unfortunately, I have no time now to check if the problem is still there, but this discussion may contain the information you need: https://lsbbugs.linuxfoundation.org/show_bug.cgi?id=2854
If that helps, I reported that problem here after it had been detected by the LSB tests for Fontconfig library. The tests can be found here: ftp://ftp.linuxfoundation.org/pub/lsb/snapshots/t2c-desktop-tests/ Information about the tests is available in the README file in the package, namely in <...>/opt/lsb/doc/lsb-test-desktop-t2c/README). The tests were run on Mandriva Cooker and Mandriva 2010 installed with default settings including the locale and fonts.
Downloading iso to check; meanwhile, thinking about possible reason why it happened. at the run time, fontconfig builds the pattern to pick up the best matched font and look up with it. at that time, recording the score to determine what the font are best for the pattern. to avoid the conflict on the score, fontconfig has the list that ordered by the priority: http://cgit.freedesktop.org/fontconfig/tree/src/fcmatch.c#n188 If the font has same score on the same object or even if it has higher score on other objects but lower priority object, it's simply ignored when figuring out the best matched font: http://cgit.freedesktop.org/fontconfig/tree/src/fcmatch.c#n484 this would be the side-effect though, I'm working on adding FC_FILE to FcFontMatch() on Bug#28491 and giving highest priority to FC_FILE to pick up exactly. as the result of FcFontMatch() contains FC_FILE as well, that would ensure the same result with the FcPattern returned by FcFontMatch() after all. "If that is the case" of course.
Okay, had a time to track this down. this was actually duplicate bug of Bug#28958; would rather be due to the side effect of its bad behavior. The logic how it introduced is, 20-mdv-CJK-dualwidth.conf was accidentally applied by matching langs wrongly as it's described in Bug#28958. I can see the testcase attached works fine on even 2.9.0 and HEAD in git repo as well. *** This bug has been marked as a duplicate of bug 28958 ***
(In reply to comment #6) > Okay, had a time to track this down. this was actually duplicate bug of > Bug#28958; would rather be due to the side effect of its bad behavior. Well done! Thank you for explanation.
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.