- mcclim-devel - mailman3.common-lisp.net

[mcclim-devel] A few questions about dragging functions
by Evgeny M. Zubok 07 Dec '09

07 Dec '09

I'm reimplementing the drag-output-record, dragging-output to be more closer to CLIM specification. This work is almost done. However, a behaviour of drag-output-record is underspecified in some places. My questions are about `feedback' argument of drag-output-record. The following is what the CLIM specification says about feedback function and that's all what we have: ------------------------------------------------------------------------ `feedback' allows the programmer to identify a "feedback" function of seven arguments: the output record, the stream, the initial x and y position of the pointer, the current x and y position of the pointer, and a drawing argument (either :erase or :draw). It has dynamic extent. The default is nil, meaning that the feedback behavior will be for the output record to track the pointer. (The feedback argument is used when the programmer desires more complex feedback behavior, such as drawing a "rubber band" line as the user moves the mouse.) Note that if feedback is supplied, erase is ignored. ------------------------------------------------------------------------ My current solution. Notes: (i) the numbers with star means that the action is performed by user in the `feedback' function; (ii) (INITIAL-X INITIAL-Y) is the pointer coordinate when the user initially clicks the button on the desired record; (iii) (X-OLD Y-OLD) is remembered previous pointer coordinate. The user calls drag-output-record. In drag-output-record: 1* Call (feedback RECORD STREAM INITIAL-X INITIAL-Y INITIAL-X INITIAL-Y :DRAW) 2. Set X-OLD := INITIAL-X; Y-OLD := INITIAL-Y 3. User moves the pointer. Now X Y is a new pointer position. 4* Call (feedback RECORD STREAM INITIAL-X INITIAL-Y X-OLD Y-OLD :ERASE). Erase previous feedback effect and output record. 5. Change output-record-position of the RECORD to a new location. 6* Call (feedback RECORD STREAM INITIAL-X INITIAL-Y X Y :DRAW) where the user draws the record at it's new position and draws feedback effect. Note, that RECORD already has the new coordinates in output-record-position. 7. X-OLD := X; Y-OLD := Y 8. Repeat from 4 ... 9. User clicks a pointer button 10* Call (feedback RECORD STREAM INITIAL-X INITIAL-Y X Y :ERASE). Erase last feedback effect and the output record. 11. Replay the output record without feedback effect at it's final position. 12. Exit --- Qusetion about my solution. =========================== Q: Where the dragged output record should be erased and redrawn (i. e. replayed) when the `feedback' is supplied: in the `feedback' function by user or inside the drag-output-record function? My solution: I've delegated the erasing and redrawing the dragged record to the user. The situation with erasing is more clear. CLIM specification states that if `feedback' argument is supplied, the `erase' argument is ignored. As far as user already had the possibility to provide the `erase' argument with custom function (`erase-output-record' by default), then this possibility only migrates to the :ERASE part of `feedback' function. A situation with `feedback :DRAW' is unclear. The redrawing of dragged output record can be accomplished either (i) in the drag-output-record before `feedback :DRAW' or (ii) by user in `feedback :DRAW', manually replaying the record and the desired feedback effect. In other words, there are two algorithms, which are almost equivalent in the sense of visible effect, but not equivalent with respect to the user. (I) My current solution. Erasing/redrawing of output record and feedback effect is accompishing by user. 1. Call `feedback :ERASE' where user erases the dragged output record and additional feedback effect from their previous position (with possible replaying). 2. Change output-record-position to a new position inside drag-output-record. 3. Call 'feedback :DRAW' where user draws the dragged output record and then the additional feedback effect at the new position. (II) Alternative solution. The output record is redrawing in the drag-output-record. 1. Call `feedback :ERASE' where user erases the dragged output record and additional feedback effect from previous position (with possible replaying). 2. Change output-record-position to a new position inside drag-output-record 3. Draw the dragged output record at it's new position inside the drag-output-record by replaying required region that contains the output record. 4. Call 'feedback :DRAW' where user draws only the additional feedback effect. What to prefer? The former provides more flexibility to control output record appearence as it's dragged. For example, I could implement dragging that is snapped to a grid by erasing/redrawing output record and additional feedback effect only when the pointer occures in the next grid cell area. This is not possible with (II), bacause we cannot control the redrawing of output record. How it was implemented in original CLIM? Does anyone have any legacy code or examples that use the drag-output-record with `feedback'? --- Q: When the `feedback' is called with :DRAW, does the RECORD already have a new position on STREAM, i. e. the coordinates where it will be drawn? My solution: See item 5. I'm changing output-record-position in the drag-output-record just before calling `feedback :DRAW'. Only the original CLIM implementation could clear how this was implemented. --- Q: Am I right when passing the X-OLD Y-OLD to the `feedback :ERASE'? My solution: If we are using the current pointer coordinates to draw feedback effect in `feedback :DRAW' (for example, to draw line with flipping ink from 0,0 to current pointer location), then to erase this feedback effect in subsequent :ERASE the previous pointer coordinates are required, not the current. However, CLIM spec says, that only current pointer coordinates are passed to feedback :ERASE/:DRAW. Alternative solution: user somewhere remembers coordinates that are passed to `feedback :DRAW' and use them when it's required to erase previous feedback.

1 0

[mcclim-devel] How to use McCLIM on SnowLeopard with SBCL ?
by 十亀眞怜 22 Nov '09

22 Nov '09

Hello, I try to use McCLIM on Mac OSX SnowLeopard with latest version SBCL. I finished install mcclim and try to test program. (require 'clim-examples) (clim-demo::demodemo) Then I got Error like this: debugger invoked on a SB-BSD-SOCKETS:HOST-NOT-FOUND-ERROR: Name service error in "getaddrinfo": 8 (nodename nor servname provided, or not known) Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. (SB-BSD-SOCKETS::ADDRINFO-ERROR "getaddrinfo" 8) But I can't figure out why this error happen. Does anyone can solve this probrem? Pleas help me. Many Thanks.-------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/

1 0

[mcclim-devel] faster clim-clx:pixel-translator
by Nikodemus Siivola 14 Nov '09

14 Nov '09

One of the reasons IMAGE-TO-XIMAGE is slow is that pixel translators are _really_ slow. Attached patch fixes this bit. (On SBCL at least -- presumably elsewhere as well.) Cheers, -- Nikodemus

1 0

[mcclim-devel] another question
by Žiga Lenarčič 05 Nov '09

05 Nov '09

Hi! Here's my previos email I sent as a non-member: ---------------- Hi McCLIM developers! I have a few questions, in no particular order: * I've started 'theming' McCLIM to give it a more modern look (a darker look).. I've started with /Looks/pixie.lisp and went from there. Is pixie.lisp an example of 'correct' skinning process - effectively creating new classes with overridden methods for various things or is it better to just redefine the handle-redraw methods of original gadgets and be done with it? Pixie has a problem for instance - mouse wheel scrolling doesn't work, because it reimplements scrolling logic implemented in gadgets.lisp or somewhere else. Wouldn't it be more correct to use the 'default' logic and only redefine handle-repaint methods, if change in functionality isn't needed? * what is the correct way to add my own widgets? I assume I should look at gadgets.lisp and start from there. Are new widgets welcome in the main McCLIM source tree or is McCLIM closely following some CLIM specification and doesn't want to go beyond that? * I'm using CLX backend and default/freetype/truetype font renedering. I've noticed that with default X11 font rendering, the usual textstyle (sans-serif, roman) is much more readable at size :small, than :normal. For antialiased fonts, :normal works great. Perhaps the default fontsize should be :small (or mcclim's clx default font render should just interpret :normal as :small) - clim- examples applications would look nicer out of the box and I wouldn't need to write cases in my app (if ''freetype'' :normal :small) to make stuff look nice. I think this has been mentioned before.. * right now McCLIMs 'textfield' is vastly different from text fields in other toolkits. I think we could conform better if the caret was just a line (not a block), if the caret blinked properly, if there was caret positioning via mouse click and if there was selection possible. I don't know how other McCLIM users feel about this - but if I added these features, would they be added to McCLIM? Would it be better to add a new 'gadget' for this 'modern' text field stuff? Regards, Ziga ----------------- I have another question: * What's the state of unicode support with McCLIM. I guess this is backend specific, since SBCL supports unicode strings very nicely. I use McCLIM on Mac OS X and non ASCII keys don't produce anything in McCLIM. Perhaps this is a problem with Mac OS X's X11 server? I've looked into 'freetype' font rendering and (I think) it assumes that char-code is < 256. Is there any unicode support in McCLIM? Regards, Ziga

3 3

[mcclim-devel] A few questions
by Žiga Lenarčič 04 Nov '09

04 Nov '09

Hi McCLIM developers! I have a few questions, in no particular order: * I've started 'theming' McCLIM to give it a more modern look (a darker look).. I've started with /Looks/pixie.lisp and went from there. Is pixie.lisp an example of 'correct' skinning process - effectively creating new classes with overridden methods for various things or is it better to just redefine the handle-redraw methods of original gadgets and be done with it? Pixie has a problem for instance - mouse wheel scrolling doesn't work, because it reimplements scrolling logic implemented in gadgets.lisp or somewhere else. Wouldn't it be more correct to use the 'default' logic and only redefine handle-repaint methods, if change in functionality isn't needed? * what is the correct way to add my own widgets? I assume I should look at gadgets.lisp and start from there. Are new widgets welcome in the main McCLIM source tree or is McCLIM closely following some CLIM specification and doesn't want to go beyond that? * I'm using CLX backend and default/freetype/truetype font renedering. I've noticed that with default X11 font rendering, the usual textstyle (sans-serif, roman) is much more readable at size :small, than :normal. For antialiased fonts, :normal works great. Perhaps the default fontsize should be :small (or mcclim's clx default font render should just interpret :normal as :small) - clim- examples applications would look nicer out of the box and I wouldn't need to write cases in my app (if ''freetype'' :normal :small) to make stuff look nice. I think this has been mentioned before.. * right now McCLIMs 'textfield' is vastly different from text fields in other toolkits. I think we could conform better if the caret was just a line (not a block), if the caret blinked properly, if there was caret positioning via mouse click and if there was selection possible. I don't know how other McCLIM users feel about this - but if I added these features, would they be added to McCLIM? Would it be better to add a new 'gadget' for this 'modern' text field stuff? Regards, Ziga

2 1

[mcclim-devel] [PATCH] In display-exit-boxes present Cancel button as an abort-button.
by Kilian Sprotte 15 Oct '09

15 Oct '09

Hello! I am attaching a small fix for the Cancel button in accepting-values dialogs. Currently, it behaves like the Ok button (instead of aborting a command, it will let it run). WITH-OUTPUT-AS-PRESENTATION was wrapped twice around the Cancel button, so that's what I cleaned up. Cheers, Kilian Sprotte

2 1

[mcclim-devel] Title panes
by Robert Swindells 06 Oct '09

06 Oct '09

There doesn't seem to be a display-title method for the title-pane class, is this deliberate ? The examples in the Franz CLIM User Guide imply to me that you should be able to use this pane type without needing to supply a display-function for it. Robert Swindells

3 4

[mcclim-devel] A stab at MEDIUM-DRAW-IMAGE-DESIGN* implementation for gtkairo
by Samium Gromoff 01 Sep '09

01 Sep '09

Dear list, the included patch (also available in git[1]) provides an initial attempt at implementation of image design drawing for gtkairo. It's lacking masking support, as well as might leak memory (I'm not sure why cairo doesn't let me to destroy the surface I myself has created, for instance), so any comments would be very appreciated. diff --git a/Backends/gtkairo/cairo.lisp b/Backends/gtkairo/cairo.lisp index 1db8406..0600912 100644 --- a/Backends/gtkairo/cairo.lisp +++ b/Backends/gtkairo/cairo.lisp @@ -534,6 +534,103 @@ (cairo_move_to cr (df x) (df (+ y y2)))) (pango_cairo_show_layout cr layout)))))) +;; Stolen from the CLX backend. +(defmethod climi::medium-draw-image-design* + ((medium cairo-medium) (design climi::rgb-image-design) x y) + (destructuring-bind (&optional surface buffer mask) + (slot-value design 'climi::medium-data) + (unless surface + (let* ((image (slot-value design 'climi::image))) + (setf (values surface buffer) (image-to-cairosurface image)) + (when (climi::image-alpha-p image) + (error "~@<Drawing of images with alpha component is not supported.~:@>")) + (setf (slot-value design 'climi::medium-data) (list surface buffer mask)))) + (when mask + (error "~@<A mask in your image design.~:@>")) + (with-medium (medium) + (multiple-value-bind (x y) + (transform-position + (sheet-device-transformation (medium-sheet medium)) + x y) + (setf x (float x 0d0)) + (setf y (float y 0d0)) + (with-slots (cr) medium + (cairo_set_source_surface cr surface x y) + (cond + #+ (or) + (mask + (xlib:with-gcontext (gcontext + :clip-mask mask + :clip-x x + :clip-y y) + (xlib:copy-area pixmap gcontext 0 0 width height + da x y))) + (t + (cairo_paint cr)))))))) + +(defmethod climi::medium-free-image-design + ((medium cairo-medium) (design climi::rgb-image-design)) + (destructuring-bind (&optional surface buffer mask) + (slot-value design 'climi::medium-data) + (when surface + #+ (or) + ;; This one bites, no idea why. + (cairo_destroy surface) + (cffi:foreign-free buffer) + (setf (slot-value design 'climi::medium-data) nil)))) + +;; Was: CLX/compute-rgb-image-mask +#+ (or) +(defun compute-rgb-image-mask (drawable image) + (let* ((width (climi::image-width image)) + (height (climi::image-height image)) + (bitmap (xlib:create-pixmap :drawable drawable + :width width + :height height + :depth 1)) + (gc (xlib:create-gcontext :drawable bitmap + :foreground 1 + :background 0)) + (idata (climi::image-data image)) + (xdata (make-array (list height width) + :element-type '(unsigned-byte 1))) + (im (xlib:create-image :width width + :height height + :depth 1 + :data xdata)) ) + (dotimes (y width) + (dotimes (x height) + (if (> (aref idata x y) #x80000000) + (setf (aref xdata x y) 0) + (setf (aref xdata x y) 1)))) + (unless (or (>= width 2048) (>= height 2048)) ;### CLX breaks here + (xlib:put-image bitmap gc im :src-x 0 :src-y 0 + :x 0 :y 0 :width width :height height + :bitmap-p nil)) + (xlib:free-gcontext gc) + bitmap)) + +;; Was: CLX/image-to-ximage +(defun image-to-cairosurface (image) + (let* ((width (climi::image-width image)) + (height (climi::image-height image)) + (idata (climi::image-data image)) + (stride (cairo_format_stride_for_width :rgb24 width)) + (cairodata (cffi:foreign-alloc :uint8 :count (* stride height)))) + (declare (type (simple-array (unsigned-byte 32) (* *)) idata)) + (loop :for row-offset :from 0 :by stride + :for y :from 0 :below height + :do (loop :for offset :from row-offset :by 4 + :for x :from 0 :below width + :do (let ((px (aref idata y x))) + (setf (cffi:mem-ref cairodata :uint32 offset) + (dpb (ldb (byte 8 0) px) (byte 8 16) + (dpb (ldb (byte 8 8) px) (byte 8 8) + (dpb (ldb (byte 8 16) px) (byte 8 0) + 0))))))) + (values (cairo_image_surface_create_for_data cairodata :rgb24 width height stride) + cairodata))) + (defmethod medium-finish-output ((medium cairo-medium)) (with-medium (medium) (when (cr medium) diff --git a/Backends/gtkairo/ffi.lisp b/Backends/gtkairo/ffi.lisp index 1fb7207..993e6ab 100644 --- a/Backends/gtkairo/ffi.lisp +++ b/Backends/gtkairo/ffi.lisp @@ -333,6 +333,12 @@ (arg0 :pointer) ;cairo_font_face_t * ) +(defcfun "cairo_format_stride_for_width" + :int + (arg0 cairo_format_t) + (arg1 :int) + ) + (defcfun "cairo_get_font_face" :pointer (arg0 :pointer) ;cairo_t * @@ -643,6 +649,14 @@ (arg4 :double) ;double ) +(defcfun "cairo_set_source_surface" + :void + (arg0 :pointer) ;cairo_t * + (arg1 :pointer) ;cairo_surface_t * + (arg2 :double) + (arg3 :double) + ) + (defcfun "cairo_set_tolerance" :void (arg0 :pointer) ;cairo_t * regards, Samium Gromoff -- 1. git://git.feelingofgreen.ru/mcclim, the 'gtkairo-mdid' branch _deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

1 0

[mcclim-devel] PNG read support for McCLIM.
by Samium Gromoff 31 Aug '09

31 Aug '09

Good day folks, the included patch (also available via git[1]) adds a bridge to PNG-READ[2] by Jakub Higersberger, adding pure CL PNG support to McCLIM. diff --git a/Extensions/Bitmap-formats/png.lisp b/Extensions/Bitmap-formats/png.lisp new file mode 100644 index 0000000..3c75b13 --- /dev/null +++ b/Extensions/Bitmap-formats/png.lisp @@ -0,0 +1,44 @@ +;;; -*- Mode: Lisp; Package: MCCLIM-IMAGES -*- + +;;; (c) copyright 2009 by +;;; Samium Gromoff (_deepfire(a)feelingofgreen.ru) + +;;; This library is free software; you can redistribute it and/or +;;; modify it under the terms of the GNU Library General Public +;;; License as published by the Free Software Foundation; either +;;; version 2 of the License, or (at your option) any later version. +;;; +;;; This library is distributed in the hope that it will be useful, +;;; but WITHOUT ANY WARRANTY; without even the implied warranty of +;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +;;; Library General Public License for more details. +;;; +;;; You should have received a copy of the GNU Library General Public +;;; License along with this library; if not, write to the +;;; Free Software Foundation, Inc., 59 Temple Place - Suite 330, +;;; Boston, MA 02111-1307 USA. + +(in-package :clim-internals) + +(define-bitmap-file-reader :png (image-pathname) + (let* ((png-state (png-read:read-png-file image-pathname)) + (data (png-read:image-data png-state)) + (depth (png-read:bit-depth png-state)) + (height (png-read:height png-state)) + (width (png-read:width png-state)) + (array (make-array (list height width) :element-type '(unsigned-byte 32)))) + (unless (member depth '(8 32)) + (error "~@<PNG-encoded images with bit depth ~D are not supported. The only supported bit depths are 8 and 32.~:@>" depth)) + (dotimes (y height) + (dotimes (x width) + (case depth + ((8 32) + (let ((red (aref data x y 0)) + (green (aref data x y 1)) + (blue (aref data x y 2))) + (setf (aref array y x) + (dpb red (byte 8 0) + (dpb green (byte 8 8) + (dpb blue (byte 8 16) + (dpb (- 255 0) (byte 8 24) 0)))))))))) + array)) diff --git a/mcclim-png-bitmaps.asd b/mcclim-png-bitmaps.asd new file mode 100644 index 0000000..0a63f70 --- /dev/null +++ b/mcclim-png-bitmaps.asd @@ -0,0 +1,24 @@ +;;; -*- Mode: Lisp -*- + +;;; (c) copyright 2009 by +;;; Samium Gromoff (_deepfire(a)feelingofgreen.ru) +;;; +;;; This library is free software; you can redistribute it and/or +;;; modify it under the terms of the GNU Library General Public +;;; License as published by the Free Software Foundation; either +;;; version 2 of the License, or (at your option) any later version. +;;; +;;; This library is distributed in the hope that it will be useful, +;;; but WITHOUT ANY WARRANTY; without even the implied warranty of +;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +;;; Library General Public License for more details. +;;; +;;; You should have received a copy of the GNU Library General Public +;;; License along with this library; if not, write to the +;;; Free Software Foundation, Inc., 59 Temple Place - Suite 330, +;;; Boston, MA 02111-1307 USA. + +(asdf:defsystem :mcclim-png-bitmaps + :description "Support for PNG images in McCLIM bitmap reading functions." + :depends-on (:mcclim :png-read) + :components ((:file "png" :pathname #P"Extensions/Bitmap-formats/png"))) regards, Samium Gromoff -- 1. git://git.feelingofgreen.ru/mcclim, branch 'png-bitmaps' 2. git://github.com/Ramarren/png-read.git _deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

1 0

Re: [mcclim-devel] how to subclass a pane in good style?
by Samium Gromoff 31 Aug '09

31 Aug '09

Good day folks, the included patch (also available via git[1]) adds a bridge to PNG-READ by Jakub Higersberger, adding pure CL PNG support to McCLIM. diff --git a/Extensions/Bitmap-formats/png.lisp b/Extensions/Bitmap-formats/png.lisp new file mode 100644 index 0000000..3c75b13 --- /dev/null +++ b/Extensions/Bitmap-formats/png.lisp @@ -0,0 +1,44 @@ +;;; -*- Mode: Lisp; Package: MCCLIM-IMAGES -*- + +;;; (c) copyright 2009 by +;;; Samium Gromoff (_deepfire(a)feelingofgreen.ru) + +;;; This library is free software; you can redistribute it and/or +;;; modify it under the terms of the GNU Library General Public +;;; License as published by the Free Software Foundation; either +;;; version 2 of the License, or (at your option) any later version. +;;; +;;; This library is distributed in the hope that it will be useful, +;;; but WITHOUT ANY WARRANTY; without even the implied warranty of +;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +;;; Library General Public License for more details. +;;; +;;; You should have received a copy of the GNU Library General Public +;;; License along with this library; if not, write to the +;;; Free Software Foundation, Inc., 59 Temple Place - Suite 330, +;;; Boston, MA 02111-1307 USA. + +(in-package :clim-internals) + +(define-bitmap-file-reader :png (image-pathname) + (let* ((png-state (png-read:read-png-file image-pathname)) + (data (png-read:image-data png-state)) + (depth (png-read:bit-depth png-state)) + (height (png-read:height png-state)) + (width (png-read:width png-state)) + (array (make-array (list height width) :element-type '(unsigned-byte 32)))) + (unless (member depth '(8 32)) + (error "~@<PNG-encoded images with bit depth ~D are not supported. The only supported bit depths are 8 and 32.~:@>" depth)) + (dotimes (y height) + (dotimes (x width) + (case depth + ((8 32) + (let ((red (aref data x y 0)) + (green (aref data x y 1)) + (blue (aref data x y 2))) + (setf (aref array y x) + (dpb red (byte 8 0) + (dpb green (byte 8 8) + (dpb blue (byte 8 16) + (dpb (- 255 0) (byte 8 24) 0)))))))))) + array)) diff --git a/mcclim-png-bitmaps.asd b/mcclim-png-bitmaps.asd new file mode 100644 index 0000000..0a63f70 --- /dev/null +++ b/mcclim-png-bitmaps.asd @@ -0,0 +1,24 @@ +;;; -*- Mode: Lisp -*- + +;;; (c) copyright 2009 by +;;; Samium Gromoff (_deepfire(a)feelingofgreen.ru) +;;; +;;; This library is free software; you can redistribute it and/or +;;; modify it under the terms of the GNU Library General Public +;;; License as published by the Free Software Foundation; either +;;; version 2 of the License, or (at your option) any later version. +;;; +;;; This library is distributed in the hope that it will be useful, +;;; but WITHOUT ANY WARRANTY; without even the implied warranty of +;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +;;; Library General Public License for more details. +;;; +;;; You should have received a copy of the GNU Library General Public +;;; License along with this library; if not, write to the +;;; Free Software Foundation, Inc., 59 Temple Place - Suite 330, +;;; Boston, MA 02111-1307 USA. + +(asdf:defsystem :mcclim-png-bitmaps + :description "Support for PNG images in McCLIM bitmap reading functions." + :depends-on (:mcclim :png-read) + :components ((:file "png" :pathname #P"Extensions/Bitmap-formats/png"))) regards, Samium Gromoff -- 1. git://git.feelingofgreen.ru/mcclim, branch 'png-bitmaps' _deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

1 0