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

[Lauris Kaplinski <lauris ximian com>]

Hello Owen!

On 17 Jun 2001 15:09:31 -0400, Owen Taylor wrote:
> > I'll outline the problem with pangolayout one more time.
> > In pangolayout each glyph has fixed coordinates. So it is
> > terribly sensitive about real output resolution - if the one
> > used for metrics and actual one mismatch, you will possibly get
> > ugly visible artefacts in text (imagine word 'lill' in small
> > font, where all 3 inter-glyph distances are not equal).
> > But very probably there are plenty of situations, where the actual
> > output resolution is not known during job creation. So some
> > reasonable default (600dpi) should be used. Glyphlists
> > try to push final glyph placement into further stage of
> > pipeline, where there is more chance, that resolution is settled.
> > With Pangolayout, you risk with artefact from the first stage.
> 
> You persist in making this too hard. :-)

I do not think so. Read ahead [2].

>  - You don't use the same PangoLayout for printing and screen
>    display - a PangoLayout is tied to a particular output
>    device.

OK...

>  - When you create a layout that you want to display on the 
>    screen with line breaks the same as the printer, you 
>    store both resolutions in the PangoContext

Even better...

>  - The gnome-print shaper reports logical metrics based on
>    the printer resolution, so line breaks come out right,
>    but positions glyphs with the screen resolution, so
>    your inter-glyph spacing is preserved too.
> /.../
> The point is, to deal with changes in resolution, _don't_
> try and use a fancy scheme for adjusting your already
> positioned text, simply relayout.
> 
> Layout must be fast for interactive applications, so worrying 
> about performance when moving from one device to another
> just isn't worth it.  
> 
> Yes, this does mean that your layout has to be done at the
> point where you know your output device. 

Well, here lies the problem [2] - but - it is actually not relevant
to current discussion [1].

> PangoLayout wasn't designed for PDF style applications, where 
> you try to get exactly the same line breaks without knowing your 
> output resolution, or the set of available fonts. I don't
> see this particularly mattering.
> 
> (To the extent it does matter, it matters most for rendering to
> PDF. AFAIK, PDF doesn't have any sort of programmatic glyph-list
> idea. It just positions stuff for a fixed target resolution.)

I do not know much about PDF, but PostScript certainly has [3] ;-)

OK. I'll explain.

[1] IMHO the current discussion was about frontend - which format to 
use, so people can print fully internationalized text with (very)
good quality, without major pain.
I originally thought it could be some rich text format, probaly
fed line-by-line, and gnome-print would use Pango library to layout it. 
I was pointed, that it is potentially still too fuzzy.
So discussion arised, whether to feed PangoLayout to frontend, and
I was quite against it, for reasons you already mentioned
[PangoLayout wasn't designed for PDF style applications...]
I have not followed Pango development, but from what you describe,
PnagoContext is the thing needed. Needed for no-pain frontend to
printing text from most gnome apps.

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

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

Best wishes,
Lauris Kaplinski