Re: [ft-devel] Known problem with FT_StreamRec::base being non-NULL also for file-based streams?

[Behdad Esfahbod]

On 03/05/2010 02:26 AM, address@hidden 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