[cl-pdf-devel] CMUCL compatibility fixes and new color handling code

[Marc Battyani]

"Klaus Weidner" <klaus at atsec.com> 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