*****************************************************************
*                                                               *
*   Amiga Type Engine: BETA 5b Update                           *
*   Produced by Gordon Fecyk 13 AUG 1995                        *
*                                                               *
*****************************************************************

NEW THIS VERSION:

Support for TA_DeviceDPI tag in OpenDiskFont().  Now you can open a font
with any X/Y DPI and use it, IE: open a font that's 72 x 36 DPI for
a 640x400 Workbench screen so it's twice as wide, or open a font for
printing on a 120 x 144 DPI printer.  I modified some of my code to
accomodate both textfonts and diskfont headers, for the NewScaledDiskFont
patch described below.

Support for NewScaledDiskFont().  Apps that use this call to generate
large bitmaps can now do so at any DPI, as per OpenDiskFont() above.
NOTE:  As per the ARKM:Libraries III, apps must StripFont() and UnLoadSeg()
the resulting seglist to free up the memory used by this call.  I plan
to recommend this as the prefered method for generating printer bitmap
fonts.  The code used here will become the engine for a library I may
try to write, a'la type1.library, which (if there's more demand for it
than just two people) will interface with Commodore's "proper" outline
engine scheme.  

Personally I think the bullet interface is way too slow and clumbsy, 
so I'll have to weigh the needs of app writers and users vs
the need for speed.  If app writers use the OS to draw text and to
build printer bitmaps we won't need that interface.
(Woody Williams: Input please!!!!!!!!!!!!!!!!)

(How come ATM on Windows is a great technological marvel, wheras
Amiga ATE is just a major OS hack?  Thphth.)

The NewScaledDiskFont() patch is the last work I should have to do
before completing the user interface, meaning this engine's pretty
much finished.  

Change requested by one tester: Don't print a message on startup.
I just hacked the startup message for now... if you want visual feedback
run ATE from User-Startup instead of from Workbench.  You will still
get an exit message with ATE -exit and you'll still get error messages
via that stupid console window.  I'll kill that window as soon as I
know the engine's near perfect.

*********** Bug Fixes ******************

Traces of leftover memory from Beta5a seemed to dissapear now.  Weird.
Now I only leave behind 3 KB un-freed, and that I think is from DICE
startup code.  DICE 3.01's due anytime and I hope the update will fix
some of this.  There's no un-freed memory from any call otherwise,
including NewScaledDiskFont.  Not bad, huh?

I experimented with using ATE fonts as WB defaults, and found that Beta5a
could somehow exit while WB used one of the ATE fonts.  This shouldn't have
happened as the open count of said font was > 0.  This seemed to go away
in Beta5b, but I still caution using ATE fonts for WB defaults.  If
you really want to try it, run ATEbeta5b just before IPrefs in your
Startup-Sequence.  Because you need to modify Startup-Sequence to do
this, I don't recommend it at all.  But it will work....

*********** New Bugs *******************

NewScaledDiskFont() calls must use the spec defined in ARKM:Libraries III.
In addition to this I extended the spec a bit, so you can request a new
style in the generated diskfont.  This call works wether you use FSF_TAGGED
or not, so the only way it can fail is via a PS error or if you run out
of memory (fingers crossed...)

Generating a NewScaledDiskFont() takes up to 20 seconds, actually faster
than the original 30 seconds from POST V17.  Not bad, but still almost
2x as slow as CG fonts.  This was on my 25 MHz '030.

ARKM:Libraries III tells us that diskfont.library cannot tell the difference
between a font with an aspect ratio (TA_DeviceDPI) and one without.  This
means if you try opening _ATE_Times 24 with a ratio of 2:1 and then try
opening it again without any ratio requested, you'll get the font with
the ratio anyway, or vice versa.  I don't try to fix this in my patch,
but I try to follow software styled fonts with ratios for stupid apps that
blatantly SetSoftStyle() normal fonts.  I don't recommend using OpenDiskFont
for obtaining fonts with weird DPI settings, and neither does ARKM:Libs III.
Use NewScaledDiskFont() to get exactly what you want, then UnLoadSeg() it
when finished.  Use OpenDiskFont() for display fonts or fonts you KNOW
should stay at a 1:1 ratio.  Avail Flush will kill off unused fonts with
ratios, should this happen.

Fonts will still get chopped off if they draw taller than the requested
pixel height (EG: FunkyFont 24 draws nearly 30 pixels tall!)  I need advice
on wether the system can tolerate fonts that are really taller than
specified in tf_YSize, or wether apps can handle getting a font that has
a larger tf_YSize than they requested in ta_YSize.  No, I won't put the
scaling code back in, as this distorts some fonts.

*********** Contact Information **

Gordon Fecyk
BSMT 5531 McRae Street
Richmond, BC   V6V 2P5
Canada

Phone: +1-604-526-8724

E-MAIL: gordonf@vcn.bc.ca