[Fontconfig] Re: [patch]: mmapping FontConfig data structures

[Keith Packard]

On Fri, 2005-06-10 at 13:50 -0400, Patrick Lam wrote:

> It so happens that I have also modified fontconfig to make most internal
> data structures offset-based rather than address-based, and it would be
> relatively straightforward.  However, this causes a large diff file, and
> can productively be done in another diff if you'd be willing to commit
> this one, so that we separate the two sets of major changes from each other.

I think separating these two changes is a good idea.

> I'm not currently familiar with the existing 'fc-cache' program, but
> will look into it.  I also need to think a bit about how to do automatic
> discovery of new fonts, but it ought to be possible with a bit of work.

fc-cache constructs the fonts.cache-1 files from the internal
representation.  Note that fontconfig also stores cache information in
~/.fonts.cache-1 for fonts which aren't stored in the per-directory
fonts.cache-1 files.  The '-1' in both
of these names is designed to version the cache information, when we
change the representation of the cache files, we'll want to bump that
version number.

The ~/.fonts.cache file will also want to use this new mmap-able format.

> Going to an offset-based representation would make these files
> address-independent.  This is straightforward but tedious.

With your plan to do these changes in two stages, we will (at least) be
able to test this more invasive change separately.

> As with my earlier diff from two months back, the only
> externally-visible change would be FcPattern* -> FcPatternIdx.

We can't have any externally visible changes as that would require
recoding every fontconfig using application...

I suggest that either we permit two separate representations within the
FcPattern datatype or we figure out how to use an offset-based
representation for dynamically created patterns.

> How would you like to proceed?  I could equally well cook up a patch
> which changes FcPattern* -> FcPatternIdx, etc and you could commit that
> first.  

I think this is a good first step

> This would be a large but straightforward patch, easy to review;
> from that version, I could fix the current patch to use offsets instead.

I'm not sure we want this intermediate state at all.

> Once we have the functionality in the current patch, then I could look
> into automatic updating and subsuming the current cache files.

The automatic updating of the cache files is already managed by
fontconfig, so all that we need to is change the representation of those
cache files.

-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/20050610/f24125dd/attachment.pgp