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

[Klaus Weidner]

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