On Sun, 08 Jul 2007 12:11:29 +0200, "Daniel Diaz" <[EMAIL PROTECTED]> said: > Hi, > > First of all thank you very much for this wonderful library. > > I have searched the archive of this list, so I hope I don't ask neither > a trivial question nor an already answered question. > > I'd like to use the cache subsystem for font faces but some points are > not clear enough. Here is what I have understood : > > 1) I have to manage my own data structure (e.g. hash-table) to always > provide a unique FTC_FaceID to the cache. > this doesn't need to be as complex as a hash table. What's really required is that every FTC_FaceID is unique and corresponds to an immutable font reference. The demo program simply malloc a structure for each font listed in a directory, and return their address as the FTC_FaceID.
> 2) The relation between a FCT_FaceID and a FT_Face is done by a callback > function (my face_requester function). > > 3) It is up to me to obtain a face (with FT_New_Face) and to maintain > the relation between a FCT_FaceID and a FT_Face. the cache sub-system doesn't know anything about how fonts are installed and accessed on your system. so basically, you abstract the font references through a FTC_FaceID, and the cache uses them as follows: - directly compares their value for lookups/matches - calls the "face requester" callback to obtain a FT_Face object from it the face requester must "translate" a FTC_FaceID into a new FT_Face object. when the requester exists, the cache sub-system *owns* the FT_Face and will be free to release it any time it deems appropriate. > 4) I use FTC_Manager_LookupFace with a FTC_FaceID to obtain a face from > the cache, which acts as follows: > 4.1) if a FT_Face corresponding to FTC_FaceID is found it is > returned, else > 4.2) if there is a free room the face is added to the cache, else > 4.3) the oldest entry is removed from the cache and the new one is > added. The cache calls FT_Done_Face on the removed face. > yes > Q1) Is this correct ? BTW: it would be great if a "skeleton" of a user > code could be added to the documentation. > > Q2) There is an asymmetry: I create the face (FT_New_Face) but it is > destroyed by the cache (4.3). I conclude my face_requester function is > ONLY called in 4.3 and thus has to perform a FT_New_Face / > FT_New_Memory_Face. Is it ok ? yes, the idea is that *you* know how to access the font files (where they're stored, either on disk/memory/wathever), so you should be responsible for creating the FT_Face. After that, the cache sub-system manages the object(s) I ask this because initially I tough I could keep triplets <path_name, font_index, FT_Face> in my data > structure (and thus the face_requester simply returns the associated > FT_Face). BTW: this also could be documented. > you don't need to keep the FT_Face, a FTC_FaceID would typically point to a (path, face_index) tuple, but can also be more complex depending on your needs. the important point is that the content referenced by the FTC_FaceID should not change between cache API calls. > Q3) Is there a way to be informed when an entry is removed from the > cache (4.3) ? > no, and you shouldn't know, this would only make things more complex, and probably slower too. > Q4) Else, how can I remove useless entries from my own data structure ? > I mean if the cache only uses max_faces entries, I'd like to use tmore > or less he same amount for my own data structure (it is for an embedded > application where memory usage is crucial) ? From what I have understood > my data structure always grows... If true this is a serious > (un)limitation :-) > you don't need to manage the FT_Face objects yourself, they're are totally owner by the cache sub-system once the face requester exits. Of course, you can still open other FT_Face objects in other parts of your code, but they will simply not be used/managed by the cache itself... Hope this helps, - David Turner > Thank you very much for your help. > > > > > > _______________________________________________ > Freetype-devel mailing list > Freetype-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/freetype-devel _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel