From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Fri May 24 2002 - 10:46:40 EDT
On Fri, 24 May 2002, Joaquin Cuenca Abela wrote:
>
> --- Martin Sevior <msevior@mccubbin.ph.unimelb.edu.au>
> wrote:
> >
> >
> > 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.
>
> Yup.
>
> Right now we rely in X default text drawing, or
> windows TextOut, that draws the beginning of the run
> at the specified x, y position, but it draws the
> others characters in the run using the x advance
> specified by the font used (at screen resolution).
>
> That's giving us non wysiwyg behaviour on the
> horizontal dimension, as for instance, Times New Roman
> 12points 'i' has an x advance of 3 points at screen
> resolution, but we need to use a x advance of 3.4xxx
> (or something). I.e. the linearly scaled x advance of
> Times New Roman 'i' character (value that will be used
> for printing, because printers have much better
> resolution).
>
> (so far, that's what we have, and that's what you have
> just explained, isn't it?)
Yes. This is exactly right.
>
> Ok, what if we had a way to decide the position of
> *each* individual characters, and not only run starts?
>
> That way we could track the x position of the pen in
> high precision coordinates (layout coordinates, if you
> want), and draw each character at the exact right x
> position (rounded to the nearest integer) that will we
> used in the printer.
>
> If we do it that way we should get no runs overlaps,
> only individual characters a bit too near or a bit too
> far, but overall we will get the right layout.
>
> Btw, that's how the MSWord is doing it. Type in word
> a bunch of 'i' in Times, and you will see that
> sometimes the interletter space is 3, and other times
> is 4. And they place the last 'i' in the exact right
> side of the page (and not at 2 inches away from the
> right side like us).
>
OK. Now I understand. We won't even lose in speed because we already have
to process each individual character because of remapGlyphs!
This is really cool.
> Others thing that we can gain with this method is
> kerning pairs on screen (word don't seems to have
> that, but TeX have had it for years).
>
Yay!
> Now, for the technical details...
>
> Xft2 has a call to specify the exact position of each
> character in a string (XftDrawGlyphSpec), and so has
> windows (ExtTextOutEx).
>
> The changes involved will be the use in the drawChars
> functions of these methods, and the use of layout
> units for horizontal layout (this time runs should not
> overlap because the rounding errors will be
> distributed between each character).
>
> To use kerning pairs, we will need some more changes,
> but we can leave it for later discussion. One thing
> at a time.
>
This is all very exciting and sounds like a major advance for X11 - but
what about other platforms?
> > > 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.
>
> take in account that I want to extract the *linear*
> metrics of the font. Ie, before the hinter touch the
> glyph, and before it's scaled down.
>
> I have this field in my debug code in Xft, and I'm
> seeing the right float value (as if it was with layout
> precision) extracted from a font at 12 points
> (freetype gives us this field).
>
Oh lovely - this is all freetype code?
> > > 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.
>
> pango doesn't do subpixel positioning afaik. It does
> the line/word breaking (for instance, for Thai that's
> far from trivial), and all kinds of i18n stuff, as
> replacing glyphs et al, but I think that we still have
> to do the fine positioning stuff ourselves.
>
OK
> > 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?
>
> agreed. What do you guys think about all this?
> What I currently have is a system that works... so
> well as the old code... mostly, but with full metrics
> information in my hand, without using custom
> configuration for fonts, and with antialiasing in new
> and old X servers.
>
> The big piece lacking to make abiword usable *WITHOUT*
> touching a single system font/configuration file is
> printing.
>
Do you still have problems with symbol or dingbat fonts? I Suspect your
problems might have been the non-standard encoding. To print these with
gnome-print I had to translate the Adobe encoding to unicode. This code is
all sitting in the xap_UnixGnomePrintGraphics.cpp If it's the unicode
translation problem you can just reuse this.
Regarding the printing Type 1 fonts - can we at least use those from the
old setup?
> This problem is much easier than before, because
> fontconfig gives us the metrics file of a give font,
> but we should still change the code to not rely on
> ttftools for TT fonts, and such stuff.
>
> Besides from that, I currently run my copy of AbiWord
> having rm -rf /usr/share/AbiSuite/fonts. (I don't
> even need to use the shell wrapper, but if I want the
> dictionary and such).
>
Can you print? This is very exciting stuff Joaquin :-)
> Cheers,
>
> P.S. I will drop abiword-dev from the CC list because
> my email will not hit the mailing list anyway (I'm not
> subscribed with this address). If somebody can
> forward it, it will be much appreciated.
>
Will do :-)
This archive was generated by hypermail 2.1.4 : Fri May 24 2002 - 10:51:07 EDT