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?