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

[suzuki toshiya]

Dear Werner,

Oh, I slipped to mention a change from my patch in previous
post and committed one. In previous post in this list, I added
a public function FT_List_GetNodeAt(). But, now I moved it into
ttgload.c, as a private function. It is just because once we
publish some function, we cannot withdraw it. If there is a
better place to include the internal utility functions, I will
do so.

Regards,
mpsuzuki

suzuki toshiya wrote:
> 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.
>>
> 
> _______________________________________________
> Freetype mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/freetype
>