--- Tomas Frydrych <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
