- cl-gd-devel@lists.common-lisp.net - mailman3.common-lisp.net

[cl-gd-devel] Premature loading of GD library can cause problems
by Alain Picard 10 Jan '08

10 Jan '08

Dear all, At the end of init.lisp, there is a line, at toplevel, like so: (load-gd-glue) This can cause problems under certain scenarios; e.g. using Lispworks with a delivered application, on a system different from where the application was delivered. What we do, for example, is this: - app starts - set up some logical translations, from current working directory or an environment variable, say XOS_HOME - push "XOS:LIBS;" onto the list of *shared-library-directories* - call (load-gd-glue) to initalize GD. Now, in LW 5, this is failing, because in uffi, the call to load-foreign-library ends up calling #+lispworks (fli:register-module module :real-name filename :connection-style :immediate) which tries to load the library on a path which does not exist on the remote host. This all happens even before the delivered MAIN function has a chance to run and set things right. I'm expecting that LW4 and LW5 are doing something different internally which is causing this bug (behaviour?) to only manifest now. I'm not completely clear in my mind who's "fault" this situation is; I think I can see that SBCL/CMUCL users, who might tend to not deliver runnable images, but rather the core + fasls, would want the current behaviour; i.e. loading init.lisp causes the GD library to get loaded, but it seems onerous to force this choice onto everyone. For now, I have no choice but to modify my copy of cl-gd to comment out this line, something I prefer not to do when tracking 3rd party sources. Does anybody have an opinion on this situation? I think I myself, as library author, would omit the (load-gd-glue) call, and leave that to users to put in their own files at toplevel if so they wish. Are there any other "good" solutions? Cheers, Alain Picard -- Please read about why Top Posting is evil at: http://en.wikipedia.org/wiki/Top-posting and http://www.dickalba.demon.co.uk/usenet/guide/faq_topp.html Please read about why HTML in email is evil at: http://www.birdhouse.org/etc/evilmail.html

2 5

[cl-gd-devel] fill shapes with transformation?
by Jeff Cunningham 21 Oct '07

21 Oct '07

Hi; I'm probably doing something wrong, but I can't figure out how to draw rectangles with a fill color using a transformation. The code below illustrates the problem I'm having. The first draw-rectangle should be filled in red. It isn't drawn at all. The second rectangle is outlined in blue as it should be. Both these two use a transformation to place the rectangle. The third does not and it fills just fine. Is this expected behavior? Or am I doing something wrong? Thanks. --Jeff (with-image* (200 200) (allocate-color 68 70 85) (let ((fn "test.png") (red (allocate-color 255 0 0)) (white (allocate-color 255 255 255)) (blue (allocate-color 0 0 100))) (with-transformation (:x1 -100 :x2 100 :y1 -100 :y2 100) (draw-rectangle* -30 -30 30 30 :color red :filled t) (draw-rectangle* -20 -20 20 20 :color blue :filled nil)) (without-transformations (draw-rectangle* 95 95 105 105 :color white :filled t)) (write-image-to-file fn :if-exists :supersede) (sb-ext:run-program "/usr/bin/xv" (list fn))))

2 2

[cl-gd-devel] Resizing Images
by Volkan YAZICI 23 Sep '07

23 Sep '07

Hi, While trying to resize images, using COPY-IMAGE, there occurs serious color losses. Here is an example code snippet to re-produce the problem: (cl-gd:with-image-from-file (src "/tmp/src.jpg" :jpeg) (let* ((src-w (cl-gd:image-width src)) (src-h (cl-gd:image-height src)) (dst-w (truncate (/ src-w 2))) ; WIDTH /2 (dst-h (truncate (/ src-h 2)))) ; HEIGHT/2 (cl-gd:with-image (dst dst-w dst-h) ;; Set transparent color, if any. (let ((transparent-color (cl-gd:transparent-color src))) (if transparent-color (destructuring-bind (red green blue alpha) (cl-gd:color-components transparent-color :image src) (setf (cl-gd:transparent-color dst) (cl-gd:allocate-color red green blue :alpha alpha :image dst))))) ;; Copy source scaled onto the destination. (cl-gd:copy-image src dst 0 0 0 0 (cl-gd:image-width src) (cl-gd:image-height src) :resample t :resize t :dest-width dst-w :dest-height dst-h) ;; Output result. (cl-gd:write-image-to-file "/tmp/dst.jpg" :type :jpeg :image dst :if-exists :supersede)))) Can anybody spot the problem in the above code? (Removing the part that sets the transparent color doesn't make any difference.) How do you resize images in cl-gd? Regards.

2 3

[cl-gd-devel] with-transformation off-by-one bug?
by Michael J. Forster 14 Sep '07

14 Sep '07

Hi Edi, I'm using CL-GD with both LispWorks 5.0 on OS X and CMUCL 19b on FreeBSD to plot some graphs, and I'm very grateful for your work here. CL-GD is slick to use and more than fast enough for generating sparklines on an interactive web-based dashboard. I'm using WITH-TRANSFORMATION to simplify the graph plotting, and it's not behaving the way I would expect. As I read it in the documentation, this... (with-transformation (:x1 0 :width width :y1 0 :height height) ...) ... should transform the coordinate system from this... 0,0 -----> width - 1 | | | V height - 1 ... to this... height - 1 ^ | | | 0,0 -----> width - 1 Instead, I get this... height ^ | | | 0,1 -----> width - 1 The y-axis transformation isn't consistent with that of the x-axis. What's even more confusing, is that if the x-axis transformation does work then the following should only complain about y1, y2, and height, and not about x1, x2, and width, but that's not the case: (let ((height 100) (width 100)) (with-transformation (:x1 0 :x2 (1- width) :width width :y1 0 :y2 (1- height) :height height) ...)) Indeed, when I checked the macroexpansion, I see... (UNLESS #:X154021 (SETQ #:X154021 (- #:X254022 #:WIDTH54023))) (UNLESS #:X254022 (SETQ #:X254022 (+ #:X154021 #:WIDTH54023))) (UNLESS #:WIDTH54023 (SETQ #:WIDTH54023 (- #:X254022 #:X154021))) (UNLESS #:Y154024 (SETQ #:Y154024 (- #:Y254025 #:HEIGHT54026))) (UNLESS #:Y254025 (SETQ #:Y254025 (+ #:Y154024 #:HEIGHT54026))) (UNLESS #:HEIGHT54026 (SETQ #:HEIGHT54026 (- #:Y254025 #:Y154024))) Again, I would have thought, instead, that... width = (x2 - x1) + 1 height = (y2 - y1) + 1 So, the y-axis transformation isn't what I expected, but the macroexpansion suggests that the x-axis transformation should be off by one as well, yet it isn't. Am I nuts? Below is the snippet I was running to grok WITH-TRANSFORMATION. I can mail you the images I got, if you like. Thanks in advance, Mike (let* ((height 100) (width 100) (origin+1 (list 1 1)) (x-axis+1 (list 10 1 20 1 30 1 40 1 50 1 60 1 70 1 80 1 90 1 width 1)) (y-axis+1 (list 1 10 1 20 1 30 1 40 1 50 1 60 1 70 1 80 1 90 1 height)) (x-axis-end+1 (list (1- width) 1)) (y-axis-end+1 (list 1 (1- height)))) (cl-gd:with-image* (width height) (allocate-color 255 255 255) (let ((black (allocate-color 0 0 0)) (red (allocate-color 255 0 0)) (green (allocate-color 0 255 0)) (blue (allocate-color 0 0 255)) (yellow (allocate-color 255 255 0))) (draw-rectangle* 0 (1- height) ; or 0 and ... (1- width) 0 ; (1- height), doesn't matter :color yellow) (draw-rectangle* 0 height ; or 0 and ... width 0 ; ... height, doesn't matter :color black) (set-pixels origin+1 :color red) (set-pixels x-axis+1 :color green) (set-pixels x-axis-end+1 :color blue) (set-pixels y-axis+1 :color green) (set-pixels y-axis-end+1 :color blue)) (write-image-to-file "/tmp/test1.png" :if-exists :supersede)) (cl-gd:with-image* (width height) (allocate-color 255 255 255) (let ((black (allocate-color 0 0 0)) (red (allocate-color 255 0 0)) (green (allocate-color 0 255 0)) (blue (allocate-color 0 0 255)) (yellow (allocate-color 255 255 0))) (with-transformation (:x1 0 ;;:x2 99 :width width :y1 0 ;;:y2 99 :height height ) (draw-rectangle* 0 (1- height) ; or 0 and ... (1- width) 0 ; (1- height), doesn't matter :color yellow) (draw-rectangle* 0 height ; or 0 and ... width 0 ; ... height, doesn't matter :color black) (set-pixels origin+1 :color red) (set-pixels x-axis+1 :color green) (set-pixels x-axis-end+1 :color blue) (set-pixels y-axis+1 :color green) (set-pixels y-axis-end+1 :color blue)) (write-image-to-file "/tmp/test2.png" :if-exists :supersede)))) -- Michael J. Forster <mike(a)sharedlogic.ca>

2 5

[cl-gd-devel] thread safety in cl-gd
by Alain Picard 30 Jul '07

30 Jul '07

Dear all, I'm wondering if cl-gd has been thoroughly tested for thread safety? I've experienced a couple of segfaults here and there, apparently at random, in libgd. Cursory inspection of the code seems to suggest, for instance, that *transfomers* is not safe; the only references to this variable I see are in specials.lisp: (defvar *transformers* nil "Stack of currently active transformer objects.") and in WITH-TRANFORMATION, which does not create a new binding for *transformers*, but rather just pushes a new transformation onto the global *transformers*. Am I reading this right? It seems to me that two different lispworks threads could run in such a way so that 1 thread inadvertently starts running with transformers that another thread establishes then gets swapped out. Comments? Alain Picard -- Please read about why Top Posting is evil at: http://en.wikipedia.org/wiki/Top-posting and http://www.dickalba.demon.co.uk/usenet/guide/faq_topp.html Please read about why HTML in email is evil at: http://www.birdhouse.org/etc/evilmail.html

2 3

[cl-gd-devel] Image to array of bytes
by Andrei Stebakov 30 May '07

30 May '07

Instead of saving an image into a file using write-image-to-file I was trying to provide a hunchentoot handler which outputs an array of bytes (just like in the hunchentoot test.lisp image-ram-page example). For this I thought write-jpeg-to-stream would be the best candidate so I did following: (let ((s (make-string-output-stream :element-type '(unsigned-byte 8)))) (write-jpeg-to-stream s :image bg-image) (let ((image-data (make-array (image-size bg-image) :element-type '(unsigned-byte 8)))) (read-sequence image-data s) image-data))))))) For which the SBCL complains: #<SB-IMPL::STRING-OUTPUT-STREAM {CE6D171}> is not a binary output stream. I am wondering if I am doing the right thing and choosing the right function for the task. I also tried to create a stream with flexi-stream:make-in-memory-output-stream without any success. Thank you, Andrew **

2 2

[cl-gd-devel] :convert-chars of draw-freetype-string
by Jong-won Choi 24 Apr '07

24 Apr '07

I don't know much about gd and cl-gd and currently I don't understand what :convert-chars does so I'm trying to understand it. When I tried utf-8 Korean string with test-020, it did not render characters correctly. But if I set ':convert-chars nil' all the characters rendered correctly. I guess maybe gd itself handles non-ascii characters correctly(if this is true, maybe the :convert-chars can be removed from the function) Please use Korean string "커먼리습" (utf-8 encoded) for "Common Lisp", install ttf-unfonts package(Ubuntu and Debian), and use "/usr/share/fonts/truetype/unfonts/UnBatang.ttf" to exercise it with test-020. Thanks Jong-won Choi

2 6

[cl-gd-devel] :do-not-draw of draw-freetype-string
by Jong-won Choi 05 Apr '07

05 Apr '07

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

2 5

[cl-gd-devel] iconv and cl-gd
by Jong-won Choi 30 Mar '07

30 Mar '07

Dear cl-gd developers I know what iconv does quite well. I tried 'grep iconv ...' to figure out how it is used in cl-gd, and found nothing. Is link option -liconv really necessary? I built the cl-gd-glue shared library without the option and didn't have a problem so far(my client want to avoid GPL and LGPL softwares if it is possible) Thanks Jong-won Choi

2 2

[cl-gd-devel] Error with draw-feetype-string
by Andrei Stebakov 24 Mar '07

24 Mar '07

I am not sure if it's hunchentoot or gd because when I specify "arial" for the functon, it works. When the same string comes from (session-value 'text) I got following error: Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER: "arial" is not of type (OR SIMPLE-BASE-STRING NULL (ALIEN:ALIEN (* (ALIEN:SIGNED 8)))) 0: (DEBUG:BACKTRACE 536870911 #<String-Output Stream>) 1: (HUNCHENTOOT:GET-BACKTRACE #<unused-arg>) 2: ("DEFUN PROCESS-REQUEST" #<TYPE-ERROR {58123B7D}>) 3: (SIGNAL #<TYPE-ERROR {58123B7D}>) 4: (ERROR TYPE-ERROR :FUNCTION-NAME CL-GD::GD-IMAGE-STRING-FT :DATUM "arial" :EXPECTED-TYPE (OR SIMPLE-BASE-STRING NULL (ALIEN:ALIEN (* (ALIEN:SIGNED 8))))) . . . 6: (KERNEL::INTERNAL-ERROR #.(SYSTEM:INT-SAP #x3FFFBF04) #<unused-arg>) 7: ("call_into_lisp+#x8C [#x805560C] /usr/bin/cmucl") 8: ("funcall2+#x2C [#x80553EE] /usr/bin/cmucl") 9: ("interrupt_internal_error+#xC3 [#x80506F1] /usr/bin/cmucl") 10: ("sigtrap_handler+#x187 [#x8055260] /usr/bin/cmucl") 11: (CL-GD::GD-IMAGE-STRING-FT #<Alien (* (ALIEN:STRUCT CL-GD::GD-IMAGE (CL-GD::PIXELS (* (* (ALIEN:UNSIGNED 8)))) (CL-GD::SX (ALIEN:SIGNED 32)) (CL-GD::SY (ALIEN:SIGNED 32)) (CL-GD::COLORS-TOTAL (ALIEN:SIGNED 32)) (CL-GD::RED (ARRAY (ALIEN:SIGNED 32) 256)) (CL-GD::GREEN (ARRAY (ALIEN:SIGNED 32) 256)) (CL-GD::BLUE (ARRAY (ALIEN:SIGNED 32) 256)) (OPEN (ARRAY (ALIEN:SIGNED 32) 256)) (CL-GD::TRANSPARENT (ALIEN:SIGNED 32)) (CL-GD::POLY-INTS (* (ALIEN:SIGNED 32))) (CL-GD::POLY-ALLOCATED (ALIEN:SIGNED 32)) (CL-GD::BRUSH (* (ALIEN:STRUCT CL-GD::GD-IMAGE))) (CL-GD::TILE (* (ALIEN:STRUCT CL-GD::GD-IMAGE))) (CL-GD::BRUSH-COLOR-MAP (ARRAY (ALIEN:SIGNED 32) 256)) (CL-GD::TILE-COLOR-MAP (ARRAY (ALIEN:SIGNED 32) 256)) (CL-GD::STYLE-LENGTH (ALIEN:SIGNED 32)) (CL-GD::STYLE-POS (ALIEN:SIGNED 32)) (CL-GD::STYLE (* (ALIEN:SIGNED 32))) (CL-GD::INTERFACE (ALIEN:SIGNED 32)) (CL-GD::THICK (ALIEN:SIGNED 32)) (CL-GD::ALPHA (ARRAY (ALIEN:SIGNED 32) 256)) (CL-GD::TRUE-COLOR (ALIEN:SIGNED 32)) (CL-GD::T-PIXELS (* (* (ALIEN:SIGNED 32)))) (CL-GD::ALPHA-BLENDING-FLAG (ALIEN:SIGNED 32)) (CL-GD::SAVE-ALPHA-FLAG (ALIEN:SIGNED 32)) (CL-GD::AA (ALIEN:SIGNED 32)) (CL-GD::AA-COLOR (ALIEN:SIGNED 32)) (CL-GD::AA-DO-NOT-BLEND (ALIEN:SIGNED 32)) (CL-GD::AA-OPACITY (* (* (ALIEN:UNSIGNED 8)))) (CL-GD::AA-POLYGON (ALIEN:SIGNED 32)) (CL-GD::AAL-X1 (ALIEN:SIGNED 32)) (CL-GD::AAL-Y1 (ALIEN:SIGNED 32)) (CL-GD::AAL-X2 (ALIEN:SIGNED 32)) (CL-GD::AAL-Y2 (ALIEN:SIGNED 32)) (CL-GD::AAL-BX-AX (ALIEN:SIGNED 32)) (CL-GD::AAL-BY-AY (ALIEN:SIGNED 32)) (CL-GD::AAL-LAB-2 (ALIEN:SIGNED 32)) (CL-GD::AAL-LAB SINGLE-FLOAT) (CL-GD::CX1 (ALIEN:SIGNED 32)) (CL-GD::CY1 (ALIEN:SIGNED 32)) (CL-GD::CX2 (ALIEN:SIGNED 32)) (CL-GD::CY2 (ALIEN:SIGNED 32)))) at #x00000000> #<Alien (* (ALIEN:SIGNED 32)) at #x0808D178> 0 "arial" 40.0d0 0.0d0 0 0 "555") 12: (CL-GD:DRAW-FREETYPE-STRING 0 0 "555" :ANTI-ALIASED T :POINT-SIZE 40 :ANGLE 0 :CONVERT-CHARS T :LINE-SPACING NIL :FONT-NAME "arial" :DO-NOT-DRAW T :COLOR 0 :IMAGE NIL)

2 4