[Gnome-print] Re: gnome font RFC quickie

[Liam Quin <liam holoweb net>]

Lauris Kaplinski wrote:
> 1. GnomeFontGroup
> 2. GnomeFontFamily
> 3. GnomeFontFace
> 4. GnomeFont
> 5. GnomeFontTransformed
> 
> 1. Serves for user grouping and managing fonts
> 
> 2. Is collection of related typefaces, mainly for easy managing
> 
> 3. Should be mostly hidden from user - it is raw font data holder - such
>    data, that can be embedded in object or sent to printer
> 
> 4. Is visually unscaled, but metrically scaled font. I.e. it has assigned
>    certain output resolution (in points). This is the most visible object
>    to user - and it is user responsibility to set correct output
>    resolution.

Where in here do I get the actual per-font metrics, as found in the
font file? Or will I have to write my own code to read an AFM file?

If the font bounding box is other than 1,000 units, how do I know that?

> I.e. if you want to layout page, it is best to scale font to desired
> resolution. All metric information will be adjusted to that resolution and
> although on-screen display may not be as nice as possible, output is
> guaranteed to be best.
I'm expecting to keep two sets of metrics, one for the printer and one
for the screen, and compensate for the differnences myself.  If a
library will do that for me that's fine, but I don't expect it.

I very much expect to keep track of the errors in character positioning.
For PostScript devices, that includes the PostScript positioning
roundoff error that you can see if you print a row of iiiiiiiiiiiiii at
various sizes, from 3pt up to 12pt, first positioned with a single
PsotScript show and then positioned individually using the metrics.

> If you plan to do some abrakadabra with font, such as nontrivial
> transforms, best scale it to some very big value. Then font uses
> internally metrics adjusted to infinity.
Most commercial systems use fixed-point numbers as far as I know.
The problem is that a 1/100th inch rounding error will make a word
of text touch a line, if you put text in a box.

> NB! metrics still look out unscaled to user (given for 1000 unit
> font). But these are adjusted to scale to integers in given size.
TrueType fonts are not restricted to a 1,000 unit font.
Actally type 1 fonts aren't either, but at least some versions of
ATM require 1000 units per em.

> 5. Is mostly needed by canvas item and print context implementations. This
>    manages glyph cache. From it you can also extract final metrics.
This looks OK.

[...]
> There should be something like GNOME_FONT_SCALE_AUTOMATIC,
> GNOME_FONT_SCALE_EXACT, GNOME_FONT_SCALE_INFINITY global parameter in
> library, so if once set to automatic or infinity, you do not need to
> bother about output resolution. Still for exact layouting purposes there
> is always a way set set this manually.
> AUTOMATIC - output library always uses metric adjusted to real output
> resolution. This gives best possible glyph/word lookout, but may distort
> lines/layout.
> INFINITY - output library uses sub-pixel positioning. Usable for
> antialiased display, either reduce readability of glyph shapes or
> distort inter-character distances. Layout stays always the same.

sub-pixel positioing is a display characteristic, and should not be
available only if you're ignoring the printer and display resolution.
Or maybe I'm tired, it's very hot here :-X

> I hope this will minimize user headache, still preserving possibility to
> do high-quality layout.

High-quality text is *difficult*, especially because the human eye is
very very sensitive to irregularities in spacing.  Although the conscious
resolution of the eye is only about 10^-4 radians (I don't know what that
translates to in distance on a page or screen at 18" distance), the eye
itself apeears to be more sensitive than that.

A 0.1pt change in letter spacing is quite visible.  That's not surprising
if you've ever looked ata "thou guage" for measuring sparkplug gaps.

Best,

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