Re: Pango documentation & a few questions

[Owen Taylor <otaylor redhat com>]

Patrick <pabos glypsube org> writes:

> > -----
> > QUOTE:
> > -----
> > "
> > PANGO_SCALE
> > 
> > #define PANGO_SCALE 1024
> > 
> > The PANGO_SCALE macro represents the scale between dimensions used for
> > Pango distances and device units. (The definition of device units is
> > dependent on the output device; it will typically be pixels for a
> > screen, and points for a printer.) PANGO_SCALE is currently 1000, but
> > this may be changed in the future.

It did change to be 1024...

> > When setting font sizes, device units are always considered to be points
> > (as in "12 point font"), rather than pixels.

> > The PangoGlyphUnit type is used to store dimensions within Pango.
> > Dimensions are stored in 1/64ths of a point. 

You managed to find an even older piece of docs ... I don't remember
using 1/64th, before 1/1000, but I guess I did at one point.

> > ----
> > DOES THIS MEAN ....
> > ----
> > 1pt = 1/72 inch
> > 1/72/64 = 1/4608 inch per Pango dimension unit
> > 
> > to find device units multiply by PANGO_SCALE:
> > 1/4608 * 1024 = 1/4.5 pixel per Pango dimension unit (for a screen)
> > 1/4608 * 1024 = 1/4.5 points per Pango dimension unit (for a printer)

No, you are reading far too much into the docs here. :-)

Pango units are 1/PANGO_SCALE of a device unit; device units are pixels
on the the screen, and possibly postscript points for a postscript
backend (though we don't have such a critter at the moment). PANGO_SCALE 
is 1024 and unlikely to further change.

[...]

> > My guess is that it is only used in the high-level functions of Pango
> > where layout x,y arguments are passed in the form of device coordinates.
> > If this is the case, using any function lower-than PangoLayout should
> > avoid PANGO_SCALE right? In particular, if pango_shape is called, it
> > will be using the currently set rendering method to do the shaping. Is
> > this shaping process independent of PANGO_SCALE?

Pango units are used universally throughout Pango for all dimensions
except for  a few convenience functions that have _pixels in the name. 
And a few device specific rendering functions like 
pango_x_render_layout.

> > I'm still grokking all of the factors influencing WYSIWYG and typography
> > terms in general so may I missing something, but I'm not understanding
> > why it would be beneficial to define the meaning of a device unit
> > differently for a screen or a printer. You could convert between the two
> > if the resolution of the screen is known but why wouldn't you want to
> > keep everything in physical units (ie. 1/4608 of an inch) instead and
> > only convert to device units as a final step (on the application's side
> > away from Pango)? This seems like it only needlessly complicates the
> > relationship between a screen and a printer. I'd like to make a canvas
> > that does everything in terms of physical units and only converts when
> > appropriate to the final display device units. After all, doesn't it
> > make sense to treat printers and screens in the same manner - ie. as
> > devices which can handle a certain colourspace, with a certain horz and
> > vert resolution, which ultimately rasterize everything to pixels/dots?

PANGO_SCALE is there to enable sub-pixel positioning without using
floating point; it has nothing to do with phyisical dimensions vs.
device units. The choice of the "device unit" is up to the particular 
Pango backend.

The reason you probably would want to use postscript points rather 
than pixels as the device unit when rendering to a postscript backend
is that postscript code is (somewhat) device independent and all
positioning in postscript is done in postscript points. You might
know the resolution of the printer; the resolution of the printer
might be different depending on the output mode, you might be
writing out a file to be sent elsewhere.

Regards,
                                        Owen