This post is something like a memo for myself, but I think
it could be useful somebody interested in LFS...
Yet I've not finished a compilation for minimum patchset
for LFS... Because following barriers, an introduction
of new variable type FT_StreamOffset which is something
like off_t would be expected.
1) FreeType stream I/O functions should be (incompatibly) changed
The public API file, ftsystem.h has a following API for
the stream object in FreeType;
typedef struct FT_StreamRec_
{
unsigned char* base;
unsigned long size;
unsigned long pos;
FT_StreamDesc descriptor;
FT_StreamDesc pathname;
FT_Stream_IoFunc read;
FT_Stream_CloseFunc close;
FT_Memory memory;
unsigned char* cursor;
unsigned char* limit;
} FT_StreamRec;
Also read/seek the stream object of FreeType has 32-bit
limitation.
typedef unsigned long
(*FT_Stream_IoFunc)( FT_Stream stream,
unsigned long offset,
unsigned char* buffer,
unsigned long count );
Apparently, it should be (incompatibly) changed when
LFS > 32-bit is expected on ILP32 platforms.
2) FreeType memory allocator should be (incompatibly) changed
Because FreeType2 tries to use mmap() for faster access of
the font file, if we consider the possibility that a file
over 32-bit is mmap()ed, the size of memory buffer should be
dealt by size_t, not by long typed variables (on ILP32 systems).
Even if we exclude such possibility, FT_StreamRec class
does not distinguish the size/pos for memory buffer from those
for file handle.
On 11/25/2013 09:29 PM, suzuki toshiya wrote:
> Dear Behdad,
>
> Thank you for comment. Yes, the most widely used font formats
> in today, TrueType derivatives, are not designed to be greater
> than 4GB, it would be a reason why few people is interested in
> the radical (binary-incompatible) change of FreeType to support
> LFS.
>
> Regards,
> mpsuzuki
>
> On 11/25/2013 08:11 PM, Behdad Esfahbod wrote:
>> On 13-11-23 03:23 AM, Werner LEMBERG wrote:
>>>
>>> Toshiya-san,
>>>
>>>
>>> thanks for your analysis. I wasn't aware of this situation.
>>>
>>>> I'm questionable which is more forthcoming; the disappear of ILP32
>>>> or the inflation of font filesize greater than 2GB. When FreeType3
>>>> is planned, of course I will propose the changeset to support LFS
>>>> natively.
>>>
>>> Do you think that a workaround for Unix is possible, as I've tried to
>>> outline in another e-mail?
>>
>> I'd say just limit acceptable font size to 2GB and move on.
>>
>
>
> _______________________________________________
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>
_______________________________________________
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
