GnomeFont state of affairs
- From: Lauris Kaplinski <lauris kaplinski com>
- To: gnome-devel-list gnome org
- Cc: gnome-print helixcode com, miguel helixcode com,otaylor redhat com, liam holoweb net
- Subject: GnomeFont state of affairs
- Date: Fri, 16 Jun 2000 18:59:16 +0200 (CEST)
Hello fellows!
I have spent my last 1.5 weeks half coding, half thinking about portable
font library for Gnome. Now there is something like preliminary skeleton
in my hard drive, but before putting the thing up to CVS, I would like to
get another round of suggestions, is such thing needed, or not.
There are 3 main font API-s, that more or less intersect with my one.
FreeType - extremely powerful multi-format font library
GnomePrint font API - it is sufficent for small things
Pango/Gtk+ 1.4 font API - will be standard part of next Gtk+
Now my own reasoning for separate Gnome font API is following:
Gnome has some specific needs, which are not covered by low-level API -
such as font installing, font sharing in workgroups, font matching between
different output devices & so on.
At the same time I do not plan implement replacements for existing font
loading and rendering libraries, but instead embrace these to
consistent, portable and EASY TO USE wrapper. For maximum power there
should remain a way, to access underlying libraries and raw data directly.
FreeType is very powerful, but too hard to use for average application
programming. Still I think, keeping FreeType API available through
GnomeFont is one of priorities.
Gnome print font handling does not scale at moment to anything other than
latin encoded fonts, and extending it will result in something similar to
my project anyways.
Gtk+/Pango has a bit different emphasis, being interested in layouting
multilingual texts with given set of fonts. I do not believe, that
it would be good idea to build heavy things like network font services and
on-the-fly font conversion into Gtk+/Pango.
So the current .plan is following:
* GnomeFont has certain quite high-level, device and encoding independent
API for font grouping, selecting and accessing features of general
interest (like font name, supported languages etc.)
* It has a layer of more low-level glyph rendering functions, mostly to be
used in display and printing engines (rendering to raster devices,
outlines etc.)
* It either emulates (in case of Type1 fonts for example) or gives
transparent access (OT fonts) to all TrueType/OpenType features
* All rendering, metrics etc. are accessible in device independent,
typographically correct (scaled to master output device) or font system
internal way.
* All types are based on GtkObjects (GObjects), are opaque and can be
extended over network.
What has been done:
* Semi-complete object skeleton
* Preliminary freetype (freetype1 at moment) font wrapper
* Some portability wrapping (to get rid of TrueType platform dependance)
* TrueType -> libart outline conversion
I was capable seeing trueType iso-8859-1 character sets of all my TTF
files on GnomeCanvas this morning. It is almost nothing ;) but
nevertheless step to the direction of usability.
Lauris
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]