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

[Klaus Weidner]

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: #<Function (:MACRO WITH-OUTPUT-TO-STRING) {102BF711}>
  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