Re: gnome font RFC II

[Liam Quin <liam holoweb net>]

I started writing up some stuff at
http://www.holoweb.net/~liam/glayout/fontservices.html
although it's very incomplete right now.

> 2 - font selection
> There will be several pre-defined groups, such as:
>   Latin-Renaissance
>   Latin-Baroque
>   etc.
Maybe used established names, e.g. see Robert Bringhurst's book
on typography.

> Also, users can create and reorder groups
and delete them too? :-)

Users also need to be able to deactivate fonts -- i.e. remove them from
the font chooser -- without uninstalling them.
Then you can install a font group "xxx project" while you work on that
project, and uninstall it later.  A font in more than one group gets
removed from the font chooser dialogue box only when no active font
group contains it.

> Methods so far:
> 
[...]
> Returns list of group names, covering given language (at least one font in
> group should cover it)
and NULL returns all?

Some languages can be written with more than one script -- e.g. Japanese,
Malaysian, Irish Gaelic -- so there are different font sets for the same
language.  And a given script can handle more than one language.

The font group should probably be by glyph coverage, not by language,
or by both script and language.

> It is completely gnome font responsibility to construct families from
> different font files/formats.
OK, but users may need to help out here.
There's no obvious way for software to associate
    Celestia Italic
    Celestia Ornaments
    Celestia Antiqua
    Celestia Semibold
with each other correctly.

> const GSList * gnome_font_group_get_families (GnomeFontgroup * group, ...)
> Return list, which has to be copied, if not consumed immediately (like
> group list)
Is this thread safe? Why doesn't it use gmalloc?

[...]

> Now, current implementation uses GnomeFont for sized font, and
> GnomeFontMap for unsized one. Unfortunately sized font can mean two mostly
> different things:
> a - font sized to given final output resolution - which means specific,
>   usually integer metrics, adjusted glyph shape & so on
> b - font sized to given userland units. This is relative size and does not
>   have any connection to real glyph rendering

I suggest (b) is actually an unsized font.

> For (a) I would implement separate class GnomeFontTransformed (as scaling
> has not to be uniform).
This is also OK.  There are some devices that have non-linear font
scaling (e.g. "m" gets wider as you get smaller, to account for optical
effects) but I don't know if any are in widespread use today.  I doubt it.

> Implementing (b) depends, how the connection with output resolution is
> established in user API. As I currently tend to prefer infinite output
> resolution, b is simply double number, kept in font structure.
It's *much* better to keep a specific resolution, e.g. millipoints.
Any program trying to display "WYSIWYG"-style printer preview on the
screen needs to keep track of the exact rounding error between printer
and font metrics, and will need to do so in integer units.

Hence, I suggest
typedef long g_millipoints;

> Almost everyone has got angry, if MSWord has reformatted pages after
> changing printer. Unfortunately this is almost the right thing to do - as
> exact font metrics depend on output resolution.

It's 100% unacceptable for a page layout program.  If you go this way,
I won't be able to use gnome-font very easily.

TrueType fonts *do* format differently for different resolutions, and
therefore I don't mind if the user has to specify the output device.

> Still using desired output resolution is mostly impossible in networked
> environment.
Windows does it.  If necessary, have  "desired output resolution" button.

> Still, mentioned subsystems (canvasitems and print contexts) should take
> resolution into account internally, adjusting whitespaces between
> words. This can produce undesirable artefacts sometimes, but hopefully
> will work well most times.
See the web page at 
http://www.holoweb.net/~liam/glayout/fontsandprinting.html
for notes on why this isn't OK.  I've written drivers for typesetters
and for laser pritners and for low-resolution screens, and can say
that the no, this approach doesn't work well enough for good quality work.

> I hope that:
> - anyone doing real layout, is using >1200dpi printers
Coach House Press in Toronto (a well-known Fine Press) uses 600 and 800 dpi
laser printers for most work -- only very rarely do they break out the
film machines (up to 2450dpi as I recall) these days.

>   resolution can be considered infinite with minimal distorts
This isn't true in practice.  For example, in a font like courier,
a 0.1 inch error across a page is not uncommon if you ignore the
rounding errors.  I've measured it.  This means text in a box looks
like crap.  I don't want gnome printing to look like crap.

> - for on-screen preview it is always possible to request full antialiased
>   display (which gives correct overall impression, although is more
>   difficult to read)
Not everyone wants their terminal to be hard to read; this also doesn't
work too well on an 8-bit display, and not at all on a 1-bit display.

Lee

-- 
Liam Quin - Barefoot in Toronto - liam@holoweb.net - http://www.holoweb.net/
Ankh on irc.sorcery.net http://valinor.sorcery.net/
Co-author, The XML Specification Guide, Wiley, 1999
Forthcoming: The Open Source XML Database Toolkit