On 03/05/2010 02:26 AM, mpsuz...@hiroshima-u.ac.jp wrote: > >> Checking the source code, I wonder if I should also check for (face_flags & >> FT_FACE_FLAG_EXTERNAL_STREAM) to detect whether it's an mmapped stream or the >> user provided it (and hence we cannot mprotect). The docs say: "Don't read >> or >> test this flag." > > Please let me know more detail about what the information > is needed at the part. Yet I'm not understanding the idea > of "blob" in HarfBuzz.
Well, in short, all the hb_blob_t in HarfBuzz is about communicating to harfbuzz what it can do with the memory backing the font file. There are three different cases we are interested in: - The memory is read-only; harfbuzz will make a copy if it needs to modify it. - The memory is writable and it is ok to write to it. harfbuzz will not make a copy. - The memory is read-only, but can be made writable using mprotect() or similar (win32, ...) functionality. HarfBuzz only makes changes to the font data if it detects corrupt fonts. The changes are NOT meant to be written back to the font file. Currently the hb-ft glue layer assumes that font data is mmap()ed or are otherwise mprotect()able. This fails for examples when: - Font data is in ROM. In this case mprotect() will fail and harfbuzz will make a copy of the memory. Not a huge problem. - FreeType malloc()ed the font data. In this case, mprotect() is not necessary and will probably affect memory beyond the font data (since mprotect works on whole pages). - Font data is coming from the user. In this case it may not be desirable to modify the data. Adding API to FTStream to be able to detect the above cases, specially the user-provided data, would be useful. Thanks, behdad _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
