[cl-gd-devel] :do-not-draw of draw-freetype-string
When draw-freetype-string is called with ':do-not-draw t', I get: ----------------<START>--------------------- Condition: 0.05521739130434778 cannot be converted to foreign type (:SIGNED-INTEGER-TYPE 32). Call to CL-GD::GD-IMAGE-STRING-FT (offset 521) CL-GD::IM : #<Pointer to type (:STRUCT CL-GD::GD-IMAGE) = #x00000000> CL-GD::BRECT : #<Pointer to type :INT = #x081E2778> CL-GD::FG : 0 CL-GD::FONTNAME : "/opt/Korean/fonts/UnBatangBold.ttf" CL-GD::PTSIZE : 10.0 CL-GD::ANGLE : 1.5707963267948966 CL-GD::X : 0.05521739130434778 CL-GD::Y : 0.058695652173913 STRING : "Number of Outcome" ----------------<END>--------------------- I think there was no transformer for x and y coordinates, and finally gd-image-string-ft was called with the exactly same x and y arguments of draw-freetype-string. I do not have this problem with old cl-gd (0.4.8). Here is a diff output between 0.4.8 and 0.5.3(draw-freetype-string only): ----------------<START>--------------------- *************** *** 132,139 **** rendering during bounding rectangle calculation." (check-type string string) (check-type font-name (or pathname string)) ! (check-type color integer) ! (check-type image image) (with-transformed-alternative ((x x-transformer) (y y-transformer) --- 133,144 ---- rendering during bounding rectangle calculation." (check-type string string) (check-type font-name (or pathname string)) ! (cond (do-not-draw ! (setq color 0 ! image *null-image*)) ! (t ! (check-type color integer) ! (check-type image image))) (with-transformed-alternative ((x x-transformer) (y y-transformer) *************** *** 159,167 **** 'gd-ft-string-extra 'line-spacing) (coerce line-spacing 'double-float)) ! (gd-image-string-ft-ex (if do-not-draw ! *null-image* ! (img image)) c-bounding-rectangle (if anti-aliased color (- color)) c-font-name --- 164,170 ---- 'gd-ft-string-extra 'line-spacing) (coerce line-spacing 'double-float)) ! (gd-image-string-ft-ex (img image) c-bounding-rectangle (if anti-aliased color (- color)) c-font-name *************** *** 171,179 **** c-string strex))) (t ! (gd-image-string-ft (img (if do-not-draw ! *null-image* ! image)) c-bounding-rectangle (if anti-aliased color (- color)) c-font-name --- 174,180 ---- c-string strex))) (t ! (gd-image-string-ft (img image) c-bounding-rectangle (if anti-aliased color (- color)) c-font-name
On Fri, 30 Mar 2007 07:15:09 +0900, Jong-won Choi <jc@itsec.co.kr> wrote:
When draw-freetype-string is called with ':do-not-draw t', I get:
----------------<START>--------------------- Condition: 0.05521739130434778 cannot be converted to foreign type (:SIGNED-INTEGER-TYPE 32).
Call to CL-GD::GD-IMAGE-STRING-FT (offset 521) CL-GD::IM : #<Pointer to type (:STRUCT CL-GD::GD-IMAGE) = #x00000000> CL-GD::BRECT : #<Pointer to type :INT = #x081E2778> CL-GD::FG : 0 CL-GD::FONTNAME : "/opt/Korean/fonts/UnBatangBold.ttf" CL-GD::PTSIZE : 10.0 CL-GD::ANGLE : 1.5707963267948966 CL-GD::X : 0.05521739130434778 CL-GD::Y : 0.058695652173913 STRING : "Number of Outcome" ----------------<END>---------------------
Could you please send a self-contained example that I can use to reproduce your problem? Also, it's generally a good idea to tell us which Lisp you are using, which OS you are on, and so on.
I think there was no transformer for x and y coordinates, and finally gd-image-string-ft was called with the exactly same x and y arguments of draw-freetype-string.
I do not have this problem with old cl-gd (0.4.8). Here is a diff output between 0.4.8 and 0.5.3(draw-freetype-string only):
I don't see anything in the diff that would affect transformations. Cheers, Edi.
Edi Weitz wrote:
Could you please send a self-contained example that I can use to reproduce your problem? Also, it's generally a good idea to tell us which Lisp you are using, which OS you are on, and so on.
I thought they are unrelated on this specific problem (maybe I'm wrong). I'm using LW4.4.5 and Ubuntu LTS
I think there was no transformer for x and y coordinates, and finally gd-image-string-ft was called with the exactly same x and y arguments of draw-freetype-string.
I do not have this problem with old cl-gd (0.4.8). Here is a diff output between 0.4.8 and 0.5.3(draw-freetype-string only):
I don't see anything in the diff that would affect transformations.
I don't know much about cl-gd details. But with 0.4.8 code, _image_ in with-transformed-alternative(code below) is not *null-image* yet. I think that's the main difference between 0.4.8 and 0.5.3. I'm guessing, for 0.5.3 code (find image *transformers* ...) returns nil with *null-image*, in contrast to 0.4.8 code returns a correct(?) transformer. For this one I can't send you a simple example - because the existing code is very hairy. ------------------------------------ (defmacro with-transformed-alternative ((&rest transformations) &body body) "Internal macro used to make functions transformation-aware. TRANSFORMATION is a list of (EXPR TRANSFORMATION) pairs where each EXPR will be replaced by the transformation denoted by TRANSFORMATION." (with-unique-names (transformer) (let ((transformations-alist (loop for (expr transformation) in transformations collect `(,expr . (funcall (,transformation ,transformer) ,expr))))) ;; note that we always use the name 'IMAGE' - no problem because ;; this is a private macro `(let ((,transformer (find image *transformers* :key #'image))) (cond (,transformer ,(sublis transformations-alist `(progn ,@body) :test #'equal)) (t (progn ,@body)))))))
On Fri, 30 Mar 2007 18:04:46 +0900, Jong-won Choi <jc@itsec.co.kr> wrote:
I don't know much about cl-gd details. But with 0.4.8 code, _image_ in with-transformed-alternative(code below) is not *null-image* yet. I think that's the main difference between 0.4.8 and 0.5.3. I'm guessing, for 0.5.3 code (find image *transformers* ...) returns nil with *null-image*, in contrast to 0.4.8 code returns a correct(?) transformer.
Yes, it looks like you're right and my recent update broke things. I'm on my way to Cambridge for the ILC now, though, so I probably won't be able to fix this before the end of next week. Thanks for the report, Edi.
On Sat, 31 Mar 2007 12:51:04 +0200, Edi Weitz <edi@agharta.de> wrote:
Yes, it looks like you're right and my recent update broke things.
I've released 0.5.4 which hopefully fixes this.
participants (2)
-
Edi Weitz -
Jong-won Choi