[mcclim-devel] support for clisp (1)

[Robert Strandh]

Hello, 

Bruno Haible writes:
 > Robert Strandh wrote:
 > >  > About the second one: Could someone please explain what the intent of
 > >  > the package EXTERNAL-FORMAT in McCLIM is?
 > >
 > > It looks like it tries to handle functions for translating from some
 > > internal format of McCLIM (hopefully Unicode) to X11 font encoding.
 > 
 > OK. Under which conditions should the code which uses and defines
 > external-format::ksc5601-code-to-font-index etc. be defined?
 > - If the Lisp implementation supports Unicode?
 >   #+unicode
 > - If CLIM should support Unicode?
 >   #+clim-unicode

It looks to me like the functionality in that package should always be
there.  A McCLIM text style should probably correspond to multiple X
fonts possibly each with a different font encoding.  The translate
function passed to draw-glyphs should be tailored to that font set
because it knows about the encoding of each X font and when it would
have to switch between fonts. 

 > And what shall happen on implementations that don't have an EXTERNAL-FORMAT
 > package? Why is there no (DEFPACKAGE "EXTERNAL-FORMAT" ...) in McCLIM?

I don't know, because I am not sure who wrote the Korean gadget test.
But McCLIM clearly breaks if :unicode is a feature.  Again, I don't
think that package should be there and that the functionality that it
supplies always should. 

Now the question is: is there a reasonable way that we can hide the
complexity of the translate function at the CLIM level.  Or should we
on the contrary find a way to expose its flexibility to the programmer
using CLIM? 

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------