--- Begin Message ---
|
Subject: |
[OpenType] Proposal for new line height calculation rules in OpenType fonts |
|
Date: |
Fri, 10 Feb 2006 10:42:02 -0800 |
OpenType list address: address@hidden
Hello everybody,
We are going to propose a solution for problems with defining text line
height that font and application developers experience on Windows
platform.
As you know, each OpenType font includes an OS/2 table defining two
groups of values for vertical font metrics. The first group is
sTypoAscender, sTypoDescender, and sTypoLineGap that were intended to be
used to calculate default line spacing. The second is usWinAscent and
usWinDescent, used to define glyph clipping areas. Unfortunately, it
historically happened that usWin values are actually used both by
applications for determining line height and by GDI for glyph clipping
at the same time.
Since these values are used for two different things, this obviously
causes problems. In most fonts (like normal Latin fonts), font
developers can set usWinAscent and usWinDescent values that produce
correct line spacing and clipping won't be a problem. But for some fonts
which have tall glyphs, like Cambria Math, Zapfino, or Bickham Script
Pro, the only way to avoid clipping is to specify very large
usWinAscent/Descent values. This will cause applications to have really
big line height - this is what you see, for example, if you select those
fonts in Notepad.
At the same time, fonts always had sTypoAscender/Descender/LineGap
values that were really intended for line spacing calculations. This
would be great if applications could switch to using typo values.
However, as usual, there is a backward compatibility problem. Also,
there are many fonts out in the world which do not have typo values set
correctly since those values were rarely used or tested under Windows.
So, the switch can not just happen automatically.
The solution we propose is to introduce a special compatibility flag in
the font, which will tell applications that sTypoAscent/Descent/LineGap
values are correct and can be used to calculate line height. Older fonts
that do not have such flag set will behave the same way as they did
before. New fonts that can have both sets of values work consistently
will not need the flag, so it is not required to have it set on all new
fonts or re-release already shipped fonts. This should solve both
backward compatibility and incorrect values problem.
The flag is defined in the fsSelection field of OS/2 table. There are
more benefits of this particular approach:
- The place for the flag had been chosen so there is no need
for any code change in Windows GDI. All values that are needed -
sTypoAscent, sTypoDescent, sTypoLineGap and fsSelection, are available
through existing GetOutlineTextMetrics function.
- Applications have full control over line height. They may use
the new logic or work in compatibility mode. Every application can
switch to the new behavior at its own pace.
- Since GDI is not changed, every older application will
continue to operate exactly the same as they do now.
- Since GDI is not changed, modified applications will work on
downlevel systems without any special change to the application or OS.
The proposed definition of the flag would be following:
Bit 7: UseTypoValues
Use the sTypoAscender and sTypoDescender and sTypoLineGap to
determine line height.
If bit 7 is set, then the line height will be determined by
sTypoLineGap + sTypoAscender + sTypoDescender.
Please let us know if you have any opinion on this.
Thank you,
Sergey
Subscribe: address@hidden
Unsubscribe: address@hidden
Set list to inactive: address@hidden
Set list to active: address@hidden
Message mode: address@hidden
Digest mode: address@hidden
--- End Message ---