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 [email protected] https://lists.nongnu.org/mailman/listinfo/freetype
