Re: 2-bytes character display ready ?

[BALATON Zoltan]

Hello,

On Fri, 22 Feb 2002, Fred Kiefer wrote:
> If I do understand Nicola correctly we should just send a NSString from
> the front end to the back end. Which is probably the most easiest
> solution. As we will only do this from the NSStringDrawing code and
> advise all users to use that instead we could replace this later on,
> with out much trouble. So as for a short time solution we add this extra
> method on NSGraphicsContext, whichs default implementation is just the
> conversion to the font encoding currently done by the drawiong code.
> And everybody that wants to see real 16 Bit characters just slots it a
> better implementaiton of XGFont (I will polish the standard one up a bit
> to support this as well)
> This will be a derivation from a pure PostScript drawing interface (as
> an exchange I will postbone the Bezier path extension), but I promise to
> make sure it works for the xdps backend and for PS printing.

I think we should not deviate from the postscript interface, since this
assures the correct WYSIWYG behaviour. The postscript interface should be
rich enough to describe everything correctly for every device. (Afterall
it is used for that for years.) The X API sometimes does not map to
postscript, but the xgps backend should then do the mapping probably by
emulating the missing parts. Also the DPS interface is part of the
OpenStep specification a subset of which is in MacOS X as Quartz
Rendering. If we want to be compatible we should support at least this
subset.

Implementing complete postscript rendering in xgps is of course not needed
and xgps was never meant to do that. It started as an intermediate backend
until dgs is usable. Unfortunately that did not happen because the
ghostscript interpreter is not ready to be used for DPS yet, but the
postscript operators are already implemented in gslib (the rendering part
of Ghostscript which can be used independently from the interpreter).
Gslib can render to a lot of devices (for which gs has a driver) not just
X. (By the way there is also a windows driver in gs, though it would be
only half the way to a windows backend; and there is a pdfwriter device.)

Implementing a backend using gslib should not be too hard, this is
something I'd like to do for a long time, but unfortunately I cannot find
the time to actually work on this. I hope to do something in the near
future, but I cannot promise anything. As far as I looked into this
starting from the xdps backend most of the DPS operators can be easily
changed to the appropriate gs_functions. Of course there may be tricky
parts which I don't see yet. (Probably the X11 gs driver needs to be
changed a bit.)

On the other hand if I remember correctly the original idea behind
backends was (a few years ago) to separate appearance from behaviour.
Currently the backend only provides the rendering library. According to
this original idea the gui library should only provide behaviour and
should not do any drawing and the backend would be responsible for all
drawing but not for any behaviour. This would also make themes possible.
In this case the frontend-backend interface would have to be defined along
different lines but then the backend should still use postscript to do the
drawing (possibly by using gslib directly) to preserve WYSIWYG.

Greetings,
BALATON Zoltan