By applying italics before outline, not after, and slanting italics
characters from the bottom up instead of top down, I now get pixel
perfect rendering for my experimental About dialogs for Loom and Indiana
Jones and the Last Crusade.
Judging by the experiments I made in a Mac emulator, condensed and
extended slant simply decreases and increases the glyph width by one.
You'd think it would depend on the font size, but apparently not. It is
possible to use both condensed and extended slant at the same time, and
it's just as useless as it sounds.
We have to take into consideration that text can use any combination of
slants. Otherwise, glyphs may spill into memory used for other glyphs.
This was probably only an issue when the glyph storage crossed the
boundary from one byte length into another.
QuickDraw appears to simply draw the character once normally and once
shifted one pixel to the right. This was perhaps most noticeable on
small characters with lots of edges. (I noticed it first on "W" in
Geneva 9.)
Memory leak happened because the scaled generated fonts were not
being cached or saved anywhere, thus they were not being destructed
and freed. Added logic to cache generated font in _winFontRegistry
itself.
Leaks observed in `trektech-win` of director engine in first few frames itself.
Instead of doing bbox-to-bbox scales, fill pixels based on distance to a reference coordinate, which ensures the same rounding behavior at each scanline.
Allow scaling of window font, ie FON, FNT. Internally this uses
same implementation as BDFScaling and MacFontScaling. Uses function
scaleSingleGlyph to scale each glyph.
Fonts in `mcluhan-win` used some of these fonts where the sizes
were different than parsed.
leading of a font is added to the height of the font when returning font
height, additionally the definition of leading says:
`Alternatively called line spacing, leading is the space between lines`
This fixes alignment of texts in `warlock-100` while also fixing the
line heights in `theapartment`.
- The primary change is to fix or improve the scaling of BDF fonts
- Now uses the same approach as in MacFonts scaling that is creating another surface and refactor it with a grayscalemap
- Bugs - there are still some problems when testing in capital letters
- The refactoring code for MacFont that magnifies the font on a surface and then uses a grayscalemap to refactor the scaling, is pushed back into a resuable method in the base font class.
- surface magnigy funtion transfer and scaleSingleGlyph method add to the font class.
The leading value in Macintosh fonts is the space between lines,
defined as the space between a descent line and the ascent line
below it. Clients need this to draw text and calculate its height
as classic Macintosh did.
MacFontManager didn't have a mechanism to report which fonts it loaded
from an external resource. It also requires that any fonts that aren't
built-in be explicitly registered by name by the client before they can
be used. This combination meant that a client couldn't load fonts from
an external file and use them by their properties (id / size / style).
SCI contains Mac fonts in its executable along with a table that maps
each SCI font id to a Mac font id and size. The font name isn't a part
of this since the Classic Mac Toolbox API took id / size / style as
input when drawing text.
Now MacFontManager exposes the font families it has loaded along with
their names. This allows a client to see which fonts were loaded,
register them by name, and proceed to use them with the existing API.
Surface::create already initialized memory to 0 and getPixels can be
nullptr if bitmap size is 0. In this case memset gets called with
nullptr which is undefined behaviour.
