Dear all, Please find attached the fontconfig patches that we are currently using to fix various issues. Feel free to merge these patches upstream. - fontconfig-2.6.0-win32-full-path.patch fix bogus use of GetFullPathName on Win32; the last argument is a pointer to char* not a char buffer. - fontconfig-2.6.0-decl.patch fix C++ style declarations to work with non-gcc C compilers - fontconfig-2.6.0-APPSHAREFONTDIR.patch introduce a new magic APPSHAREFONTDIR path in the configuration file to mean ../share/fonts with respect to the executable location - fontconfig-2.6.0-Win32-netpath.patch fix FcConvertDosPath() to not remove leading ''\\'' so that network paths work under Win32 - fontconfig-2.6.0-cache-validation.patch if the in memory and on disk caches are the same validate that the cache is still up to date, otherwise runtime font installation does not work until fc-cache or some other app rebuilds the cache file. - fontconfig-2.6.0-cache-insert.patch when a cache is rebuilt and inserted into the linked list of caches the stat data should be brought up to date once the cache is written to disk, otherwise the next time the cache is verified it will be reloaded even if the in memory version matches the on disk cache. - fontconfig-2.6.0-Win32-atomic-replace.patch under Windows an mmap''ed file cannot be removed so FcAtomicReplaceOrig() fails if the old cache is larger than FC_CACHE_MIN_MMAP and is still open (either by the same or other app); this patch workarounds this issue by renaming the old cache file if the unlink fails. Note that with this patch fontconfig may leave .OLD cache files around, but I do not have a better idea on how to overcome this. Feedback is of course always welcome. Best, Diego -- Diego Santa Cruz, PhD Technology Architect _________________________________ SpinetiX S.A. Rue des Terreaux 17 1003, Lausanne, Switzerland T +41 21 341 15 50 F +41 21 311 19 56 diego.santacruz at spinetix.com http://www.spinetix.com _________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: fontconfig-2.6.0-win32-full-path.patch Type: application/octet-stream Size: 364 bytes Desc: fontconfig-2.6.0-win32-full-path.patch Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20090203/b65c4a0d/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: fontconfig-2.6.0-decl.patch Type: application/octet-stream Size: 791 bytes Desc: fontconfig-2.6.0-decl.patch Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20090203/b65c4a0d/attachment-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: fontconfig-2.6.0-APPSHAREFONTDIR.patch Type: application/octet-stream Size: 706 bytes Desc: fontconfig-2.6.0-APPSHAREFONTDIR.patch Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20090203/b65c4a0d/attachment-0002.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: fontconfig-2.6.0-Win32-netpath.patch Type: application/octet-stream Size: 219 bytes Desc: fontconfig-2.6.0-Win32-netpath.patch Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20090203/b65c4a0d/attachment-0003.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: fontconfig-2.6.0-cache-validation.patch Type: application/octet-stream Size: 527 bytes Desc: fontconfig-2.6.0-cache-validation.patch Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20090203/b65c4a0d/attachment-0004.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: fontconfig-2.6.0-cache-insert.patch Type: application/octet-stream Size: 931 bytes Desc: fontconfig-2.6.0-cache-insert.patch Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20090203/b65c4a0d/attachment-0005.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: fontconfig-2.6.0-Win32-atomic-replace.patch Type: application/octet-stream Size: 891 bytes Desc: fontconfig-2.6.0-Win32-atomic-replace.patch Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20090203/b65c4a0d/attachment-0006.obj
Diego Santa Cruz wrote:> Dear all,Hi Deigo,> Please find attached the fontconfig patches that we are currently using > to fix various issues. Feel free to merge these patches upstream.I''ve committed all but the last two.> - fontconfig-2.6.0-cache-insert.patch > when a cache is rebuilt and inserted into the linked list of > caches the stat data should be brought up to date once the cache is > written to disk, otherwise the next time the cache is verified it will > be reloaded even if the in memory version matches the on disk cache.Wouldn''t we be better off freeing the cache we have and loading it from disk? That way we can mmap it. Right?> - fontconfig-2.6.0-Win32-atomic-replace.patch > under Windows an mmap''ed file cannot be removed so > FcAtomicReplaceOrig() fails if the old cache is larger than > FC_CACHE_MIN_MMAP and is still open (either by the same or other app); > this patch workarounds this issue by renaming the old cache file if the > unlink fails. Note that with this patch fontconfig may leave .OLD cache > files around, but I do not have a better idea on how to overcome this.This should be fine. What if the OLD file is still in use? Then we still fail. How about trying OLD, OLD2, OLD3? OLD files will still be use if there''s an application mapping them still. For example, even with your patch, the second time you install fonts, it may fail. behdad> Feedback is of course always welcome. > > Best, > > Diego > > -- > Diego Santa Cruz, PhD > Technology Architect > _________________________________ > SpinetiX S.A. > Rue des Terreaux 17 > 1003, Lausanne, Switzerland > T +41 21 341 15 50 > F +41 21 311 19 56 > diego.santacruz at spinetix.com > http://www.spinetix.com > _________________________________ > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Fontconfig mailing list > Fontconfig at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/fontconfig
> -----Original Message----- > From: Behdad Esfahbod [mailto:behdad.esfahbod at gmail.com] On Behalf Of > Behdad Esfahbod> I''ve committed all but the last two.Glad to know that I can contribute a bit to open source projects :-)> > > - fontconfig-2.6.0-cache-insert.patch > > when a cache is rebuilt and inserted into the linked list of > > caches the stat data should be brought up to date once the cache is > > written to disk, otherwise the next time the cache is verified it > will > > be reloaded even if the in memory version matches the on disk cache. > > Wouldn''t we be better off freeing the cache we have and loading it from > disk? > That way we can mmap it. Right? >Yeah, that would be even better. I admit that I stopped halfway through, but when I saw that the cache files in our setting are at most a few KBytes then I moved to some more urgent stuff. However using the mmap is an additional step on top of this patch (or a modified version of it), since if the cache size is less than the minimum mmap size there is no point in re-reading it from disk and this patch is still useful.> > - fontconfig-2.6.0-Win32-atomic-replace.patch > > under Windows an mmap''ed file cannot be removed so > > FcAtomicReplaceOrig() fails if the old cache is larger than > > FC_CACHE_MIN_MMAP and is still open (either by the same or other > app); > > this patch workarounds this issue by renaming the old cache file if > the > > unlink fails. Note that with this patch fontconfig may leave .OLD > cache > > files around, but I do not have a better idea on how to overcome > this. > > This should be fine. What if the OLD file is still in use? Then we > still > fail. How about trying OLD, OLD2, OLD3? OLD files will still be use > if > there''s an application mapping them still. For example, even with your > patch, > the second time you install fonts, it may fail. >Yep, I agree that this is only a partial solution that works in some cases only. In our app it does work since after reloading the fontconfig caches we force pango to drop all its fontconfig references as well, so the OLD file is never mapped when we need to write a new one. I''m not comfortable using too many OLDx files since that may leave quite a bit of old files around in the cache directory. Unfortunately I have not come up with any better way of doing this. Is there a way in Windows to at least mark a file for deletion once nobody has it mapped nor opened ? That would be a way of not leaving useless files behind. What do you think would be a sane number of OLDx versions to try before giving up? Best, Diego PS: sorry if the lines in this message are too long, I''m really fighting with MS Outlook to be more Internet friendly but somehow it sometimes insists in not formatting Internet messages to the specified width.
Diego Santa Cruz wrote:>> -----Original Message----- >> From: Behdad Esfahbod [mailto:behdad.esfahbod at gmail.com] On Behalf Of >> Behdad Esfahbod > >> I''ve committed all but the last two. > > Glad to know that I can contribute a bit to open source projects :-) > >>> - fontconfig-2.6.0-cache-insert.patch >>> when a cache is rebuilt and inserted into the linked list of >>> caches the stat data should be brought up to date once the cache is >>> written to disk, otherwise the next time the cache is verified it >> will >>> be reloaded even if the in memory version matches the on disk cache. >> Wouldn''t we be better off freeing the cache we have and loading it from >> disk? >> That way we can mmap it. Right? >> > > Yeah, that would be even better. I admit that I stopped halfway through, but when I saw that the cache files in our setting are at most a few KBytes then I moved to some more urgent stuff. However using the mmap is an additional step on top of this patch (or a modified version of it), since if the cache size is less than the minimum mmap size there is no point in re-reading it from disk and this patch is still useful.Right. I''ll give it a try. But I''m short in time for testing this. So if you can do that, would be even better.>>> - fontconfig-2.6.0-Win32-atomic-replace.patch >>> under Windows an mmap''ed file cannot be removed so >>> FcAtomicReplaceOrig() fails if the old cache is larger than >>> FC_CACHE_MIN_MMAP and is still open (either by the same or other >> app); >>> this patch workarounds this issue by renaming the old cache file if >> the >>> unlink fails. Note that with this patch fontconfig may leave .OLD >> cache >>> files around, but I do not have a better idea on how to overcome >> this. >> >> This should be fine. What if the OLD file is still in use? Then we >> still >> fail. How about trying OLD, OLD2, OLD3? OLD files will still be use >> if >> there''s an application mapping them still. For example, even with your >> patch, >> the second time you install fonts, it may fail. >> > > Yep, I agree that this is only a partial solution that works in some cases only. In our app it does work since after reloading the fontconfig caches we force pango to drop all its fontconfig references as well, so the OLD file is never mapped when we need to write a new one. I''m not comfortable using too many OLDx files since that may leave quite a bit of old files around in the cache directory. Unfortunately I have not come up with any better way of doing this. Is there a way in Windows to at least mark a file for deletion once nobody has it mapped nor opened ? That would be a way of not leaving useless files behind. What do you think would be a sane number of OLDx versions to try before giving up?That''s a question for win32 people. AFAIC, something like 3 or 4 is fine. behdad> Best, > > Diego > > PS: sorry if the lines in this message are too long, I''m really fighting with MS Outlook to be more Internet friendly but somehow it sometimes insists in not formatting Internet messages to the specified width.
Behdad Esfahbod wrote:>>>> - fontconfig-2.6.0-cache-insert.patchOk, I''ve also pushed a variant of this now. Seems to work in my limited testing.>>>> - fontconfig-2.6.0-Win32-atomic-replace.patchI can''t test on Win32, so I''ll test for a revised version of this one. Thanks for all the patches! behdad