From marc.battyani at fractalconcept.com Fri Apr 2 20:04:59 2004 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Fri, 2 Apr 2004 22:04:59 +0200 Subject: [cl-pdf-devel] cl-pdf and cl-typesetting repositories merged Message-ID: <03f401c418ed$c7cdb700$0303a8c0@marc2> Hello, As cl-typesetting depends heavily on cl-pdf, I merged the cl-pdf and cl-typesetting repositories into a single repository. The full repository is here: http://www.fractalconcept.com:8000/open-source/ The cl-pdf part: http://www.fractalconcept.com:8000/open-source/cl-pdf/ The cl-typesetting part: http://www.fractalconcept.com:8000/open-source/cl-typesetting/ I hope to be able to make a new release of cl-typesetting next week with all the stuff added by Dmitri Ivanov(col-span and splitable tables, document layout, etc.). Though all this is already in the repository. Marc From klaus at atsec.com Tue Apr 13 03:47:43 2004 From: klaus at atsec.com (Klaus Weidner) Date: Mon, 12 Apr 2004 22:47:43 -0500 Subject: [cl-pdf-devel] CMUCL compatibility fixes and new color handling code Message-ID: <20040413034743.GA22913@w-m-p.com> Hello, a few results of experimenting with the latest cl-pdf and cl-typesetting code, after once again being disgusted with LaTeX's arbitrary limitations... First of all, the UFFI code still broke on CMUCL, and I finally found out why. Apparently, in CMUCL the foreign library needs to be loaded from a different file than the one it's used from, at least according to the tests contained in the Debian package cl-uffi-tests: ;;; For CMUCL, it's necessary to load foreign files separate from ;;; their usage As a workaround, I've moved the uffi:def-function call to zlib.lisp instead of init.lisp - with that it works fine for cmucl and sbcl. Next, the cl-typesetting examples break because the (set-rgb SYMBOL) method is implemented only for lispworks, and the examples use color specifications such as :red. Other platforms fail with an obscure error message. To fix this, I converted the X11 color database (MIT licensed, so that should be okay) to Lisp hashes, which provides an adequate selection of color names and keywords for all platforms. Note that I copied the list of colors into the source code - so you don't need the X11 file unless you want to rebuild that list. I took out the lispworks special case while doing that - I'd prefer this part to be platform independent ;-) I also updated the (get-rgb STRING) method to support color names as well as the #rrggbb specifications. Note that I didn't add any error handling for undefined colors, since I don't know what the appropriate action should be in such a case. Finally, I'm getting a fairly weird message when compiling cl-typeset w/ CMUCL, it claims that BOX is being redefined. Apparently the (defclass box) in boxes.lisb and the (:accessor box) in tables.lisp conflict - what does the standard say about this? That's just a warning and it works fine if I let it override the definition, but it isn't pretty. To avoid sounding too negative, I continue to be highly impressed by the code, and hope to find more time to hack on it. I need it to handle change bars... -Klaus === old "box" description in boxes.lisp === BOX is an internal symbol in the TYPESET package. Function: # Function arguments: (condition) Its declared argument types are: (T) Its result type is: T On Thursday, 4/8/04 03:39:50 pm CDT it was compiled from: target:code/error.lisp Created: Sunday, 6/8/03 02:23:48 am CDT Comment: $Header: /home/anoncvs/CVS-cmucl/src/code/error.lisp,v 1.65 2003/02/15 23:41:30 pmai Exp $ Its closure environment is: 0: TYPESET::BOX It names a class #. # is a structure of type STANDARD-CLASS. CLASS-INFO: #. ENUMERABLE: NIL. NAME: TYPESET::BOX. LAYOUT: # {481B3565}>. STATE: NIL. DIRECT-SUPERCLASSES: NIL. SUBCLASSES: #. PCL-CLASS: #. It names a PCL class #. # is a class, it is an instance of PCL::STANDARD-CLASS. Its proper name is TYPESET::BOX. The direct superclasses are: (STANDARD-OBJECT), and the direct subclasses are: (TYPESET::CHAR-BOX TYPESET::SOFT-BOX). The class precedence list is: (TYPESET::BOX STANDARD-OBJECT PCL::STD-OBJECT PCL::SLOT-OBJECT INSTANCE ...) There are 9 methods specialized for this class. Its direct slots are: DX, documentation "" DY, documentation "" BASELINE, documentation "" OFFSET, documentation "" === new "box" description in tables.lisp === BOX is an internal symbol in the TYPESET package. Function: # # is a generic function. Its arguments are: (TYPESET::TABLE-CELL) Its methods are: 1: BOX (TYPESET::TABLE-CELL) Method documentation: "automatically generated reader method" It names a class #. # is a structure of type STANDARD-CLASS. CLASS-INFO: #. ENUMERABLE: NIL. NAME: TYPESET::BOX. LAYOUT: # {48066E6D}>. STATE: NIL. DIRECT-SUPERCLASSES: NIL. SUBCLASSES: #. PCL-CLASS: #. It names a PCL class #. # is a class, it is an instance of PCL::STANDARD-CLASS. Its proper name is TYPESET::BOX. The direct superclasses are: (STANDARD-OBJECT), and the direct subclasses are: (TYPESET:TABLE TYPESET::CHAR-BOX TYPESET::SOFT-BOX). The class precedence list is: (TYPESET::BOX STANDARD-OBJECT PCL::STD-OBJECT PCL::SLOT-OBJECT INSTANCE ...) There are 9 methods specialized for this class. Its direct slots are: DX, documentation "" DY, documentation "" BASELINE, documentation "" OFFSET, documentation "" -------------- next part -------------- diff -urN orig/cl-pdf/cl-pdf.asd cl-pdf/cl-pdf.asd --- orig/cl-pdf/cl-pdf.asd Fri Dec 19 15:36:21 2003 +++ cl-pdf/cl-pdf.asd Mon Apr 12 22:29:32 2004 @@ -26,7 +26,8 @@ (:file "t1-font" :depends-on ("font-metrics" "encodings")) (:file "font" :depends-on ("t1-font")) (:file "pdf" :depends-on ("font")) - (:file "pdf-base" :depends-on ("pdf")) + (:file "x11-colors" :depends-on ("defpackage")) + (:file "pdf-base" :depends-on ("pdf" "x11-colors")) (:file "pdf-geom" :depends-on ("pdf-base")) (:file "text" :depends-on ("pdf-base")) (:file "bar-codes" :depends-on ("pdf-geom")) diff -urN orig/cl-pdf/init.lisp cl-pdf/init.lisp --- orig/cl-pdf/init.lisp Mon Feb 9 14:39:42 2004 +++ cl-pdf/init.lisp Mon Apr 12 20:45:04 2004 @@ -23,13 +23,6 @@ (uffi:load-foreign-library zlib-path :module "zlib" :supporting-libraries '("c")) - (uffi:def-function ("compress" c-compress) - ((dest (* :unsigned-char)) - (destlen (* :long)) - (source :cstring) - (source-len :long)) - :returning :int - :module "zlib") (setf *zlib-loaded* t *compress-streams* t)) (progn (warn "Unable to load zlib. Disabling compression.") diff -urN orig/cl-pdf/pdf-base.lisp cl-pdf/pdf-base.lisp --- orig/cl-pdf/pdf-base.lisp Mon Feb 9 14:39:42 2004 +++ cl-pdf/pdf-base.lisp Mon Apr 12 22:07:37 2004 @@ -157,9 +157,11 @@ (values (aref color 0)(aref color 1)(aref color 2))) (:method ((color string)) ; takes a CSS color string like "#CCBBFF" - (values (/ (parse-integer color :start 1 :end 3 :radix 16) 255.0) - (/ (parse-integer color :start 3 :end 5 :radix 16) 255.0) - (/ (parse-integer color :start 5 :end 7 :radix 16) 255.0))) + (if (eql #\# (aref color 0)) + (values (/ (parse-integer color :start 1 :end 3 :radix 16) 255.0) + (/ (parse-integer color :start 3 :end 5 :radix 16) 255.0) + (/ (parse-integer color :start 5 :end 7 :radix 16) 255.0)) + (values-list (gethash (string-downcase color) *x11-color-string-map*)))) (:method ((color integer)) ; a la CSS but specified as a Lisp number like #xCCBBFF (values (/ (ldb (byte 8 16) color) 255.0) @@ -167,9 +169,7 @@ (/ (ldb (byte 8 0) color) 255.0))) (:method ((color symbol)) ; :blue, :darkgreen, or win32:color_3dface - #+lispworks - (lw:when-let (color (color:get-color-spec color)) - (get-rgb color))) ) + (values-list (gethash color *x11-color-keyword-map*)))) (defun set-color-stroke (color) (multiple-value-call #'set-rgb-stroke (get-rgb color))) diff -urN orig/cl-pdf/pdf.lisp cl-pdf/pdf.lisp --- orig/cl-pdf/pdf.lisp Mon Feb 9 16:06:07 2004 +++ cl-pdf/pdf.lisp Mon Apr 12 20:42:37 2004 @@ -188,7 +188,7 @@ ;;; Used to embrace a pdf string used in places other than content streams, ;; e.g. annotations. (let ((string (if (stringp obj) obj (princ-to-string obj)))) - (with-output-to-string (stream nil :element-type (array-element-type string)) + (with-output-to-string (stream nil) (write-char #\( stream) (loop for char across string do (case char ((#\( #\) #\\) (write-char #\\ stream))) diff -urN orig/cl-pdf/x11-colors.lisp cl-pdf/x11-colors.lisp --- orig/cl-pdf/x11-colors.lisp Wed Dec 31 18:00:00 1969 +++ cl-pdf/x11-colors.lisp Mon Apr 12 22:32:42 2004 @@ -0,0 +1,795 @@ +(in-package :pdf) + +(defvar *x11-colors* + '(("LightGreen" 144 238 144) + ("light green" 144 238 144) + ("DarkRed" 139 0 0) + ("dark red" 139 0 0) + ("DarkMagenta" 139 0 139) + ("dark magenta" 139 0 139) + ("DarkCyan" 0 139 139) + ("dark cyan" 0 139 139) + ("DarkBlue" 0 0 139) + ("dark blue" 0 0 139) + ("DarkGray" 169 169 169) + ("dark gray" 169 169 169) + ("DarkGrey" 169 169 169) + ("dark grey" 169 169 169) + ("grey100" 255 255 255) + ("gray100" 255 255 255) + ("grey99" 252 252 252) + ("gray99" 252 252 252) + ("grey98" 250 250 250) + ("gray98" 250 250 250) + ("grey97" 247 247 247) + ("gray97" 247 247 247) + ("grey96" 245 245 245) + ("gray96" 245 245 245) + ("grey95" 242 242 242) + ("gray95" 242 242 242) + ("grey94" 240 240 240) + ("gray94" 240 240 240) + ("grey93" 237 237 237) + ("gray93" 237 237 237) + ("grey92" 235 235 235) + ("gray92" 235 235 235) + ("grey91" 232 232 232) + ("gray91" 232 232 232) + ("grey90" 229 229 229) + ("gray90" 229 229 229) + ("grey89" 227 227 227) + ("gray89" 227 227 227) + ("grey88" 224 224 224) + ("gray88" 224 224 224) + ("grey87" 222 222 222) + ("gray87" 222 222 222) + ("grey86" 219 219 219) + ("gray86" 219 219 219) + ("grey85" 217 217 217) + ("gray85" 217 217 217) + ("grey84" 214 214 214) + ("gray84" 214 214 214) + ("grey83" 212 212 212) + ("gray83" 212 212 212) + ("grey82" 209 209 209) + ("gray82" 209 209 209) + ("grey81" 207 207 207) + ("gray81" 207 207 207) + ("grey80" 204 204 204) + ("gray80" 204 204 204) + ("grey79" 201 201 201) + ("gray79" 201 201 201) + ("grey78" 199 199 199) + ("gray78" 199 199 199) + ("grey77" 196 196 196) + ("gray77" 196 196 196) + ("grey76" 194 194 194) + ("gray76" 194 194 194) + ("grey75" 191 191 191) + ("gray75" 191 191 191) + ("grey74" 189 189 189) + ("gray74" 189 189 189) + ("grey73" 186 186 186) + ("gray73" 186 186 186) + ("grey72" 184 184 184) + ("gray72" 184 184 184) + ("grey71" 181 181 181) + ("gray71" 181 181 181) + ("grey70" 179 179 179) + ("gray70" 179 179 179) + ("grey69" 176 176 176) + ("gray69" 176 176 176) + ("grey68" 173 173 173) + ("gray68" 173 173 173) + ("grey67" 171 171 171) + ("gray67" 171 171 171) + ("grey66" 168 168 168) + ("gray66" 168 168 168) + ("grey65" 166 166 166) + ("gray65" 166 166 166) + ("grey64" 163 163 163) + ("gray64" 163 163 163) + ("grey63" 161 161 161) + ("gray63" 161 161 161) + ("grey62" 158 158 158) + ("gray62" 158 158 158) + ("grey61" 156 156 156) + ("gray61" 156 156 156) + ("grey60" 153 153 153) + ("gray60" 153 153 153) + ("grey59" 150 150 150) + ("gray59" 150 150 150) + ("grey58" 148 148 148) + ("gray58" 148 148 148) + ("grey57" 145 145 145) + ("gray57" 145 145 145) + ("grey56" 143 143 143) + ("gray56" 143 143 143) + ("grey55" 140 140 140) + ("gray55" 140 140 140) + ("grey54" 138 138 138) + ("gray54" 138 138 138) + ("grey53" 135 135 135) + ("gray53" 135 135 135) + ("grey52" 133 133 133) + ("gray52" 133 133 133) + ("grey51" 130 130 130) + ("gray51" 130 130 130) + ("grey50" 127 127 127) + ("gray50" 127 127 127) + ("grey49" 125 125 125) + ("gray49" 125 125 125) + ("grey48" 122 122 122) + ("gray48" 122 122 122) + ("grey47" 120 120 120) + ("gray47" 120 120 120) + ("grey46" 117 117 117) + ("gray46" 117 117 117) + ("grey45" 115 115 115) + ("gray45" 115 115 115) + ("grey44" 112 112 112) + ("gray44" 112 112 112) + ("grey43" 110 110 110) + ("gray43" 110 110 110) + ("grey42" 107 107 107) + ("gray42" 107 107 107) + ("grey41" 105 105 105) + ("gray41" 105 105 105) + ("grey40" 102 102 102) + ("gray40" 102 102 102) + ("grey39" 99 99 99) + ("gray39" 99 99 99) + ("grey38" 97 97 97) + ("gray38" 97 97 97) + ("grey37" 94 94 94) + ("gray37" 94 94 94) + ("grey36" 92 92 92) + ("gray36" 92 92 92) + ("grey35" 89 89 89) + ("gray35" 89 89 89) + ("grey34" 87 87 87) + ("gray34" 87 87 87) + ("grey33" 84 84 84) + ("gray33" 84 84 84) + ("grey32" 82 82 82) + ("gray32" 82 82 82) + ("grey31" 79 79 79) + ("gray31" 79 79 79) + ("grey30" 77 77 77) + ("gray30" 77 77 77) + ("grey29" 74 74 74) + ("gray29" 74 74 74) + ("grey28" 71 71 71) + ("gray28" 71 71 71) + ("grey27" 69 69 69) + ("gray27" 69 69 69) + ("grey26" 66 66 66) + ("gray26" 66 66 66) + ("grey25" 64 64 64) + ("gray25" 64 64 64) + ("grey24" 61 61 61) + ("gray24" 61 61 61) + ("grey23" 59 59 59) + ("gray23" 59 59 59) + ("grey22" 56 56 56) + ("gray22" 56 56 56) + ("grey21" 54 54 54) + ("gray21" 54 54 54) + ("grey20" 51 51 51) + ("gray20" 51 51 51) + ("grey19" 48 48 48) + ("gray19" 48 48 48) + ("grey18" 46 46 46) + ("gray18" 46 46 46) + ("grey17" 43 43 43) + ("gray17" 43 43 43) + ("grey16" 41 41 41) + ("gray16" 41 41 41) + ("grey15" 38 38 38) + ("gray15" 38 38 38) + ("grey14" 36 36 36) + ("gray14" 36 36 36) + ("grey13" 33 33 33) + ("gray13" 33 33 33) + ("grey12" 31 31 31) + ("gray12" 31 31 31) + ("grey11" 28 28 28) + ("gray11" 28 28 28) + ("grey10" 26 26 26) + ("gray10" 26 26 26) + ("grey9" 23 23 23) + ("gray9" 23 23 23) + ("grey8" 20 20 20) + ("gray8" 20 20 20) + ("grey7" 18 18 18) + ("gray7" 18 18 18) + ("grey6" 15 15 15) + ("gray6" 15 15 15) + ("grey5" 13 13 13) + ("gray5" 13 13 13) + ("grey4" 10 10 10) + ("gray4" 10 10 10) + ("grey3" 8 8 8) + ("gray3" 8 8 8) + ("grey2" 5 5 5) + ("gray2" 5 5 5) + ("grey1" 3 3 3) + ("gray1" 3 3 3) + ("grey0" 0 0 0) + ("gray0" 0 0 0) + ("thistle4" 139 123 139) + ("thistle3" 205 181 205) + ("thistle2" 238 210 238) + ("thistle1" 255 225 255) + ("MediumPurple4" 93 71 139) + ("MediumPurple3" 137 104 205) + ("MediumPurple2" 159 121 238) + ("MediumPurple1" 171 130 255) + ("purple4" 85 26 139) + ("purple3" 125 38 205) + ("purple2" 145 44 238) + ("purple1" 155 48 255) + ("DarkOrchid4" 104 34 139) + ("DarkOrchid3" 154 50 205) + ("DarkOrchid2" 178 58 238) + ("DarkOrchid1" 191 62 255) + ("MediumOrchid4" 122 55 139) + ("MediumOrchid3" 180 82 205) + ("MediumOrchid2" 209 95 238) + ("MediumOrchid1" 224 102 255) + ("plum4" 139 102 139) + ("plum3" 205 150 205) + ("plum2" 238 174 238) + ("plum1" 255 187 255) + ("orchid4" 139 71 137) + ("orchid3" 205 105 201) + ("orchid2" 238 122 233) + ("orchid1" 255 131 250) + ("magenta4" 139 0 139) + ("magenta3" 205 0 205) + ("magenta2" 238 0 238) + ("magenta1" 255 0 255) + ("VioletRed4" 139 34 82) + ("VioletRed3" 205 50 120) + ("VioletRed2" 238 58 140) + ("VioletRed1" 255 62 150) + ("maroon4" 139 28 98) + ("maroon3" 205 41 144) + ("maroon2" 238 48 167) + ("maroon1" 255 52 179) + ("PaleVioletRed4" 139 71 93) + ("PaleVioletRed3" 205 104 137) + ("PaleVioletRed2" 238 121 159) + ("PaleVioletRed1" 255 130 171) + ("LightPink4" 139 95 101) + ("LightPink3" 205 140 149) + ("LightPink2" 238 162 173) + ("LightPink1" 255 174 185) + ("pink4" 139 99 108) + ("pink3" 205 145 158) + ("pink2" 238 169 184) + ("pink1" 255 181 197) + ("HotPink4" 139 58 98) + ("HotPink3" 205 96 144) + ("HotPink2" 238 106 167) + ("HotPink1" 255 110 180) + ("DeepPink4" 139 10 80) + ("DeepPink3" 205 16 118) + ("DeepPink2" 238 18 137) + ("DeepPink1" 255 20 147) + ("red4" 139 0 0) + ("red3" 205 0 0) + ("red2" 238 0 0) + ("red1" 255 0 0) + ("OrangeRed4" 139 37 0) + ("OrangeRed3" 205 55 0) + ("OrangeRed2" 238 64 0) + ("OrangeRed1" 255 69 0) + ("tomato4" 139 54 38) + ("tomato3" 205 79 57) + ("tomato2" 238 92 66) + ("tomato1" 255 99 71) + ("coral4" 139 62 47) + ("coral3" 205 91 69) + ("coral2" 238 106 80) + ("coral1" 255 114 86) + ("DarkOrange4" 139 69 0) + ("DarkOrange3" 205 102 0) + ("DarkOrange2" 238 118 0) + ("DarkOrange1" 255 127 0) + ("orange4" 139 90 0) + ("orange3" 205 133 0) + ("orange2" 238 154 0) + ("orange1" 255 165 0) + ("LightSalmon4" 139 87 66) + ("LightSalmon3" 205 129 98) + ("LightSalmon2" 238 149 114) + ("LightSalmon1" 255 160 122) + ("salmon4" 139 76 57) + ("salmon3" 205 112 84) + ("salmon2" 238 130 98) + ("salmon1" 255 140 105) + ("brown4" 139 35 35) + ("brown3" 205 51 51) + ("brown2" 238 59 59) + ("brown1" 255 64 64) + ("firebrick4" 139 26 26) + ("firebrick3" 205 38 38) + ("firebrick2" 238 44 44) + ("firebrick1" 255 48 48) + ("chocolate4" 139 69 19) + ("chocolate3" 205 102 29) + ("chocolate2" 238 118 33) + ("chocolate1" 255 127 36) + ("tan4" 139 90 43) + ("tan3" 205 133 63) + ("tan2" 238 154 73) + ("tan1" 255 165 79) + ("wheat4" 139 126 102) + ("wheat3" 205 186 150) + ("wheat2" 238 216 174) + ("wheat1" 255 231 186) + ("burlywood4" 139 115 85) + ("burlywood3" 205 170 125) + ("burlywood2" 238 197 145) + ("burlywood1" 255 211 155) + ("sienna4" 139 71 38) + ("sienna3" 205 104 57) + ("sienna2" 238 121 66) + ("sienna1" 255 130 71) + ("IndianRed4" 139 58 58) + ("IndianRed3" 205 85 85) + ("IndianRed2" 238 99 99) + ("IndianRed1" 255 106 106) + ("RosyBrown4" 139 105 105) + ("RosyBrown3" 205 155 155) + ("RosyBrown2" 238 180 180) + ("RosyBrown1" 255 193 193) + ("DarkGoldenrod4" 139 101 8) + ("DarkGoldenrod3" 205 149 12) + ("DarkGoldenrod2" 238 173 14) + ("DarkGoldenrod1" 255 185 15) + ("goldenrod4" 139 105 20) + ("goldenrod3" 205 155 29) + ("goldenrod2" 238 180 34) + ("goldenrod1" 255 193 37) + ("gold4" 139 117 0) + ("gold3" 205 173 0) + ("gold2" 238 201 0) + ("gold1" 255 215 0) + ("yellow4" 139 139 0) + ("yellow3" 205 205 0) + ("yellow2" 238 238 0) + ("yellow1" 255 255 0) + ("LightYellow4" 139 139 122) + ("LightYellow3" 205 205 180) + ("LightYellow2" 238 238 209) + ("LightYellow1" 255 255 224) + ("LightGoldenrod4" 139 129 76) + ("LightGoldenrod3" 205 190 112) + ("LightGoldenrod2" 238 220 130) + ("LightGoldenrod1" 255 236 139) + ("khaki4" 139 134 78) + ("khaki3" 205 198 115) + ("khaki2" 238 230 133) + ("khaki1" 255 246 143) + ("DarkOliveGreen4" 110 139 61) + ("DarkOliveGreen3" 162 205 90) + ("DarkOliveGreen2" 188 238 104) + ("DarkOliveGreen1" 202 255 112) + ("OliveDrab4" 105 139 34) + ("OliveDrab3" 154 205 50) + ("OliveDrab2" 179 238 58) + ("OliveDrab1" 192 255 62) + ("chartreuse4" 69 139 0) + ("chartreuse3" 102 205 0) + ("chartreuse2" 118 238 0) + ("chartreuse1" 127 255 0) + ("green4" 0 139 0) + ("green3" 0 205 0) + ("green2" 0 238 0) + ("green1" 0 255 0) + ("SpringGreen4" 0 139 69) + ("SpringGreen3" 0 205 102) + ("SpringGreen2" 0 238 118) + ("SpringGreen1" 0 255 127) + ("PaleGreen4" 84 139 84) + ("PaleGreen3" 124 205 124) + ("PaleGreen2" 144 238 144) + ("PaleGreen1" 154 255 154) + ("SeaGreen4" 46 139 87) + ("SeaGreen3" 67 205 128) + ("SeaGreen2" 78 238 148) + ("SeaGreen1" 84 255 159) + ("DarkSeaGreen4" 105 139 105) + ("DarkSeaGreen3" 155 205 155) + ("DarkSeaGreen2" 180 238 180) + ("DarkSeaGreen1" 193 255 193) + ("aquamarine4" 69 139 116) + ("aquamarine3" 102 205 170) + ("aquamarine2" 118 238 198) + ("aquamarine1" 127 255 212) + ("DarkSlateGray4" 82 139 139) + ("DarkSlateGray3" 121 205 205) + ("DarkSlateGray2" 141 238 238) + ("DarkSlateGray1" 151 255 255) + ("cyan4" 0 139 139) + ("cyan3" 0 205 205) + ("cyan2" 0 238 238) + ("cyan1" 0 255 255) + ("turquoise4" 0 134 139) + ("turquoise3" 0 197 205) + ("turquoise2" 0 229 238) + ("turquoise1" 0 245 255) + ("CadetBlue4" 83 134 139) + ("CadetBlue3" 122 197 205) + ("CadetBlue2" 142 229 238) + ("CadetBlue1" 152 245 255) + ("PaleTurquoise4" 102 139 139) + ("PaleTurquoise3" 150 205 205) + ("PaleTurquoise2" 174 238 238) + ("PaleTurquoise1" 187 255 255) + ("LightCyan4" 122 139 139) + ("LightCyan3" 180 205 205) + ("LightCyan2" 209 238 238) + ("LightCyan1" 224 255 255) + ("LightBlue4" 104 131 139) + ("LightBlue3" 154 192 205) + ("LightBlue2" 178 223 238) + ("LightBlue1" 191 239 255) + ("LightSteelBlue4" 110 123 139) + ("LightSteelBlue3" 162 181 205) + ("LightSteelBlue2" 188 210 238) + ("LightSteelBlue1" 202 225 255) + ("SlateGray4" 108 123 139) + ("SlateGray3" 159 182 205) + ("SlateGray2" 185 211 238) + ("SlateGray1" 198 226 255) + ("LightSkyBlue4" 96 123 139) + ("LightSkyBlue3" 141 182 205) + ("LightSkyBlue2" 164 211 238) + ("LightSkyBlue1" 176 226 255) + ("SkyBlue4" 74 112 139) + ("SkyBlue3" 108 166 205) + ("SkyBlue2" 126 192 238) + ("SkyBlue1" 135 206 255) + ("DeepSkyBlue4" 0 104 139) + ("DeepSkyBlue3" 0 154 205) + ("DeepSkyBlue2" 0 178 238) + ("DeepSkyBlue1" 0 191 255) + ("SteelBlue4" 54 100 139) + ("SteelBlue3" 79 148 205) + ("SteelBlue2" 92 172 238) + ("SteelBlue1" 99 184 255) + ("DodgerBlue4" 16 78 139) + ("DodgerBlue3" 24 116 205) + ("DodgerBlue2" 28 134 238) + ("DodgerBlue1" 30 144 255) + ("blue4" 0 0 139) + ("blue3" 0 0 205) + ("blue2" 0 0 238) + ("blue1" 0 0 255) + ("RoyalBlue4" 39 64 139) + ("RoyalBlue3" 58 95 205) + ("RoyalBlue2" 67 110 238) + ("RoyalBlue1" 72 118 255) + ("SlateBlue4" 71 60 139) + ("SlateBlue3" 105 89 205) + ("SlateBlue2" 122 103 238) + ("SlateBlue1" 131 111 255) + ("azure4" 131 139 139) + ("azure3" 193 205 205) + ("azure2" 224 238 238) + ("azure1" 240 255 255) + ("MistyRose4" 139 125 123) + ("MistyRose3" 205 183 181) + ("MistyRose2" 238 213 210) + ("MistyRose1" 255 228 225) + ("LavenderBlush4" 139 131 134) + ("LavenderBlush3" 205 193 197) + ("LavenderBlush2" 238 224 229) + ("LavenderBlush1" 255 240 245) + ("honeydew4" 131 139 131) + ("honeydew3" 193 205 193) + ("honeydew2" 224 238 224) + ("honeydew1" 240 255 240) + ("ivory4" 139 139 131) + ("ivory3" 205 205 193) + ("ivory2" 238 238 224) + ("ivory1" 255 255 240) + ("cornsilk4" 139 136 120) + ("cornsilk3" 205 200 177) + ("cornsilk2" 238 232 205) + ("cornsilk1" 255 248 220) + ("LemonChiffon4" 139 137 112) + ("LemonChiffon3" 205 201 165) + ("LemonChiffon2" 238 233 191) + ("LemonChiffon1" 255 250 205) + ("NavajoWhite4" 139 121 94) + ("NavajoWhite3" 205 179 139) + ("NavajoWhite2" 238 207 161) + ("NavajoWhite1" 255 222 173) + ("PeachPuff4" 139 119 101) + ("PeachPuff3" 205 175 149) + ("PeachPuff2" 238 203 173) + ("PeachPuff1" 255 218 185) + ("bisque4" 139 125 107) + ("bisque3" 205 183 158) + ("bisque2" 238 213 183) + ("bisque1" 255 228 196) + ("AntiqueWhite4" 139 131 120) + ("AntiqueWhite3" 205 192 176) + ("AntiqueWhite2" 238 223 204) + ("AntiqueWhite1" 255 239 219) + ("seashell4" 139 134 130) + ("seashell3" 205 197 191) + ("seashell2" 238 229 222) + ("seashell1" 255 245 238) + ("snow4" 139 137 137) + ("snow3" 205 201 201) + ("snow2" 238 233 233) + ("snow1" 255 250 250) + ("thistle" 216 191 216) + ("MediumPurple" 147 112 219) + ("medium purple" 147 112 219) + ("purple" 160 32 240) + ("BlueViolet" 138 43 226) + ("blue violet" 138 43 226) + ("DarkViolet" 148 0 211) + ("dark violet" 148 0 211) + ("DarkOrchid" 153 50 204) + ("dark orchid" 153 50 204) + ("MediumOrchid" 186 85 211) + ("medium orchid" 186 85 211) + ("orchid" 218 112 214) + ("plum" 221 160 221) + ("violet" 238 130 238) + ("magenta" 255 0 255) + ("VioletRed" 208 32 144) + ("violet red" 208 32 144) + ("MediumVioletRed" 199 21 133) + ("medium violet red" 199 21 133) + ("maroon" 176 48 96) + ("PaleVioletRed" 219 112 147) + ("pale violet red" 219 112 147) + ("LightPink" 255 182 193) + ("light pink" 255 182 193) + ("pink" 255 192 203) + ("DeepPink" 255 20 147) + ("deep pink" 255 20 147) + ("HotPink" 255 105 180) + ("hot pink" 255 105 180) + ("red" 255 0 0) + ("OrangeRed" 255 69 0) + ("orange red" 255 69 0) + ("tomato" 255 99 71) + ("LightCoral" 240 128 128) + ("light coral" 240 128 128) + ("coral" 255 127 80) + ("DarkOrange" 255 140 0) + ("dark orange" 255 140 0) + ("orange" 255 165 0) + ("LightSalmon" 255 160 122) + ("light salmon" 255 160 122) + ("salmon" 250 128 114) + ("DarkSalmon" 233 150 122) + ("dark salmon" 233 150 122) + ("brown" 165 42 42) + ("firebrick" 178 34 34) + ("chocolate" 210 105 30) + ("tan" 210 180 140) + ("SandyBrown" 244 164 96) + ("sandy brown" 244 164 96) + ("wheat" 245 222 179) + ("beige" 245 245 220) + ("burlywood" 222 184 135) + ("peru" 205 133 63) + ("sienna" 160 82 45) + ("SaddleBrown" 139 69 19) + ("saddle brown" 139 69 19) + ("IndianRed" 205 92 92) + ("indian red" 205 92 92) + ("RosyBrown" 188 143 143) + ("rosy brown" 188 143 143) + ("DarkGoldenrod" 184 134 11) + ("dark goldenrod" 184 134 11) + ("goldenrod" 218 165 32) + ("LightGoldenrod" 238 221 130) + ("light goldenrod" 238 221 130) + ("gold" 255 215 0) + ("yellow" 255 255 0) + ("LightYellow" 255 255 224) + ("light yellow" 255 255 224) + ("LightGoldenrodYellow" 250 250 210) + ("light goldenrod yellow" 250 250 210) + ("PaleGoldenrod" 238 232 170) + ("pale goldenrod" 238 232 170) + ("khaki" 240 230 140) + ("DarkKhaki" 189 183 107) + ("dark khaki" 189 183 107) + ("OliveDrab" 107 142 35) + ("olive drab" 107 142 35) + ("ForestGreen" 34 139 34) + ("forest green" 34 139 34) + ("YellowGreen" 154 205 50) + ("yellow green" 154 205 50) + ("LimeGreen" 50 205 50) + ("lime green" 50 205 50) + ("GreenYellow" 173 255 47) + ("green yellow" 173 255 47) + ("MediumSpringGreen" 0 250 154) + ("medium spring green" 0 250 154) + ("chartreuse" 127 255 0) + ("green" 0 255 0) + ("LawnGreen" 124 252 0) + ("lawn green" 124 252 0) + ("SpringGreen" 0 255 127) + ("spring green" 0 255 127) + ("PaleGreen" 152 251 152) + ("pale green" 152 251 152) + ("LightSeaGreen" 32 178 170) + ("light sea green" 32 178 170) + ("MediumSeaGreen" 60 179 113) + ("medium sea green" 60 179 113) + ("SeaGreen" 46 139 87) + ("sea green" 46 139 87) + ("DarkSeaGreen" 143 188 143) + ("dark sea green" 143 188 143) + ("DarkOliveGreen" 85 107 47) + ("dark olive green" 85 107 47) + ("DarkGreen" 0 100 0) + ("dark green" 0 100 0) + ("aquamarine" 127 255 212) + ("MediumAquamarine" 102 205 170) + ("medium aquamarine" 102 205 170) + ("CadetBlue" 95 158 160) + ("cadet blue" 95 158 160) + ("LightCyan" 224 255 255) + ("light cyan" 224 255 255) + ("cyan" 0 255 255) + ("turquoise" 64 224 208) + ("MediumTurquoise" 72 209 204) + ("medium turquoise" 72 209 204) + ("DarkTurquoise" 0 206 209) + ("dark turquoise" 0 206 209) + ("PaleTurquoise" 175 238 238) + ("pale turquoise" 175 238 238) + ("PowderBlue" 176 224 230) + ("powder blue" 176 224 230) + ("LightBlue" 173 216 230) + ("light blue" 173 216 230) + ("LightSteelBlue" 176 196 222) + ("light steel blue" 176 196 222) + ("SteelBlue" 70 130 180) + ("steel blue" 70 130 180) + ("LightSkyBlue" 135 206 250) + ("light sky blue" 135 206 250) + ("SkyBlue" 135 206 235) + ("sky blue" 135 206 235) + ("DeepSkyBlue" 0 191 255) + ("deep sky blue" 0 191 255) + ("DodgerBlue" 30 144 255) + ("dodger blue" 30 144 255) + ("blue" 0 0 255) + ("RoyalBlue" 65 105 225) + ("royal blue" 65 105 225) + ("MediumBlue" 0 0 205) + ("medium blue" 0 0 205) + ("LightSlateBlue" 132 112 255) + ("light slate blue" 132 112 255) + ("MediumSlateBlue" 123 104 238) + ("medium slate blue" 123 104 238) + ("SlateBlue" 106 90 205) + ("slate blue" 106 90 205) + ("DarkSlateBlue" 72 61 139) + ("dark slate blue" 72 61 139) + ("CornflowerBlue" 100 149 237) + ("cornflower blue" 100 149 237) + ("NavyBlue" 0 0 128) + ("navy blue" 0 0 128) + ("navy" 0 0 128) + ("MidnightBlue" 25 25 112) + ("midnight blue" 25 25 112) + ("LightGray" 211 211 211) + ("light gray" 211 211 211) + ("LightGrey" 211 211 211) + ("light grey" 211 211 211) + ("grey" 190 190 190) + ("gray" 190 190 190) + ("LightSlateGrey" 119 136 153) + ("light slate grey" 119 136 153) + ("LightSlateGray" 119 136 153) + ("light slate gray" 119 136 153) + ("SlateGrey" 112 128 144) + ("slate grey" 112 128 144) + ("SlateGray" 112 128 144) + ("slate gray" 112 128 144) + ("DimGrey" 105 105 105) + ("dim grey" 105 105 105) + ("DimGray" 105 105 105) + ("dim gray" 105 105 105) + ("DarkSlateGrey" 47 79 79) + ("dark slate grey" 47 79 79) + ("DarkSlateGray" 47 79 79) + ("dark slate gray" 47 79 79) + ("black" 0 0 0) + ("white" 255 255 255) + ("MistyRose" 255 228 225) + ("misty rose" 255 228 225) + ("LavenderBlush" 255 240 245) + ("lavender blush" 255 240 245) + ("lavender" 230 230 250) + ("AliceBlue" 240 248 255) + ("alice blue" 240 248 255) + ("azure" 240 255 255) + ("MintCream" 245 255 250) + ("mint cream" 245 255 250) + ("honeydew" 240 255 240) + ("seashell" 255 245 238) + ("LemonChiffon" 255 250 205) + ("lemon chiffon" 255 250 205) + ("ivory" 255 255 240) + ("cornsilk" 255 248 220) + ("moccasin" 255 228 181) + ("NavajoWhite" 255 222 173) + ("navajo white" 255 222 173) + ("PeachPuff" 255 218 185) + ("peach puff" 255 218 185) + ("bisque" 255 228 196) + ("BlanchedAlmond" 255 235 205) + ("blanched almond" 255 235 205) + ("PapayaWhip" 255 239 213) + ("papaya whip" 255 239 213) + ("AntiqueWhite" 250 235 215) + ("antique white" 250 235 215) + ("linen" 250 240 230) + ("OldLace" 253 245 230) + ("old lace" 253 245 230) + ("FloralWhite" 255 250 240) + ("floral white" 255 250 240) + ("gainsboro" 220 220 220) + ("WhiteSmoke" 245 245 245) + ("white smoke" 245 245 245) + ("GhostWhite" 248 248 255) + ("ghost white" 248 248 255) + ("snow" 255 250 250))) + +(defvar *x11-color-string-map* + (let ((h (make-hash-table :test #'equal))) + (dolist (c *x11-colors*) + (setf (gethash (string-downcase (car c)) h) + (mapcar (lambda (v) (/ v 255.0)) + (cdr c)))) + h) + "Hash table mapping lowercase color strings to (r g b) lists") + +(defvar *x11-color-keyword-map* + (let ((h (make-hash-table :test #'eq))) + (dolist (c *x11-colors*) + (setf (gethash (intern (string-upcase (car c)) "KEYWORD") + h) + (mapcar (lambda (v) (/ v 255.0)) + (cdr c)))) + h) + "Hash table mapping :COLOR keywords to (r g b) lists") + +;; only needed to run this once to generate the color table above +#-(and) +(defun generate-color-table (&optional (rgb-db #p"/usr/lib/X11/rgb.txt")) + (let ((colors nil)) + (with-open-file (i rgb-db :direction :input) + (do ((line (read-line i nil :eof) + (read-line i nil :eof))) + ((eq line :eof)) + (multiple-value-bind (match regs) + (cl-ppcre:scan-to-strings + "^\\s*(\\d+)\\s+(\\d+)\\s+(\\d+)\\s+(.*?)\\s*$" + line) + (if match + (push (list (aref regs 3) + (parse-integer (aref regs 0)) + (parse-integer (aref regs 1)) + (parse-integer (aref regs 2))) + colors))))) + (format t "(~{~S~%~})" colors) + nil)) diff -urN orig/cl-pdf/zlib.lisp cl-pdf/zlib.lisp --- orig/cl-pdf/zlib.lisp Fri Jan 30 10:31:48 2004 +++ cl-pdf/zlib.lisp Mon Apr 12 20:45:21 2004 @@ -6,6 +6,14 @@ ;Adapted from an UFFI example +(uffi:def-function ("compress" c-compress) + ((dest (* :unsigned-char)) + (destlen (* :long)) + (source :cstring) + (source-len :long)) + :returning :int + :module "zlib") + (defun compress-string (source) "Returns two values: array of bytes containing the compressed data and the numbe of compressed bytes" From klaus at atsec.com Tue Apr 13 03:56:47 2004 From: klaus at atsec.com (Klaus Weidner) Date: Mon, 12 Apr 2004 22:56:47 -0500 Subject: [cl-pdf-devel] CMUCL compatibility fixes and new color handling code In-Reply-To: <20040413034743.GA22913@w-m-p.com> References: <20040413034743.GA22913@w-m-p.com> Message-ID: <20040413035647.GA23373@w-m-p.com> Oops, forgot to explain one part of the patch. CMUCL doesn't like the :element-type specification for with-output-to-string, and according to the standard that indeed doesn't seem to be permitted. -Klaus On Mon, Apr 12, 2004 at 10:47:43PM -0500, Klaus Weidner wrote: > diff -urN orig/cl-pdf/pdf.lisp cl-pdf/pdf.lisp > --- orig/cl-pdf/pdf.lisp Mon Feb 9 16:06:07 2004 > +++ cl-pdf/pdf.lisp Mon Apr 12 20:42:37 2004 > @@ -188,7 +188,7 @@ > ;;; Used to embrace a pdf string used in places other than content streams, > ;; e.g. annotations. > (let ((string (if (stringp obj) obj (princ-to-string obj)))) > - (with-output-to-string (stream nil :element-type (array-element-type string)) > + (with-output-to-string (stream nil) > (write-char #\( stream) > (loop for char across string > do (case char ((#\( #\) #\\) (write-char #\\ stream))) From divanov at aha.ru Tue Apr 13 05:51:51 2004 From: divanov at aha.ru (Dmitri Ivanov) Date: Tue, 13 Apr 2004 09:51:51 +0400 Subject: [cl-pdf-devel] CMUCL compatibility fixes and new color handling code References: <20040413034743.GA22913@w-m-p.com> Message-ID: <001701c4211b$d0ea8300$644302c3@digo> Hello Klaus, | ...snip...| | Next, the cl-typesetting examples break because the (set-rgb SYMBOL) | method is implemented only for lispworks, and the examples use color | specifications such as :red. Other platforms fail with an obscure error | message. Agree that the symbolic color specification must not have been included in the example file :-) But this feature is that useful and has to be available to other CL implementations. | To fix this, I converted the X11 color database (MIT licensed, so that | should be okay) to Lisp hashes, which provides an adequate selection | of color names and keywords for all platforms. Note that I copied the | list of colors into the source code - so you don't need the X11 file | unless you want to rebuild that list. I took out the lispworks special | case while doing that - I'd prefer this part to be platform independent | ;-) | | I also updated the (get-rgb STRING) method to support color names as | well as the #rrggbb specifications. Note that I didn't add any error | handling for undefined colors, since I don't know what the appropriate | action should be in such a case. Good proposal. Suggest including x11-colors.lisp as an optional feature, i.e. conditionalizing the rest of code by something like #+x11-colors and #-x11-colors. | Finally, I'm getting a fairly weird message when compiling cl-typeset | w/ CMUCL, it claims that BOX is being redefined. Apparently the | (defclass box) in boxes.lisb and the (:accessor box) in tables.lisp | conflict - what does the standard say about this? That's just a warning | and it works fine if I let it override the definition, but it isn't | pretty. According to the standard, there is no limitation on using the same symbol as a class name and a function name since those are in different "namespaces". Please investigate how to suppress the warning on CMUCL. | Oops, forgot to explain one part of the patch. CMUCL doesn't like the | :element-type specification for with-output-to-string, and according to | the standard that indeed doesn't seem to be permitted. What standard do you refer to? ANSI CL _does allow_ :element-type. Pragmatically, I need this when dealing with Unicode characters. Suggest conditionalize with #-cmu. -- Sincerely, Dmitri Ivanov lisp.ystok.ru From klaus at atsec.com Tue Apr 13 06:10:15 2004 From: klaus at atsec.com (Klaus Weidner) Date: Tue, 13 Apr 2004 01:10:15 -0500 Subject: [cl-pdf-devel] CMUCL compatibility fixes and new color handling code In-Reply-To: <001701c4211b$d0ea8300$644302c3@digo> References: <20040413034743.GA22913@w-m-p.com> <001701c4211b$d0ea8300$644302c3@digo> Message-ID: <20040413061015.GB23373@w-m-p.com> On Tue, Apr 13, 2004 at 09:51:51AM +0400, Dmitri Ivanov wrote: > Agree that the symbolic color specification must not have been included in > the example file :-) > But this feature is that useful and has to be available to other CL > implementations. I agree that it's useful, that's why I took a stab at making a portable implementation of it... > | I also updated the (get-rgb STRING) method to support color names as > | well as the #rrggbb specifications. Note that I didn't add any error > | handling for undefined colors, since I don't know what the appropriate > | action should be in such a case. > > Good proposal. Suggest including x11-colors.lisp as an optional feature, > i.e. conditionalizing the rest of code by something like #+x11-colors and > #-x11-colors. I'm not entirely sure what the point of conditionalizing that is, unless there's some other standard color selection mechanism included instead. Keep in mind that my code does not in any way depend on having X11 installed, it's completely self-contained, and nobody *forces* you to use the keywords or strings if you don't like them. You can always directly specify colors, i.e. based on your own mappings. A less invasive approach would be to use the 16 W3C standardized HTML colors. Note that the larger set of nonstandard HTML colors supported by IE and Netscape/Mozilla appears to be identical to the X11 color set. > According to the standard, there is no limitation on using the same symbol > as a class name and a function name since those are in different > "namespaces". Please investigate how to suppress the warning on CMUCL. I'll see if I can find something, but I must admit that it's not something I have high hopes for solving. It took me long enough just to figure out what the warning message was all about :-( > | Oops, forgot to explain one part of the patch. CMUCL doesn't like the > | :element-type specification for with-output-to-string, and according to > | the standard that indeed doesn't seem to be permitted. > > What standard do you refer to? ANSI CL _does allow_ :element-type. > Pragmatically, I need this when dealing with Unicode characters. Suggest > conditionalize with #-cmu. Sorry about that, I was obviously looking in the wrong place. Then that seems to be a CMUCL bug, it doesn't know about the keyword: WITH-OUTPUT-TO-STRING is an external symbol in the COMMON-LISP package. Macro-function: # Macro arguments: ((var &optional string) &body (forms decls)) So conditionalizing it is the right thing to do. SBCL appears to be standards-compliant here. -Klaus From divanov at aha.ru Tue Apr 13 08:12:20 2004 From: divanov at aha.ru (Dmitri Ivanov) Date: Tue, 13 Apr 2004 12:12:20 +0400 Subject: [cl-pdf-devel] CMUCL compatibility fixes and new color handling code References: <20040413034743.GA22913@w-m-p.com> <001701c4211b$d0ea8300$644302c3@digo> <20040413061015.GB23373@w-m-p.com> Message-ID: <001f01c4212f$3bde7230$644302c3@digo> Hello Klaus, |> Good proposal. Suggest including x11-colors.lisp as an optional |> feature, i.e. conditionalizing the rest of code by something like |> #+x11-colors and #-x11-colors. | | I'm not entirely sure what the point of conditionalizing that is, | unless there's some other standard color selection mechanism included | instead. Keep in mind that my code does not in any way depend on having | X11 installed, it's completely self-contained, and nobody *forces* you | to use the keywords or strings if you don't like them. You can always | directly specify colors, i.e. based on your own mappings. I consider conditionalizing the only way not to be forced. | A less invasive approach would be to use the 16 W3C standardized HTML | colors. Note that the larger set of nonstandard HTML colors supported | by IE and Netscape/Mozilla appears to be identical to the X11 color | set. Is there much need of anything standard here? In contrast to browsers, PDF does not standardize on symbolic color names. OTOH, creating PDF files is a kind of private process. Authors are unlikely to share their typeset-dependent code (except while developing cl-pdf itself), but the resulting pdfs instead. They are likely to exploit the color system they get used to within their favorite CL development environment, e.g. LispWorks CAPI, and not to learn any additional color database. IMHO a color system should be provided for those implementations that lack it (even if the system comes from honorable X11 :-)). -- Sincerely, Dmitri Ivanov lisp.ystok.ru From marc.battyani at fractalconcept.com Tue Apr 13 11:23:54 2004 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Tue, 13 Apr 2004 13:23:54 +0200 Subject: [cl-pdf-devel] CMUCL compatibility fixes and new color handlingcode References: <20040413034743.GA22913@w-m-p.com> <20040413035647.GA23373@w-m-p.com> Message-ID: <02dc01c42149$cef74fa0$0a04a8c0@marcxp> "Klaus Weidner" klaus at atsec.com writes: > Oops, forgot to explain one part of the patch. CMUCL doesn't like the > :element-type specification for with-output-to-string, and according to > the standard that indeed doesn't seem to be permitted. >From the hyperspec : Macro WITH-OUTPUT-TO-STRING Syntax: with-output-to-string (var &optional string-form &key element-type) declaration* form* => result* Arguments and Values: var---a variable name. string-form---a form or nil; if non-nil, evaluated to produce string. string---a string that has a fill pointer. element-type---a type specifier; evaluated. The default is character. So it looks like it's a CMUCL problem here. If you are using using the latest version, I will put a few #-cmucl for this. (If a cmucl feature exists) Marc From marc.battyani at fractalconcept.com Tue Apr 13 11:23:30 2004 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Tue, 13 Apr 2004 13:23:30 +0200 Subject: [cl-pdf-devel] CMUCL compatibility fixes and new color handling code References: <20040413034743.GA22913@w-m-p.com> Message-ID: <02db01c42149$c11080f0$0a04a8c0@marcxp> "Klaus Weidner" writes: > a few results of experimenting with the latest cl-pdf and cl-typesetting > code, after once again being disgusted with LaTeX's arbitrary > limitations... I understand that... ;-) > First of all, the UFFI code still broke on CMUCL, and I finally found out > why. Apparently, in CMUCL the foreign library needs to be loaded from a > different file than the one it's used from, at least according to the > tests contained in the Debian package cl-uffi-tests: > > ;;; For CMUCL, it's necessary to load foreign files separate from > ;;; their usage > > As a workaround, I've moved the uffi:def-function call to zlib.lisp > instead of init.lisp - with that it works fine for cmucl and sbcl. OK, no problem, I'm used to change the zlib ffi at each release! :) But by doing so you loose the ability to reconnect at run time. For instance in a saved image or a delivered application. So maybe the (load-zlib) should be put zlib.lisp? Or should only be called from the application? Is there a similar problem with SBCL ? Are there other people using cl-pdf with CMUCL ? What do they do with zlib? > Next, the cl-typesetting examples break because the (set-rgb SYMBOL) > method is implemented only for lispworks, and the examples use color > specifications such as :red. Other platforms fail with an obscure error > message. > > To fix this, I converted the X11 color database (MIT licensed, so that > should be okay) to Lisp hashes, which provides an adequate selection > of color names and keywords for all platforms. Note that I copied the > list of colors into the source code - so you don't need the X11 file > unless you want to rebuild that list. I took out the lispworks special > case while doing that - I'd prefer this part to be platform independent ;-) > > I also updated the (get-rgb STRING) method to support color names as > well as the #rrggbb specifications. Note that I didn't add any error > handling for undefined colors, since I don't know what the appropriate > action should be in such a case. Thanks for the code, I'm adding it to cl-pdf for the non Lispworks implementations. (The X11 color table is already included in LW. This is why Dmitri does not want it) I will publish it ASAP. > Finally, I'm getting a fairly weird message when compiling cl-typeset w/ > CMUCL, it claims that BOX is being redefined. Apparently the (defclass > box) in boxes.lisb and the (:accessor box) in tables.lisp conflict - what > does the standard say about this? That's just a warning and it works fine > if I let it override the definition, but it isn't pretty. This is rather strange. It should work IMO. Does it work on SBCL ? > To avoid sounding too negative, I continue to be highly impressed by the > code, and hope to find more time to hack on it. I need it to handle > change bars... :) Marc From edi at agharta.de Tue Apr 13 12:11:40 2004 From: edi at agharta.de (Edi Weitz) Date: Tue, 13 Apr 2004 14:11:40 +0200 Subject: [cl-pdf-devel] CMUCL compatibility fixes and new color handlingcode In-Reply-To: <02dc01c42149$cef74fa0$0a04a8c0@marcxp> (Marc Battyani's message of "Tue, 13 Apr 2004 13:23:54 +0200") References: <20040413034743.GA22913@w-m-p.com> <20040413035647.GA23373@w-m-p.com> <02dc01c42149$cef74fa0$0a04a8c0@marcxp> Message-ID: On Tue, 13 Apr 2004 13:23:54 +0200, "Marc Battyani" wrote: > If you are using using the latest version, I will put a few #-cmucl > for this. (If a cmucl feature exists) Should be #-cmu. Edi. From marc.battyani at fractalconcept.com Tue Apr 13 12:28:51 2004 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Tue, 13 Apr 2004 14:28:51 +0200 Subject: [cl-pdf-devel] CMUCL compatibility fixes and new color handlingcode References: <20040413034743.GA22913@w-m-p.com><20040413035647.GA23373@w-m-p.com><02dc01c42149$cef74fa0$0a04a8c0@marcxp> Message-ID: <031d01c42152$e227cab0$0a04a8c0@marcxp> "Edi Weitz" wrote: > On Tue, 13 Apr 2004 13:23:54 +0200, "Marc Battyani" wrote: > > > If you are using using the latest version, I will put a few #-cmucl > > for this. (If a cmucl feature exists) > > Should be #-cmu. OK. BTW as you are the latest one who changed the zlib FFI ;-), have you some ideas on the CMUCL FFI problem? (and on the other CMUCL issues...) Marc From crimsonf at cs.tu-berlin.de Tue Apr 13 13:13:02 2004 From: crimsonf at cs.tu-berlin.de (Stephan Frank) Date: Tue, 13 Apr 2004 15:13:02 +0200 (MEST) Subject: [cl-pdf-devel] CMUCL compatibility fixes and new color handlingcode In-Reply-To: <02dc01c42149$cef74fa0$0a04a8c0@marcxp> References: <20040413034743.GA22913@w-m-p.com> <20040413035647.GA23373@w-m-p.com> <02dc01c42149$cef74fa0$0a04a8c0@marcxp> Message-ID: On Tue, 13 Apr 2004, Marc Battyani wrote: > "Klaus Weidner" klaus at atsec.com writes: > > > Oops, forgot to explain one part of the patch. CMUCL doesn't like the > > :element-type specification for with-output-to-string, and according to > > the standard that indeed doesn't seem to be permitted. > > >From the hyperspec : > > Macro WITH-OUTPUT-TO-STRING > Syntax: > with-output-to-string (var &optional string-form &key element-type) > declaration* form* > => result* > Arguments and Values: > var---a variable name. > string-form---a form or nil; if non-nil, evaluated to produce string. > string---a string that has a fill pointer. > element-type---a type specifier; evaluated. The default is character. > > So it looks like it's a CMUCL problem here. If you are using using the > latest version, I will put a few #-cmucl for this. (If a cmucl feature > exists) Hallo, current CMUCL snapshots should have no problem with this. from cvs log: revision 1.96 date: 2003/07/17 17:48:32; author: gerd; state: Exp; lines: +3 -2 * src/code/macros.lisp (with-output-to-string): Add and ignore element-type. So Klaus is probably using the latest official release (18e) which does not incorporate this fix yet. Kind regards, Stephan From marc.battyani at fractalconcept.com Tue Apr 13 13:31:06 2004 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Tue, 13 Apr 2004 15:31:06 +0200 Subject: [cl-pdf-devel] CMUCL compatibility fixes and new colorhandlingcode References: <20040413034743.GA22913@w-m-p.com><20040413035647.GA23373@w-m-p.com><02dc01c42149$cef74fa0$0a04a8c0@marcxp> Message-ID: <038c01c4215b$93c94c00$0a04a8c0@marcxp> "Stephan Frank" wrote: > On Tue, 13 Apr 2004, Marc Battyani wrote: ... > > So it looks like it's a CMUCL problem here. If you are using using the > > latest version, I will put a few #-cmucl for this. (If a cmucl feature > > exists) > > current CMUCL snapshots should have no problem with this. from cvs log: > > revision 1.96 > date: 2003/07/17 17:48:32; author: gerd; state: Exp; lines: +3 -2 > * src/code/macros.lisp (with-output-to-string): Add and > ignore element-type. > > So Klaus is probably using the latest official release (18e) which does > not incorporate this fix yet. Great! Are the other issues also corrected in the current CMUCL ? Marc From marc.battyani at fractalconcept.com Tue Apr 13 13:47:52 2004 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Tue, 13 Apr 2004 15:47:52 +0200 Subject: [cl-pdf-devel] standard color names References: <20040413034743.GA22913@w-m-p.com><20040413035647.GA23373@w-m-p.com><02dc01c42149$cef74fa0$0a04a8c0@marcxp> Message-ID: <039901c4215d$ed41e3d0$0a04a8c0@marcxp> Hello, I've merged Klaus Weidner's code for using standard color names in implementations other than Lispworks. In Lispworks the Lispworks color module is used instead It's on the repository. Marc From crimsonf at cs.tu-berlin.de Tue Apr 13 14:55:33 2004 From: crimsonf at cs.tu-berlin.de (Stephan Frank) Date: Tue, 13 Apr 2004 16:55:33 +0200 (MEST) Subject: [cl-pdf-devel] CMUCL compatibility fixes and new colorhandlingcode In-Reply-To: <038c01c4215b$93c94c00$0a04a8c0@marcxp> References: <20040413034743.GA22913@w-m-p.com><20040413035647.GA23373@w-m-p.com><02dc01c42149$cef74fa0$0a04a8c0@marcxp> <038c01c4215b$93c94c00$0a04a8c0@marcxp> Message-ID: On Tue, 13 Apr 2004, Marc Battyani wrote: > "Stephan Frank" wrote: > > > On Tue, 13 Apr 2004, Marc Battyani wrote: > ... > > > So it looks like it's a CMUCL problem here. If you are using using the > > > latest version, I will put a few #-cmucl for this. (If a cmucl feature > > > exists) > > > > current CMUCL snapshots should have no problem with this. from cvs log: > > > > revision 1.96 > > date: 2003/07/17 17:48:32; author: gerd; state: Exp; lines: +3 -2 > > * src/code/macros.lisp (with-output-to-string): Add and > > ignore element-type. > > > > So Klaus is probably using the latest official release (18e) which does > > not incorporate this fix yet. > > Great! > Are the other issues also corrected in the current CMUCL ? The move of (uffi:def-function ("compress" c-compress)...) is still necessary, otherwise there will be a complaint that "compress" is unknown. The 'box' name-clash seems to have been corrected, but I don't know for 100% sure -- my cl-pdf is broken somehow so I can't compile a complete system. At least compiling and loading boxes/tables.lisp does not give any redefinition warnings. By the way, what is the best way to _anonymously_ check out the current sources? I am unable to do this since the repository location changed resently. regs, Stephan From marc.battyani at fractalconcept.com Tue Apr 13 15:14:43 2004 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Tue, 13 Apr 2004 17:14:43 +0200 Subject: [cl-pdf-devel] CMUCL compatibility fixes and new colorhandlingcode References: <20040413034743.GA22913@w-m-p.com><20040413035647.GA23373@w-m-p.com><02dc01c42149$cef74fa0$0a04a8c0@marcxp><038c01c4215b$93c94c00$0a04a8c0@marcxp> Message-ID: <040401c4216a$0d66afe0$0a04a8c0@marcxp> "Stephan Frank" wrote: > The move of (uffi:def-function ("compress" c-compress)...) is still > necessary, otherwise there will be a complaint that "compress" is unknown. Is it a warning or and error ? Maybe the def-function must be at the top level ? > The 'box' name-clash seems to have been corrected, but I don't know for > 100% sure -- my cl-pdf is broken somehow so I can't compile a complete > system. At least compiling and loading boxes/tables.lisp does not give > any redefinition warnings. ok. > By the way, what is the best way to _anonymously_ check out the current > sources? I am unable to do this since the repository location changed > resently. The repository is anonymous. So you should be able to checkout it with a subversion 1.0 client. It is there now: http://www.fractalconcept.com:8000/public/open-source/cl-pdf/ And the cl-typesetting one is here: http://www.fractalconcept.com:8000/public/open-source/cl-typesetting/ Or even better get both with http://www.fractalconcept.com:8000/public/open-source/ Marc From klaus at atsec.com Tue Apr 13 16:54:57 2004 From: klaus at atsec.com (Klaus Weidner) Date: Tue, 13 Apr 2004 11:54:57 -0500 Subject: [cl-pdf-devel] CMUCL compatibility fixes and new colorhandlingcode In-Reply-To: <040401c4216a$0d66afe0$0a04a8c0@marcxp> References: <040401c4216a$0d66afe0$0a04a8c0@marcxp> Message-ID: <20040413165457.GA28280@w-m-p.com> On Tue, Apr 13, 2004 at 05:14:43PM +0200, Marc Battyani wrote: > "Stephan Frank" wrote: > > The move of (uffi:def-function ("compress" c-compress)...) is still > > necessary, otherwise there will be a complaint that "compress" is unknown. > > Is it a warning or and error ? > Maybe the def-function must be at the top level ? It's an error - compiling the init.lisp file works, but loading the resulting .x86f file immediately generates an error about the missing foreign function "compress". Apparently the foreign library must be loaded first (done when loading "init"), then the file containing the foreign function definition can be loaded in a separate step. > > By the way, what is the best way to _anonymously_ check out the current > > sources? I am unable to do this since the repository location changed > > resently. > > The repository is anonymous. So you should be able to checkout it with a > subversion 1.0 client. Are the -current.tar.gz snapshots on your web site current? That may be easier if you don't have a subversion client. -Klaus From klaus at atsec.com Tue Apr 13 18:42:22 2004 From: klaus at atsec.com (Klaus Weidner) Date: Tue, 13 Apr 2004 13:42:22 -0500 Subject: [cl-pdf-devel] CMUCL compatibility fixes and new color handling code In-Reply-To: <001f01c4212f$3bde7230$644302c3@digo> References: <20040413034743.GA22913@w-m-p.com> <001701c4211b$d0ea8300$644302c3@digo> <20040413061015.GB23373@w-m-p.com> <001f01c4212f$3bde7230$644302c3@digo> Message-ID: <20040413184222.GA28979@w-m-p.com> On Tue, Apr 13, 2004 at 12:12:20PM +0400, Dmitri Ivanov wrote: > Is there much need of anything standard here? In contrast to browsers, PDF > does not standardize on symbolic color names. > > OTOH, creating PDF files is a kind of private process. Authors are unlikely > to share their typeset-dependent code (except while developing cl-pdf > itself), but the resulting pdfs instead. They are likely to exploit the > color system they get used to within their favorite CL development > environment, e.g. LispWorks CAPI, and not to learn any additional color > database. > > IMHO a color system should be provided for those implementations that lack > it (even if the system comes from honorable X11 :-)). All that I'm asking for is that if the cl-pdf library supports the use of color names and keywords in the public API, I would want those to work the same way on all supported platforms. According to Marc's response, Lispworks already contains the X11 color table, so I agree that the extra definition is redundant in this case since the result is the same. But if a different implementation were to use an incompatible color scheme, I'd much prefer that to be dealt with via separate methods, so that applications built on cl-pdf keep working the same way. It's fine if particular implementations support extra colors such as win32:color_3dface, as long as it's clear what's portable and what isn't. What I want to avoid is having an ill-defined API for the PDF library, where a program using just public interfaces may produce different results or not work at all depending on the platform it's running on. An alternative would have been to exclude named color support from the cl-pdf package, and leaving it to a higher-level module such as cl-typesetting to offer a standard color selection mechanism, but I think it's useful to have this in cl-pdf as well. -Klaus From marc.battyani at fractalconcept.com Tue Apr 13 18:49:24 2004 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Tue, 13 Apr 2004 20:49:24 +0200 Subject: [cl-pdf-devel] CMUCL compatibility fixes and new colorhandlingcode References: <040401c4216a$0d66afe0$0a04a8c0@marcxp> <20040413165457.GA28280@w-m-p.com> Message-ID: <04c101c42188$0d509430$0a04a8c0@marcxp> "Klaus Weidner" wrote: > Apparently the foreign library must be loaded first (done when loading > "init"), then the file containing the foreign function definition can be > loaded in a separate step. Does this change if the (load-zlib) call is put in another file ? > > > By the way, what is the best way to _anonymously_ check out the current > > > sources? I am unable to do this since the repository location changed > > > resently. > > > > The repository is anonymous. So you should be able to checkout it with a > > subversion 1.0 client. > > Are the -current.tar.gz snapshots on your web site current? That may be > easier if you don't have a subversion client. Yes, it is generated each time I publish a new repository version. You just loose the comments, history, etc. Marc From klaus at atsec.com Tue Apr 13 18:46:29 2004 From: klaus at atsec.com (Klaus Weidner) Date: Tue, 13 Apr 2004 13:46:29 -0500 Subject: [cl-pdf-devel] CMUCL compatibility fixes and new color handlingcode In-Reply-To: References: <20040413034743.GA22913@w-m-p.com> <20040413035647.GA23373@w-m-p.com> <02dc01c42149$cef74fa0$0a04a8c0@marcxp> Message-ID: <20040413184629.GB28979@w-m-p.com> On Tue, Apr 13, 2004 at 03:13:02PM +0200, Stephan Frank wrote: > current CMUCL snapshots should have no problem with this. from cvs log: > > revision 1.96 > date: 2003/07/17 17:48:32; author: gerd; state: Exp; lines: +3 -2 > * src/code/macros.lisp (with-output-to-string): Add and > ignore element-type. > > So Klaus is probably using the latest official release (18e) which does > not incorporate this fix yet. Correct, I'm using the 18e-9 Debian "unstable" package. Marc, can you please put in the #-cmu anyway, since probably quite a few people are still using the official release? It shouldn't hurt those with newer versions since according to the CVS comment, the argument is ignored anyway. -Klaus From marc.battyani at fractalconcept.com Tue Apr 13 19:00:22 2004 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Tue, 13 Apr 2004 21:00:22 +0200 Subject: [cl-pdf-devel] CMUCL compatibility fixes and new colorhandlingcode References: <20040413034743.GA22913@w-m-p.com><20040413035647.GA23373@w-m-p.com><02dc01c42149$cef74fa0$0a04a8c0@marcxp> <20040413184629.GB28979@w-m-p.com> Message-ID: <04dd01c42189$939b4840$0a04a8c0@marcxp> "Klaus Weidner" wrote: > On Tue, Apr 13, 2004 at 03:13:02PM +0200, Stephan Frank wrote: > > current CMUCL snapshots should have no problem with this. from cvs log: > > > > revision 1.96 > > date: 2003/07/17 17:48:32; author: gerd; state: Exp; lines: +3 -2 > > * src/code/macros.lisp (with-output-to-string): Add and > > ignore element-type. > > > > So Klaus is probably using the latest official release (18e) which does > > not incorporate this fix yet. > > Correct, I'm using the 18e-9 Debian "unstable" package. > > Marc, can you please put in the #-cmu anyway, since probably quite a few > people are still using the official release? It shouldn't hurt those with > newer versions since according to the CVS comment, the argument is > ignored anyway. Done. It's in the repository (and in the current tgz) Marc From klaus at atsec.com Tue Apr 13 19:04:51 2004 From: klaus at atsec.com (Klaus Weidner) Date: Tue, 13 Apr 2004 14:04:51 -0500 Subject: [cl-pdf-devel] CMUCL compatibility fixes and new colorhandlingcode In-Reply-To: <20040413165457.GA28280@w-m-p.com> References: <040401c4216a$0d66afe0$0a04a8c0@marcxp> <20040413165457.GA28280@w-m-p.com> Message-ID: <20040413190451.GC28979@w-m-p.com> On Tue, Apr 13, 2004 at 11:54:57AM -0500, Klaus Weidner wrote: > On Tue, Apr 13, 2004 at 05:14:43PM +0200, Marc Battyani wrote: > > "Stephan Frank" wrote: > > > The move of (uffi:def-function ("compress" c-compress)...) is still > > > necessary, otherwise there will be a complaint that "compress" is unknown. > > > > Is it a warning or and error ? > > Maybe the def-function must be at the top level ? > > It's an error - compiling the init.lisp file works, but loading the > resulting .x86f file immediately generates an error about the missing > foreign function "compress". That reminds me - would there be a clean way to make zlib support a compile-time feature rather than a run-time selection via the global variable? The CMUCL build broke when loading, before it got a chance to look at the variable, so the only way to disable zlib support would have been to actually rip out the offending code (which is what I did on my first attempt). Since the package does work without compression, and getting zlib to work is apparently a large stumbling block for people who want to try the package, I'd even suggest keeping compression off by default (or determine at compile time if it will work), so that people who try the code don't run into unpleasant portability issues. Of course, those who use it in production are encouraged to use compression, but they are presumably willing to invest some time into getting it working. This kind of thing is IMHO one of the really unpleasant parts of the Lisp experience - all too often, my attempts to run new code resulted only in cryptic error messages. I spent hours trying to get simple CLIM programs to work, and still haven't succeeded in getting gsharp and closure running properly. That annoys me despite being a fan of the language, and I hate to think what impression that makes on people who are less enthusiastic about it... BTW, I'm not picking specifically on CMUCL here, I've had similar experiences with other implementations I've tried. To paraphrase Spiderman, "with great power comes great fragility"? -Klaus From klaus at atsec.com Tue Apr 13 19:16:58 2004 From: klaus at atsec.com (Klaus Weidner) Date: Tue, 13 Apr 2004 14:16:58 -0500 Subject: [cl-pdf-devel] CMUCL compatibility fixes and new colorhandlingcode In-Reply-To: <04c101c42188$0d509430$0a04a8c0@marcxp> References: <20040413165457.GA28280@w-m-p.com> <04c101c42188$0d509430$0a04a8c0@marcxp> Message-ID: <20040413191658.GD28979@w-m-p.com> On Tue, Apr 13, 2004 at 08:49:24PM +0200, Marc Battyani wrote: > Does this change if the (load-zlib) call is put in another file ? No, unless you move the load-foreign-library call along with it (which is roughly equivalent to what my patch did). It looks as if any Lisp file containing an uffi:def-function cannot be loaded in CMUCL unless the foreign library has already been linked in using uffi:load-foreign-library, so these two must be in separate files. Something like this: - load file containing code using uffi:load-foreign-library - call it at load time, (i.e. via the (load-zlib) at toplevel) - load file containing uffi:def-function -Klaus From marc.battyani at fractalconcept.com Tue Apr 13 19:24:01 2004 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Tue, 13 Apr 2004 21:24:01 +0200 Subject: [cl-pdf-devel] CMUCL compatibility fixes and new colorhandlingcode References: <040401c4216a$0d66afe0$0a04a8c0@marcxp><20040413165457.GA28280@w-m-p.com> <20040413190451.GC28979@w-m-p.com> Message-ID: <052701c4218c$e0eb6dc0$0a04a8c0@marcxp> "Klaus Weidner" wrote: > That reminds me - would there be a clean way to make zlib support a > compile-time feature rather than a run-time selection via the global > variable? The CMUCL build broke when loading, before it got a chance to > look at the variable, so the only way to disable zlib support would have > been to actually rip out the offending code (which is what I did on my > first attempt). Yes, it's what load-zlib is suppoed to do :( Have you tried an ignore-errors like this: (defun load-zlib (&optional force) (when force (setf *zlib-loaded* nil)) (unless *zlib-loaded* (let ((zlib-path (find-zlib-path))) (if zlib-path (ignore-errors (format t "~&;;; Loading ~s" zlib-path) (uffi:load-foreign-library zlib-path :module "zlib" :supporting-libraries '("c")) (uffi:def-function ("compress" c-compress) ((dest (* :unsigned-char)) (destlen (* :long)) (source :cstring) (source-len :long)) :returning :int :module "zlib") (setf *zlib-loaded* t *compress-streams* t)) (progn (warn "Unable to load zlib. Disabling compression.") (setf *compress-streams* nil)))))) > Since the package does work without compression, and getting zlib to work > is apparently a large stumbling block for people who want to try the > package, I'd even suggest keeping compression off by default (or > determine at compile time if it will work), so that people who try the > code don't run into unpleasant portability issues. Of course, those who > use it in production are encouraged to use compression, but they are > presumably willing to invest some time into getting it working. It's better to find a way of gracefully remove the compression if it's not available. > > > This kind of thing is IMHO one of the really unpleasant parts of the Lisp > experience - all too often, my attempts to run new code resulted only in > cryptic error messages. I spent hours trying to get simple CLIM programs > to work, and still haven't succeeded in getting gsharp and closure > running properly. That annoys me despite being a fan of the language, and > I hate to think what impression that makes on people who are less > enthusiastic about it... > > BTW, I'm not picking specifically on CMUCL here, I've had similar > experiences with other implementations I've tried. To paraphrase > Spiderman, "with great power comes great fragility"? > > Hum it's rather (with-rant (:mode t) ...) ;-) IMO, it's more a problem of open source v.s. commercial software. (documentation and support) Have you tried to ask in the CMUCL mailing lists ? Marc From edi at agharta.de Tue Apr 13 20:13:07 2004 From: edi at agharta.de (Edi Weitz) Date: Tue, 13 Apr 2004 22:13:07 +0200 Subject: [cl-pdf-devel] CMUCL compatibility fixes and new color handlingcode In-Reply-To: <031d01c42152$e227cab0$0a04a8c0@marcxp> (Marc Battyani's message of "Tue, 13 Apr 2004 14:28:51 +0200") References: <20040413034743.GA22913@w-m-p.com> <20040413035647.GA23373@w-m-p.com> <02dc01c42149$cef74fa0$0a04a8c0@marcxp> <031d01c42152$e227cab0$0a04a8c0@marcxp> Message-ID: On Tue, 13 Apr 2004 14:28:51 +0200, "Marc Battyani" wrote: > BTW as you are the latest one who changed the zlib FFI ;-), have you > some ideas on the CMUCL FFI problem? IIRC the problem is that CMUCL can't compile an ALIEN:DEF-ALIEN-ROUTINE (which is what UFFI:DEF-FUNCTION translates to) unless the corresponding library is already loaded, so the LOAD-ZLIB approach won't work. I think you need to split it into two files, something like this: --------------------------- init.lisp --------------------------- (in-package pdf) (defvar *zlib-loaded* nil) (eval-when (:compile-toplevel :load-toplevel :execute) (defun find-zlib-path () (uffi:find-foreign-library "libz" *zlib-search-paths* :drive-letters '("C" "D" "E") :types '("so" "a" "dll" "dylib")))) #+:cmu (eval-when (:compile-toplevel :load-toplevel :execute) (let ((zlib-path (find-zlib-path))) (when zlib-path (format t "~&;;; Loading ~s" zlib-path) (uffi:load-foreign-library zlib-path :module "zlib" :supporting-libraries '("c")) (pushnew :zlib-found *features*)))) --------------------------- init.lisp --------------------------- --------------------------- init2.lisp --------------------------- (in-package pdf) (defun load-zlib (&optional force) (when force (setf *zlib-loaded* nil)) (unless *zlib-loaded* (let ((zlib-path (find-zlib-path))) (if zlib-path (progn (format t "~&;;; Loading ~s" zlib-path) (uffi:load-foreign-library zlib-path :module "zlib" :supporting-libraries '("c")) #+(or (not :cmu) :zlib-found) (uffi:def-function ("compress" c-compress) ((dest (* :unsigned-char)) (destlen (* :long)) (source :cstring) (source-len :long)) :returning :int :module "zlib") (setf *zlib-loaded* t *compress-streams* t)) (progn (warn "Unable to load zlib. Disabling compression.") (setf *compress-streams* nil)))))) (load-zlib) --------------------------- init2.lisp --------------------------- Disclaimer: I'm not a CMUCL expert. You should ask on their mailing list. BTW, UFFI already keeps track of loaded foreign libraries and won't load the same library twice unless you force it to do so. So *ZLIB-LOADED* is actually not needed. Or, from a different angle, the FORCE argument to LOAD-ZLIB is bogus unless you call UFFI like (UFFI:LOAD-FOREIGN-LIBRARY ... :FORCE-LOAD FORCE) HTH, Edi. From edi at agharta.de Tue Apr 13 20:23:18 2004 From: edi at agharta.de (Edi Weitz) Date: Tue, 13 Apr 2004 22:23:18 +0200 Subject: [cl-pdf-devel] CMUCL compatibility fixes and new colorhandlingcode In-Reply-To: <052701c4218c$e0eb6dc0$0a04a8c0@marcxp> (Marc Battyani's message of "Tue, 13 Apr 2004 21:24:01 +0200") References: <040401c4216a$0d66afe0$0a04a8c0@marcxp> <20040413165457.GA28280@w-m-p.com> <20040413190451.GC28979@w-m-p.com> <052701c4218c$e0eb6dc0$0a04a8c0@marcxp> Message-ID: On Tue, 13 Apr 2004 21:24:01 +0200, "Marc Battyani" wrote: > IMO, it's more a problem of open source v.s. commercial software. > (documentation and support) Marc, you must be kidding. Or you've talked too much to Kent Pitman lately... :) I'm a paying customer of Xanalys as well as Corman but I can't really say that their support and documentation are siginificantly better than those of, say, CMUCL or CLISP. The LispWorks documentation is incomplete and poorly organized. Also, there's a good chance that if you find a bug or an omission they won't fix it unless you pay for it. Corman... well, don't get me started. The only commercial Lisp company with superior support and docs seems to be Franz - you get what you pay for... Note that I'm not dissing LispWorks or Corman Lisp here. These are both fine products and I don't regret that I bought them. I just wanted to put things into perspective. Cheers, Edi. From marc.battyani at fractalconcept.com Tue Apr 13 21:37:35 2004 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Tue, 13 Apr 2004 23:37:35 +0200 Subject: [cl-pdf-devel] CMUCL compatibility fixes and new colorhandlingcode References: <040401c4216a$0d66afe0$0a04a8c0@marcxp><20040413165457.GA28280@w-m-p.com> <20040413190451.GC28979@w-m-p.com><052701c4218c$e0eb6dc0$0a04a8c0@marcxp> Message-ID: <058b01c4219f$89dd60c0$0a04a8c0@marcxp> "Edi Weitz" wrote: > On Tue, 13 Apr 2004 21:24:01 +0200, "Marc Battyani" wrote: > > > IMO, it's more a problem of open source v.s. commercial software. > > (documentation and support) > > Marc, you must be kidding. Or you've talked too much to Kent Pitman > lately... :) Hehehe... ;-) Of course I'm for open source, otherwise I wouldn't have released cl-pdf etc.. [...] > The only commercial Lisp company with superior support and docs seems > to be Franz - you get what you pay for... Documentation is something that I can only write under heavy pressure. In fact most of my clients who know me well enough keep the last 20% payment for the docs ;-) Marc From alemmens at xs4all.nl Fri Apr 23 08:59:08 2004 From: alemmens at xs4all.nl (Arthur Lemmens) Date: Fri, 23 Apr 2004 10:59:08 +0200 Subject: [cl-pdf-devel] Embedding several PDF files in one document Message-ID: Hi, I have no experience with CL-PDF yet, and I've only just started reading the PDF standard. I've written a simple web site that lets users registrate for a conference. Users can submit abstracts and papers in PDF-format. My client wants to automatically generate an abstract book that contains all the submitted abstracts and starts with some kind of contents overview with the names of the authors, titles of the abstracts, etc. This means I would have to somehow embed all the submitted PDF-documents and generate a new document. I've been browsing through the standard, but I don't think it explicitly mentions embedding other PDF files. I suppose it should be possible, using constructs like File Attachment annotations (6.6.14), Destinations (7.3) and File Specifications (7.4.2), but I don't see the big picture yet. I would appreciate some hints to get me started. Do you think it is possible at all? Is it possible with the current version of CL-PDF, or should I write some extensions? (I'll contribute any CL-PDF extensions that I may need to write, of course.) Should I be looking at File Attachments and File Specifications, or is there something else I'm missing? Thanks a lot, Arthur Lemmens From marc.battyani at fractalconcept.com Fri Apr 23 10:42:46 2004 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Fri, 23 Apr 2004 12:42:46 +0200 Subject: [cl-pdf-devel] Embedding several PDF files in one document References: Message-ID: <02df01c4291f$b804e4f0$0a02a8c0@marcxp> "Arthur Lemmens" > I have no experience with CL-PDF yet, and I've only just > started reading the PDF standard. > > I've written a simple web site that lets users registrate > for a conference. Users can submit abstracts and papers > in PDF-format. My client wants to automatically generate > an abstract book that contains all the submitted abstracts > and starts with some kind of contents overview with the names > of the authors, titles of the abstracts, etc. If you want formatted output you should use cl-typesetting, cl-pdf is only the rendering layer. > This means I would have to somehow embed all the submitted > PDF-documents and generate a new document. I've been browsing > through the standard, but I don't think it explicitly mentions > embedding other PDF files. I suppose it should be possible, using > constructs like File Attachment annotations (6.6.14), Destinations > (7.3) and File Specifications (7.4.2), but I don't see the big > picture yet. If you want to include a pdf page, what you need is a Form XObject. But if you want to merge several pages then you probably need to parse the pdf to extract the pages. > I would appreciate some hints to get me started. Do you think > it is possible at all? Is it possible with the current version > of CL-PDF, or should I write some extensions? (I'll contribute > any CL-PDF extensions that I may need to write, of course.) Should > I be looking at File Attachments and File Specifications, or is > there something else I'm missing? I don't think that file attachements are usable for this. There are several tools that merge pdf files. May be it's a good idea to look at them to see what they do. For instance here is one in C++: http://thierry.schmit.free.fr/dev/mbtPdfAsm/enMbtPdfAsm2.html You can generate a very simple pdf files (just a hello world) with cl-pdf and then merge them with such a tool to see what is in the resulting pdf. You will need to parse the pdf files. I have a crude pdf file parser but as I didn't used it for some time it probably need some work to be operational again. I didn't published it because it's not portable as it uses the parser generator of Lispworks. The lexer should also be replaced by a cl-ppcre one. Marc From alemmens at xs4all.nl Fri Apr 23 12:57:39 2004 From: alemmens at xs4all.nl (Arthur Lemmens) Date: Fri, 23 Apr 2004 14:57:39 +0200 Subject: [cl-pdf-devel] Embedding several PDF files in one document In-Reply-To: <02df01c4291f$b804e4f0$0a02a8c0@marcxp> References: <02df01c4291f$b804e4f0$0a02a8c0@marcxp> Message-ID: Marc Battyani wrote: > If you want to include a pdf page, what you need is a Form XObject. But if > you want to merge several pages then you probably need to parse the pdf to > extract the pages. Ah, I was hoping I wouldn't have to do that. > You will need to parse the pdf files. I have a crude pdf file parser but as > I didn't used it for some time it probably need some work to be operational > again. I didn't published it because it's not portable as it uses the parser > generator of Lispworks. I would be interested in that. I'm developing on Lispworks anyway, and portability is not my primary concern right now. (I've never used Lispworks' parser generator, by the way. Were you happy with it? If so, then one way to make your PDF-parser portable would be to write a portable version of Lispworks' generator.) Thanks a lot for your answer, Arthur Lemmens From marc.battyani at fractalconcept.com Fri Apr 23 13:53:16 2004 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Fri, 23 Apr 2004 15:53:16 +0200 Subject: [cl-pdf-devel] Embedding several PDF files in one document References: <02df01c4291f$b804e4f0$0a02a8c0@marcxp> Message-ID: <039b01c4293a$557d6620$0a02a8c0@marcxp> "Arthur Lemmens" wrote: > Marc Battyani wrote: > > > If you want to include a pdf page, what you need is a Form XObject. But if > > you want to merge several pages then you probably need to parse the pdf to > > extract the pages. > > Ah, I was hoping I wouldn't have to do that. > > > You will need to parse the pdf files. I have a crude pdf file parser but as > > I didn't used it for some time it probably need some work to be operational > > again. I didn't published it because it's not portable as it uses the parser > > generator of Lispworks. > > I would be interested in that. I'm developing on Lispworks anyway, > and portability is not my primary concern right now. OK I will send it to you. > (I've never used > Lispworks' parser generator, by the way. Were you happy with it? If so, > then one way to make your PDF-parser portable would be to write a portable > version of Lispworks' generator.) Yes, it works well. But in the PDF case the grammar is very simple and a parser generator is overkill :) Marc From kw at w-m-p.com Fri Apr 23 15:51:33 2004 From: kw at w-m-p.com (Klaus Weidner) Date: Fri, 23 Apr 2004 10:51:33 -0500 Subject: [cl-pdf-devel] Embedding several PDF files in one document In-Reply-To: <02df01c4291f$b804e4f0$0a02a8c0@marcxp> References: <02df01c4291f$b804e4f0$0a02a8c0@marcxp> Message-ID: <20040423155132.GC10081@w-m-p.com> On Fri, Apr 23, 2004 at 12:42:46PM +0200, Marc Battyani wrote: > "Arthur Lemmens" > > My client wants to automatically generate > > an abstract book that contains all the submitted abstracts > > and starts with some kind of contents overview with the names > > of the authors, titles of the abstracts, etc. > > If you want formatted output you should use cl-typesetting, cl-pdf is only > the rendering layer. Another important question is if you need to modify the page content of the articles you're merging, for example if you want continuous page numbers throughout the document. This gets tricky if you have no direct control over the individual layout. It would be easier if you could tell the authors to use no page headers and footers at all. Adding things to an existing PDF file in fixed locations is doable. Do you need to automatically extract the abstract and metadata, or would it be okay to manually extract that to generate the introductory material? > There are several tools that merge pdf files. May be it's a good idea to > look at them to see what they do. For instance here is one in C++: > http://thierry.schmit.free.fr/dev/mbtPdfAsm/enMbtPdfAsm2.html There's also the pdftk, the PDF tool kit, which can merge and split documents. It's GPL licensed. > You will need to parse the pdf files. I have a crude pdf file parser but as > I didn't used it for some time it probably need some work to be operational > again. I didn't published it because it's not portable as it uses the parser > generator of Lispworks. The lexer should also be replaced by a cl-ppcre one. I also have a PDF file parser in CL, which I use to extract text from documents. The language parsing is complete, but I haven't implemented more operators than the few I needed. It doesn't use any cl-pdf code, but a wrapper layer could probably take care of feeding the parsed code back to it for output. It's not currently open sourced, but I could ask my boss about that. It's not exactly our core business area ;-) -Klaus From marc.battyani at fractalconcept.com Fri Apr 23 16:03:22 2004 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Fri, 23 Apr 2004 18:03:22 +0200 Subject: [cl-pdf-devel] Embedding several PDF files in one document References: <02df01c4291f$b804e4f0$0a02a8c0@marcxp> <039b01c4293a$557d6620$0a02a8c0@marcxp> Message-ID: <03e901c4294c$835d9c60$0a02a8c0@marcxp> "Arthur Lemmens" wrote: > Marc Battyani wrote: > > > But in the PDF case the grammar is very simple and a parser > > generator is overkill :) > > Yes, I'm beginning to see that now. The lexical structure seems > quite simple, too. > > But I'm getting the impression that you can't just parse a PDF file > from start to end; in general, you have to read the cross-reference > table (at the end of the file) first and use random-access to parse > arbitrary objects in the file. Yes my parser does all that. I read/parse a pdf file and then I can write to it, add pages etc. > I think this is necessary because of the way they specified streams. > A 'stream' starts with a dictionary which specifies the length of > the stream. After the dictionary comes the "stream" keyword, followed > by the contents of the stream, followed by the "endstream" keyword. Streams are not a problem because you have their size so it's just a read-sequence. > Now, I think you can't just parse the stream by reading lines > until you see the "endstream" keyword. After all, a line starting > with "endstream" could be just a part of the stream contents. So > you have to use the length that's specified in the dictionary > that's in front of the stream. But the length can be specified > by an indirect object reference; to resolve that reference you > may need an object that's located after the stream contents. > > Do you agree with this, or am I making things more complicated > than necessary? Yes, you need all that but it's not too difficult. (my parser has less than 300 lines IIRC) Marc From kw at w-m-p.com Fri Apr 23 16:54:41 2004 From: kw at w-m-p.com (Klaus Weidner) Date: Fri, 23 Apr 2004 11:54:41 -0500 Subject: [cl-pdf-devel] Embedding several PDF files in one document In-Reply-To: <03e901c4294c$835d9c60$0a02a8c0@marcxp> References: <039b01c4293a$557d6620$0a02a8c0@marcxp> <03e901c4294c$835d9c60$0a02a8c0@marcxp> Message-ID: <20040423165441.GF10081@w-m-p.com> On Fri, Apr 23, 2004 at 06:03:22PM +0200, Marc Battyani wrote: > "Arthur Lemmens" wrote: > > Now, I think you can't just parse the stream by reading lines > > until you see the "endstream" keyword. After all, a line starting > > with "endstream" could be just a part of the stream contents. So > > you have to use the length that's specified in the dictionary > > that's in front of the stream. But the length can be specified > > by an indirect object reference; to resolve that reference you > > may need an object that's located after the stream contents. > > Yes, you need all that but it's not too difficult. (my parser has less than > 300 lines IIRC) I can confirm that this part is easy - my code uses delayed evaluation to make access to indirect objects completely transparent to the functions using them. -Klaus From alemmens at xs4all.nl Fri Apr 23 17:05:16 2004 From: alemmens at xs4all.nl (Arthur Lemmens) Date: Fri, 23 Apr 2004 19:05:16 +0200 Subject: [cl-pdf-devel] Embedding several PDF files in one document In-Reply-To: <20040423155132.GC10081@w-m-p.com> References: <02df01c4291f$b804e4f0$0a02a8c0@marcxp> <20040423155132.GC10081@w-m-p.com> Message-ID: Klaus Weidner wrote: > Another important question is if you need to modify the page > content of the articles you're merging, for example if you want > continuous page numbers throughout the document. Yes, that's a good point. > Do you need to automatically extract the abstract and metadata, or would > it be okay to manually extract that to generate the introductory > material? No, abstract and metadata don't come from the PDF-documents, but come from the database behind the web site. > There's also the pdftk, the PDF tool kit, which can merge and split > documents. It's GPL licensed. Thanks for the link. > I also have a PDF file parser in CL, which I use to extract text from > documents. The language parsing is complete, but I haven't implemented > more operators than the few I needed. I'm thinking of doing something similar now. I don't have much time for this, so I'll keep it as simple as possible. > It doesn't use any cl-pdf code, but a wrapper layer could probably take > care of feeding the parsed code back to it for output. > > It's not currently open sourced, but I could ask my boss about that. Thanks for the offer. I would be interested, of course. But maybe Marc's parser would be closer to what I need (assuming the result of Marc's parser would be more or less compatible with cl-pdf). Thanks a lot, Klaus and Marc. Your answers have been very helpful. Arthur Lemmens From alemmens at xs4all.nl Fri Apr 23 17:07:46 2004 From: alemmens at xs4all.nl (Arthur Lemmens) Date: Fri, 23 Apr 2004 19:07:46 +0200 Subject: [cl-pdf-devel] Embedding several PDF files in one document In-Reply-To: <20040423165441.GF10081@w-m-p.com> References: <039b01c4293a$557d6620$0a02a8c0@marcxp> <03e901c4294c$835d9c60$0a02a8c0@marcxp> <20040423165441.GF10081@w-m-p.com> Message-ID: Klaus Weidner wrote: > I can confirm that this part is easy - my code uses delayed evaluation to > make access to indirect objects completely transparent to the functions > using them. Sounds good. It's always nice to see concepts like delayed evaluation put to a good use. Arthur From marc.battyani at fractalconcept.com Fri Apr 23 17:26:48 2004 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Fri, 23 Apr 2004 19:26:48 +0200 Subject: [cl-pdf-devel] Embedding several PDF files in one document References: <02df01c4291f$b804e4f0$0a02a8c0@marcxp> <20040423155132.GC10081@w-m-p.com> Message-ID: <042f01c42958$2a5c7620$0a02a8c0@marcxp> "Klaus Weidner" wrote: > On Fri, Apr 23, 2004 at 12:42:46PM +0200, Marc Battyani wrote: > > You will need to parse the pdf files. I have a crude pdf file parser but as > > I didn't used it for some time it probably need some work to be operational > > again. I didn't published it because it's not portable as it uses the parser > > generator of Lispworks. The lexer should also be replaced by a cl-ppcre one. > > I also have a PDF file parser in CL, which I use to extract text from > documents. The language parsing is complete, but I haven't implemented > more operators than the few I needed. > > It doesn't use any cl-pdf code, but a wrapper layer could probably take > care of feeding the parsed code back to it for output. May be we should merge the two parsers. (that is take 90% of yours ;-) I don't parse the stream content because I just needed to write over (or under) existing pages, not modify them. So I have a macro like: (with-existing-page (page-number before)...) > It's not currently open sourced, but I could ask my boss about that. It's > not exactly our core business area ;-) :) Marc From kw at w-m-p.com Fri Apr 23 18:12:24 2004 From: kw at w-m-p.com (Klaus Weidner) Date: Fri, 23 Apr 2004 13:12:24 -0500 Subject: [cl-pdf-devel] Embedding several PDF files in one document In-Reply-To: <042f01c42958$2a5c7620$0a02a8c0@marcxp> References: <20040423155132.GC10081@w-m-p.com> <042f01c42958$2a5c7620$0a02a8c0@marcxp> Message-ID: <20040423181224.GA12835@w-m-p.com> On Fri, Apr 23, 2004 at 07:26:48PM +0200, Marc Battyani wrote: > May be we should merge the two parsers. (that is take 90% of yours ;-) > > I don't parse the stream content because I just needed to write over (or > under) existing pages, not modify them. So I have a macro like: > (with-existing-page (page-number before)...) Looks like a good fit, since that's something I've wanted but which my code does not support. > > It's not currently open sourced, but I could ask my boss about that. It's > > not exactly our core business area ;-) Okay, I'll check to see what I can do about that. -Klaus From marc.battyani at fractalconcept.com Sat Apr 24 20:55:46 2004 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Sat, 24 Apr 2004 22:55:46 +0200 Subject: [cl-pdf-devel] Portability was: Final zlib fix, and CLISP support References: <20040424203005.GA5617@w-m-p.com> Message-ID: <082901c42a3e$856193c0$0a02a8c0@marcxp> "Klaus Weidner" wrote: > I have verified that this works with CMUCL and SBCL. > > But in addition, this change makes cl-pdf work on CLISP, and probably any > other common lisp as well. > > cl-typesetting mostly works on CLISP, including my XHTML renderer. There > are still a few portability issues in the table code to resolve that I > haven't tracked down yet, nil values end up in max calls somehow. It's > also complaining about floating point contagion, which may be a useful > pointer towards potential optimizations for other platforms. BTW I'm interested to know on which implementations cl-pdf and/or cl-typesetting works. It works on Lispworks, SBCL, CMUCL, ACL, almost CLISP now. Others ? [sent to the cl-pdf mailing list also] Marc From marc.battyani at fractalconcept.com Sat Apr 24 22:24:50 2004 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Sun, 25 Apr 2004 00:24:50 +0200 Subject: [cl-pdf-devel] Re: Final zlib fix, and CLISP support References: <20040424203005.GA5617@w-m-p.com> Message-ID: <089a01c42a4a$f62a99b0$0a02a8c0@marcxp> "Klaus Weidner" [replying to cl-pdf rather than cl-typesetting mailing list] > yet another attempt at fixing the annoying zlib issue... Let's fix it definitively! (or at least until next time ;-) > My new approach is the following: > > - in cl-pdf.asd, attempt to load the uffi library in an ignore-errors > clause. If successful, add :uffi to *features*. ok > - conditionalize the zlib dependent code using #+uffi ok > - if uffi is not present or zlib is not loaded successfully, > automatically set *compress-streams* to NIL. ok but I've rather set *compress-streams* to nil in the defvar in config.lisp. it will be set to t only if zlib loads successfully > I have verified that this works with CMUCL and SBCL. > > But in addition, this change makes cl-pdf work on CLISP, and probably any > other common lisp as well. Have you tried Edi's modification with CMUCL ? He kept the dynamic nature of #'load-zlib so this will also work in delivered images/exe. This is lost with your patch because you put the (uffi:def-function ("compress" c-compress) at the top level. So I merged your patch (uffi) with Edi's one (zlib) It still works on Lispworks at least. :) Can you try it with CMUCL etc.? It's in the repository and the tarball. Marc From kw at w-m-p.com Sun Apr 25 00:38:58 2004 From: kw at w-m-p.com (Klaus Weidner) Date: Sat, 24 Apr 2004 19:38:58 -0500 Subject: [cl-pdf-devel] Re: Final zlib fix, and CLISP support In-Reply-To: <089a01c42a4a$f62a99b0$0a02a8c0@marcxp> References: <20040424203005.GA5617@w-m-p.com> <089a01c42a4a$f62a99b0$0a02a8c0@marcxp> Message-ID: <20040425003858.GB6970@w-m-p.com> On Sun, Apr 25, 2004 at 12:24:50AM +0200, Marc Battyani wrote: > "Klaus Weidner" > > - if uffi is not present or zlib is not loaded successfully, > > automatically set *compress-streams* to NIL. > > ok but I've rather set *compress-streams* to nil in the defvar in > config.lisp. it will be set to t only if zlib loads successfully Good point, that's cleaner. > Have you tried Edi's modification with CMUCL ? He kept the dynamic nature of > #'load-zlib so this will also work in delivered images/exe. This is lost > with your patch because you put the (uffi:def-function ("compress" > c-compress) at the top level. Almost - sbcl also needs the workaround, see attached patch. With the additional change, cl-pdf works on CMUCL, SBCL and CLISP, with compression being active for the first two and off for CLISP. The attached cl-typesetting patch makes the complex single-page-example work on clisp, including the table. It needs some settings to ensure the expected floating point behavior and charset, which I've put in specials.lisp for now. One error reported by CLISP was a floating point underflow in the wavelet rule, which may actually be conforming behavior. The exp value is 1.9d-41, which cannot be expressed in a single-float. The other implementations apparently return zero here. What still isn't working on CLISP are the splittable tables. I've fiddled around with the code a bit, but the complex loop macros are terrible to debug. -Klaus -------------- next part -------------- diff -urN -x *.fas -x *.lib orig/cl-pdf/init.lisp cl-pdf/init.lisp --- orig/cl-pdf/init.lisp Sat Apr 24 17:18:54 2004 +++ cl-pdf/init.lisp Sat Apr 24 18:47:51 2004 @@ -15,7 +15,7 @@ :drive-letters '("C" "D" "E") :types '("so" "a" "dll" "dylib")))) -#+(and cmu uffi) +#+(and uffi (or cmu sbcl)) (eval-when (:compile-toplevel :load-toplevel :execute) (let ((zlib-path (find-zlib-path))) (when zlib-path -------------- next part -------------- diff -urN -x *.fas -x *.lib orig/cl-typesetting/cl-typesetting.asd cl-typesetting/cl-typesetting.asd --- orig/cl-typesetting/cl-typesetting.asd Thu Apr 22 05:23:18 2004 +++ cl-typesetting/cl-typesetting.asd Sat Apr 24 18:32:45 2004 @@ -6,7 +6,6 @@ (in-package asdf) -#+(or allegro lispworks cmu sbcl openmcl mcl scl) (defsystem :cl-typesetting :name "cl-typesetting" :author "Marc Battyani " diff -urN -x *.fas -x *.lib orig/cl-typesetting/specials.lisp cl-typesetting/specials.lisp --- orig/cl-typesetting/specials.lisp Thu Apr 22 05:23:18 2004 +++ cl-typesetting/specials.lisp Sat Apr 24 18:44:12 2004 @@ -4,6 +4,11 @@ (in-package typeset) +#+clisp +(setq custom:*floating-point-contagion-ansi* t + custom:*warn-on-floating-point-contagion* nil + custom:*default-file-encoding* (ext:encoding-charset "iso-8859-1")) + (defconstant +huge-number+ (truncate most-positive-fixnum 10)) (defconstant +epsilon+ 0.0001) diff -urN -x *.fas -x *.lib orig/cl-typesetting/test.lisp cl-typesetting/test.lisp --- orig/cl-typesetting/test.lisp Tue Apr 20 17:16:58 2004 +++ cl-typesetting/test.lisp Sat Apr 24 18:34:20 2004 @@ -128,7 +128,7 @@ (pdf:set-color-stroke (color box)) (pdf:move-to (- dx/2) 0) (loop for x from (- dx/2) by 0.2 - for y = (* dy/2 (cos (* x 0.8)) (exp (* x x -0.006))) + for y = (* dy/2 (cos (* x 0.8)) (exp (* x x -0.006d0))) while (< x dx/2) do (pdf:line-to x y)) (pdf:stroke)))) From marc.battyani at fractalconcept.com Sun Apr 25 14:27:19 2004 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Sun, 25 Apr 2004 16:27:19 +0200 Subject: [cl-pdf-devel] Re: Final zlib fix, and CLISP support References: <20040424203005.GA5617@w-m-p.com><089a01c42a4a$f62a99b0$0a02a8c0@marcxp> <20040425003858.GB6970@w-m-p.com> Message-ID: <0a4501c42ad1$6b0ca9e0$0a02a8c0@marcxp> "Klaus Weidner" wrote: > > Have you tried Edi's modification with CMUCL ? He kept the dynamic nature of > > #'load-zlib so this will also work in delivered images/exe. This is lost > > with your patch because you put the (uffi:def-function ("compress" > > c-compress) at the top level. > > Almost - sbcl also needs the workaround, see attached patch. > > With the additional change, cl-pdf works on CMUCL, SBCL and CLISP, > with compression being active for the first two and off for CLISP. OK done. Let's hope it's the final "final version" ;-) Marc From alemmens at xs4all.nl Mon Apr 26 11:13:45 2004 From: alemmens at xs4all.nl (Arthur Lemmens) Date: Mon, 26 Apr 2004 13:13:45 +0200 Subject: [cl-pdf-devel] Representation of basic PDF objects Message-ID: Hi, I've started work on the PDF parser. My first idea was to use the following mapping from the basic PDF objects to Lisp objects: - true -> :true - false -> :false - number -> number - string -> string - name -> symbol in the PDF package - array -> vector - dictionary -> property list - stream -> pdf-stream - null -> nil Mapping names to symbols, dictionaries to property lists and null to nil would make for a more elegant mapping than what CL-PDF seems to be using now, I think. CL-PDF seems to use Lisp strings for names, and :null for NIL. Using :null instead of NIL means that you would have to insert some special checks when reading/changing dictionary values. (Because a :null value in a dictionary should be equivalent to having to omitting the key from the dictionary. This is exactly equivalent to having a NIL value in a Lisp property list.) These checks seem to be missing from CL-PDF at the moment. Also, using two separate Lisp types (strings and symbols) for two separate PDF types (strings and names) seems more elegant to me than using Lisp strings for both strings and names. Do you agree with this or am I missing something? Thanks, Arthur Lemmens From marc.battyani at fractalconcept.com Mon Apr 26 14:31:34 2004 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Mon, 26 Apr 2004 16:31:34 +0200 Subject: [cl-pdf-devel] Representation of basic PDF objects References: Message-ID: <0eb301c42b9b$2dca62a0$0a02a8c0@marcxp> "Arthur Lemmens" wrote: > I've started work on the PDF parser. Good. > My first idea was to use the following mapping from the basic PDF > objects to Lisp objects: > - true -> :true > - false -> :false > - number -> number > - string -> string > - name -> symbol in the PDF package > - array -> vector > - dictionary -> property list > - stream -> pdf-stream > - null -> nil > > Mapping names to symbols, dictionaries to property lists > and null to nil would make for a more elegant mapping than > what CL-PDF seems to be using now, I think. CL-PDF seems to > use Lisp strings for names, and :null for NIL. Hum... I prefer the current mapping. Names are case sensitive so symbols are not a good representation (except for Franz modern mode fan ;-) Also you have to generate names for fonts and other temporary pdf objects. You would end up with lots of symbols! (and symbols are heavy weight objects compared to string) Alists are as nice as property lists IMO but they work with strings. The true/false is not a real problem, IIRC there is only one place where a true is used and none with false. > Using :null instead of NIL means that you would have to > insert some special checks when reading/changing dictionary > values. (Because a :null value in a dictionary should be > equivalent to having to omitting the key from the dictionary. > This is exactly equivalent to having a NIL value in a Lisp > property list.) These checks seem to be missing from CL-PDF > at the moment. It has probably never be needed so far. (There is no "null" in the cl-pdf sources.) > Also, using two separate Lisp types (strings and symbols) for > two separate PDF types (strings and names) seems more elegant > to me than using Lisp strings for both strings and names. > > Do you agree with this or am I missing something? No! (I mean I don't agree ;-) I think the best way is to use the current cl-pdf representation if you want to be able to use it to write into the parsed pdf. Marc From alemmens at xs4all.nl Mon Apr 26 18:23:32 2004 From: alemmens at xs4all.nl (Arthur Lemmens) Date: Mon, 26 Apr 2004 20:23:32 +0200 Subject: [cl-pdf-devel] Representation of basic PDF objects In-Reply-To: <0eb301c42b9b$2dca62a0$0a02a8c0@marcxp> References: <0eb301c42b9b$2dca62a0$0a02a8c0@marcxp> Message-ID: Marc Battyani wrote: > "Arthur Lemmens" wrote: > >> I've started work on the PDF parser. > > Good. The grammar is simple enough that I've decided to skip Lispworks' parser generator and just write some extra parse functions 'by hand'. So the result should be portable. >> Mapping names to symbols, dictionaries to property lists >> and null to nil would make for a more elegant mapping than >> what CL-PDF seems to be using now, I think. CL-PDF seems to >> use Lisp strings for names, and :null for NIL. > > Hum... I prefer the current mapping. > Names are case sensitive so symbols are not a good representation Well, symbols are case sensitive too. But it is a good point that I hadn't thought of yet. > Also you have to generate names for fonts and other temporary pdf objects. > You would end up with lots of symbols! (and symbols are heavy weight objects > compared to string) > Alists are as nice as property lists IMO but they work with strings. > The true/false is not a real problem, IIRC there is only one place where a > true is used and none with false. You look at this from the point of view of generating PDF, but at the moment I'm looking at it with the idea of parsing and editing existing PDF documents. That gives a slightly different perspective on stuff like this. As a matter of fact, at the moment I'm even considering the idea of (semi-automatically) defining a CLOS class for each kind of PDF object with separate slots for corresponding to each dictionary key. That way, you could edit any element of the document by using the right (setf slot-value). But this may be overkill, and it may take more time than I can spend right now. >> Using :null instead of NIL means that you would have to >> insert some special checks when reading/changing dictionary >> values. (Because a :null value in a dictionary should be >> equivalent to having to omitting the key from the dictionary. >> This is exactly equivalent to having a NIL value in a Lisp >> property list.) These checks seem to be missing from CL-PDF >> at the moment. > > It has probably never be needed so far. (There is no "null" in the > cl-pdf sources.) No, but there may be in existing documents ;-) > No! (I mean I don't agree ;-) OK, I get the message ;-) Thanks for your feedback. Regards, Arthur From marc.battyani at fractalconcept.com Mon Apr 26 19:21:15 2004 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Mon, 26 Apr 2004 21:21:15 +0200 Subject: [cl-pdf-devel] Representation of basic PDF objects References: <0eb301c42b9b$2dca62a0$0a02a8c0@marcxp> Message-ID: <109901c42bc3$a5a86470$0a02a8c0@marcxp> "Arthur Lemmens" wrote: > Marc Battyani wrote: > The grammar is simple enough that I've decided to skip Lispworks' > parser generator and just write some extra parse functions 'by hand'. > So the result should be portable. Good point. ... > You look at this from the point of view of generating PDF, but at the > moment I'm looking at it with the idea of parsing and editing existing > PDF documents. That gives a slightly different perspective on stuff > like this. As a matter of fact, at the moment I'm even considering the > idea of (semi-automatically) defining a CLOS class for each kind of PDF > object with separate slots for corresponding to each dictionary key. > That way, you could edit any element of the document by using the right > (setf slot-value). But this may be overkill, and it may take more time > than I can spend right now. Well IMO what you want to do is open, parse, draw on existing pages, add new pages then write and close it. At least it was what I needed. So you don't need to parse all. In the parser I've sent to you, I keep the pdf streams as byte sequences without looking at what is inside. It's much faster that way ;-) > > It has probably never be needed so far. (There is no "null" in the > > cl-pdf sources.) > > No, but there may be in existing documents ;-) Yes but IMO you should just read and write them in the same way (strings) rather than read, convert to symbol then convert to string, write. Well again this is if you just want to draw on an existing pdf. If you want to analyse a pdf then it's another story. > > No! (I mean I don't agree ;-) > > OK, I get the message ;-) > Thanks for your feedback. Sorry, but I replied to you just after reading the CLISP developpers replies about an ambiguous feature of LOOP (cf. the cl-typesetting mailing list for details) so I was rather upset :( Marc From marc.battyani at fractalconcept.com Mon Apr 26 21:08:23 2004 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Mon, 26 Apr 2004 23:08:23 +0200 Subject: [cl-pdf-devel] Representation of basic PDF objects References: <0eb301c42b9b$2dca62a0$0a02a8c0@marcxp> <109901c42bc3$a5a86470$0a02a8c0@marcxp> Message-ID: <113601c42bd2$9cc577d0$0a02a8c0@marcxp> "Arthur Lemmens" wrote: > Marc Battyani wrote: > > > Yes but IMO you should just read and write them in the same way (strings) > > rather than read, convert to symbol then convert to string, write. Well > > again this is if you just want to draw on an existing pdf. If you want to > > analyse a pdf then it's another story. > > I understand what you mean. I have this tendency to generalize a bit > more than is strictly necessary for my current problem, and not to > worry too much about some extra overhead. I think the Extreme Programming > philosophy of "Only do what you need today" is a bit too extreme ;-) Yes, extremes are always too extremes. ;-) In both directions... > > Sorry, but I replied to you just after reading the CLISP developpers replies > > about an ambiguous feature of LOOP (cf. the cl-typesetting mailing list for > > details) so I was rather upset :( > > Yeah, I saw your messages on cl-typesetting. Sometimes I get the impression > that the CLISP maintainers would rather program in Scheme ;-) I don't know how old is CLISP but I remember that in the late 80's there was a violent anti-CL trend in the European academic people. So your analysis is probably the good one they would indeed rather prefer to program in Scheme... > But I agree > with Klaus that ITERATE is a very nice package. I've been using it from > time to time for my own programs and would like to see it used more often > for Open Source stuff. Yes, I also like ITERATE this is why I proposed it to Klaus. If everybody is OK I will integrate it to cl-pdf/cl-typesetting. By using it we will avoid the problem of the fuzzy loop semantics on the anti-loop implementation. > P.S. Are you, or anyone else on this list, planning to go to the > Lisp workshop in Oslo? I don't know yet. I would like for sure! Marc From divanov at aha.ru Tue Apr 27 06:06:43 2004 From: divanov at aha.ru (Dmitri Ivanov) Date: Tue, 27 Apr 2004 10:06:43 +0400 Subject: [cl-pdf-devel] Representation of basic PDF objects References: <0eb301c42b9b$2dca62a0$0a02a8c0@marcxp> Message-ID: <007701c42c20$be0d6120$cb4d02c3@digo> Hello Marc and Arthur, | Marc Battyani wrote: | |> "Arthur Lemmens" wrote: | >> Mapping names to symbols, dictionaries to property lists | >> and null to nil would make for a more elegant mapping than | >> what CL-PDF seems to be using now, I think. CL-PDF seems to | >> use Lisp strings for names, and :null for NIL. |> |> Hum... I prefer the current mapping. |> Names are case sensitive so symbols are not a good representation | | Well, symbols are case sensitive too. But it is a good point that | I hadn't thought of yet. | |> Also you have to generate names for fonts and other temporary pdf |> objects. You would end up with lots of symbols! (and symbols are heavy |> weight objects compared to string) Alists are as nice as property |> lists IMO but they work with strings. The true/false is not a real |> problem, IIRC there is only one place where a true is used and none |> with false. | | You look at this from the point of view of generating PDF, but at the | moment I'm looking at it with the idea of parsing and editing existing | PDF documents. That gives a slightly different perspective on stuff | like this. As a matter of fact, at the moment I'm even considering the | idea of (semi-automatically) defining a CLOS class for each kind of PDF | object with separate slots for corresponding to each dictionary key. | That way, you could edit any element of the document by using the right | (setf slot-value). But this may be overkill, and it may take more time | than I can spend right now. I partially agree with both of you. I neither see real necessity to switch from alists to plists for dictionary representation, nor need to use symbols instead of strings pervasively. But to facilitate parsing, we should unify as much "atoms" as possible. Here is the excerpt from my rather old post: | For dictionary property names, I would recommend using symbols like |> |/Length| or keywords with corresponding string set as properties, |> e.g.: | | (setf (get :length 'pdf:namestring) "/Length") | (defmethod write-object ((obj keyword) &optional root-level) | (declare (ignorable root-level)) | (write-string (or (get obj 'pdf:namestring) (symbol-name obj)) | *pdf-stream*)) | | Strings are quite enough for the time being (generation), but could | lead to excessive memory consumption and performance degradation for | more complex tasks: parsing and editing. -- Sincerely, Dmitri Ivanov lisp.ystok.ru From alemmens at xs4all.nl Tue Apr 27 07:27:37 2004 From: alemmens at xs4all.nl (Arthur Lemmens) Date: Tue, 27 Apr 2004 09:27:37 +0200 Subject: [cl-pdf-devel] Representation of basic PDF objects In-Reply-To: <007701c42c20$be0d6120$cb4d02c3@digo> References: <0eb301c42b9b$2dca62a0$0a02a8c0@marcxp> <007701c42c20$be0d6120$cb4d02c3@digo> Message-ID: Dmitri Ivanov wrote: > I partially agree with both of you. I neither see real necessity to switch > from alists to plists for dictionary representation, nor need to use symbols > instead of strings pervasively. But to facilitate parsing, we should unify > as much "atoms" as possible. Here is the excerpt from my rather old post: > > | For dictionary property names, I would recommend using symbols like > |> |/Length| or keywords with corresponding string set as properties, > |> e.g.: > | > | (setf (get :length 'pdf:namestring) "/Length") > | (defmethod write-object ((obj keyword) &optional root-level) > | (declare (ignorable root-level)) > | (write-string (or (get obj 'pdf:namestring) (symbol-name obj)) > | *pdf-stream*)) > | > | Strings are quite enough for the time being (generation), but could > | lead to excessive memory consumption and performance degradation for > | more complex tasks: parsing and editing. Yes, something like that feels more Lispy to me than the way it's currently done. After sleeping on it, I still have the feeling that sooner or later we'll want to move towards representing each separate PDF dictionary type by a full-fledged CLOS class, with each slot corresponding to a key in the dictionary. It should not be too much work to build a table that maps the case-sensitive PDF key names to Lisp's normal way of naming symbols. But I'm probably not going to do that this week, and next week I'm on holiday. Regards, Arthur Lemmens From alemmens at xs4all.nl Tue Apr 27 09:32:53 2004 From: alemmens at xs4all.nl (Arthur Lemmens) Date: Tue, 27 Apr 2004 11:32:53 +0200 Subject: [cl-pdf-devel] Representation of basic PDF objects In-Reply-To: <113601c42bd2$9cc577d0$0a02a8c0@marcxp> References: <0eb301c42b9b$2dca62a0$0a02a8c0@marcxp> <109901c42bc3$a5a86470$0a02a8c0@marcxp> <113601c42bd2$9cc577d0$0a02a8c0@marcxp> Message-ID: Hi, I have one more question/remark about representing PDF objects. CL-PDF seems to represent PDF-strings by Lisp strings, but with the PDF-delimiters (left and right parenthesis) included in the string. I think that's quite error-prone. I think it's more logical to strip off the PDF-delimiters on input and just add them back on output. That way, you can just manipulate your Lisp strings any way you like, without having to worry about PDF's delimiters. For instance, here's a snippet of CL-PDF: (setf (content outline) (make-instance 'dictionary :dict-values `(,@(if parent `(("/Title" . ,(concatenate 'string "(" (title outline) ")")) that could have been simplified if you just added the delimiters on output. I'd be interested in your opinion about this. I'm starting to like the PDF specification quite a lot, by the way. It's well-written and it seems to have a clean and flexible design. Regards, Arthur Lemmens From divanov at aha.ru Tue Apr 27 11:51:33 2004 From: divanov at aha.ru (Dmitri Ivanov) Date: Tue, 27 Apr 2004 15:51:33 +0400 Subject: [cl-pdf-devel] Representation of basic PDF objects References: <0eb301c42b9b$2dca62a0$0a02a8c0@marcxp><109901c42bc3$a5a86470$0a02a8c0@marcxp><113601c42bd2$9cc577d0$0a02a8c0@marcxp> Message-ID: <008901c42c4e$24c332a0$cb4d02c3@digo> Hello Arthur, | I have one more question/remark about representing PDF objects. | CL-PDF seems to represent PDF-strings by Lisp strings, but with | the PDF-delimiters (left and right parenthesis) included in the | string. I think that's quite error-prone. I am afraid, you've got a wrong impression. Parenthesis mostly added only when writing into *pdf-stream* by means of the def-pdf-op macro. IIRC pdf-string is an additional function used outside content streams, hence rather rare. | I think it's more logical to strip off the PDF-delimiters on input | and just add them back on output. That way, you can just manipulate | your Lisp strings any way you like, without having to worry about | PDF's delimiters. For instance, here's a snippet of CL-PDF: | | (setf (content outline) | (make-instance 'dictionary | :dict-values `(,@(if parent `(("/Title" . ,(concatenate | 'string "(" | (title outline) ")")) | | that could have been simplified if you just added the delimiters | on output. | | I'd be interested in your opinion about this. Agree. | I'm starting to like the PDF specification quite a lot, by the way. | It's well-written and it seems to have a clean and flexible design. So did I, though I wish I had not. But that was the only chance to deal with cl-pdf :-) -- Sincerely, Dmitri Ivanov lisp.ystok.ru From marc.battyani at fractalconcept.com Tue Apr 27 16:53:02 2004 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Tue, 27 Apr 2004 18:53:02 +0200 Subject: [cl-pdf-devel] Representation of basic PDF objects References: <0eb301c42b9b$2dca62a0$0a02a8c0@marcxp><109901c42bc3$a5a86470$0a02a8c0@marcxp><113601c42bd2$9cc577d0$0a02a8c0@marcxp> Message-ID: <011701c42c78$1ba3bdf0$0a02a8c0@marcxp> "Arthur Lemmens" wrote: > > I have one more question/remark about representing PDF objects. > CL-PDF seems to represent PDF-strings by Lisp strings, but with > the PDF-delimiters (left and right parenthesis) included in the > string. I think that's quite error-prone. > > I think it's more logical to strip off the PDF-delimiters on input > and just add them back on output. That way, you can just manipulate > your Lisp strings any way you like, without having to worry about > PDF's delimiters. For instance, here's a snippet of CL-PDF: > > (setf (content outline) > (make-instance 'dictionary > :dict-values `(,@(if parent `(("/Title" . ,(concatenate 'string "(" > (title outline) ")")) > > that could have been simplified if you just added the delimiters > on output. Well anyway this is not good. It should use the quoting function as there could be some unbalanced paren in the title. I will change it. And it can't be handled in the output for now because strings are used to represent different things. > I'd be interested in your opinion about this. > > I'm starting to like the PDF specification quite a lot, by the way. > It's well-written and it seems to have a clean and flexible design. Yes, PDF is nice. Marc From marc.battyani at fractalconcept.com Tue Apr 27 17:07:00 2004 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Tue, 27 Apr 2004 19:07:00 +0200 Subject: [cl-pdf-devel] Representation of basic PDF objects References: <0eb301c42b9b$2dca62a0$0a02a8c0@marcxp><007701c42c20$be0d6120$cb4d02c3@digo> Message-ID: <011f01c42c7a$0f28c960$0a02a8c0@marcxp> "Arthur Lemmens" wrote: > > Yes, something like that feels more Lispy to me than the way it's > currently done. After sleeping on it, I still have the feeling that > sooner or later we'll want to move towards representing each separate > PDF dictionary type by a full-fledged CLOS class, with each slot > corresponding to a key in the dictionary. It should not be too much > work to build a table that maps the case-sensitive PDF key names to > Lisp's normal way of naming symbols. But I'm probably not going to > do that this week, and next week I'm on holiday. I'm don't think it will be a good idea, who will have to create big clos objects because they are potentially lots of slots even if most of them are never used. You will also have to write a write-object method for each of them and the memory footprint will be higher. All this for no advantage when you generate pdf and only a small one when you parse one. And parsing is very seldom used compared to writing. IMO even if I had to rewrite cl-pdf now I will stick to the alist or plist model. BTW my most important problem (and probably yours too) is the lack of time. So I would very much prefer that we work on new functionnalities and features rather than trying to update something that works already pretty well. ;-) For instance the charts I wrote are rather crude, there is no support for unicode, etc. Marc From marc.battyani at fractalconcept.com Tue Apr 27 17:08:56 2004 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Tue, 27 Apr 2004 19:08:56 +0200 Subject: [cl-pdf-devel] Representation of basic PDF objects References: <0eb301c42b9b$2dca62a0$0a02a8c0@marcxp><109901c42bc3$a5a86470$0a02a8c0@marcxp><113601c42bd2$9cc577d0$0a02a8c0@marcxp> <008901c42c4e$24c332a0$cb4d02c3@digo> Message-ID: <012501c42c7a$53db4dd0$0a02a8c0@marcxp> "Dmitri Ivanov" wrote: > Hello Arthur, > > | I'm starting to like the PDF specification quite a lot, by the way. > | It's well-written and it seems to have a clean and flexible design. > > So did I, though I wish I had not. But that was the only chance to deal with > cl-pdf :-) Yes,this reminds me that documentation is really a missing feature. ;-) More examples would be nice too. Marc From alemmens at xs4all.nl Tue Apr 27 18:19:30 2004 From: alemmens at xs4all.nl (Arthur Lemmens) Date: Tue, 27 Apr 2004 20:19:30 +0200 Subject: [cl-pdf-devel] Representation of basic PDF objects In-Reply-To: <012501c42c7a$53db4dd0$0a02a8c0@marcxp> References: <0eb301c42b9b$2dca62a0$0a02a8c0@marcxp><109901c42bc3$a5a86470$0a02a8c0@marcxp><113601c42bd2$9cc577d0$0a02a8c0@marcxp> <008901c42c4e$24c332a0$cb4d02c3@digo> <012501c42c7a$53db4dd0$0a02a8c0@marcxp> Message-ID: Marc Battyani wrote: > "Dmitri Ivanov" wrote: >> Hello Arthur, >> >> | I'm starting to like the PDF specification quite a lot, by the way. >> | It's well-written and it seems to have a clean and flexible design. >> >> So did I, though I wish I had not. But that was the only chance to deal > with >> cl-pdf :-) I seem to have missed Dmitri's mail. Could you please send it to me once more, Dmitri? Spasibo ;-) Arthur From marc.battyani at fractalconcept.com Tue Apr 27 22:09:11 2004 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Wed, 28 Apr 2004 00:09:11 +0200 Subject: [cl-pdf-devel] ITERATE added to cl-pdf and cl-typesetting References: <0f6701c42ba3$4064fbc0$0a02a8c0@marcxp><007601c42c20$bcffe8c0$cb4d02c3@digo><20040427160021.GG28833@w-m-p.com><01b501c42c86$4b84a300$0a02a8c0@marcxp><20040427200101.GE29424@w-m-p.com> <022a01c42c99$de734050$0a02a8c0@marcxp> Message-ID: <027601c42ca4$4571ef90$0a02a8c0@marcxp> Following the discussions about the need to have a looping construct with a clearly defined semantics and with a coherent and predictable behavior on different implementations, I've decided to integrate ITERATE to cl-pdf. ITERATE is a superset of LOOP. I've also integrated the ITERATE manual to the repository so that everybody can read it. This has been added to the cl-pdf and cl-typesetting repositories and tarballs. Comments welcomed! Marc From alemmens at xs4all.nl Tue Apr 27 23:11:54 2004 From: alemmens at xs4all.nl (Arthur Lemmens) Date: Wed, 28 Apr 2004 01:11:54 +0200 Subject: [cl-pdf-devel] Representation of basic PDF objects In-Reply-To: <011f01c42c7a$0f28c960$0a02a8c0@marcxp> References: <0eb301c42b9b$2dca62a0$0a02a8c0@marcxp><007701c42c20$be0d6120$cb4d02c3@digo> <011f01c42c7a$0f28c960$0a02a8c0@marcxp> Message-ID: [My previous messages bounced, because the file was too big. Here's a zipped version.] Marc Battyani wrote: > So I would very much prefer that we work on new functionnalities and > features OK, I've finished the parser. To test it, I've written a COPY-DOCUMENT function that parses a document, renumbers all indirect objects (I'm going to have to do that for the merging anyway), and writes out the result. I tested it on all the PDF files on my hard drive (that turned out to be 175 files, 130 MB). I opened all generated copies with Acrobat Reader 5.0 (on Windows XP). As far as I can see, Acrobat Reader has no problems with any of them (except for the files that are encrypted, but that's only to be expected). That's the good part. The bad part is that I haven't integrated this in any way with CL-PDF (in fact, it works independently of CL-PDF at the moment). I just copied the stuff I needed from PDF.LISP and modified it where necessary. Moreover, there's not much left from your original parser ;-) I'm willing to look into integrating this with CL-PDF, but I won't have any time for this in the next two weeks (I'm leaving for France in a couple of days and have a deadline before that). I've attached the code. You can do with it whatever you want. Thanks for your feedback, Arthur Lemmens -------------- next part -------------- A non-text attachment was scrubbed... Name: pdf-parse-2.zip Type: application/zip Size: 8037 bytes Desc: not available URL: From marc.battyani at fractalconcept.com Wed Apr 28 19:59:43 2004 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Wed, 28 Apr 2004 21:59:43 +0200 Subject: [cl-pdf-devel] Representation of basic PDF objects References: <0eb301c42b9b$2dca62a0$0a02a8c0@marcxp><007701c42c20$be0d6120$cb4d02c3@digo> <011f01c42c7a$0f28c960$0a02a8c0@marcxp> Message-ID: <05d901c42d5b$59e63730$0a02a8c0@marcxp> "Arthur Lemmens" wrote: > Marc Battyani wrote: > > > So I would very much prefer that we work on new functionnalities and > > features > > OK, I've finished the parser. To test it, I've written a COPY-DOCUMENT > function that parses a document, renumbers all indirect objects (I'm > going to have to do that for the merging anyway), and writes out the > result. Great! > I tested it on all the PDF files on my hard drive (that turned out to > be 175 files, 130 MB). I opened all generated copies with Acrobat > Reader 5.0 (on Windows XP). As far as I can see, Acrobat Reader has > no problems with any of them (except for the files that are encrypted, > but that's only to be expected). Good. > That's the good part. The bad part is that I haven't integrated this > in any way with CL-PDF (in fact, it works independently of CL-PDF at > the moment). I just copied the stuff I needed from PDF.LISP and > modified it where necessary. Bad! > Moreover, there's not much left from > your original parser ;-) Good, as I told you it was a rather crude hack. But it was compatible with cl-pdf ;-) > I'm willing to look into integrating this with CL-PDF, but I won't > have any time for this in the next two weeks (I'm leaving for France > in a couple of days and have a deadline before that). OK > I've attached the code. You can do with it whatever you want. Good, I will have a look at this. Marc From alemmens at xs4all.nl Wed Apr 28 20:44:54 2004 From: alemmens at xs4all.nl (Arthur Lemmens) Date: Wed, 28 Apr 2004 22:44:54 +0200 Subject: [cl-pdf-devel] Representation of basic PDF objects In-Reply-To: <05d901c42d5b$59e63730$0a02a8c0@marcxp> References: <0eb301c42b9b$2dca62a0$0a02a8c0@marcxp><007701c42c20$be0d6120$cb4d02c3@digo> <011f01c42c7a$0f28c960$0a02a8c0@marcxp> <05d901c42d5b$59e63730$0a02a8c0@marcxp> Message-ID: Marc Battyani wrote: >> That's the good part. The bad part is that I haven't integrated this >> in any way with CL-PDF (in fact, it works independently of CL-PDF at >> the moment). I just copied the stuff I needed from PDF.LISP and >> modified it where necessary. > > Bad! Yes, I know. This was the fastest way to get things working. I also felt that I didn't understand CL-PDF well enough (yet) to change it. But I think I understand the first 5 chapters of the PDF spec well enough now to write a parser for it ;-) We'll get the parser integrated with CL-PDF. It'll just take some more time. I expect that the parser is fully portable, by the way. I think it uses nothing but standard Common Lisp (except for the definition of +external-format+, which I copied from CL-PDF). It doesn't depend on regular expressions or parser generators either. >> Moreover, there's not much left from >> your original parser ;-) > Good, as I told you it was a rather crude hack. One funny coincidence was that I originally used your mechanism for keeping track of the parenthesis level when parsing a PDF string. This worked perfectly well for the first 120 files I tested, until it crashed on file #121. It turned out that this was a PDF file of your talk for the ILC 2002 conference ;-) So I removed the parenthesis level mechanism; it isn't mentioned anywhere in the spec anyway. Arthur From alemmens at xs4all.nl Wed Apr 28 21:07:35 2004 From: alemmens at xs4all.nl (Arthur Lemmens) Date: Wed, 28 Apr 2004 23:07:35 +0200 Subject: [cl-pdf-devel] Representation of basic PDF objects In-Reply-To: <05d901c42d5b$59e63730$0a02a8c0@marcxp> References: <0eb301c42b9b$2dca62a0$0a02a8c0@marcxp><007701c42c20$be0d6120$cb4d02c3@digo> <011f01c42c7a$0f28c960$0a02a8c0@marcxp> <05d901c42d5b$59e63730$0a02a8c0@marcxp> Message-ID: Marc Battyani wrote: > "Arthur Lemmens" wrote: > >> OK, I've finished the parser. To test it, I've written a COPY-DOCUMENT >> function that parses a document, renumbers all indirect objects (I'm >> going to have to do that for the merging anyway), and writes out the >> result. > > Great! Oops, I just discovered the first bug in the parser: I forgot to add your name to the copyright message. Sorry about that; it was a last-minute thing just before sending it. No offense intended. Arthur From marc.battyani at fractalconcept.com Wed Apr 28 21:24:19 2004 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Wed, 28 Apr 2004 23:24:19 +0200 Subject: [cl-pdf-devel] Representation of basic PDF objects References: <0eb301c42b9b$2dca62a0$0a02a8c0@marcxp><007701c42c20$be0d6120$cb4d02c3@digo> <011f01c42c7a$0f28c960$0a02a8c0@marcxp> <05d901c42d5b$59e63730$0a02a8c0@marcxp> Message-ID: <066201c42d67$2b869c20$0a02a8c0@marcxp> "Arthur Lemmens" > > Oops, I just discovered the first bug in the parser: I forgot to > add your name to the copyright message. Sorry about that; it was > a last-minute thing just before sending it. No offense intended. No problem :-) Marc From marc.battyani at fractalconcept.com Wed Apr 28 21:30:21 2004 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Wed, 28 Apr 2004 23:30:21 +0200 Subject: [cl-pdf-devel] Representation of basic PDF objects References: <0eb301c42b9b$2dca62a0$0a02a8c0@marcxp><007701c42c20$be0d6120$cb4d02c3@digo><011f01c42c7a$0f28c960$0a02a8c0@marcxp><05d901c42d5b$59e63730$0a02a8c0@marcxp> Message-ID: <066801c42d68$032b6200$0a02a8c0@marcxp> "Arthur Lemmens" wrote: > Marc Battyani wrote: > > >> That's the good part. The bad part is that I haven't integrated this > >> in any way with CL-PDF (in fact, it works independently of CL-PDF at > >> the moment). I just copied the stuff I needed from PDF.LISP and > >> modified it where necessary. > > > > Bad! > > Yes, I know. This was the fastest way to get things working. > I also felt that I didn't understand CL-PDF well enough (yet) to > change it. But I think I understand the first 5 chapters of the PDF > spec well enough now to write a parser for it ;-) > > We'll get the parser integrated with CL-PDF. It'll just take some > more time. I expect that the parser is fully portable, by the way. Good! So we will be able to integrate it to cl-pdf when it is compatible. > I think it uses nothing but standard Common Lisp (except for the > definition of +external-format+, which I copied from CL-PDF). It > doesn't depend on regular expressions or parser generators either. Yes, the pdf syntax is rather simple. It's much better to have a stand alone parser. > >> Moreover, there's not much left from > >> your original parser ;-) > > > Good, as I told you it was a rather crude hack. > > One funny coincidence was that I originally used your mechanism > for keeping track of the parenthesis level when parsing a PDF string. > This worked perfectly well for the first 120 files I tested, until > it crashed on file #121. It turned out that this was a PDF file of > your talk for the ILC 2002 conference ;-) So I removed the parenthesis > level mechanism; it isn't mentioned anywhere in the spec anyway. Heh, yet another good reason to move from TeX to cl-typesetting. ;-) (the paper was written with TeX) Marc