The original patch courtecy of IRC user grib. The original comment:
Try to coordinate using windows bitmap fonts in the MacFontManager needs to consider
pixels, points, and DPI
Font sizes are usually described in terms of "point" sizes, and rendered
as a number of pixels.
Windows fonts and Macintosh fonts used different DPI (dots per inch).
Bitmap fonts on Mac mostly used 72 dpi, so 72-point font would be about 72 pixels high.
Windows bitmap fonts mostly assumed 96 dpi, so a 72-point font would be 96 pixels high.
director:trektech loads a Windows bitmap font file that is nominally 12 point at 96 dpi. It is 14 pixels high.
Since we cache windows an mac fonts, this ensures that we check both caches
before attempting to generate substitutes, whuch affects greatly
performance in Windows Director games
This flag prevents Mac fonts substitutions with equivalent TTF fonts.
Of course, being this a flag, it will not impact any previous game using
this. It will only impact whichever engine will decide to set it to active
(in our case, SCUMM).
When loading other fonts than the system ones, they would get ID -1, not
the one from their resource ID. Even if you later registered the font
name, the old font entries would still be wrong. Another possibility
would be to update _fontRegistry when registering fonts, but sev was ok
with this way so let's go with it for now.
It does not consider the possibility of ID collisions the way
registerFontName() does, but apparently there shouldn't be much risk of
that.
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.
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.
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.
Previously the methods would pass by reference, then convert to a
pointer on success and take ownership. This isn't ideal, as a
reference suggests no transferral of ownership, and doesn't suggest
it needs to be a heap resource allocated by new.
References to FOND resource streams are stored in an array.
Font streams were registered by their family name in a hashmap.
When a second font with the same name was encoutered it would replace
the pointer to the previous font.
The only use case for the hashmap was to register the stream to be able
to later close them.
