discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Type1 fonts & status of various backends


From: nicola
Subject: Re: Type1 fonts & status of various backends
Date: Wed, 18 Oct 2000 13:24:42 +0100 (BST)

> Still I would say that a statement about the status of the different backends
> could help.

I am not the right person to make a general or definitive statement about
this question, but I might give you quite a good account of what the
current feeling about the question is.  Also, I am not really able to tell
you where and how you can better help to improve fonts in the backends -
Adam is certainly the best person to help you on that.

The backend situation is as follows:

{Xdps + DGS} will provide the full functionality.  Full postscript
support.

Xgps provides [now] a subset of that functionality.  Other backends (eg a
windows one) will also provide a subset of that functionality.

The reasons for having these backends with limited functionality are:

 * it is much more easier to write a backend without full postscript
   support.
   This is true both for the X backend (xgps is working *now*) and for
   future backends for other architectures.  We want to make a windows
   port possible and to have that we must make sure that writing a windows
   backend will be as easy as possible.  A windows backend will have
   (initially?) a 'limited functionality', the same way as xgps has.

 * it still makes a lot of sense to have a backend with only limited
   functionality simply because most gui applications don't need full
   postscript at all.  They usually use gui components and only the
   simplest postscript functions (mainly to draw lines, fill rectangles,
   paste images, copy areas).  The gui components themselves mainly
   use backend functions to:

    - draw lines
    - copy regions
    - draw text
    - fill rectangles
    - paste images

   so they work nicely with a limited backend, as soon as the backend
   implements these fundamental functions.

In the particular case of xgps, in order to minimize the effort, nearly
half of the backend code is shared between xgps and xdps.  This means
that, when working on the common half, improving xgps also means improving
xdps, and viceversa.  Only the strictly postscript drawing stuff is
different between the two, where xdps uses real postscript while xgps
emulates the simplest stuff with X lib calls.  Adam can certainly tell you
more about this.

The future of xgps is pretty unclear to me.



> > For xgps I think that our current solution will be good enough
> > until we switch over to use Pango (htttp://www.pango.org) in a few
> > years.

Ahm - I don't see how `Pango' could solve anything.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]