Re: [Gnome-print] Re: gnome font RFC II

[Lauris Kaplinski <lauris kaplinski com>]

On Sat, 10 Jun 2000, Liam Quin wrote:

> 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? :-)

These will go to font-installation API one time ;) - whatever method Gnome
evetually chooses for it.

> 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.

The language parameter should be quite extended, if necessary. Still it is
not reasonable to build language->coverage mapping into every userland
program - and user exactly want to write text in given language.
As of languages with different scripts - these scripts can be either:
- visible as font subtypes (roman and italic are different scripts too)
- accessible as language extension
"en", "en_US", "pt", "iso-8859-1", "latin" select all fonts with standard
latin glyphs
"ja" will select fonts with either hiragana or katakana available.
"ja:xxx" will select font with given script
Is this reasonable?

> > 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.

This is also font installation issue - and user, of course, should be able
to intercept it in many ways.
Still - for most well-known fonts we can ship font database, doing just
such kind of mapping.

> 
> > 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?

No. But I do not know any good reason thread-safe font selection is needed
in userland library. You usually do not have 2 font selection dialogs for
same programs, running as different threads. And font servers, renderers
and similar processes do not need these functions - or implement these in
different way at all. These are solely for font convenient font browsing.
I bet, requiring user to free lists results in more memory leaks. But this
is debatable. We can require user to do g_slist_free.

> [...]
> 
> > 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;

I cannot see, why you need to use integers here.
You need to know exact placement of every char (word) in printer units -
these are integers - yes. Now, given screen resolution and zooming factor
these are transformed to floats.
Either:
- use antialiasing, and do exact placement of display chars
- use rounded placement per char or per word
In both cases the layout calculations are done in printer units anyway.

> > 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.

Yeah - but you DO change output resolution in given case (changing printer
in MSWord). So the behaviour still is correct, I think. What is wrong, is
that you cannot fix output resolution manually, so it is not changed every
time, you switch printer.

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

Seems OK idea.

> > 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.

What about a call:

gnome_font_scalefont (font, xscale, yscale)

Which sets fonts internal pointsize. The results DO NOT affect
outline/glyph size - these are changed by canvas affine transforms /
gnome-print concat operator, but force font to use metrics adjusted for
given resolution.

So vector illustration program can safely set font scale to 1000, and get
unsized metrics for both display and print. Page layout program (which
does not need unusual font transforming) can scale it to exact size.

The only problem will be badly designed programs, doing for example:
gnome_font_scalefont (font, 6, 6)
gnome_print_scale (pc, 10, 10)
gnome_print_setfont (pc, font)
gnome_print_show (pc, "uglytext")
In which case they get 60pt result with 6pt adjusted metrics.
This problem appears every time, somebody scales embedded bonobo
component.

> > - 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.

You cannot get all things right unfortunately ;(
Either:
- printed output is ugly (using spacing not adjusted to output resolution)
- screen display is ugly (using spacing adjusted for output resolution)
- you have to do antialiasing
I simply cannot see a way to get over that :( - other than forbiding user
zooming their display, so pixel/point ratio is always 1 :)

Lauris