No Subject

 PangoContext *context = gnome_print_get_pango_context (gp_context);
 PangoLayout *layout = pango_layout_new (context);

 pango_layout_set_markup (layout, "Some <i>italic</i> text", -1);
 pango_layout_set_width (5 * 72 * PANGO_SCALE); /* 5 inches */

 gnome_print_moveto (x, y);
 gnome_print_show_pango_layout (gp_context, layout); 

Now clearly, this API does in fact have problems with adjusting for
resolution occur if we don't have information about the target device:

 - We are sending to a remote printer and don't have enough
   information about that printer to know the exact metrics.

 - We are rendering to PDF

 - We are rendering to a gnome-print metafile for some reason.

I'm not sure these problems are as bad as you think - there are a lot
of other things to worry about fixing before we go from "good enough"
text rendering to "make type freaks happy" text rendering. (And if you
don't know your target device, your output is going to suffer, at
least to some extent.) But certainly, they would be good to avoid if
possible.

One possibility for the last is to serialize the PangoLayout and
restore it at the other end as another PangoLayout. This is
straightforward enough. However, it doesn't help with PS or PDF, and
you'd have to pass metrics information for your font to make sure that
the layout on the other end matched the original layout in line breaks
and overall extents. Finally, PangoLayout doesn't cover all layout
possibilities with Pango. So, we'll ignore that.

So, yes, if we aren't going to accept simple glyph positioning, then
we probably need some mechanism like your glyph lists.

> [2] Completely different story is, what happens inside gnome-print.
> I'll stick here with GlyphLists for several reasons:
> 1) PangoLayout can be translated to glyphlists without pain
> 2) Glyphlists can be translated to positioned glyphs without pain
> 3) Glyphlists allow producing decent layout in complex cases - like
>    if we do not know exact printer font metrics - if properly built.
> 4) Last but not least. Applications may want to implement their
>    own text layout (either private pango engine, or something
>    completely different). So one cannot rely, that the same layouting
>    engine is present during final print stage - unless we include
>    loads of ugly callback hooks into gnome-print.
> But well, it does not affect anybody, unless he/she has some very
> specific printing needs, that cannot be done by distributed
> layout libraries.

The obvious question here is how GlyphLists relate to Pango.
Currently, 1) is not true - PangoLayout's can only be 
converted to a collection of PangoGlyphString, a much simpler
representation. (Each glyph has a x and a y offset, and an
advance width.) 

But simply switching over to your glyphlist representation
is not an option:

 - It's more complex than is useful for simple font formats, like X
   fonts; making shapers harder to write, and layout operations
   slower.

 - It is insufficient for OpenType, which is our targeted font format
   of the future. For instance, a common and useful positioning
   operation in OpenType is to position one glyph with respect to a
   hinted control point of another glyph.
   
One somewhat reasonable thing to consider for the future is
to consider virtualizing PangoGlyphString and making it
specific to a particular rendering system. 

Currently, PangoGlyphString is not opaque, and a lot of code
in PangoLayout accesses and modifies it directly, but the
actual set of operations needed on the glyph string is not
all that large - basically:

 1) Getting the extents of the string
 2) Figuring out the logical positions for characters in the input 
    stream within the glyph string

Unfortunately, we don't have time to experiment with that at
this point before Pango-1.0.
 
> [3] Glyphlist vs. positioned rendering in PostScript is
> 
>   show vs. xyshow
> 
> As much as I have spoken with printing professionals, using
> xyshow is bad bad - unless you know exact printer font metrics
> - scaled and grid-fitted for given final output size. In case of
> printers with Type1/TTF and bitmap versions of the same font, it
> involves lots of ugliness. The ultimate printing applications have
> to deal with that ugliness, but there is quite big room between
> trivial ones and HQ printing press utilities IMHO.
> 
> The real solution should be something like:
> 
> (word0) show x0 y0 moveto (word2) show x1 y1 moveto ...
> 
> That can be achieved with glyphlists.
> Of course, PS sucks heavily for any complex language. But having
> really good font (with all ligatures, forms and different kashidas)
> it should translate to arabic, for example, well.

Arabic is a _quite_ complex typographically, potentially going well
beyond the capabilities of glyphlist or postscript.

One of the primary uses of positioning against control points is to
handle the calligraphic style of Arabic script used for Urdu, which
has a slanted baseline - each word drops down from right to left.

Regards,
                                        Owen