From marc.battyani at fractalconcept.com Tue Apr 5 21:13:10 2005 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Tue, 5 Apr 2005 23:13:10 +0200 Subject: [cl-pdf-devel] cl-pdf repository update References: <074c01c503f3$13b432c0$0a02a8c0@marcxp> Message-ID: <019701c53a24$46defe20$0a02a8c0@marcxp> I've commited the latest modifications to the cl-pdf repository. Rev 88: Native integration of salza 0.7.1 for the content-streams compression. Salza is Zach Beane's zlib in Lisp (No more FFI problems ;-) and is now the default compression for cl-pdf. It is even slightly faster than using zlib through FFI. (the other compressions are still there for some time (look at cl-pdf.asd if you want to use them) Refactoring of charts. Added pre and post draw hooks for plot-xy (to draw a background etc.). Removed cl-pdf.system as all the other systems cl-pdf depends on have no .system defined. (I will put it back if somebody wants to add and maintain them) The full repository is here: http://www.fractalconcept.com:8000/public/open-source/ (It's a subversion 1.1 repository.) The projects repositories are: http://www.fractalconcept.com:8000/public/open-source/cl-pdf/ http://www.fractalconcept.com:8000/public/open-source/cl-typesetting/ http://www.fractalconcept.com:8000/public/open-source/mod_lisp/ There are also tarballs available http://www.fractalconcept.com/download/cl-pdf-current.tgz http://www.fractalconcept.com/download/cl-typesetting-current.tgz BTW the (somewhat outdated) home pages for these projects are here: http://www.fractalconcept.com/asp/html/cl-pdf.html http://www.fractalconcept.com/asp/html/cl-typesetting.html http://www.fractalconcept.com/asp/html/mod_lisp.html Marc From marc.battyani at fractalconcept.com Fri Apr 8 08:20:26 2005 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Fri, 8 Apr 2005 10:20:26 +0200 Subject: [cl-pdf-devel] cl-pdf with salza References: <074c01c503f3$13b432c0$0a02a8c0@marcxp> <019701c53a24$46defe20$0a02a8c0@marcxp> Message-ID: <069101c53c13$d26ad8b0$0a02a8c0@marcxp> I did not get much feedback on the new release with salza for the compression. Any problems/comments on this before I make a wider announce ? Thanks, Marc From marc.battyani at fractalconcept.com Fri Apr 8 14:29:04 2005 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Fri, 8 Apr 2005 16:29:04 +0200 Subject: [cl-pdf-devel] cl-pdf repository update References: <074c01c503f3$13b432c0$0a02a8c0@marcxp> <019701c53a24$46defe20$0a02a8c0@marcxp> Message-ID: <07a701c53c47$524252b0$0a02a8c0@marcxp> Sorry, 2 files were missing in Salza. :( Corrected now in Rev 89 Marc > I've commited the latest modifications to the cl-pdf repository. > > Rev 88: > Native integration of salza 0.7.1 for the content-streams compression. Salza > is Zach Beane's zlib in Lisp (No more FFI problems ;-) and is now the > default compression for cl-pdf. It is even slightly faster than using zlib > through FFI. (the other compressions are still there for some time (look at > cl-pdf.asd if you want to use them) > > Refactoring of charts. Added pre and post draw hooks for plot-xy (to draw a > background etc.). > > Removed cl-pdf.system as all the other systems cl-pdf depends on have no > .system defined. (I will put it back if somebody wants to add and maintain > them) > > The full repository is here: > http://www.fractalconcept.com:8000/public/open-source/ > (It's a subversion 1.1 repository.) > > The projects repositories are: > http://www.fractalconcept.com:8000/public/open-source/cl-pdf/ > http://www.fractalconcept.com:8000/public/open-source/cl-typesetting/ > http://www.fractalconcept.com:8000/public/open-source/mod_lisp/ > > There are also tarballs available > http://www.fractalconcept.com/download/cl-pdf-current.tgz > http://www.fractalconcept.com/download/cl-typesetting-current.tgz > > BTW the (somewhat outdated) home pages for these projects are here: > http://www.fractalconcept.com/asp/html/cl-pdf.html > http://www.fractalconcept.com/asp/html/cl-typesetting.html > http://www.fractalconcept.com/asp/html/mod_lisp.html > > Marc > > > _______________________________________________ > cl-pdf-devel site list > cl-pdf-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cl-pdf-devel > From divanov at aha.ru Fri Apr 8 17:21:39 2005 From: divanov at aha.ru (Dmitriy Ivanov) Date: Fri, 8 Apr 2005 21:21:39 +0400 Subject: [cl-pdf-devel] cl-pdf with salza References: <074c01c503f3$13b432c0$0a02a8c0@marcxp><019701c53a24$46defe20$0a02a8c0@marcxp> <069101c53c13$d26ad8b0$0a02a8c0@marcxp> Message-ID: <000001c53c5f$96ae6b60$7e5802c3@digo> Hello Marc, | I did not get much feedback on the new release with salza for the | compression. | Any problems/comments on this before I make a wider announce ? The salza compression seems to work on LWW4.4. With string-to-octets and other contribs of my own, it even works for Unicode strings, i.e. lw:text-string :-) The only "serious" amendment I have had to add is computing the length of pdf stream with list content: (defmethod initialize-instance :after ((obj pdf-stream) &rest init-options &key empty) (unless empty (add-dict-value obj "/Length" #'(lambda (&aux (content (content obj))) (if (consp content) (reduce #'+ content :key #'length) (length content)))))) IMHO, salza code looks rather huge for such utility. Too many packages and files (cf. Franz's inflate.cl), about 100Kb of fasl, does not provide enough macrology to be ported efficiently to various Lisp implementations. Is it really fast? BTW, octet-replace does just the same thing as fli:replace-foreign-array. -- Sincerely, Dmitriy Ivanov lisp.ystok.ru From marc.battyani at fractalconcept.com Fri Apr 8 20:52:08 2005 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Fri, 8 Apr 2005 22:52:08 +0200 Subject: [cl-pdf-devel] cl-pdf with salza References: <074c01c503f3$13b432c0$0a02a8c0@marcxp><019701c53a24$46defe20$0a02a8c0@marcxp><069101c53c13$d26ad8b0$0a02a8c0@marcxp> <000001c53c5f$96ae6b60$7e5802c3@digo> Message-ID: <089701c53c7c$d5592e50$0a02a8c0@marcxp> "Dmitriy Ivanov" wrote: > Hello Marc, Hi Dmitriy, > | I did not get much feedback on the new release with salza for the > | compression. > | Any problems/comments on this before I make a wider announce ? > > The salza compression seems to work on LWW4.4. With string-to-octets and > other contribs of my own, it even works for Unicode strings, i.e. lw:text-string > :-) Good! Converting cl-pdf to binary and then Unicode is now rather high on my priority list. > The only "serious" amendment I have had to add is computing the length of > pdf stream with list content: > > (defmethod initialize-instance :after ((obj pdf-stream) &rest init-options > &key empty) > (unless empty > (add-dict-value obj "/Length" #'(lambda (&aux (content (content obj))) > (if (consp content) > (reduce #'+ content :key #'length) > (length content)))))) Good catch. It's strange that the pdf are readable by acrobat! > IMHO, salza code looks rather huge for such utility. Too many packages and > files (cf. Franz's inflate.cl), about 100Kb of fasl, does not provide enough > macrology to be ported efficiently to various Lisp implementations. Is it > really fast? On my tests, it's a little bit faster than zlib through FLI on LWW. The major point is that there is no allocation of huge buffers so it's more memory efficient. The 100kb of fasl is impressive but for instance octet-replace is only 157 bytes even if the fasl is 4kb! > BTW, octet-replace does just the same thing as fli:replace-foreign-array. octet-replace works on lisp data, not on foreign one ? Patches to improve salza's speed (and cl-pdf's ;-) are welcomed. Marc From tom at rakegroup.com Fri Apr 8 23:43:20 2005 From: tom at rakegroup.com (tom at rakegroup.com) Date: Fri, 8 Apr 2005 19:43:20 -0400 Subject: [cl-pdf-devel] cl-pdf repository update In-Reply-To: <07a701c53c47$524252b0$0a02a8c0@marcxp> References: <074c01c503f3$13b432c0$0a02a8c0@marcxp> <019701c53a24$46defe20$0a02a8c0@marcxp> <07a701c53c47$524252b0$0a02a8c0@marcxp> Message-ID: <1113003800.4257171838305@rakegroup.com> These fixes work on clisp, I believe they will work on SBCL as well but I need to go to work to test that again! Without the color-space fix all verions of example3 should produce an unreadable pdf file! Once patched I can generate ex1.pdf to ex8.pdf and read them in acrobat. Here is a svn diff for my clisp fixes Index: pdf.lisp =================================================================== --- pdf.lisp (revision 89) +++ pdf.lisp (working copy) @@ -350,6 +350,8 @@ &allow-other-keys) ;;; Args: color-space - can be an array! (enforce-/ filter) ; color-space) + (if (stringp color-space) + (enforce-/ color-space)) (setf (content image) (make-instance 'pdf-stream :no-compression no-compression Index: salza/deflate-stream-interface.lisp =================================================================== --- salza/deflate-stream-interface.lisp (revision 89) +++ salza/deflate-stream-interface.lisp (working copy) @@ -74,7 +74,7 @@ #+(and allegro (not octet-characters)) (excl:string-to-octets string :start start :end end :null-terminate nil) #+(and clisp (not octet-characters)) - (ext:convert-string-to-bytes string charset:ascii :start start :end end) + (ext:convert-string-to-bytes string charset:iso-8859-1 :start start :end end) #+(or octet-characters lispworks) (let* ((length (- end start)) (result (make-array length :element-type 'octet))) I use the following to compile in clisp because is assumes we are in ASCII which is only 7 bit! We need iso-8859-1 so we tell clisp that before the compile. Could this go in the asd file??? ;; turn off WARNINGS for math stuff. #+clisp (setf *warn-on-floating-point-contagion* nil) ;;In CLISP default encoding is ASCII 7bit cl-pdf is ISO-8859-1 encoding #+clisp (setf *default-file-encoding* (ext:make-encoding :charset charset:iso-8859-1 :line-terminator :dos)) (asdf:operate 'asdf:load-op :cl-pdf) (load "/cygdrive/c/Documents and Settings/twr/My Documents/lisp/cl-pdf-r89/examples/examples.lisp") -tom rake Quoting Marc Battyani : > Sorry, 2 files were missing in Salza. :( > > Corrected now in Rev 89 > > Marc > > > I've commited the latest modifications to the cl-pdf repository. > > > > Rev 88: > > Native integration of salza 0.7.1 for the content-streams compression. > Salza > > is Zach Beane's zlib in Lisp (No more FFI problems ;-) and is now the > > default compression for cl-pdf. It is even slightly faster than using zlib > > through FFI. (the other compressions are still there for some time (look > at > > cl-pdf.asd if you want to use them) > > > > Refactoring of charts. Added pre and post draw hooks for plot-xy (to draw > a > > background etc.). > > > > Removed cl-pdf.system as all the other systems cl-pdf depends on have no > > .system defined. (I will put it back if somebody wants to add and maintain > > them) > > > > The full repository is here: > > http://www.fractalconcept.com:8000/public/open-source/ > > (It's a subversion 1.1 repository.) > > > > The projects repositories are: > > http://www.fractalconcept.com:8000/public/open-source/cl-pdf/ > > http://www.fractalconcept.com:8000/public/open-source/cl-typesetting/ > > http://www.fractalconcept.com:8000/public/open-source/mod_lisp/ > > > > There are also tarballs available > > http://www.fractalconcept.com/download/cl-pdf-current.tgz > > http://www.fractalconcept.com/download/cl-typesetting-current.tgz > > > > BTW the (somewhat outdated) home pages for these projects are here: > > http://www.fractalconcept.com/asp/html/cl-pdf.html > > http://www.fractalconcept.com/asp/html/cl-typesetting.html > > http://www.fractalconcept.com/asp/html/mod_lisp.html > > > > Marc > > > > > > _______________________________________________ > > cl-pdf-devel site list > > cl-pdf-devel at common-lisp.net > > http://common-lisp.net/mailman/listinfo/cl-pdf-devel > > > > > _______________________________________________ > cl-pdf-devel site list > cl-pdf-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cl-pdf-devel > From divanov at aha.ru Sat Apr 9 14:47:25 2005 From: divanov at aha.ru (Dmitriy Ivanov) Date: Sat, 9 Apr 2005 18:47:25 +0400 Subject: [cl-pdf-devel] cl-pdf with salza References: <074c01c503f3$13b432c0$0a02a8c0@marcxp><019701c53a24$46defe20$0a02a8c0@marcxp><069101c53c13$d26ad8b0$0a02a8c0@marcxp> <000001c53c5f$96ae6b60$7e5802c3@digo> <089701c53c7c$d5592e50$0a02a8c0@marcxp> Message-ID: <000101c53d13$36ad57d0$294202c3@digo> Hello Marc, | "Dmitriy Ivanov" wrote: | On my tests, it's a little bit faster than zlib through FLI on LWW. The | major point is that there is no allocation of huge buffers so it's more | memory efficient. The 100kb of fasl is impressive but for instance | octet-replace is only 157 bytes even if the fasl is 4kb! | |> BTW, octet-replace does just the same thing as |> fli:replace-foreign-array. | | octet-replace works on lisp data, not on foreign one ? | Patches to improve salza's speed (and cl-pdf's ;-) are welcomed. I see. Moreover, octet-replace does the same thing as replace, but more efficiently :-) To optimize on LW, put (optimize #+lispworks (hcl:fixnum-safety 0)) and you get 118 bytes. The type sys:int32 corresponds (singned-byte 32), which IMHO less convenient then (unsingned-byte 32). For example, MD5 widely uses modulo-2^32 addition. In what way sys:int32 can help to implement this? -- Sincerely, Dmitriy Ivanov www.ystok.ru From marc.battyani at fractalconcept.com Sun Apr 10 20:57:26 2005 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Sun, 10 Apr 2005 22:57:26 +0200 Subject: [cl-pdf-devel] cl-pdf repository update References: <074c01c503f3$13b432c0$0a02a8c0@marcxp> <019701c53a24$46defe20$0a02a8c0@marcxp> <07a701c53c47$524252b0$0a02a8c0@marcxp> <1113003800.4257171838305@rakegroup.com> Message-ID: <020901c53e0f$e7dcb580$0a02a8c0@marcxp> wrote: > These fixes work on clisp, I believe they will work on SBCL as well but I need > to go to work to test that again! Without the color-space fix all verions of > example3 should produce an unreadable pdf file! > > Once patched I can generate ex1.pdf to ex8.pdf and read them in acrobat. Good, example3 was effectively bugged! > Here is a svn diff for my clisp fixes [...] OK added. > ;;In CLISP default encoding is ASCII 7bit cl-pdf is ISO-8859-1 encoding > #+clisp (setf *default-file-encoding* (ext:make-encoding :charset > charset:iso-8859-1 :line-terminator :dos)) :dos ? it's probably :unix here as we don't want clisp to transform the LF in CR/LF and we already have :unix in config.lisp. Can you confirm this before I add it ? Thanks, Marc From marc.battyani at fractalconcept.com Sun Apr 10 20:57:30 2005 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Sun, 10 Apr 2005 22:57:30 +0200 Subject: [cl-pdf-devel] cl-pdf with salza References: <074c01c503f3$13b432c0$0a02a8c0@marcxp><019701c53a24$46defe20$0a02a8c0@marcxp><069101c53c13$d26ad8b0$0a02a8c0@marcxp> <000001c53c5f$96ae6b60$7e5802c3@digo> <089701c53c7c$d5592e50$0a02a8c0@marcxp> <000101c53d13$36ad57d0$294202c3@digo> Message-ID: <020a01c53e0f$ea8df2d0$0a02a8c0@marcxp> "Dmitriy Ivanov" wrote: > > I see. Moreover, octet-replace does the same thing as replace, but more > efficiently :-) > > To optimize on LW, put > (optimize #+lispworks (hcl:fixnum-safety 0)) > and you get 118 bytes. OK, I add this. > The type sys:int32 corresponds (singned-byte 32), which IMHO less convenient > then (unsingned-byte 32). For example, MD5 widely uses modulo-2^32 addition. > In what way sys:int32 can help to implement this? Looks like you have found how to use it ;-) (refering to your announce in lisp-hug) Marc From divanov at aha.ru Mon Apr 11 18:21:13 2005 From: divanov at aha.ru (Dmitriy Ivanov) Date: Mon, 11 Apr 2005 22:21:13 +0400 Subject: [cl-pdf-devel] cl-pdf with salza References: <074c01c503f3$13b432c0$0a02a8c0@marcxp><019701c53a24$46defe20$0a02a8c0@marcxp><069101c53c13$d26ad8b0$0a02a8c0@marcxp> <000001c53c5f$96ae6b60$7e5802c3@digo> <089701c53c7c$d5592e50$0a02a8c0@marcxp> <000101c53d13$36ad57d0$294202c3@digo> <020a01c53e0f$ea8df2d0$0a02a8c0@marcxp> Message-ID: <000801c53ec3$65251100$455802c3@digo> Hello Marc, |> The type sys:int32 corresponds (singned-byte 32), which IMHO less | convenient |> then (unsingned-byte 32). For example, MD5 widely uses modulo-2^32 | addition. |> In what way sys:int32 can help to implement this? | | Looks like you have found how to use it ;-) | (refering to your announce in lisp-hug) Modulo-2^32 addition has turned out not to be a problem. The really missed operations are mod and logical-right-shift (not propagating the sign bit). I have managed to improve SALZA performance on LW 4.4 slightly using sys:int32 arithmetic. See the bunch of the changed files attached. I have had to change the order of source files in the system definition - look at my defsys.lisp. Below is the excerpt from the simple test case. (setq size 100000 src (make-array size :element-type '(unsigned-byte 8))) (dotimes (i size) (setf (aref src i) (random 256)))) ;#-lw-int32 (extended-time (progn (setq v1 (zlib:compress-sequence src)) (length v1))) ;user time = 0.421 ;system time = 0.000 ;Elapsed time = 0:00:00 ;Allocation = 10759576 bytes standard / 2057 bytes conses ;0 Page faults ;#+lw-int32 (extended-time (progn (setq v2 (zlib:compress-sequence src)) (length v2))) ;user time = 0.234 ;system time = 0.000 ;Elapsed time = 0:00:00 ;Allocation = 4200024 bytes standard / 4499 bytes conses ;0 Page faults Please test. -- Sincerely, Dmitriy Ivanov lisp.ystok.ru -------------- next part -------------- A non-text attachment was scrubbed... Name: salza.zip Type: application/x-zip-compressed Size: 13640 bytes Desc: not available URL: From marc.battyani at fractalconcept.com Mon Apr 11 18:35:14 2005 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Mon, 11 Apr 2005 20:35:14 +0200 Subject: [cl-pdf-devel] cl-pdf with salza References: <074c01c503f3$13b432c0$0a02a8c0@marcxp><019701c53a24$46defe20$0a02a8c0@marcxp><069101c53c13$d26ad8b0$0a02a8c0@marcxp> <000001c53c5f$96ae6b60$7e5802c3@digo> <089701c53c7c$d5592e50$0a02a8c0@marcxp> <000101c53d13$36ad57d0$294202c3@digo> <020a01c53e0f$ea8df2d0$0a02a8c0@marcxp> <000801c53ec3$65251100$455802c3@digo> Message-ID: <049d01c53ec5$34f136b0$0a02a8c0@marcxp> "Dmitriy Ivanov" wrote: > I have managed to improve SALZA performance on LW 4.4 slightly using sys:int32 > arithmetic. See the bunch of the changed files attached. I have had to > change the order of source files in the system definition - look at my > defsys.lisp. > > Below is the excerpt from the simple test case. > > (setq size 100000 > src (make-array size :element-type '(unsigned-byte 8))) > (dotimes (i size) (setf (aref src i) (random 256)))) > > ;#-lw-int32 > (extended-time (progn (setq v1 (zlib:compress-sequence src)) (length v1))) > ;user time = 0.421 > ;system time = 0.000 > ;Elapsed time = 0:00:00 > ;Allocation = 10759576 bytes standard / 2057 bytes conses > > ;#+lw-int32 > (extended-time (progn (setq v2 (zlib:compress-sequence src)) (length v2))) > ;user time = 0.234 > ;system time = 0.000 > ;Elapsed time = 0:00:00 > ;Allocation = 4200024 bytes standard / 4499 bytes conses Very cool. Now it should be much faster than using the FLI zlib. But as I have a big deadline in 3 days. I probably won't be able to look at this before Friday :( Marc From divanov at aha.ru Tue Apr 12 07:34:13 2005 From: divanov at aha.ru (Dmitriy Ivanov) Date: Tue, 12 Apr 2005 11:34:13 +0400 Subject: [cl-pdf-devel] cl-pdf with salza References: <074c01c503f3$13b432c0$0a02a8c0@marcxp><019701c53a24$46defe20$0a02a8c0@marcxp><069101c53c13$d26ad8b0$0a02a8c0@marcxp> <000001c53c5f$96ae6b60$7e5802c3@digo> <089701c53c7c$d5592e50$0a02a8c0@marcxp> <000101c53d13$36ad57d0$294202c3@digo> <020a01c53e0f$ea8df2d0$0a02a8c0@marcxp> <000801c53ec3$65251100$455802c3@digo> <049d01c53ec5$34f136b0$0a02a8c0@marcxp> Message-ID: <000001c53f32$587403c0$d54e02c3@digo> Hello Marc, | "Dmitriy Ivanov" wrote: | |> I have managed to improve SALZA performance on LW 4.4 slightly using | sys:int32 |> arithmetic. See the bunch of the changed files attached. I have had to |> change the order of source files in the system definition - look at my |> defsys.lisp. |> |> Below is the excerpt from the simple test case. |> |> (setq size 100000 |> src (make-array size :element-type '(unsigned-byte 8))) |> (dotimes (i size) (setf (aref src i) (random 256)))) |> |> ;#-lw-int32 |> (extended-time (progn (setq v1 (zlib:compress-sequence src)) (length |> v1))) ;user time = 0.421 ;system time = 0.000 ;Elapsed |> time = 0:00:00 ;Allocation = 10759576 bytes standard / 2057 bytes |> conses ;#+lw-int32 (extended-time (progn (setq v2 |> (zlib:compress-sequence src)) (length v2))) ;user time = 0.234 |> ;system time = 0.000 |> ;Elapsed time = 0:00:00 |> ;Allocation = 4200024 bytes standard / 4499 bytes conses | | Very cool. Now it should be much faster than using the FLI zlib. My latest amended version of salza.zip is available at http://lisp.ystok.ru/cl-pdf.html Further improvements: 1) Small code changes in types.lisp and compressor.lisp. 2) In compress-sequence (zlib.lisp), binding output to the specialized vector (make-array 0 :adjustable t :element-type 'octet) instead of a general one gives a considerable benefit: ;user time = 0.140 ;system time = 0.000 ;Elapsed time = 0:00:00 ;Allocation = 1617240 bytes standard / 5599 bytes conses One week point: the current version sets the compression level rigidly (defconstant +zlib-compression-level+ 2), which seems a bit low (for example, GNU ZLIB provides 6 by default). Is there any plans to advance in that direction, Zachary? -- Sincerely, Dmitriy Ivanov lisp.ystok.ru From marc.battyani at fractalconcept.com Tue Apr 12 10:08:51 2005 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Tue, 12 Apr 2005 12:08:51 +0200 Subject: [cl-pdf-devel] cl-pdf with salza References: <074c01c503f3$13b432c0$0a02a8c0@marcxp><019701c53a24$46defe20$0a02a8c0@marcxp><069101c53c13$d26ad8b0$0a02a8c0@marcxp><000001c53c5f$96ae6b60$7e5802c3@digo><089701c53c7c$d5592e50$0a02a8c0@marcxp><000101c53d13$36ad57d0$294202c3@digo><020a01c53e0f$ea8df2d0$0a02a8c0@marcxp><000801c53ec3$65251100$455802c3@digo><049d01c53ec5$34f136b0$0a02a8c0@marcxp> <000001c53f32$587403c0$d54e02c3@digo> Message-ID: <067501c53f47$a13bdcd0$0a02a8c0@marcxp> "Dmitriy Ivanov" wrote: Hi Dmitri, > 2) In compress-sequence (zlib.lisp), binding output to the specialized > vector > (make-array 0 :adjustable t :element-type 'octet) This point worries me somewhat as I don't use compress-sequence anymore. I now collect a list of buffers to reduce the memory use. Are you sure to use the latest version of cl-pdf ? Marc From divanov at aha.ru Tue Apr 12 12:04:58 2005 From: divanov at aha.ru (Dmitriy Ivanov) Date: Tue, 12 Apr 2005 16:04:58 +0400 Subject: [cl-pdf-devel] cl-pdf with salza References: <074c01c503f3$13b432c0$0a02a8c0@marcxp><019701c53a24$46defe20$0a02a8c0@marcxp><069101c53c13$d26ad8b0$0a02a8c0@marcxp><000001c53c5f$96ae6b60$7e5802c3@digo><089701c53c7c$d5592e50$0a02a8c0@marcxp><000101c53d13$36ad57d0$294202c3@digo><020a01c53e0f$ea8df2d0$0a02a8c0@marcxp><000801c53ec3$65251100$455802c3@digo><049d01c53ec5$34f136b0$0a02a8c0@marcxp> <000001c53f32$587403c0$d54e02c3@digo> <067501c53f47$a13bdcd0$0a02a8c0@marcxp> Message-ID: <001401c53f5c$b42aeba0$d54e02c3@digo> Hello Marc, |> 2) In compress-sequence (zlib.lisp), binding output to the specialized |> vector |> (make-array 0 :adjustable t :element-type 'octet) | | This point worries me somewhat as I don't use compress-sequence | anymore. I now collect a list of buffers to reduce the memory use. | Are you sure to use the latest version of cl-pdf ? I see. I meant Zach's compress-sequence (in zlib.lisp). Sorry for the worry. -- Sincerely, Dmitriy Ivanov lisp.ystok.ru From divanov at aha.ru Tue Apr 12 12:38:47 2005 From: divanov at aha.ru (Dmitriy Ivanov) Date: Tue, 12 Apr 2005 16:38:47 +0400 Subject: [cl-pdf-devel] cl-pdf with salza References: <000001c53c5f$96ae6b60$7e5802c3@digo> <089701c53c7c$d5592e50$0a02a8c0@marcxp> <000101c53d13$36ad57d0$294202c3@digo> <020a01c53e0f$ea8df2d0$0a02a8c0@marcxp> <000801c53ec3$65251100$455802c3@digo> <049d01c53ec5$34f136b0$0a02a8c0@marcxp> <000001c53f32$587403c0$d54e02c3@digo> <20050412104808.GK1428@xach.com> Message-ID: <001501c53f5c$b52c7d20$d54e02c3@digo> Hello Zach, |> One week point: the current version sets the compression level rigidly |> (defconstant +zlib-compression-level+ 2), |> which seems a bit low (for example, GNU ZLIB provides 6 by default). |> Is there any plans to advance in that direction, Zachary? | | The ZLIB data format does not prescribe a compression technique, it | only describes the resulting output; implementations are free to use | whatever mechanism they like. The format's "compression level" value | is purely informational and is not required to have any effect on the | compressed output. | | Salza uses a fixed compression technique right now, so there is no | flexibility between speed and space. I would like to add this in the | future. Thanks for the explanation. As there are no limits to improve someone else's program, exuse my further digging :-). I include di-huffman.lisp in my salza.zip (at lisp.ystok.ru/cl-pdf.html). It is a rewrite of your huffman.lisp from version 0.4 augmented by Wade's suggestions on speeding up calls of the write-bits. Rationale: the distance table is rather huge and should not be included into the delivered image. Moreover, zlib functionality can even not be claimed by the application user gestures. So I suggest cretating and populating this table (actually, the two tables distance-vals and distance-lens) at run time by invoking the new initialize-huffman function from make-deflate-stream. With this rewrite, my favorite example exhibits further impovements: (setq size 100000 src (make-array size :element-type '(unsigned-byte 8))) (dotimes (i size) (setf (aref src i) (random 256)))) Timing the evaluation of (PROGN (SETQ V2 (SALZA:COMPRESS-SEQUENCE SRC)) (LENGTH V2)) user time = 0.093 system time = 0.000 Elapsed time = 0:00:00 Allocation = 1614320 bytes standard / 319 bytes conses -- Sincerely, Dmitriy Ivanov lisp.ystok.ru From edi at agharta.de Thu Apr 14 13:50:36 2005 From: edi at agharta.de (Edi Weitz) Date: Thu, 14 Apr 2005 15:50:36 +0200 Subject: [cl-pdf-devel] Problems with Adobe Reader 7 Message-ID: Hi! I was happy to get my first application that uses CL-TYPESETTING to produce PDF output up and running this weekend. However, it turns out that the documents work fine with Acrobat Reader 6 but render as blank pages with Acrobat Reader 7. My customer unfortunately uses version 7. Has anyone else seen these problems? Any idea what could be the cause? Thanks, Edi. From marc.battyani at fractalconcept.com Thu Apr 14 21:26:32 2005 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Thu, 14 Apr 2005 23:26:32 +0200 Subject: [cl-pdf-devel] Problems with Adobe Reader 7 References: Message-ID: <015c01c54138$a24f7ee0$0b03a8c0@marcxp> > I was happy to get my first application that uses CL-TYPESETTING to > produce PDF output up and running this weekend. Congratulations! ;-) > However, it turns out > that the documents work fine with Acrobat Reader 6 but render as blank > pages with Acrobat Reader 7. My customer unfortunately uses version > 7. Has anyone else seen these problems? Any idea what could be the > cause? I'm still using acrobat reader 6, I will get acrobat reader 7 to look at the problem. Marc From marc.battyani at fractalconcept.com Thu Apr 14 21:29:44 2005 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Thu, 14 Apr 2005 23:29:44 +0200 Subject: [cl-pdf-devel] Re: Report generators for LispWorks References: <011901c54035$368bc0a0$9c52e4d5@alcinoos> <0bb001c5403a$2d7c2a40$0a02a8c0@marcxp> <012701c54047$a8b224f0$9c52e4d5@alcinoos> <0c4f01c54050$6c1c9120$0a02a8c0@marcxp> <003101c54104$ba11f1e0$0100a8c0@JOHNDONNEPC> Message-ID: <016801c54139$15dd8eb0$0b03a8c0@marcxp> "Denis Mashkevich" wrote: [I've put the cl-pdf-devel list in copy] > cl-pdf's output crashes "Adobe Acrobat ebook reader" (this acrobat version > was preinstalled on one of the computers I use). > It displays fine in all other Acrobat Reader versions. I've tried to find > the installer for this version (on Adobe's site and elsewhere), but > couldn't. > All other pdfs I read in this app displayed fine. I've checked the version > of one of the other pdfs, it was 1.4 - so this reader is apparently capable > of displaying pdf 1.4. As I am not familiar with pdf file format, I have not > looked into this issue further. > I don't know if this should bother you at all, since this is a relatively > obscure app, but this issue may be indicative of some larger problem. OK I will have a look at this ebook reader. Edi Weitz have just signaled a problem with acrobat reader 7 as well. Marc From edi at agharta.de Thu Apr 14 22:10:01 2005 From: edi at agharta.de (Edi Weitz) Date: Fri, 15 Apr 2005 00:10:01 +0200 Subject: [cl-pdf-devel] Problems with Adobe Reader 7 In-Reply-To: <015c01c54138$a24f7ee0$0b03a8c0@marcxp> (Marc Battyani's message of "Thu, 14 Apr 2005 23:26:32 +0200") References: <015c01c54138$a24f7ee0$0b03a8c0@marcxp> Message-ID: On Thu, 14 Apr 2005 23:26:32 +0200, "Marc Battyani" wrote: > I'm still using acrobat reader 6, I will get acrobat reader 7 to > look at the problem. I forgot to say that this doesn't happen with /all/ PDFs generated by CL-PDF. I can send you and example for one that fails if you want. Cheers, Edi. From tom at rakegroup.com Thu Apr 14 23:31:33 2005 From: tom at rakegroup.com (tom at rakegroup.com) Date: Thu, 14 Apr 2005 19:31:33 -0400 Subject: [cl-pdf-devel] cl-pdf repository update In-Reply-To: <020901c53e0f$e7dcb580$0a02a8c0@marcxp> References: <074c01c503f3$13b432c0$0a02a8c0@marcxp> <019701c53a24$46defe20$0a02a8c0@marcxp> <07a701c53c47$524252b0$0a02a8c0@marcxp> <1113003800.4257171838305@rakegroup.com> <020901c53e0f$e7dcb580$0a02a8c0@marcxp> Message-ID: <1113521493.425efd5527119@rakegroup.com> Quoting Marc Battyani : > wrote: > > > These fixes work on clisp, I believe they will work on SBCL as well but I > need > > to go to work to test that again! Without the color-space fix all verions > of > > example3 should produce an unreadable pdf file! > > > > Once patched I can generate ex1.pdf to ex8.pdf and read them in acrobat. > > Good, example3 was effectively bugged! > > > Here is a svn diff for my clisp fixes > [...] > > OK added. > > > ;;In CLISP default encoding is ASCII 7bit cl-pdf is ISO-8859-1 encoding > > #+clisp (setf *default-file-encoding* (ext:make-encoding :charset > > charset:iso-8859-1 :line-terminator :dos)) > > :dos ? it's probably :unix here as we don't want clisp to transform the LF > in CR/LF and we already have :unix in config.lisp. Marc, on line-terminator works. (setf *default-file-encoding* (ext:make-encoding :charset charset:iso-8859-1)) I tried this on both clisp for windows/cygwin and linux. Sorry for the late reply. -tom rake > > Can you confirm this before I add it ? > > Thanks, > > Marc > > > From edi at agharta.de Fri Apr 15 08:26:00 2005 From: edi at agharta.de (Edi Weitz) Date: Fri, 15 Apr 2005 10:26:00 +0200 Subject: [cl-pdf-devel] Problems with Adobe Reader 7 In-Reply-To: <20050415024427.GB24636@w-m-p.com> (Klaus Weidner's message of "Thu, 14 Apr 2005 21:44:27 -0500") References: <015c01c54138$a24f7ee0$0b03a8c0@marcxp> <20050415024427.GB24636@w-m-p.com> Message-ID: On Thu, 14 Apr 2005 21:44:27 -0500, Klaus Weidner wrote: > I'd be interested in an example, I can try to give it a go if nobody > beats me to it... The simple example below for me produces a file that is fine for Acrobat Reader 6 but renders as a blank page with Reader 7. (in-package typeset) (defun foo (rows &optional (file "test-table.pdf")) (with-document () (let ((max (make-array (length (first rows)) :initial-element 0))) (dolist (row rows) (loop for col in row for col-index from 0 for size = (tt::compute-boxes-natural-size (tt::boxes (compile-text () col)) #'dx) do (setf (aref max col-index) (max (aref max col-index) size)))) (draw-pages (compile-text () (tt:table (:col-widths (coerce max 'list) :border 1) (dolist (row rows) (tt:row () (dolist (cell row) (tt:cell () cell)))))) :break :after) (pdf:write-document file))) nil) (foo '(("one" "two" "three") ("Groucho" "Chico" "Harpo") ("do" "re" "mi"))) Cheers, Edi. From marc.battyani at fractalconcept.com Fri Apr 15 09:29:40 2005 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Fri, 15 Apr 2005 11:29:40 +0200 Subject: [cl-pdf-devel] Problems with Adobe Reader 7 References: <015c01c54138$a24f7ee0$0b03a8c0@marcxp> <20050415024427.GB24636@w-m-p.com> Message-ID: <032801c5419d$a803cf20$0b03a8c0@marcxp> "Edi Weitz" wrote: > The simple example below for me produces a file that is fine for > Acrobat Reader 6 but renders as a blank page with Reader 7. > > (in-package typeset) > > (defun foo (rows &optional (file "test-table.pdf")) > (with-document () > (let ((max (make-array (length (first rows)) > :initial-element 0))) > (dolist (row rows) > (loop for col in row > for col-index from 0 > for size = (tt::compute-boxes-natural-size > (tt::boxes (compile-text () col)) > #'dx) > do (setf (aref max col-index) > (max (aref max col-index) size)))) > (draw-pages (compile-text () > (tt:table (:col-widths (coerce max 'list) :border 1) > (dolist (row rows) > (tt:row () > (dolist (cell row) > (tt:cell () cell)))))) > :break :after) > (pdf:write-document file))) > nil) > > (foo '(("one" "two" "three") > ("Groucho" "Chico" "Harpo") > ("do" "re" "mi"))) I installed acrobat reader 7 and tried your example with LWW4.4. It works for me. Can you try the attached pdf ? Marc -------------- next part -------------- A non-text attachment was scrubbed... Name: test-table.pdf Type: application/pdf Size: 1159 bytes Desc: not available URL: From edi at agharta.de Fri Apr 15 10:06:00 2005 From: edi at agharta.de (Edi Weitz) Date: Fri, 15 Apr 2005 12:06:00 +0200 Subject: [cl-pdf-devel] Problems with Adobe Reader 7 In-Reply-To: <032801c5419d$a803cf20$0b03a8c0@marcxp> (Marc Battyani's message of "Fri, 15 Apr 2005 11:29:40 +0200") References: <015c01c54138$a24f7ee0$0b03a8c0@marcxp> <20050415024427.GB24636@w-m-p.com> <032801c5419d$a803cf20$0b03a8c0@marcxp> Message-ID: On Fri, 15 Apr 2005 11:29:40 +0200, "Marc Battyani" wrote: > I installed acrobat reader 7 and tried your example with LWW4.4. It > works for me. Can you try the attached pdf ? Yes, it works. FWIW, I updated my copy of CL-PDF, re-compiled and now it also works for me. Seems like it is something that has changed a couple of days ago - the version I was working with was checked out from SVN less than a week ago. Sorry for the noise, Edi. From tom at rakegroup.com Fri Apr 15 13:53:10 2005 From: tom at rakegroup.com (tom at rakegroup.com) Date: Fri, 15 Apr 2005 09:53:10 -0400 Subject: [cl-pdf-devel] cl-pdf repository update In-Reply-To: <1113521493.425efd5527119@rakegroup.com> References: <074c01c503f3$13b432c0$0a02a8c0@marcxp> <019701c53a24$46defe20$0a02a8c0@marcxp> <07a701c53c47$524252b0$0a02a8c0@marcxp> <1113003800.4257171838305@rakegroup.com> <020901c53e0f$e7dcb580$0a02a8c0@marcxp> <1113521493.425efd5527119@rakegroup.com> Message-ID: <1113573190.425fc74677a2f@www.rakegroup.com> Quoting tom at rakegroup.com: > Quoting Marc Battyani : > > > wrote: > > > > > These fixes work on clisp, I believe they will work on SBCL as well but I > > need > > > to go to work to test that again! Without the color-space fix all verions > > of > > > example3 should produce an unreadable pdf file! > > > > > > Once patched I can generate ex1.pdf to ex8.pdf and read them in acrobat. > > > > Good, example3 was effectively bugged! > > > > > Here is a svn diff for my clisp fixes > > [...] > > > > OK added. > > > > > ;;In CLISP default encoding is ASCII 7bit cl-pdf is ISO-8859-1 encoding > > > #+clisp (setf *default-file-encoding* (ext:make-encoding :charset > > > charset:iso-8859-1 :line-terminator :dos)) > > > > :dos ? it's probably :unix here as we don't want clisp to transform the LF > > in CR/LF and we already have :unix in config.lisp. > Marc, > > That should be *no* line-terminator works. -tom rake > on line-terminator works. > > (setf *default-file-encoding* (ext:make-encoding :charset > charset:iso-8859-1)) > > I tried this on both clisp for windows/cygwin and linux. > > Sorry for the late reply. > > -tom rake > > > > > Can you confirm this before I add it ? > > > > Thanks, > > > > Marc > > > > > > > > > > _______________________________________________ > cl-pdf-devel site list > cl-pdf-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cl-pdf-devel > From marc.battyani at fractalconcept.com Fri Apr 15 15:05:36 2005 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Fri, 15 Apr 2005 17:05:36 +0200 Subject: [cl-pdf-devel] cl-pdf repository update References: <074c01c503f3$13b432c0$0a02a8c0@marcxp> <019701c53a24$46defe20$0a02a8c0@marcxp> <07a701c53c47$524252b0$0a02a8c0@marcxp> <1113003800.4257171838305@rakegroup.com> <020901c53e0f$e7dcb580$0a02a8c0@marcxp> <1113521493.425efd5527119@rakegroup.com> <1113573190.425fc74677a2f@www.rakegroup.com> Message-ID: <01fc01c541cc$9565fcb0$0a02a8c0@marcxp> wrote: > > on line-terminator works. > > > > (setf *default-file-encoding* (ext:make-encoding :charset > > charset:iso-8859-1)) > > > > I tried this on both clisp for windows/cygwin and linux. > That should be *no* line-terminator works. OK I will put this. Marc From marc.battyani at fractalconcept.com Wed Apr 20 12:05:27 2005 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Wed, 20 Apr 2005 14:05:27 +0200 Subject: [cl-pdf-devel] cl-pdf with salza References: <074c01c503f3$13b432c0$0a02a8c0@marcxp><019701c53a24$46defe20$0a02a8c0@marcxp><069101c53c13$d26ad8b0$0a02a8c0@marcxp> <000001c53c5f$96ae6b60$7e5802c3@digo> <089701c53c7c$d5592e50$0a02a8c0@marcxp> <000101c53d13$36ad57d0$294202c3@digo> <020a01c53e0f$ea8df2d0$0a02a8c0@marcxp> <000801c53ec3$65251100$455802c3@digo> Message-ID: <28b801c545a1$3eb18640$0a02a8c0@marcxp> Hi Dmitri, > I have managed to improve SALZA performance on LW 4.4 slightly using sys:int32 > arithmetic. See the bunch of the changed files attached. I have had to > change the order of source files in the system definition - look at my > defsys.lisp. > Please test. From marc.battyani at fractalconcept.com Wed Apr 20 12:45:59 2005 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Wed, 20 Apr 2005 14:45:59 +0200 Subject: [cl-pdf-devel] cl-pdf with salza References: <074c01c503f3$13b432c0$0a02a8c0@marcxp><019701c53a24$46defe20$0a02a8c0@marcxp><069101c53c13$d26ad8b0$0a02a8c0@marcxp><000001c53c5f$96ae6b60$7e5802c3@digo><089701c53c7c$d5592e50$0a02a8c0@marcxp><000101c53d13$36ad57d0$294202c3@digo><020a01c53e0f$ea8df2d0$0a02a8c0@marcxp><000801c53ec3$65251100$455802c3@digo> <28b801c545a1$3eb18640$0a02a8c0@marcxp> Message-ID: <28db01c545a6$e843c3d0$0a02a8c0@marcxp> I wrote: [Sorry, I've sent the mail with non content...] > Hi Dmitri, > > > I have managed to improve SALZA performance on LW 4.4 slightly using > sys:int32 > > arithmetic. See the bunch of the changed files attached. I have had to > > change the order of source files in the system definition - look at my > > defsys.lisp. > > > Please test. Seems OK for me. I just changed the asd file so that it loads correctly. Is di-huffman.lisp a portable replacement for huffman.lisp or is it for LW or LW4.4+ only ? Marc From divanov at aha.ru Wed Apr 20 13:58:11 2005 From: divanov at aha.ru (Dmitriy Ivanov) Date: Wed, 20 Apr 2005 17:58:11 +0400 Subject: [cl-pdf-devel] cl-pdf with salza References: <074c01c503f3$13b432c0$0a02a8c0@marcxp><019701c53a24$46defe20$0a02a8c0@marcxp><069101c53c13$d26ad8b0$0a02a8c0@marcxp><000001c53c5f$96ae6b60$7e5802c3@digo><089701c53c7c$d5592e50$0a02a8c0@marcxp><000101c53d13$36ad57d0$294202c3@digo><020a01c53e0f$ea8df2d0$0a02a8c0@marcxp><000801c53ec3$65251100$455802c3@digo> <28b801c545a1$3eb18640$0a02a8c0@marcxp> <28db01c545a6$e843c3d0$0a02a8c0@marcxp> Message-ID: <004201c545b1$20a158a0$855802c3@digo> Hello Marc, | >> I have managed to improve SALZA performance on LW 4.4 slightly using |> sys:int32 | >> arithmetic. See the bunch of the changed files attached. I have had | >> to change the order of source files in the system definition - look | >> at my defsys.lisp. |> | >> Please test. | | Seems OK for me. I just changed the asd file so that it loads | correctly. Is di-huffman.lisp a portable replacement for huffman.lisp | or is it for LW or LW4.4+ only ? Portable as far as I can see. There are feature-conditionalized LW-specific declarations there but nothing is specific to LW4.4. -- Sincerely, Dmitriy Ivanov lisp.ystok.ru From marc.battyani at fractalconcept.com Wed Apr 20 16:33:26 2005 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Wed, 20 Apr 2005 18:33:26 +0200 Subject: [cl-pdf-devel] cl-pdf with salza References: <074c01c503f3$13b432c0$0a02a8c0@marcxp><019701c53a24$46defe20$0a02a8c0@marcxp><069101c53c13$d26ad8b0$0a02a8c0@marcxp><000001c53c5f$96ae6b60$7e5802c3@digo><089701c53c7c$d5592e50$0a02a8c0@marcxp><000101c53d13$36ad57d0$294202c3@digo><020a01c53e0f$ea8df2d0$0a02a8c0@marcxp><000801c53ec3$65251100$455802c3@digo><28b801c545a1$3eb18640$0a02a8c0@marcxp><28db01c545a6$e843c3d0$0a02a8c0@marcxp> <004201c545b1$20a158a0$855802c3@digo> Message-ID: <299b01c545c6$af591820$0a02a8c0@marcxp> "Dmitriy Ivanov" wrote: > | correctly. Is di-huffman.lisp a portable replacement for huffman.lisp > | or is it for LW or LW4.4+ only ? > > Portable as far as I can see. > There are feature-conditionalized LW-specific declarations there but nothing > is specific to LW4.4. OK so why a new file? If it's a portable optimized file I can just put it instead of the original one. Marc From divanov at aha.ru Wed Apr 20 17:14:48 2005 From: divanov at aha.ru (Dmitriy Ivanov) Date: Wed, 20 Apr 2005 21:14:48 +0400 Subject: [cl-pdf-devel] cl-pdf with salza References: <074c01c503f3$13b432c0$0a02a8c0@marcxp><019701c53a24$46defe20$0a02a8c0@marcxp><069101c53c13$d26ad8b0$0a02a8c0@marcxp><000001c53c5f$96ae6b60$7e5802c3@digo><089701c53c7c$d5592e50$0a02a8c0@marcxp><000101c53d13$36ad57d0$294202c3@digo><020a01c53e0f$ea8df2d0$0a02a8c0@marcxp><000801c53ec3$65251100$455802c3@digo><28b801c545a1$3eb18640$0a02a8c0@marcxp><28db01c545a6$e843c3d0$0a02a8c0@marcxp> <004201c545b1$20a158a0$855802c3@digo> <299b01c545c6$af591820$0a02a8c0@marcxp> Message-ID: <004401c545cc$900356b0$855802c3@digo> Hello Marc, | "Dmitriy Ivanov" wrote: | >>> correctly. Is di-huffman.lisp a portable replacement for >>> huffman.lisp or is it for LW or LW4.4+ only ? |> |> Portable as far as I can see. |> There are feature-conditionalized LW-specific declarations there but |> nothing is specific to LW4.4. | | OK so why a new file? If it's a portable optimized file I can just put | it instead of the original one. It is much different from the latest version in the SALZA distribution 0.7 that you have put into the cl-pdf repository originally. -- Sincerely, Dmitriy Ivanov lisp.ystok.ru From marc.battyani at fractalconcept.com Wed Apr 20 20:11:49 2005 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Wed, 20 Apr 2005 22:11:49 +0200 Subject: [cl-pdf-devel] cl-pdf and cl-typesetting release candidates References: <074c01c503f3$13b432c0$0a02a8c0@marcxp> <019701c53a24$46defe20$0a02a8c0@marcxp> Message-ID: <2fb101c545e5$31557a80$0a02a8c0@marcxp> The last "official" versions for cl-pdf and cl-typesetting are very old (1 year ?). It seems that some people don't like to use the latest versions and prefer official releases. So I plan to do one tomorrow. Please send me remarks, fixes and patches you may have from the current repository version. Rev 93: cl-pdf: Updated iterate to the latest version (1.4?) Rev 92: cl-typesetting: Perform early compression of the content-streams (as soon as they are closed) to reduce memory use. Updated Klaus Weidner's (X)HTML to pdf converter in the contrib directory. Added Spanish hyphenation file [Andrew Philpot] Rev 91: cl-pdf: Some file encoding modifications More salza optimizations [Dmitri Ivanov] The full repository is here: http://www.fractalconcept.com:8000/public/open-source/ (It's a subversion 1.1 repository.) The projects repositories are: http://www.fractalconcept.com:8000/public/open-source/cl-pdf/ http://www.fractalconcept.com:8000/public/open-source/cl-typesetting/ http://www.fractalconcept.com:8000/public/open-source/mod_lisp/ There are also tarballs available http://www.fractalconcept.com/download/cl-pdf-current.tgz http://www.fractalconcept.com/download/cl-typesetting-current.tgz BTW the (rather outdated) home pages for these projects are here: http://www.fractalconcept.com/asp/html/cl-pdf.html http://www.fractalconcept.com/asp/html/cl-typesetting.html http://www.fractalconcept.com/asp/html/mod_lisp.html Marc From divanov at aha.ru Thu Apr 21 07:33:18 2005 From: divanov at aha.ru (Dmitriy Ivanov) Date: Thu, 21 Apr 2005 11:33:18 +0400 Subject: [cl-pdf-devel] cl-pdf and cl-typesetting release candidates References: <074c01c503f3$13b432c0$0a02a8c0@marcxp><019701c53a24$46defe20$0a02a8c0@marcxp> <2fb101c545e5$31557a80$0a02a8c0@marcxp> Message-ID: <000101c54644$af5f3560$2f5802c3@digo> Hello Marc, | Please send me remarks, fixes and patches you may have from the current | repository version. | | Rev 93: | cl-pdf: | Updated iterate to the latest version (1.4?) In pdf.lisp, I guess it should look like the following: (defmethod initialize-instance :after ((obj pdf-stream) &rest init-options &key empty &allow-other-keys) (unless empty (add-dict-value obj "/Length" #'(lambda () (let ((content (content obj))) (if (consp content) (reduce #'+ content :key #'length) (length content))))))) ; <-- | Rev 91: | cl-pdf: | Some file encoding modifications | More salza optimizations [Dmitri Ivanov] Seems to work fine with my version of compress-string looking like (defun compress-string (string) (let* ((input (if (stringp string) (deflate::string-to-octets string 0 (length string))) string)) ...)) -- Sincerely, Dmitriy Ivanov lisp.ystok.ru From marc.battyani at fractalconcept.com Thu Apr 21 15:06:57 2005 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Thu, 21 Apr 2005 17:06:57 +0200 Subject: [cl-pdf-devel] cl-pdf and cl-typesetting release candidates References: <074c01c503f3$13b432c0$0a02a8c0@marcxp><019701c53a24$46defe20$0a02a8c0@marcxp><2fb101c545e5$31557a80$0a02a8c0@marcxp> <000101c54644$af5f3560$2f5802c3@digo> Message-ID: <038901c54683$c447ff40$0a02a8c0@marcxp> "Dmitriy Ivanov" wrote: > (length content))))))) ; <-- OK > Seems to work fine with my version of compress-string looking like > (defun compress-string (string) > (let* ((input (if (stringp string) > (deflate::string-to-octets string 0 (length string))) > string)) > ...)) Why don't you use the current cl-pdf version which should be more memory efficient? Marc From divanov at aha.ru Thu Apr 21 18:40:15 2005 From: divanov at aha.ru (Dmitriy Ivanov) Date: Thu, 21 Apr 2005 22:40:15 +0400 Subject: [cl-pdf-devel] cl-pdf and cl-typesetting release candidates References: <074c01c503f3$13b432c0$0a02a8c0@marcxp><019701c53a24$46defe20$0a02a8c0@marcxp><2fb101c545e5$31557a80$0a02a8c0@marcxp> <000101c54644$af5f3560$2f5802c3@digo> <038901c54683$c447ff40$0a02a8c0@marcxp> Message-ID: <000a01c546a3$873fdc10$2f5802c3@digo> Hello Marc, |> Seems to work fine with my version of compress-string looking like |> (defun compress-string (string) |> (let* ((input (if (stringp string) |> (deflate::string-to-octets string 0 (length string))) |> string)) |> ...)) | | Why don't you use the current cl-pdf version which should be more | memory efficient? I meant exactly the same version from cl-pdf/zlib.lisp except for the case when the stream content is already an octet vector. I encountered this today and have not found out yet whether it was caused by my overrides or common cl-pdf code. -- Sincerely, Dmitriy Ivanov lisp.ystok.ru From marc.battyani at fractalconcept.com Thu Apr 21 18:57:45 2005 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Thu, 21 Apr 2005 20:57:45 +0200 Subject: [cl-pdf-devel] cl-pdf and cl-typesetting release candidates References: <074c01c503f3$13b432c0$0a02a8c0@marcxp><019701c53a24$46defe20$0a02a8c0@marcxp><2fb101c545e5$31557a80$0a02a8c0@marcxp><000101c54644$af5f3560$2f5802c3@digo><038901c54683$c447ff40$0a02a8c0@marcxp> <000a01c546a3$873fdc10$2f5802c3@digo> Message-ID: <04a301c546a4$02f46880$0a02a8c0@marcxp> "Dmitriy Ivanov" wrote: > |> Seems to work fine with my version of compress-string looking like > |> (defun compress-string (string) > |> (let* ((input (if (stringp string) > |> (deflate::string-to-octets string 0 (length string))) > |> string)) > |> ...)) > | > | Why don't you use the current cl-pdf version which should be more > | memory efficient? > > I meant exactly the same version from cl-pdf/zlib.lisp except for the case > when the stream content is already an octet vector. I encountered this today > and have not found out yet whether it was caused by my overrides or common > cl-pdf code. OK. Sorry, I thought you were using your previous compress-string when you have just modified the string to octets conversion. I'm adding this. Anybody has other fixes ? Marc From edi at agharta.de Fri Apr 22 11:25:55 2005 From: edi at agharta.de (Edi Weitz) Date: Fri, 22 Apr 2005 13:25:55 +0200 Subject: [cl-pdf-devel] Re: [cl-pdf-announce] cl-pdf and cl-typesetting release candidates In-Reply-To: <2fb101c545e5$31557a80$0a02a8c0@marcxp> (Marc Battyani's message of "Wed, 20 Apr 2005 22:11:49 +0200") References: <074c01c503f3$13b432c0$0a02a8c0@marcxp> <019701c53a24$46defe20$0a02a8c0@marcxp> <2fb101c545e5$31557a80$0a02a8c0@marcxp> Message-ID: On Wed, 20 Apr 2005 22:11:49 +0200, "Marc Battyani" wrote: > Please send me remarks, fixes and patches you may have from the > current repository version. It didn't even compile on CMUCL due to the following lines at the end of huffman.lisp (note the missing parenthesis): ;;; Stub called from make-deflate-stream if di-huffman is not used. (defun initialize-huffman (&optional force) (declare (ignore force)) Using stock Salza 0.7.1 everything worked fine. As I probably said before - I'm questioning the usefulness of forking other libraries (as long as they're still maintained) and including them into cl-pdf or cl-typesetting. If there are improvements (like the ones from Dmitriy) they should be merged into the upstream code. See you in Amsterdam, Edi. From divanov at aha.ru Fri Apr 29 11:13:32 2005 From: divanov at aha.ru (Dmitriy Ivanov) Date: Fri, 29 Apr 2005 15:13:32 +0400 Subject: [cl-pdf-devel] Small improvement: pdf:make-image method on pathname Message-ID: <000801c54cb9$e1730740$0d4e02c3@digo> Hello folks, I would suggest the small change on the subject (see pdf-base.lisp). It can help in the situation where the same sampled image is about to be placed into several pdf-files and the image file type is not known in advance. To avoid an extra load, the original (defmethod make-image ((object pathname) ...) ...) is divided into the following two primitives: (defun read-bitmap-image-file (pathname &optional (type (pathname-type pathname))) (cond ((member type '("jpeg" "jpg") :test #'equalp) (read-jpeg-file pathname)) ((equalp type "png") (read-png-file pathname)) (t (error "Unsupported image file type ~s." type)))) (defmethod make-image ((object pathname) &rest args &key (type (pathname-type object))) (apply 'make-image (read-bitmap-image-file object type) args)) -- Sincerely, Dmitriy Ivanov lisp.ystok.ru