(also posted to CFFI list)
Hello!
I'm trying to use libfreetype.so via CFFI. What I hacked up so far is located here:
http://www.common-lisp.ru/cleft.asd http://www.common-lisp.ru/cleft.lisp
The code like that works:
(with-freetype lib (with-face lib (face "/usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf") (docharmap (code face) (format t "~a " (code-char code)))))
and prints out all glyphs in a font.
However, the following doesn't do what I want:
(with-freetype lib (with-face lib (face "/usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf") (set-char-size face (* 16 64) (* 16 64) 300 300) (glyph-pixarray face (char-code #\a))))
It returns #2A() Looks like the whole bitmap structure is set to zeros.
I think I'm following FreeType and CFFI tutorials closely and I can't explain what's wrong...
Thank you for your help, Dmitri
Dmitri Hrapof wrote:
(also posted to CFFI list)
Hello!
I'm trying to use libfreetype.so via CFFI. What I hacked up so far is located here:
http://www.common-lisp.ru/cleft.asd http://www.common-lisp.ru/cleft.lisp
The code like that works:
(with-freetype lib (with-face lib (face "/usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf") (docharmap (code face) (format t "~a " (code-char code)))))
and prints out all glyphs in a font.
However, the following doesn't do what I want:
(with-freetype lib (with-face lib (face "/usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf") (set-char-size face (* 16 64) (* 16 64) 300 300) (glyph-pixarray face (char-code #\a))))
It returns #2A() Looks like the whole bitmap structure is set to zeros.
I think I'm following FreeType and CFFI tutorials closely and I can't explain what's wrong...
Thank you for your help, Dmitri
mcclim-devel mailing list mcclim-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
Dmitri, I cargo-culted a mcclim-freetype-cffi out of mcclim-freetype (because the latter was SBCL specific and I use ACL). Have a look in the McCLIM CVS repository. You should find it there.
I'm afraid that I can't help you much beyond that --- I didn't actually *understand* freetype, I just removed the SBCL dependencies from mcclim-freetype (which is really mcclim-freetype-sbcl, AFAICT).
I've been hoping that the CFFI version would become more official, but it doesn't seem to have gotten any traction. I'm not actually sure that freetype in general has, for that matter.
HTH, Robert
Robert P. Goldman <rpgoldman <at> sift.info> writes:
I cargo-culted a mcclim-freetype-cffi out of mcclim-freetype (because the latter was SBCL specific and I use ACL).
And I took much of my small code from your mcclim-freetype-cffi. Thank you very much!
On Thu, Dec 07, 2006 at 07:40:47AM -0600, Robert P. Goldman wrote:
I'm afraid that I can't help you much beyond that --- I didn't actually *understand* freetype, I just removed the SBCL dependencies from mcclim-freetype (which is really mcclim-freetype-sbcl, AFAICT).
mcclim-freetype works fine with CMUCL, too. (Although you might need to be running telent-clx, rather than the CLX that comes with CMUCL.)
',mr
Martin Rydstr|m wrote:
On Thu, Dec 07, 2006 at 07:40:47AM -0600, Robert P. Goldman wrote:
I'm afraid that I can't help you much beyond that --- I didn't actually *understand* freetype, I just removed the SBCL dependencies from mcclim-freetype (which is really mcclim-freetype-sbcl, AFAICT).
mcclim-freetype works fine with CMUCL, too. (Although you might need to be running telent-clx, rather than the CLX that comes with CMUCL.)
',mr
OK. I stand corrected. Nevertheless, I argue that a freetype approach based on CFFI, which is portable over non-CMU-derived lisps as well as CMU-derived lisps is preferable, prima facie. Now, there may be some additional considerations that would make the CMU-derived-specific approach better, but I don't know of any. If you do, please let me know.
Note I'm not trying to brag about my code and denigrate others. All I did was tweak the CMU-derived-specific approach to backend to CFFI instead, a pretty minor change (and one that I did with virtually no understanding of the code.
Cheers, R
Robert Goldman wrote:
OK. I stand corrected. Nevertheless, I argue that a freetype approach based on CFFI, which is portable over non-CMU-derived lisps as well as CMU-derived lisps is preferable, prima facie. Now, there may be some additional considerations that would make the CMU-derived-specific approach better, but I don't know of any. If you do, please let me know.
Note I'm not trying to brag about my code and denigrate others. All I did was tweak the CMU-derived-specific approach to backend to CFFI instead, a pretty minor change (and one that I did with virtually no understanding of the code.
To add some historical perspective to the issue:
The mcclim-freetype code was created by Gilbert Baumann. I did the initial conversion to SBCL. This involved more than just changing package names; in order to make it usable, the code had to be changed such that SBCL no longer warned about runtime calls to %SAP-ALIEN. Not only did it worn at compile time about this; it actually generated warnings at runtime initially too. Along the way, I added a few caches to speed up glyph rendering, which finally resulted in something I could bear to use daily in climacs and the listener.
Making the compiler happy wrt %SAP-ALIEN was not trivial, and if there's anything I would be worried about in the CFFI version, it's that somewhere one of those optimizations is not implemented. If it's usably fast, I guess everything is OK. Not having used CFFI, I don't know if SBCL will still warn about these as profusely as it does when using good ol' SB-ALIEN.
Brian Mastenbrook brian@mastenbrook.net writes:
Making the compiler happy wrt %SAP-ALIEN was not trivial, and if there's anything I would be worried about in the CFFI version, it's that somewhere one of those optimizations is not implemented. If it's usably fast, I guess everything is OK. Not having used CFFI, I don't know if SBCL will still warn about these as profusely as it does when using good ol' SB-ALIEN.
I don't think that should be a worry: AFAIK CFFI uses plain SAPs all the time, making it oftentimes faster then SB-ALIEN. (The downside of this approach is losing the type-safety SB-ALIEN provides).
...or that is my impression, but I'm not awfully familiar with CFFI.
Cheers,
-- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs."
Brian Mastenbrook wrote:
Robert Goldman wrote:
OK. I stand corrected. Nevertheless, I argue that a freetype approach based on CFFI, which is portable over non-CMU-derived lisps as well as CMU-derived lisps is preferable, prima facie. Now, there may be some additional considerations that would make the CMU-derived-specific approach better, but I don't know of any. If you do, please let me know.
Note I'm not trying to brag about my code and denigrate others. All I did was tweak the CMU-derived-specific approach to backend to CFFI instead, a pretty minor change (and one that I did with virtually no understanding of the code.
To add some historical perspective to the issue:
The mcclim-freetype code was created by Gilbert Baumann. I did the initial conversion to SBCL. This involved more than just changing package names; in order to make it usable, the code had to be changed such that SBCL no longer warned about runtime calls to %SAP-ALIEN. Not only did it worn at compile time about this; it actually generated warnings at runtime initially too. Along the way, I added a few caches to speed up glyph rendering, which finally resulted in something I could bear to use daily in climacs and the listener.
Making the compiler happy wrt %SAP-ALIEN was not trivial, and if there's anything I would be worried about in the CFFI version, it's that somewhere one of those optimizations is not implemented. If it's usably fast, I guess everything is OK. Not having used CFFI, I don't know if SBCL will still warn about these as profusely as it does when using good ol' SB-ALIEN.
It's not that easy for me to test with SBCL (at least it's un-easy enough that I won't be able to get to it until after the start of the new year). I'd encourage you to have a whirl at the CFFI version of Freetype. I tried not to do anything that would make it not work on SBCL, but I can't swear that I did it all right...
BTW, I did initially try to make a version of freetype that would use a bunch of #+ and #- to add ACL support. It was just too hard for me, simple differences b/w the two models of foreign function calls foiled me. And, of course, even if I had managed it, that still would have left clisp and lispworks (at least) out in the cold. I hope that CFFI will be A Good Thing. It is for me, anyway, since beirc is now much prettier!
--- "Robert P. Goldman" rpgoldman@sift.info wrote:
I've been hoping that the CFFI version would become more official, but it doesn't seem to have gotten any traction. I'm not actually sure that freetype in general has, for that matter.
From the "I should know better than to ask this" department...
What would it take to do a native lisp implementation of something like Freetype? Could the MetaFont type work being done in Gsharp forme the basis for such an effort?
Cheers, CY
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Thanks to everybody who spent their time on this issue.
It seems that call
(load-char face char :ft-load-monochrome)
was not sufficient, contrary to my (under)undestanding of FreeType docs. Instead, two calls
(load-char face char :ft-load-default) ... (render-glyph glyph :ft-render-mode-mono)
made what I wanted.
If anyone knows FreeType expert, please ask him about this.
Sincerely yours, Dmitri
-
Brian Mastenbrook -
C Y -
Dmitri Hrapof -
Martin Rydstr|m -
Nikodemus Siivola -
Robert Goldman -
Robert P. Goldman