[cairo] Rounding bug in cairo_ft_font.c

[Owen Taylor]

On Sat, 2005-01-08 at 20:37 -0800, Keith Packard wrote:
> Around 22 o'clock on Jan 8, Owen Taylor wrote:
> 
> > Postscript can get away with device independent metrics because it's
> > only targeting the world of high resolution. And the very nature of
> > Postscript is that you've done your layout before generating the 
> > postscript file. I think we need metrics that take hinting into account.
> 
> I think you missed part of the earlier discussion...
> The metrics are reported in 'font space', but computed in pixel space 
> respecting all of the hints applied to the glyphs.

What I was actually getting at above is that Postscript's use of font
space may just be keeping it simple so that every font has a fixed
set of metrics. (Thing early 80's...) Which doesn't work for us.

> Part of that discussion also noted that having both 'hinted' and 'linear' 
> metrics visible to applications is probably a good idea so that DTP 
> applications can set text respecting linear glyph space at some 
> appropriate level.

I haven't gotten around to implementing it yet, but Pango will have
something along the lines of pango_cairo_context_set_linear_metrics(),
or pango_cairo_context_set_layout_method(). 

> > But even given device-adjustment, the font space convention doesn't
> > sound very convenient. If I'm trying to align some text, I want to
> > know how big it is in user space.
> 
> But the metrics we return are nonsense except in font space; you have no 
> basis for understanding what the 'height' means except as it relates to 
> the font transformation.

But for the case of a stretch, for a case of a shear, we do have a 
reasonable interpretation of what the metrics should be in user space.
And driving the API off of rotation doesn't make sense because setting
a font transform that is a rotation doesn't make sense. 

(Except for the special case of vertical layout, where there are lots
of other special factors.)

> > The Pango convention is user space with device adjustment; of course, 
> > in Pango, you are frequently getting metrics of mixtures of different
> > fonts in different sizes, so font space isn't even meaningful.
> 
> This is one reason why my weird 'scaled font space' works reasonably well; 
> for the usual scale-only font transform, you get sensible values for the 
> metrics and needn't translate between fonts differing only in size.

I'd suggest your 'scaled font space' works reasonably well only in so
far as that it is identical to 'user space' for the common cases.

> > Presumably, by far the most common case of non-scaling font transforms
> > is artificial oblique. Especially if we allow transforms out of
> > fonts.conf, I  don't see how we can get away without not adjusting the
> > metrics.
> 
> For artificial oblique, the character and line spacing doesn't (have to) 
> change, the only thing which does is the width of each character bounding 
> box.  And, shearing the bounding box gives an inaccurate (sometimes wildly 
> so) result.

I'm not sure offhand of whether the line spacing changes...it probably
depends on the details of how we extract the y_scale factor. If the 
x_scale/y_scale factor extraction is indeed area preserving, then that
implies the line spacing stays the same.

For the bounding box ... when someone asks for the ink rectangle for a
PangoLayout, the first requirement is that the rectangle I give them
actually bounds the rendered area. The bounding box of the sheared
bounding box does that. The unsheared bounding box doesn't. The only
thing that would be better than the sheared bounding box would be doing
an actual calculation of the bounding box of the transformed outline
pulled back to user space. 

(Implementation thought: FreeType can compute the bounding box of the
transformed outline in pixel space... after all, it needs it to figure
out what to render for the glyph. And the *common* case is that 
pixel space and user space differ only by a scale. A dead-slow path
for the general case is probably fine.)

(Implementation thought 2: currently Pango makes the assumption that
when hinting off, and no font transform, the bounding box of the
rendered area in user space is simply the bounding box of the
untransformed outline scaled by the font size. That's not strictly
true. But close. Doing better is tricky because the bounding box
of the rendered pixels isn't position invariant.)

>   We could just leave this to the PostScript model and let 
> applications compute bound boxes by measuring the path of the glyphs...

Get a bounding box for the rendered area for text is a really
fundamental. The only way we can punt on this is if we simply outlaw
artificial oblique.

Regards,
					Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050109/baad72d3/attachment.pgp