fontconfig 2.4 branch, CVS snapshot from yesterday.
It''s easy to reproduce like this:
mfabian@magellan:/tmp/test$ ls
mfabian@magellan:/tmp/test$
(no fonts here, just for testing. It doesn''t matter whether
the directory contains fonts or not).
mfabian@magellan:/tmp/test$ fc-cache -v .
fc-cache: ".": caching, 0 fonts, 0 dirs
fc-cache: succeeded
mfabian@magellan:/tmp/test$ ls
fonts.cache-2
mfabian@magellan:/tmp/test$ touch .
mfabian@magellan:/tmp/test$ fc-cache -v .
fc-cache: ".": caching, 0 fonts, 0 dirs
fc-cache: failed
mfabian@magellan:/tmp/test$ echo $?
1
mfabian@magellan:/tmp/test$
--
Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian
?????????????
Mike FABIAN wrote:> The attached patch seems to fix it.I''ve applied this patch. Matthias Clasen wrote:> Since one of the main goals of the mmap cache effort is memory > reduction, would it make sense to apply (the parts that still > apply) the patch in 2638 to move some constant data like the > glyph<n> variables in fcglyphname.h from .data to .rodata ?I''ve also applied this patch. pat
Mike FABIAN wrote:> mfabian@magellan:/tmp/test$ fc-cache -v . > fc-cache: ".": caching, 0 fonts, 0 dirs > fc-cache: failedOops, I misinterpreted the unlink() return value. Fixed. pat
Patrick Lam <plam@MIT.EDU> ????????:> Mike FABIAN wrote: >> mfabian@magellan:/tmp/test$ fc-cache -v . >> fc-cache: ".": caching, 0 fonts, 0 dirs >> fc-cache: failed > > Oops, I misinterpreted the unlink() return value. Fixed.Thank you. For the procedure I described in my last mail, it works now. But I found a similar problem which still occurs with the current cvs snapshot of the fontconfig 2.4 branch: mfabian@magellan:/tmp$ mkdir test mfabian@magellan:/tmp$ cd test mfabian@magellan:/tmp/test$ fc-cache -v -f . fc-cache: ".": caching, 0 fonts, 0 dirs fc-cache: failed mfabian@magellan:/tmp/test$ ls fonts.cache-2 mfabian@magellan:/tmp/test$ fc-cache -v -f . fc-cache: ".": caching, 0 fonts, 0 dirs fc-cache: succeeded mfabian@magellan:/tmp/test$ -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian ?????????????
with todays CVS snapshot of the fontconfig 2.4 branch:
mfabian@magellan:~/.fonts$ fc-list : family file | grep -i zenkai
./ukai.ttf: AR PL ZenKai Uni
mfabian@magellan:~/.fonts$
mfabian@magellan:~/.fonts$ ls -li --time-style=full-iso ukai.ttf
197011 -rw-r--r-- 1 mfabian suse 14296192 2005-10-14 14:47:03.000000000
+0200 ukai.ttf
mfabian@magellan:~/.fonts$ ls -lid --time-style=full-iso .
5505413 drwxr-xr-x 3 mfabian suse 4096 2005-10-14 14:51:01.000000000 +0200
./
mfabian@magellan:~/.fonts$
Now move the font to a new name and move it back:
mfabian@magellan:~/.fonts$ mv ukai.ttf ukai-new.ttf
mfabian@magellan:~/.fonts$ mv ukai-new.ttf ukai.ttf
mfabian@magellan:~/.fonts$ ls -li --time-style=full-iso ukai.ttf
197011 -rw-r--r-- 1 mfabian suse 14296192 2005-10-14 14:47:03.000000000
+0200 ukai.ttf
mfabian@magellan:~/.fonts$ ls -lid --time-style=full-iso .
5505413 drwxr-xr-x 3 mfabian suse 4096 2005-10-14 14:52:52.000000000 +0200
./
mfabian@magellan:~/.fonts$
The font still has the same i-node and time stamp and the time-stamp
of the directory is changed (as expected). Now run "fc-cache -v ."
again:
mfabian@magellan:~/.fonts$ fc-cache -v .
fc-cache: ".": caching, 71 fonts, 1 dirs
fc-cache: "./kde-override": skipping, 0 fonts, 0 dirs
fc-cache: succeeded
mfabian@magellan:~/.fonts$
And now the font appears to be gone:
mfabian@magellan:~/.fonts$ fc-list : family file | grep -i zenkai
mfabian@magellan:~/.fonts$
With fontconfig 2.3.2, the font was still available at this point!
Run fc-cache once more adding the force option:
mfabian@magellan:~/.fonts$ fc-cache -v -f .
fc-cache: ".": caching, 71 fonts, 1 dirs
fc-cache: "./kde-override": caching, 0 fonts, 0 dirs
fc-cache: succeeded
mfabian@magellan:~/.fonts$ fc-list : family file | grep -i zenkai
./ukai.ttf: AR PL ZenKai Uni
mfabian@magellan:~/.fonts$
Now the font has appeared again.
--
Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian
?????????????
Mike FABIAN <mfabian@suse.de> ????????:> But I found a similar problem which still occurs with the > current cvs snapshot of the fontconfig 2.4 branch: > > mfabian@magellan:/tmp$ mkdir test > mfabian@magellan:/tmp$ cd test > mfabian@magellan:/tmp/test$ fc-cache -v -f . > fc-cache: ".": caching, 0 fonts, 0 dirs > fc-cache: failed > mfabian@magellan:/tmp/test$ ls > fonts.cache-2 > mfabian@magellan:/tmp/test$ fc-cache -v -f . > fc-cache: ".": caching, 0 fonts, 0 dirs > fc-cache: succeeded > mfabian@magellan:/tmp/test$The attached patch seems to fix it. -------------- next part -------------- A non-text attachment was scrubbed... Name: fix-return-code.patch Type: text/x-patch Size: 642 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20051014/ca42d4b8/fix-return-code.bin -------------- next part -------------- -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian ?????????????
Mike FABIAN
2005-Nov-21 08:51 UTC
[Fontconfig] patch: fall back to POSIX if the effective value of LC_CTYPE is the empty string ""
Patrick Lam <plam@MIT.EDU> ????????:> I''ve applied this patch.Thank you! I made another small patch a while ago which I may have forgotten to submit or which may have been lost. Anyway, it is apparently not yet applied to the fontconfig 2.4 branch. If the effective value of LC_CTYPE is the empty string "", fontconfig should work the same way as in the POSIX locale, i.e. as if the element "lang" is not set. It should not try to parse a "lang" element from the empty string. This makes sure that even if LC_CTYPE is the empty string, fontconfig matches something readable. Without that it apparently matches completely random and might match a font which doesn''t even have ASCII glyphs. As a result, nothing at all may be displayed. For details where this caused a problem for a user, see: http://bugzilla.novell.com/show_bug.cgi?id=102328 -------------- next part -------------- A non-text attachment was scrubbed... Name: bugzilla-102328.patch Type: text/x-patch Size: 476 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20051019/a9058a80/bugzilla-102328.bin -------------- next part -------------- -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian ?????????????
The problem reported below still exists with todays CVS snapshot of the fontconfig 2.4 branch. Do you have any idea how to fix it? Mike FABIAN <mfabian@suse.de> ????????:> with todays CVS snapshot of the fontconfig 2.4 branch: > > mfabian@magellan:~/.fonts$ fc-list : family file | grep -i zenkai > ./ukai.ttf: AR PL ZenKai Uni > mfabian@magellan:~/.fonts$ > mfabian@magellan:~/.fonts$ ls -li --time-style=full-iso ukai.ttf > 197011 -rw-r--r-- 1 mfabian suse 14296192 2005-10-14 14:47:03.000000000 +0200 ukai.ttf > mfabian@magellan:~/.fonts$ ls -lid --time-style=full-iso . > 5505413 drwxr-xr-x 3 mfabian suse 4096 2005-10-14 14:51:01.000000000 +0200 ./ > mfabian@magellan:~/.fonts$ > > Now move the font to a new name and move it back: > > mfabian@magellan:~/.fonts$ mv ukai.ttf ukai-new.ttf > mfabian@magellan:~/.fonts$ mv ukai-new.ttf ukai.ttf > mfabian@magellan:~/.fonts$ ls -li --time-style=full-iso ukai.ttf > 197011 -rw-r--r-- 1 mfabian suse 14296192 2005-10-14 14:47:03.000000000 +0200 ukai.ttf > mfabian@magellan:~/.fonts$ ls -lid --time-style=full-iso . > 5505413 drwxr-xr-x 3 mfabian suse 4096 2005-10-14 14:52:52.000000000 +0200 ./ > mfabian@magellan:~/.fonts$ > > The font still has the same i-node and time stamp and the time-stamp > of the directory is changed (as expected). Now run "fc-cache -v ." > again: > > mfabian@magellan:~/.fonts$ fc-cache -v . > fc-cache: ".": caching, 71 fonts, 1 dirs > fc-cache: "./kde-override": skipping, 0 fonts, 0 dirs > fc-cache: succeeded > mfabian@magellan:~/.fonts$ > > And now the font appears to be gone: > > mfabian@magellan:~/.fonts$ fc-list : family file | grep -i zenkai > mfabian@magellan:~/.fonts$ > > With fontconfig 2.3.2, the font was still available at this point! > > Run fc-cache once more adding the force option: > > mfabian@magellan:~/.fonts$ fc-cache -v -f . > fc-cache: ".": caching, 71 fonts, 1 dirs > fc-cache: "./kde-override": caching, 0 fonts, 0 dirs > fc-cache: succeeded > mfabian@magellan:~/.fonts$ fc-list : family file | grep -i zenkai > ./ukai.ttf: AR PL ZenKai Uni > mfabian@magellan:~/.fonts$ > > Now the font has appeared again. > > -- > Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian > ????????????? > > _______________________________________________ > Fontconfig mailing list > Fontconfig@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/fontconfig >-- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian ?????????????
I just tried to reproduce it now and couldn''t. Can you? pat Mike FABIAN wrote:> The problem reported below still exists with todays CVS snapshot of > the fontconfig 2.4 branch. > > Do you have any idea how to fix it?
James Cloos wrote:> when I ran ''fc-cache -fv .'' in /usr/local/share/fonts. Re-running > with ''fc-cache -fv /usr/local/share/fonts'' got the correct results.The responsible code is at fcfreetype.c:1290. However, I''m not quite sure how to fix it: it seems difficult to get a full pathname from a filename. Or I could just store the filename without any pathname whatsoever. Opinions? BTW, anyone read the mail about config files vs. caches? pat
Mike FABIAN wrote:> Even if only the local file name is stored in the per-directory > cache-files, fc-list should be able to list the full path names, > shouldn''t it? While reading the cache files, fontconfig knows from > what directory the cache file has been read.Unfortunately, fontconfig then throws away this information. I can create an auxiliary data structure to store pairs of bindings (FcPattern *, directory) as they come in from disk, but that will require some hacking. However, I do agree with you that it''s useful to have fc-list print out the directory name, so I''ll try to implement this. pat
Mike FABIAN wrote:>>>>>when I ran ''fc-cache -fv .'' in /usr/local/share/fonts. Re-running >>>>>with ''fc-cache -fv /usr/local/share/fonts'' got the correct results. >>>> >>>>The responsible code is at fcfreetype.c:1290. However, I''m not quite >>>>sure how to fix it: it seems difficult to get a full pathname from a >>>>filename. Or I could just store the filename without any pathname >>>>whatsoever. Opinions? >>> >>>As cache files are per-directory, you need only store the local filename >>>itself. >> >>I''ve just committed this patch. Let me know if you see any problems >>with it. It ought to fix JimC''s issue, but not the more general >>losing-fonts issue.I''ve reverted this patch, as it breaks fontconfig-using applications (the ones that subsequently use Pango to fetch fonts). I''m not sure what the correct solution is, but stripping basenames isn''t it... I guess that I have to put full pathnames, but I don''t know how to get canonical full pathnames. Anyone? pat
>>>>> "Patrick" == Patrick Lam <plam@MIT.EDU> writes:Patrick> I think it''s one per directory; after all, all fonts in the Patrick> same directory have the same pathname! Somehow as I was writing that missive I was thinking that the string passed to open(2) would have to remain around. Obviously it can be free(2)d, so that isn''t really an issue. Patrick> FcPattern contains a ''bank'' field which will tell you about Patrick> the directory, and then I just set up a hash table or Patrick> something which returns the pathname of that directory. How Patrick> does that sound? For new code that does seem right, but how does that work for existing code? Will the lib need to bump it''s version number? It would be cool if it would work with existing pango apps. And w/o having to recompile the whole system.... -JimC -- James H. Cloos, Jr. <cloos@jhcloos.com>
>>>>> "Patrick" == Patrick Lam <plam@MIT.EDU> writes:Patrick> I''ve reverted this patch, as it breaks fontconfig-using Patrick> applications (the ones that subsequently use Pango to fetch Patrick> fonts). I''m not sure what the correct solution is, but Patrick> stripping basenames isn''t it... I guess that I have to put Patrick> full pathnames, but I don''t know how to get canonical full Patrick> pathnames. Anyone? I guess I should have read further before hijacking a thread with a postscript.... [SIGH] Anyway, to answer the question you do ask above, in general you don''t. Going from filename to path is in the same problem space as going from hash to source. With some additional info you can come up with plausible results, but others could also exist. For fc-cache, you can probably presume that <dir/> entries are absolute. Whether you should traverse the path and expand out symlinks is an open question, but that should be the only one. (You do, though, have to convert anything matching ''^~/(.+)$'' into "$HOME/$1". But otherwise relative paths in <dir/> entries can probably be defined as errors.) For paths specified in ARGV[] you need to replace ''^\./(.+)$'' with "$CWD/$1" as well as doing the tilde substitution above. The problem -- and one I should have noticed when I first realized you were storing absolute paths in the cache-2 files -- is that paths are not fixed. Between networked file systems, networked block devices (including things like fibre channel), bind mounts, process-specific namespaces, et al you cannot presume that the absolute paths are constant. Each box mounting an enterprise-wide -- or even just group-wide -- filesystem could use a different mountpoint. Chroot(2)s might bind the box''s master locations at different points. Distributed workstations might mount some central filesystem under the logged-in user''s $HOME. In short, cache-2''s support for multiple machine-specific chunks and its use of absolute paths are pi radians out of phase. The cache-1 files do not use absolute paths; the api allows the library users to locate the fonts anyway. The cache-2 api will have to replicate that behavior. AFAICS, that means each process will have to store the path to each cache-2 file and for each font opened will have to create a string in malloc(2)ed vm from that pathname and the string in the cache-2 file to pass to open(2) or mmap(2). This will regress the vm savings somewhat -- especially for programs that like to show all of the available fonts'' names rendered in said font -- but I don''t see any real alternative. (Though I''d love to be proved wrong. :) How this issue compares with the idea of moving the cache files into a single dir, naming them something like .../$(hash $pathname).cache-$ver, is another interesting question. There, absolute pathnames may be OK, provided the cache files are re-written whenever they are discovered to be out of date or corrupt. (Another interesting question: if the library causes each caller to write out a cache file when needed, what happens when 1000 apps notice the cache file is corrupt or old and start simultaneously writing out a replacement?) -JimC -- James H. Cloos, Jr. <cloos@jhcloos.com>
James Cloos wrote:> Going from filename to path is in the same problem space as going > from hash to source. With some additional info you can come up > with plausible results, but others could also exist.It seems that I should store just the filename, and then information on a per-bank basis containing the prefix for filenames in that bank. Then when we ask about the filename of an FcPattern, we should add the necessary prefix. However, this introduces a strange nonuniformity into FcPatternGetString: if it''s FC_FILE you''re getting, then fontconfig is going to rewrite it for you and append the path of the bank. I''m not sure that would be a good idea, but it seems better than alternative ideas.> AFAICS, that means each process will have to store the path to each > cache-2 file and for each font opened will have to create a string > in malloc(2)ed vm from that pathname and the string in the cache-2 > file to pass to open(2) or mmap(2). This will regress the vm savings > somewhat -- especially for programs that like to show all of the > available fonts'' names rendered in said font -- but I don''t see any > real alternative. (Though I''d love to be proved wrong. :)I think it''s one per directory; after all, all fonts in the same directory have the same pathname! FcPattern contains a ''bank'' field which will tell you about the directory, and then I just set up a hash table or something which returns the pathname of that directory. How does that sound?> How this issue compares with the idea of moving the cache files into a > single dir, naming them something like .../$(hash $pathname).cache-$ver, > is another interesting question. There, absolute pathnames may be OK, > provided the cache files are re-written whenever they are discovered > to be out of date or corrupt. (Another interesting question: if > the library causes each caller to write out a cache file when needed, > what happens when 1000 apps notice the cache file is corrupt or old > and start simultaneously writing out a replacement?)I don''t think that changes anything, since we still have an association between the pathname and the cache file name. pat
Patrick Lam <plam@MIT.EDU> ????????:> Keith Packard wrote: >> On Tue, 2005-10-25 at 17:07 -0400, Patrick Lam wrote: >> >>>James Cloos wrote: >>> >>> >>>>when I ran ''fc-cache -fv .'' in /usr/local/share/fonts. Re-running >>>>with ''fc-cache -fv /usr/local/share/fonts'' got the correct results. >>> >>>The responsible code is at fcfreetype.c:1290. However, I''m not quite >>>sure how to fix it: it seems difficult to get a full pathname from a >>>filename. Or I could just store the filename without any pathname >>>whatsoever. Opinions? >> >> As cache files are per-directory, you need only store the local filename >> itself. > > I''ve just committed this patch. Let me know if you see any problems > with it. It ought to fix JimC''s issue, but not the more general > losing-fonts issue.It does not fix the issue about loosing fonts I have reported, I still see the same problem. Although it does fix JimC''s issue that path names are not stored in the per-directory cache files, it creates the problem that fc-list cannot list the path to the fonts anymore. For example, if I have two copies of tahoma.ttf and tahomabd.ttf in ~/.fonts and in /usr/X11R6/lib/X11/fonts/truetype: mfabian@magellan:~/.fonts$ ll tahoma* -rw-r--r-- 1 mfabian suse 379588 8? 6 2004 tahoma.ttf -rw-r--r-- 1 mfabian suse 352020 8? 6 2004 tahomabd.ttf mfabian@magellan:~/.fonts$ ll /usr/X11R6/lib/X11/fonts/truetype/tahoma* -rw-r--r-- 1 root root 257636 9? 22 06:57 /usr/X11R6/lib/X11/fonts/truetype/tahoma.ttf -rw-r--r-- 1 root root 252384 9? 22 06:57 /usr/X11R6/lib/X11/fonts/truetype/tahomabd.ttf mfabian@magellan:~/.fonts$ Then fc-list cannot tell me anymore where in my system the "Tahoma" fonts are: mfabian@magellan:~/.fonts$ fc-list : family file | grep -i tahoma tahoma.ttf: Tahoma tahomabd.ttf: Tahoma mfabian@magellan:~/.fonts$ Even if only the local file name is stored in the per-directory cache-files, fc-list should be able to list the full path names, shouldn''t it? While reading the cache files, fontconfig knows from what directory the cache file has been read. -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian ?????????????
I just saw a probably similar symptom.
It took a bit of thinking to figure out what I was seeing, but
inspiration eventually struck. It looks like, given an absolute
path named $foo, then:
:; cd $foo && fc-cache -f .
results in different cache files than:
:; fc-cache -f $foo
In the former case the paths in the cache files are relative to $foo,
in the latter they are absolute.
Ie, I got paths like:
"./GhostPCL/URW_Fonts/A028-Med.ttf"
where I should have gotten:
"/usr/local/share/fonts/GhostPCL/URW_Fonts/A028-Med.ttf"
when I ran ''fc-cache -fv .'' in /usr/local/share/fonts.
Re-running
with ''fc-cache -fv /usr/local/share/fonts'' got the correct
results.
-JimC
--
James H. Cloos, Jr. <cloos@jhcloos.com>
Patrick Lam <plam@MIT.EDU> ????????:> I just tried to reproduce it now and couldn''t. Can you?Yes, I can still reproduce this with the CVS snapshot of the fontconfig 2.4 branch from today (20051024).> Mike FABIAN wrote: >> The problem reported below still exists with todays CVS snapshot of >> the fontconfig 2.4 branch. >> >> Do you have any idea how to fix it?-- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian ?????????????
>>>>> "Patrick" == Patrick Lam <plam@MIT.EDU> writes:Patrick> So I was suggesting this slightly evil thing. If you call Patrick> FcPatternGetString for an FC_FILE, then fontconfig will Patrick> silently append the path of the cache file to the path of the Patrick> file. ... ... ... The result is that no changes are visible Patrick> from the outside; no version number bumping or recompilation Patrick> required. OK. I get it now. Looks perfect. -JimC
James Cloos wrote:>>>>>>"Patrick" == Patrick Lam <plam@MIT.EDU> writes: > > > Patrick> I think it''s one per directory; after all, all fonts in the > Patrick> same directory have the same pathname! > > Somehow as I was writing that missive I was thinking that the string > passed to open(2) would have to remain around. Obviously it can be > free(2)d, so that isn''t really an issue.However, every time you ask for the font filename, you''re going to have to create a copy of that filename and keep it around. I can''t think of a way to avoid that, unfortunately; embedding a pointer to the filename in the FcPattern and destroying it in FcPatternDestroy is probably least bad. pat
Patrick Lam wrote:> I added an extra FcDirScan to this codepath. I believe that this fixes > the cache corruption problems. I hate to admit that I''m not entirely > sure why the old code had cache corruption problems, but I''ll look into > that just a bit longer. It seems to make sense though.Of course, when you think you don''t really understand what''s going on, there''s a good chance it''s because you actually don''t understand what''s going on. The problem really was in re-serializing already-serialized FcValues; I forgot a canonicalization there, so that it was writing out garbage pointers. I''ve committed a one-line fix and reverted the previous patch (which would of course always mask the problem). So the losing-font problem and the corrupted font cache problem should both be fixed now. I think this calls for 2.3.92, which I''ll try to release tomorrow morning. Are there any other issues that I should address (possibly post-2.3.92)? pat
hi,
After updating fontconfig, apps which use fontconfig are going to
crash:(, then I found FcPatternGetString(pattern, FC_FILE,... only
returns basename instread of full path name sometimes that make cairo
return NULL font face then app crashes. Then follow to fontconfig,
I think problem is here.
void
FcPatternDestroy (FcPattern *p)
{
int i;
if (FcPatternFindFullFname (p))
FcPatternAddFullFname (p, 0);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
why every call to FcPatternDestroy want to reset font full name, maybe
this object is still hold by others. Removing these two lines,
everything works fine now.:D
Patrick Lam wrote:> James Cloos wrote:
>
>>>>>>> "Patrick" == Patrick Lam
<plam@MIT.EDU> writes:
>>
>>
>>
>> Patrick> So I was suggesting this slightly evil thing. If you call
>> Patrick> FcPatternGetString for an FC_FILE, then fontconfig will
>> Patrick> silently append the path of the cache file to the path of
the
>> Patrick> file. ... ... ... The result is that no changes are
visible
>> Patrick> from the outside; no version number bumping or
recompilation
>> Patrick> required.
>>
>> OK. I get it now. Looks perfect.
>
>
> I''ve implemented this now. It was kind of messy, I guess, because
I had
> to also copy the full pathname whenever I was duplicating an FcPattern
> (and this happens a number of times). It would be nice if I could think
> of a simpler solution, but this seems to work.
>
> So, we have basenames in caches; these basenames are relative to the
> cache file''s (conceptual) location. (Even if we stuff them all in
/var,
> we know what directory the cache file belongs to.) So you can move your
> directories all around the drive, or mount them in different places, and
> things should continue working.
>
> pat
On Wed, 2005-11-02 at 02:40 -0500, Patrick Lam wrote:> Patrick Lam wrote: > > I added an extra FcDirScan to this codepath. I believe that this fixes > > the cache corruption problems. I hate to admit that I''m not entirely > > sure why the old code had cache corruption problems, but I''ll look into > > that just a bit longer. It seems to make sense though. > > Of course, when you think you don''t really understand what''s going on, > there''s a good chance it''s because you actually don''t understand what''s > going on. The problem really was in re-serializing already-serialized > FcValues; I forgot a canonicalization there, so that it was writing out > garbage pointers. I''ve committed a one-line fix and reverted the > previous patch (which would of course always mask the problem). So the > losing-font problem and the corrupted font cache problem should both be > fixed now.Cool that you found that.> I think this calls for 2.3.92, which I''ll try to release tomorrow > morning. Are there any other issues that I should address (possibly > post-2.3.92)?I would like to see the freetype-internals patch get in before 2.4
Matthias Clasen wrote:>>I think this calls for 2.3.92, which I''ll try to release tomorrow >>morning. Are there any other issues that I should address (possibly >>post-2.3.92)? > > I would like to see the freetype-internals patch get in before 2.4I haven''t had a chance to understand it yet. It seems to be useful, and should probably get in before 2.4. However, I''m not especially proficient with that area of the code, and you hadn''t tested it when you sent the patch. Could you test it, and I''ll try to understand what it does. pat
James Cloos wrote:>>>>>>"Patrick" == Patrick Lam <plam@MIT.EDU> writes: > > Patrick> I think it''s one per directory; after all, all fonts in the > Patrick> same directory have the same pathname! > > Somehow as I was writing that missive I was thinking that the string > passed to open(2) would have to remain around. Obviously it can be > free(2)d, so that isn''t really an issue.Well, I need to keep one copy around per directory, but that should be enough, and not that much of a memory drain.> Patrick> FcPattern contains a ''bank'' field which will tell you about > Patrick> the directory, and then I just set up a hash table or > Patrick> something which returns the pathname of that directory. How > Patrick> does that sound? > > For new code that does seem right, but how does that work for existing > code? Will the lib need to bump it''s version number? It would be > cool if it would work with existing pango apps. And w/o having to > recompile the whole system....So I was suggesting this slightly evil thing. If you call FcPatternGetString for an FC_FILE, then fontconfig will silently append the path of the cache file to the path of the file. (I guess I''ll also add a pointer to the FcPattern for the path, but that''s not visible outside fontconfig). If you call FcPatternGetString for anything else, nothing changes. The result is that no changes are visible from the outside; no version number bumping or recompilation required. pat
James Cloos wrote:>>>>>>"Patrick" == Patrick Lam <plam@MIT.EDU> writes: > > > Patrick> So I was suggesting this slightly evil thing. If you call > Patrick> FcPatternGetString for an FC_FILE, then fontconfig will > Patrick> silently append the path of the cache file to the path of the > Patrick> file. ... ... ... The result is that no changes are visible > Patrick> from the outside; no version number bumping or recompilation > Patrick> required. > > OK. I get it now. Looks perfect.I''ve implemented this now. It was kind of messy, I guess, because I had to also copy the full pathname whenever I was duplicating an FcPattern (and this happens a number of times). It would be nice if I could think of a simpler solution, but this seems to work. So, we have basenames in caches; these basenames are relative to the cache file''s (conceptual) location. (Even if we stuff them all in /var, we know what directory the cache file belongs to.) So you can move your directories all around the drive, or mount them in different places, and things should continue working. pat
Mike FABIAN wrote:> And now the font appears to be gone: > > mfabian@magellan:~/.fonts$ fc-list : family file | grep -i zenkai > mfabian@magellan:~/.fonts$Not only that, but .fonts.cache-2 then becomes corrupted. Interesting, eh? This seems to be the source of the cache corruption; if you run fc-cat on fonts.cache-2 at this point, you''ll find that it segfaults. I added an extra FcDirScan to this codepath. I believe that this fixes the cache corruption problems. I hate to admit that I''m not entirely sure why the old code had cache corruption problems, but I''ll look into that just a bit longer. It seems to make sense though. pat
sunmoon1997 wrote:> hi, > After updating fontconfig, apps which use fontconfig are going to > crash:(, then I found FcPatternGetString(pattern, FC_FILE,... only > returns basename instread of full path name sometimes that make cairo > return NULL font face then app crashes. Then follow to fontconfig, > I think problem is here. > void > FcPatternDestroy (FcPattern *p) > { > int i; > > if (FcPatternFindFullFname (p)) > FcPatternAddFullFname (p, 0); > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > why every call to FcPatternDestroy want to reset font full name, maybe > this object is still hold by others. Removing these two lines, > everything works fine now.:DThat''s quite mysterious. Oh! I bet that someone''s trying to destroy a constant font; the check for constantness is two lines down. So I bet it would work if I moved this two lines down. But also, there''s a memory leak here. I''ve committed an improved version, which, I believe, gets rid of the memory leak as well. pat
On Tue, 2005-10-25 at 17:07 -0400, Patrick Lam wrote:> James Cloos wrote: > > > when I ran ''fc-cache -fv .'' in /usr/local/share/fonts. Re-running > > with ''fc-cache -fv /usr/local/share/fonts'' got the correct results. > > The responsible code is at fcfreetype.c:1290. However, I''m not quite > sure how to fix it: it seems difficult to get a full pathname from a > filename. Or I could just store the filename without any pathname > whatsoever. Opinions?As cache files are per-directory, you need only store the local filename itself. -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/20051025/e5e4687c/attachment.pgp
Keith Packard wrote:> On Tue, 2005-10-25 at 17:07 -0400, Patrick Lam wrote: > >>James Cloos wrote: >> >> >>>when I ran ''fc-cache -fv .'' in /usr/local/share/fonts. Re-running >>>with ''fc-cache -fv /usr/local/share/fonts'' got the correct results. >> >>The responsible code is at fcfreetype.c:1290. However, I''m not quite >>sure how to fix it: it seems difficult to get a full pathname from a >>filename. Or I could just store the filename without any pathname >>whatsoever. Opinions? > > As cache files are per-directory, you need only store the local filename > itself.I''ve just committed this patch. Let me know if you see any problems with it. It ought to fix JimC''s issue, but not the more general losing-fonts issue. Index: src/fcfreetype.c ==================================================================RCS file: /cvs/fontconfig/fontconfig/src/fcfreetype.c,v retrieving revision 1.60.2.4 diff -u -r1.60.2.4 fcfreetype.c --- src/fcfreetype.c 22 Oct 2005 15:12:05 -0000 1.60.2.4 +++ src/fcfreetype.c 25 Oct 2005 22:28:33 -0000 @@ -47,6 +47,7 @@ #include <stdlib.h> #include <stdio.h> #include <string.h> +#include <libgen.h> #include "fcint.h" #include <ft2build.h> #include FT_FREETYPE_H @@ -1287,7 +1288,7 @@ printf ("Saving unique fullname %s\n", full); } - if (!FcPatternAddString (pat, FC_FILE, file)) + if (!FcPatternAddString (pat, FC_FILE, (FcChar8 *)basename((char *)file))) goto bail1; if (!FcPatternAddInteger (pat, FC_INDEX, id)) pat