Re: [Gnome-print] Pango and gnome-print

[Lauris Kaplinski <lauris ximian com>]

Hello!

On 01 Jun 2001 18:03:39 +0100, Tony Graham wrote:
> Owen Taylor otaylor@redhat.com wrote at 17 May 2001 10:51:46 -0400:
>  > (The details of how gnome-print will interact with Pango still have
>  > to be worked out, but the goal is certainly to use Pango as the
>  > text layout engine that positions glyphs for gnome-print.)
> 
> >From what I have read in the mail archives, I can't work out why Pango
> is being described as one day being used inside gnome-print as if
> Pango isn't being used by other programs.
> 
> An application that produces multi-page output and that wants page
> numbers and headings, etc., on each page is going to have to keep
> track of how much goes on each page.  If, for example, you wrote a
> internationalised version of pr that wraps input lines when they're
> too long to fit on one page, you'd have to count how many output lines
> were produced for each input line.
> 
> In the GTK+/GNOME world, an easy way to do that is to use Pango to
> layout the blocks of text, to keep track of the running total of the
> heights of the layouts added to the page, and to start a new page when
> adding a new layout will exceed the allowed vertical space on the
> page.
> 
> That's a simplistic example of using Pango, but it shows Pango used in 
> the application, not just in the print system.

Exactly. For any serious text-processing you certainly want to use
Pango/layout engines application-side.
The question is more about convenience frontends for printing short
labels and so on. It would make sense to have simple set of
gnome_print_xyz functions, outputting anything from single char to
single line.
Technically it would be:
rich text -> Pango -> Layout -> gnome-print -> ...
But it would probably make sense to have shorthand API, as long as
full version is still available for apps that care.

> The current answer is to use the glyph numbers in Pango's layouts in
> gnome-print's glyphlists, but in my experience the glyph numbers don't 
> exactly coincide, and nor do the available fonts.

Well, the font (together with font file image) has to be kept associated
with glyphlist anyways. Current font engine is opaque, but
I plan to open that in new gnome-print, using FreeType - so there will
always be 'official' glyph order of original font file(s).
Here again we may want to have some convenience frontend for simpler
cases - but in general we have to embed all font files into
print streams, unless we can guarantee exact font file version match.

> Lauris Kaplinski has twice proposed [1, 2] a Pango version or Pango
> implementation that generates glyph lists from rich text.  I would
> prefer to see a gnome-print implementation that accepts Pango layouts.

AFAIK current Pango layouts are not suitable for printing, as these are
adjusted for single output device. Printing has to deal with small
metric differences between different devices - but I agree, that this
can be solved in extended layout object.
Rich text == convenience methods (again ;)

> I'm probably splitting hairs, and it may be exactly what Lauris means, 
> but if your application is concerned with how much goes on the page,
> you just want to worry about the size of the text block, not how to
> translate that into terms that the print system understands.  Since
> Pango already has multiple rendering contexts, it would be useful if
> gnome-print didn't add another one.

Agreed. But we need rendering context, suitable for multi-resolution.

> Since I'm already indulging in uninvited speculation about future
> gnome-print APIs, it would also be useful if "gnome-print acting as
> lpr" (i.e. where the application isn't dealing with individual pages)
> could accept Pango-style markup for setting text attributes.

It should fit well with above.

In general - I am not myself big fan of rich text printing. But from
what I understand, there is need for such thing, to keep entry-level
printing API easy to use.
The alternative would be to work on general drawing API, that will
encapsulate rendering bot to screen and to gnome-print (something
a la Open2D). But other than ideas about adding print support to
canvas items, I do not know about progress in that direction. Here
too we want to keep application-side layouting hooks, but it can
take most layouting burden for simple cases.
But - until XRender is not ubiquitious, it will be major pain
to establish any screen-printer consistency here :(

Best wishes,
Lauris Kaplinski