Now I'm back with the compilation of freetype, I followed mpsuzuki's
advise but my target needs big-endian coding... If someone has some
hints for doing this I would apprechiate it very much. If not, will
have to figure it out on monday. Thanks alot for all help!
/Fredrik
On Sat, 5 Nov 2005 00:10:24 +0900
[EMAIL PROTECTED] wrote:
On Fri, 4 Nov 2005 15:12:36 +0100
Fredrik Carlbom [EMAIL PROTECTED] wrote:
Now I'm back with the compilation of freetype, I followed mpsuzuki's
advise but my target needs big-endian coding... If someone has some
hints for doing this I
I could build FreeType2 CVS that is checked out 2005/10/25 as
previous post. But, cross building of revisions after 2005/10/28
might fail. apinames is not enabled for cross building (I think
it's my next task after MacOS issue.
Thanks in advance for taking care of this particular problem!
This might be interesting for some of you. It means in consequence
that the higher-level code which handles GPOS has probably to discard
the kern values FreeType returns (which only looks at the `kern'
table).
Werner
---BeginMessage---
OpenType list address: [EMAIL PROTECTED]
Thomas
On Fri, Nov 04, 2005 at 11:55:16AM +0100, Werner LEMBERG wrote:
I can uderstand it but I do have a suggestion for improving it.
Excellent.
Just swapping two of the clauses around makes it better IMO: [...]
The docs for FT_New_Face() and FT_New_Memory_Face() also need to be
updated
Attached. It includes the change I suggested and copies the same
description to FT_New_Face() and FT_New_Memory_Face().
Applied, thanks.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
Hi,
Thanks for the note. Sorry but I do not have the test case, I just
looked at the code and found out the bug.
And I think there should be more change in this code section: 'limit'
should be reset by 'buffer + readsize' in where readsize is actual
read size.
Thanks,
TK
2005/11/3, [EMAIL
