Re: [ft] Failure in loading U+033F in DejaVu fonts

[suzuki toshiya]

Dear Werner,

Just I've committed the simpler patch.

Reading your comment carefully, "might not be working with the
platform whose default pointer is less than 32-bit" was already
commented :-).

Maybe just 16-bit compiler would not be sufficient, the compilers
supporting Intel tiny/small/medium memory model should be used
to check what will happen. Watcom compiler could be a candidate.
But please let me work for this issue in later...

Regards,
mpsuzuki


Werner LEMBERG wrote:
>> I updated the simplest fix in my hand.  I was going to commit it to
>> head of git repository, but savannah is in some network trouble.
>> Attached is the patch, but if anybody wants, I will make a "make
>> dist" tarball which is ready to "./configure && make".  please let
>> me know.
> 
> Savannah seems to be back, so please proceed!
> 
>> Also I have more complex patch using same strategy but do not rely
>> on arbitrary usage of GID.  I think the current patch would work on
>> the platforms whose default pointer is 32-bit.  For the platform
>> whose default pointer is 16-bit or shorter, some fonts having 64k
>> glyphs can confuse the simplest fix.
> 
> I haven't tested 16bit support since years, given that you can't
> create 16bit code with gcc.[*] However, I've just found in the
> internet that recent clang versions support an `-m16' option that
> apparently produces valid 16bit code!  So you might test compilation
> of FreeType with this option, but I guess that you will find zillions
> of problems...
> 
> Today, I'm no longer sure whether 16bit support makes sense at all, so
> maybe you shouldn't spend time on this.
> 
> 
>     Werner
> 
> 
> [*] Option `-m16' introduced in gcc 4.9.0 doesn't provide a real 16bit
>     environment; it has a special usage for bootloader code and the
>     like.
>