
 'WishList' for  Font Manager
 ----------------------------

 Created by Chris Murray, May 1992.
 Last updated by Chris, July 92.


 Pending tasks
 -------------

 * When outputting to a buffer at small scales, the text origin tends
   towards the bottom-left slightly sometimes.  In fact, this used to
   be a lot worse - the whole string would have alignment irregularities
   but I've fixed them by considering the sub-pixel positions when
   outputting path coordinates.  I think a similar thing just needs to
   be done when computing the text origin when outputting to a buffer.

 * Painting the same transformed text seems to keep on taking up cache
   space.  (cf. Mail from C.Ross)

 * Try to reimplement FontV - See notes in Fonts01 header.

 * Try to implement Dave's read/set CMOS bit in Font_Read/SetFontMax.
   See Since 298 for spec.

 * Check Apply/SetFields work correctly.  Neil wasn't sure if he'd
   finished/tested them.

 * The threshold checks that control if antialiasing is used are not good
   enough.  They approximate the width/height of the font with respect to
   the screen's axes.  This is incorrect.  It was fine for text that
   couldn't be transformed but now an arbitrary transformation matrix can
   be applied.  Consequently, the text's axes may be transformed.  We are
   really interested in the height of the font with respect to these new
   axes.  This can be computed by working out the distance between the
   transformed cap and baseline.  This (real) height should be used as
   in the antialias threshold check.

   The side-effect of the current system is that if you have text at a
   size reasonably near the antialias threshold and you rotate it
   gradually, then antialiasing is used on and off - at random as far
   as the viewer is concerned.  Nothing fatal occurs, it just looks
   appalling.


 Possible improvements
 ---------------------

 * Font Menus - allow multiple selections.  Applications like !Impression
   could use them for "Effects" menus etc.

 * When Font_FindFont is called with resolution (-1,-1), the Font Manager
   would use the default screen resolution for the *current* mode.  On a
   mode change, it would have to recache fonts at -1,-1 res at the new
   mode's default resolution.  This would make it *much* easier for the
   Wimp to use anti-aliased fonts in a mode-independent way in windows,
   since the font need not be rescaled whenever a mode change occurs - the
   Font Manager would look after it.

 * Support for UNICODE.

 * Better integration of Type1 conversion.

 * CopyDown becomes a real bottleneck when the cache is near full and
   different characters want in.  For a 256K font cache, it frequently
   moves nearly 256K just to get, say, 8K for something else.  This
   could be improved significantly if the Font Manager could allocate
   blocks from anywhere in the cache, rather than only from the top.
   Typically, blocks would be allocated in linked fragments and a free
   list maintained.  The routines that extract data from the cache would
   have to be changed to read scattered data.

 * There's something to be said about letting the Draw module do the
   anti-aliasing rather than the Font Manager.  I tested this by using
   CC's anti-aliasing Draw module and making the Font Manager always
   output paths - this gave good results, sometimes better than
   SuperSample.  Plus it doesn't suffer from anti-alias edging when you
   have two anti-aliased pieces of text overlapping one another.  It is
   faster to anti-alias at scan-line conversion time rather than doing an
   area sample later (think of a large oblique or rotated letter 'i', how
   much is space).  This would require major changes though, what a shame.
