[Gnome-print] Device independent string output

[Lauris Kaplinski <lauris kaplinski com>]

Hello

I have thought about formatting device-independent output strings to be
fed to gnome-print/gnome-canvas recently.

Problem: We have laid out text (possibly for certain printer), which we
want to output with maximum possible quality on given device (other
printer, print preview, editable canvas, etc.), at the same time keeping
all relevant layout. So how should the (logic of) layout look like?

Possible solutions:

1. Using trivial layout, like
  (abc def ghi jkl) show
do not work, as font metrics differ, depending on output resolution. So
resulting lines will have different lengths. It is also near to impossible
to encode scripts for many languages in such straightforward way.

2. Using
  (abc) show x1 y1 moveto (def) show x2 y2 moveto...
usually gives good result for roman languages, but all advanced
positioning techinques, like kerning, letterspacing etc. are near
impossible to achieve. Also, for languages with complex glyph positioning
rules, words cannot be encoded in simple straightforward way.

3. using trivial glyph positioning, such as
x1 y1 moveto (a) show x2 y2 moveto (b) show...
does disturb font native interglyph positions, so depending on output
resolution some glyphs can be too close, some too far from themselves

4. Encode unicode text and layouting rules (such as textbox dimensions)
together with text and ask Pango to lay text out for every single device.
This has 2 shortcomings:
- There has to be 2 sets of font metrics accessible to Pango (master
metrics and real device metrics) plus additional rules about which to
prefer on which occasion (how much distorting from master layout is
acceptable)
- Exact versions of Pango language engines should be encoded together with
text - at least, if we want to make such laid out text exportable.

I propose following solution:

Develop ultra-light glyph positioning language, capable of
- specifying font, size and master resolution
- specifying certain set of font subtypes, such as horisontal/versus
  vertical metric sets
- specifying currentpoint positioning both absolute and relative terms
- extracting certain set of portable metric information from font
- trivial set of standard operators
Such language is encoded together with glyph and font pointers into
glyphlist like structures, which are sent to output.

Little example - rendered string "A.T", using kerning, can look out
something like (language syntax is arbitrary)

(Helvetica 12 300 300) setfont
uselrdirection
usehmetrics
100 100 moveto
(A) show
stdadvance_rmoveto
currentpoint_push
(A.) kerning_adjust
(.) show
stdadvance_rmoveto
max_horizontal_position
(T) show
...

Some niceties:
If exact positioning, not logically related to some easily extractable
font metrics, is required, we can use absolute or relative full
(x,y) positioning - like PangoGlyphString is doing now
The most trivial latin case is also straightforward: glyph, stdadvance -
glyph, stdadvance...
We can add position anchors to every point of line - usually it should be
reasonable to add these to beginning of each word
If we want to do real antialiased layout, it is still possible - just use
master or unsized font metrics, instead of device specific ones.
The example "program" is quite long, but can be easily encoded into list,
not taking much more space, than trivial x,y,glyph -> x,y,glyph case
Still - this is NOT layouting language. It cannot add anything more to
existing word/glyph/line positioning other than keeping inter-glyph
distances as consistent as possible with font design.
It is halfway between {(abcdefghij) show} and full pango layouting,
addressing very special problem of multi-resolution management - and
freeing pango from the need of multi-resolution handling IMHO. Remember
that dual-resolution is needed in rare cases (high-quality typesetting
program), but then it is must.

I believe the resulting "instruction set" to be quite small - but cannot
be sure yet - how compact and powerful it can be.

Flames?

Lauris