[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: T1 font support in xgps
Re: T1 font support in xgps
Sun, 12 Nov 2000 14:25:59 +0100 (CET)
On Sat, 11 Nov 2000, Fred Kiefer wrote:
> I liked the way the anti alias displayed the big italic text (For the
> smaller point size, especially in the menus, I think the screen font I
> am using is better).
It probably is. What screenfont are you using by the way?
When I installed GNUstep it naturally decided to
use the XLib helvetica font. Unfortunately this font was
provided by the X Fontserver which in turn used T1 lib
to render the font.
> But more than that I like the way the icon fits
> into its background. Could you donate that icon back to the Ink
I mail it to you seperately.
> > The hard part however, is making the font system fit
> > with the rest of GNUstep. That is:
> > - Provide the T1 fonts to the GNUstep system.
> > - Map the names of the T1 fonts to names like `Helvetica' and back.
> > - Get all the font charactersitcs right.
> > - Make it possible to mix AA fonts and non AA fonts.
> > - Make it possible to use Xlib fonts and T1 fonts
> > at the same time.
> > Etc.
> As for your questions:
> It shouldn't be to hard to get decent names for the fonts and to find
> the font characteristics. Just have a look at the code in GSFontInfo and
> its two subclasses.
If have done that. What I was refering to was the fact that
the Helvetica font is not present on my system. However,
the Nimbus font is by the ghostscript system mapped
to Helvetica. The problem is that if I directly load
the Nimbus font it will only be known as the Nimbus.
The fix I made in order to demo the functionality was
to allow font name mapping. The way I have done
this is no more than a demo hack.
In general however we to provide to the AppKit user
some set of names which by the backend will be mapped
to either Xlib, T1 fonts or any other font system.
This asks for a flexible font mapping in the backend.
> It should be possible to reuse most of the code from
> AFMFontInfo. Or even better, we could try to move the Postscript font
> parsing and the AFMFontInfo up to the frontend.
I have not really looked into the AFMFontInfo. But I will.
Besides this raises a question: If we move this functionality up
to the frontend we end up having non-AppKit functionality in the
gui library. Perhaps there should be a small `utilities' layer
between the gui and the backend. This utilities layer
is part of the gui in a technical (linking) sense, but conceptually
Also, I never could made the xdps backend work. At least
it did not display any text. Are there instructions how
to use both backends? That is, that I globally can decide
which backend to use from now on.
This would make testing easier.
>What is left to do then
> is to make those two font implementation work in parallel, and I think
> this is the hardest part.
We agree on this. And for my this is essential to the question if
I want to add T1 font support.
It should be transparent, work out of the box on all systems
no need for user configuration, and if the user wants to configure
it it should be very easy!
> Perhaps we should, instead of hacking this somehow into the frontend,
> change the whole way fonts are handled by GNUstep.
I have not hacked it into the frontend. The only changes I have
made are to the backend. The reason that I referred to changes in
the frontend have to do with antialiasing.
Now somw parts of the frontend assumes that you can draw text
multiple times in the same spot without drawing the background.
Whith antialiasing this does not work the way you want.
> We could replace the
> font_cache, currently used only by the xgps backend, with a more general
> font_installer, that would be able to handle different font
> implementations. The backend than would have to select those of the
> installed fonts that belong to a supported type.
I did not think of that. But it seems a good idea to make the
font_installer THE application that will determine which fonts
are available and calculate all kind of redundant data.
Like creating an AFM dictionary for the xlib fonts.
Or am I now going to far?
One implication that should be considered is the runtime installation
of new fonts.
> The next problem is that of the display mechanism, currently text is
> shown by the graphics context directly, but to support different fonts
> in one backend, the rendering should be handed on to the font info, at
> least for the xgps backend.
Exactly my idea! Is already done in the Hack in a limited way.
> Those problems have to be solved first, before we can think of
> implementing anti aliasing for fonts in GNUstep. Having done this, we
> should be open for any font system.
Could not agree more! And that is why I want to make an inventarisation
of these issues with a proposal/discussion how to solve them BEFORE
I throw away the current demo and start a real implementation.