[cl-pdf-devel] cl-pdf with salza
Marc Battyani
marc.battyani at fractalconcept.com
Fri Apr 8 20:52:08 UTC 2005
"Dmitriy Ivanov" <divanov at aha.ru> 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
More information about the cl-pdf-devel
mailing list