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

[Lauris Kaplinski <lauris kaplinski com>]

On Sat, 10 Jun 2000, Liam Quin wrote:

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

Scaling font to 12 gives you 12 pt font metrics. Scaling it to infinity
gives you unsized font metrics. The idea is that every GnomeFont has one
master resolution. If you need 2-nd different master resolution
(i.e. want to do write hand-tuned display procedures, request 2-nd copy of
same face and scale it to required display resolution.)
What really bothers me is question, whether 12pt font metrics differ on
300, 600 and 1200 dpi laser printers. If they do (as they should), font
scaling has to be interpreted as pixel, not point scaling. So scaling font
to 100 units?, gives metrics for 24pt font on 300dpi, but 12pt font on
600dpi.
If even this is not sufficent and we should take into account per-printer
metrics, then I find better to leave high-end font handling out of
library - if somebody do not suggest me a good and portable way to specify
such per-printer metrics.

There should be usual set of real metric/shape/bbox extracting
routines. 1000 unit is only convention, so
  bpath = gnome_font_glyph_get_bpath (glyph)
  art_affine_scale (affine, 12/1000, 12/1000)
  bpath2 = art_bpath_affine_transform (bpath, affine)
Gives you 12 unit font outline
1000 unit is PS convention. It can as well be 1x1 or 12x12 or 256x256, but
I better would leave it so.

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

Plan is following:
If you need to do screen layout by hand, request 2 fonts for same face -
one scaled to printer units, other to screen units.
At the same time, most Gnome screen handling routines (mostly canvas text
creation) should free you from doing that as much, as possible. Note that
canvas items are designed display independent way, so it should be their
responsibility, to choose right font metrics. Also - display fonts tend to
change quickly (change zoom) - while printer ones stay more constant. So
it is reasonable to let choosing right thing to library, possibly adding
hint-like parameters.
Still, your mentioned behaviour should be accessible, using EXACT hint /
manual glyph positioning.

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

I would just scale everything to 1000.0 1000.0 em square (floating
point) in unsized fonts. It should make no difference, as sized variants
would be integers anyway.

> [...]
> > 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 to get something like skeleton to CVS soon. The we can start
rewriting it :)

Best wishes,
Lauris