Hi all, I''m going to prepare a 2.3.93 release later today. Now, I''m going to be travelling for the next 3 weeks. This would seem to be a good amount of time to shake out bugs for 2.4.0. I was thinking that it might be good to release 2.4.0 by mid-January, when I get back. Are there any more issues we''d like to resolve by then? pat
The mmap cache removed all but one usage of "fopen" from the source. grep fopen *c fcxml.c: f = fopen ((char *) filename, "r"); On 32 bit solaris an unsigned char is used for the file descriptor in stdio routines and I gather (ancient solaris bug 1085341) that fixing this would require an ABI change and it couldn''t be done. I wonder if it would be possible to get rid of that too and replace it with "open" at least perhaps in an #ifdef for 32 bit Solaris. I''ll also raise this with the team in Sun that handles fontconfig. -phil. Patrick Lam wrote:> Hi all, > > I''m going to prepare a 2.3.93 release later today. > > Now, I''m going to be travelling for the next 3 weeks. This would seem > to be a good amount of time to shake out bugs for 2.4.0. I was thinking > that it might be good to release 2.4.0 by mid-January, when I get back. > Are there any more issues we''d like to resolve by then? > > pat > _______________________________________________ > Fontconfig mailing list > Fontconfig@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/fontconfig
Phil Race wrote:> The mmap cache removed all but one usage of "fopen" from the source. > > grep fopen *c > fcxml.c: f = fopen ((char *) filename, "r"); > > On 32 bit solaris an unsigned char is used for the file descriptor > in stdio routines and I gather (ancient solaris bug 1085341) that > fixing this would require an ABI change and it couldn''t be done. > I wonder if it would be possible to get rid of that too and replace it > with "open" > at least perhaps in an #ifdef for 32 bit Solaris.There''s no need to use fopen there. I''ve replaced it with open and will commit momentarily. pat
Hi, I have new feature request: Is it possible to let fontconfig load different configuration according to the current system locale setting? Because users of different languages tend to use different set of fonts and settings. For an internationalized system, it''ll be best if the font settings can be adjusted automatically according to the system default language. It''s rather difficult meet all users requirement by one set of font settings. I''ll look into this issue, and try to implement it as soon as possible. I just want to know: 1. Whether it''s already supported or not. 2. Is it possible to add such feature into 2.4 release? Regards James Su On 12/21/05, Patrick Lam <plam@mit.edu> wrote:> Phil Race wrote: > > The mmap cache removed all but one usage of "fopen" from the source. > > > > grep fopen *c > > fcxml.c: f = fopen ((char *) filename, "r"); > > > > On 32 bit solaris an unsigned char is used for the file descriptor > > in stdio routines and I gather (ancient solaris bug 1085341) that > > fixing this would require an ABI change and it couldn''t be done. > > I wonder if it would be possible to get rid of that too and replace it > > with "open" > > at least perhaps in an #ifdef for 32 bit Solaris. > > There''s no need to use fopen there. I''ve replaced it with open and will > commit momentarily. > > pat > _______________________________________________ > Fontconfig mailing list > Fontconfig@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/fontconfig >
On Wed, 2005-12-21 at 14:12 +0800, Zhe Su wrote:> Hi, > I have new feature request: Is it possible to let fontconfig load > different configuration according to the current system locale > setting?You can already detect the locale in cases where the application provides no further language clue by looking in the lang field of the pattern. Can you describe how this wouldn''t be sufficient? <match> <test name="lang"> <string>ja</string> </test> <edit name="family"> <string>??????</string> </edit> </match> This forces use of Kochi Gothic whenever the lang is set to ja. Similar hacks can be used to adjust other settings. -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20051220/ba41833b/attachment.pgp
mfabian@magellan:~$ fc-match "foo:\\_\\_DUMMY\\_\\_=1" Segmentation fault (core dumped) mfabian@magellan:~$ occurs with fontconfig 2.4 CVS branch checked out on December 6th 2005. -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian ?????????????
Mike FABIAN <mfabian@suse.de> ????????:> mfabian@magellan:~$ fc-match "foo:\\_\\_DUMMY\\_\\_=1" > Segmentation fault (core dumped) > mfabian@magellan:~$ > > occurs with fontconfig 2.4 CVS branch checked out on December 6th 2005.Still happens with fontconfig 2.3.93.20051221 (2.4 CVS branch checked out yesterday). -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian ?????????????
Mike FABIAN <mfabian@suse.de> ????????:> Mike FABIAN <mfabian@suse.de> ????????: > >> mfabian@magellan:~$ fc-match "foo:\\_\\_DUMMY\\_\\_=1" >> Segmentation fault (core dumped) >> mfabian@magellan:~$ >> >> occurs with fontconfig 2.4 CVS branch checked out on December 6th 2005.Still happens with fontconfig 2.3.93.20060103 (2.4 CVS branch checked out yesterday). Dirk M?ller and me both made a patch to fix the problem. Dirk already posted his patch to the fontconfig mailing list a while ago, but this mail never arrived. Therefore I attach both my and Dirk''s patch here again. I am not sure which patch is better, both fix the crash but the behaviour is different. With Dirk''s patch: mfabian@magellan:~$ fc-match "Luxi Mono:\\_\\_DUMMY\\_\\_=1" hgjgbbmp.ttc: "HGPGothicB" "Regular" mfabian@magellan:~$ fc-match "Luxi Mono" luximr.ttf: "Luxi Mono" "Regular" mfabian@magellan:~$ fc-match sans hgjgbbmp.ttc: "HGPGothicB" "Regular" mfabian@magellan:~$ I.e. with Dirk''s patch the complete pattern is ignored when it contains __DUMMY__ and a new empty pattern is created which gives the same result as when trying to match "sans". With my patch: mfabian@magellan:~$ fc-match "Luxi Mono:\\_\\_DUMMY\\_\\_=1" luximr.ttf: "Luxi Mono" "Regular" mfabian@magellan:~$ fc-match "Luxi Mono" luximr.ttf: "Luxi Mono" "Regular" mfabian@magellan:~$ fc-match sans hgjgbbmp.ttc: "HGPGothicB" "Regular" mfabian@magellan:~$ only __DUMMY__ is ignored, the rest of the pattern is used. I.e. with my patch it behaves the same way as if I add other junk into the pattern like: mfabian@magellan:~$ fc-match "Luxi Mono:nonsense=1" luximr.ttf: "Luxi Mono" "Regular" mfabian@magellan:~$ Here "nonsense=1" is ignored as well. I still don''t know for what purpose this __DUMMY__ in fcname.c line 33 has been introduced. -------------- next part -------------- A non-text attachment was scrubbed... Name: dummy-crash.patch Type: text/x-patch Size: 518 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20060105/821c6d8c/dummy-crash.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: dummy-crash-dirk-mueller.patch Type: text/x-patch Size: 482 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20060105/821c6d8c/dummy-crash-dirk-mueller.bin -------------- next part -------------- -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian ?????????????
On Thu, 5 Jan 2006, Mike FABIAN wrote:> I am not sure which patch is better, both fix the crash but the > behaviour is different.I''ve committed your patch. __DUMMY__ is needed so that FcObjectToPtrLookup can signal an error return. pat