From: Joaquin Cuenca Abela (e98cuenc@yahoo.com)
Date: Tue May 28 2002 - 12:21:16 EDT
--- Tomas Frydrych <tomas@frydrych.uklinux.net> wrote:
>
> Hi Joaquin,
>
> > Ie, the non-linear scaling factor introduced by
> grid-fitting is only due
> > to rounding errors (visible when we pass from
> high-resolution to
> > low-resolution).
> >
> > The non-scaling factor that you're speaking about
> here is due to the
> > changes that each glyph suffers when it goes from
> a high size to a low
> > size, even when you keep it at high resolution
> (usually making the
> > characters wider to make them more easily
> readable).
>
> I am no expert on these things at all, but Leonard
> is,
neither me. I'm more than eager to ear Leonard
advices here.
> so it is worth
> seeking his comments on whatever way we decide to
> handle this. I
> have struggled with this whole problem on Win32
> about 6 months
> back, and I have observed then that the
> discrepancies between the
> layout and screen metrics cannot be explained as the
> result of
> rounding errors, the differences are way to big and
> vary from glyph
> to glyph -- they can only be reasonably explained as
> the result of
> seriously non-linear scaling of the glyphs widths
> according to a non-
> linear algorithm which is built into the font.
I will try to explain what's happening here.
Font shapes suffer 2 conceptually different
transformations when they go from the
high-resolution/"high-size" position to the
low-resolution/"low-size" position
(size as in physical size.)
The scaling from the "high-size" to the "low-size"
(say 12 points) has nothing to do with the resolution
that we'll use in the device. It's a non-linear
scaling that typographers do to make the font more
readable at tiny sizes (making the font relatively
wider at low physical sizes). That way, for instance,
the "m" get the steams clearly readable even at low
sizes.
So the metrics for a font at 12points can be (will be)
different from the metrics of the same font at
240points.
Now, once you have the font at 12points, you still
have to render it to your device. In a
high-resolution printer that's usually not a problem,
because you've high enough resolution (it's still a
problem for cheap printers will low resolution).
In your screen, things are different. The font have
to be grid-fitted to a low resolution device, and that
creates artifacts, that good hinted fonts should
remove.
When doing that, some fonts glyphs will not scale
linearly from the high-resolution space to the
low-resolution space.
Why?
For instace, take the 'i' letter in Times New Roman.
At 12points the linearly scaled size of this font
would be of 4pixels, having a central steam of 2
pixels. But others letters of the same font at the
same size (say the 'm') will have stems of only 1
pixel when linearly scaled. So the 'i' glyph is
reduced to only 3pixels to keep consistent with other
glyphs of the same font/size.
I think that this later non-linear factor is not very
important. For instance monotype take special care to
not have letters wider than the linearly scaled size,
except for some extreme cases as 'w' and 'm' (and most
of the time they are only 1 pixel wider than the
linearly scaled version).
So I think that if we the current plan (ie, get
metrics at high-resolution, use these metrics to place
individual characters, instead of using the default
scapements), we will become WYSIWYG (except on low
resolution printers).
> > I was only speaking, as you point out, of the
> metrics extracted from the
> > font at 12 points (ie, the real physical size) at
> high resolution,
> > scaled down to the resolution of the screen.
>
> OK, I misunderstood that. That's what I have been on
> about.
>
> > > The real answer to our problem is _not_ to
> request fonts at
> > > incorrect physical sizes as we do at moment.
> Instead of scaling
> > > the physical font size from say 12 to 240 points
> (72 -> 1440 dpi)
> > > we have to request a font of 12 points but tell
> the rasterizer to apply
> > > a transform of 1 point to 20 device uints. With
> FreeType this is
> > > done by call to FT_Set_Transform(). I think if
> we do this then we
> > > will not need to advance by characters to fix
> this
> >
> > I don't understand that. Why that will help us to
> draw each character
> > at the right position?
>
> I can only speak for the win32 situation, but there
> the regular calls
> to the drawing API draw the characters at the right
> position as the
> font author intended.
Yes, but they draw the characters at the right
position calculated using the low-resolution metrics,
not the high-resolution metrics.
Try running wordpad and word side by side, and type a
row of iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii in both of
them.
You will see that wordpad draws using the default
scapement (3 pixels), and word will draw using the
linearly scaled (from high-resolution to
low-resolution) scapement, ie something between 4 and
5 (some 'i' will have an interletter space of 4
pixels, and some 5).
Does it sounds as if I'm on crack, or does it sounds
more or less logic?
Cheers,
=====
Joaquin Cuenca Abela
e98cuenc@yahoo.com
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
This archive was generated by hypermail 2.1.4 : Tue May 28 2002 - 12:26:04 EDT