Re: [Gnome-print] Pango and gnome-print
- From: Owen Taylor <otaylor redhat com>
- To: Lauris Kaplinski <lauris ximian com>
- Cc: Tony Graham <Tony Graham ireland sun com>, gnome-print ximian org
- Subject: Re: [Gnome-print] Pango and gnome-print
- Date: 17 Jun 2001 15:09:31 -0400
Lauris Kaplinski <lauris@ximian.com> writes:
> Hello!
>
> First, I am not sure, whether we are talking about the same thing,
> or not ;-)
> To have glyphlist-like entry point in gnome-print is must be
> for WYSIWYG work - where you have to deal with screen-printer
> (different resolutions) consistency.
> Aso of convenience entry points - that by definition are not
> WYSIWYG - yes, we can add pangolayout based method instead of text
> based one.
> It involves 2 things:
> a) Gnome-print has to supply Pango with font metrics for given
> printer. I do not know, how this is handled, but certainly
> it is possible, if pango can use correct metrics for certain
> screen resolution.
> b) Pango layout will be converted to glyphlists internally.
> Now this theoretically can produce crap in several cases - basically
> if final printer resolution is not known during printing. But as
> we are talking about convenience methods here, this is not
> too big problem. Serious apps have to use glyphlists anyways.
>
> 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. :-)
- You don't use the same PangoLayout for printing and screen
display - a PangoLayout is tied to a particular output
device.
- 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
- 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.
This isn't exactly perfect - cursors and selections boundaries
may be off by a few pixels, but its not bad and can be
refined.[1]
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.
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.)
Regards,
Owen
[1] The easiest refinement is to change this so the logical
metric for each glyph normally corresponds to the screen
metrics, but are adjusted so the total with of each word
is equal to the printer-metric width.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]