From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Fri May 24 2002 - 02:21:28 EDT
On Thu, 23 May 2002, Joaquin Cuenca Abela wrote:
> Hi Martin, Tomas!
>
> Martin, I've checked your latest suggestion about the
> Xft crash, and so far it seems as you're 100% right.
>
> I was trying to open the Xft font with a resolution of
> current_size * UT_LAYOUT_UNITS, and that, well,
> *explodes*.
>
> Yesterday I had a few minutes to fix my patch, but
> unfortunately I've not yet finished it (I hope to
> finally be able to it this afternoon after work).
>
> When I was seeing the use of the layout units, I come
> to the conclusion that they're used for, basically,
> get the linear metrics of the font currently used with
> high precision (and not the integer precision that
> will give us getAscender() et al). Is it right?
>
Right. The point is that printing is done at substantially higher
resolution than screen layout - it also substantially improves the
rounding error problems we have from lower resolution. The idea is to
scale the *Font* then get things like ascender/width at the high
resolution and do layout at the resolution for on screen calculations of
*height*.
We then use the same font size at layout resolution when we come to to
print. Because we use exactly the same font size for both on-screen and
printing we get the same number of lines per page. This actually works.
Unfortunately we can't do the same trick to layout text horizontally at
layout resolution.
The rounding errors associated with scaling the fonts back down to screen
resolution make the the widths of the text runs quite different to that at
layout resolsution. The text ends up looking really weird on-screen. There
are numerous cases of text runs overlapping each other.
> If so, what would you think of changing the current
> way that it's basically (if I've got everything
> right):
>
> 1) Ask for a font of a given family, size, etc.
> 2) Ask for the same font but with a new size of "size
> * UT_LAYOUT_UNITS"
> 3) Draw using the first font, do layout calculations
> using the metrics of the second font (scaling as
> need).
We do this for vertical positioning already. It doesn't work for
horizontal text positioning for the reasons I described above.
>
> To just:
>
> 1) Ask for a font of a given family, size, etc.
> 2) Draw using this font, and do layout calculations
> using the high precision metrics of this font (addint
> new getAscenderAsFloat(), getDescenderAsFloat(),
> etc... to GR_Graphics).
>
> That way we don't need to keep around the two fonts,
> code in gr_UnixGraphics is simplified (no more need to
> check for the size of the font before trying to
> open/explode the font), and the client code is also
> simplified (no need to duplicate the font, change the
> size, do all the calculations with layout units).
>
This could work but I suspect that we might run into problems printing and
zooming and maintaining the same number of lines per page at all
zooms and printing resolutions. Using the layout units as the base for
all calculatations really gives us a solid foundation.
> These thoughs are only for HEAD, of course. By now
> I'm just implementing Xft support using the current
> infrastructure.
>
> So do you see any obvious flaw in the above desing
> that I'm missing?
Yes :-( I tried to do this about 11 months ago. It doesn't work because
the fonts don't exactly scale. The only solution is subpixel addressing
and positioning ala pango - which is what Tomas is working on.
However it would be great to get anti-aliased and automatic font
finding going before then. It also sounds like this is the something
like what is needed for the full pango-powered layout on the gtk/gnome
side.
Maybe you, Dom and Tomas should talk about how you plan to evolve our
current unix font mess to a saner system based on freetype/config and
pango. I have the feeling that all three of you have designs in your
heads and/or code on your harddisks. Maybe you could converge on an agreed
design and delegate one person to actually do the work?
Cheers
Martin
This archive was generated by hypermail 2.1.4 : Fri May 24 2002 - 02:25:56 EDT