ATM Development log, started 21 AUG 1994 20 JUN 94 Began playing with OS patches. Suceeded in patching OpenDiskFont(). source code: diskfontpatch.c 1 JUL 94 Canada's Birthday. Vacation! 10 AUG 94 Began playing with EXEC messages and Wait(). Unsuccessful in creating port messaging between two programs. Will try later. source code: msgtest1.c and msgtest2.c 21 AUG 94 Succeeded in EXEC message passing. Also wrote first half of a Text() handler that manipulates fonts. Uses an EXEC message port because this kind of handling must run within an AmigaDOS process. Initially only prints font names that have matching .metric files. source code: port1.c, port2.c, textserver.c 24 SEP 94 Quite a long time... Managed to get a patch/messaging system working on OpenDiskFont(). Next step: Text() 9 OCT 94 Getting closer. Encountered a curious problem patching Text(). I can't patch it the same way as OpenDiskFont(). I'll work on the font renderer until I can get some support. However, working patch and server code for OpenDiskFont() completed. surce code: ATMserver.c, ATMpatch.c 10 OCT 94 Happy Thanksgving Canada Will attempt to "merge" MKBmap and ATMServer together, so instead of just recording font names it generates fonts. Since I can't patch Text() yet I'll have it render the whole font upon OpenDiskFont(). Will allow for single character rendering later. Also introduced new file format: the .atm file lists PostScript typeface names for regular, bold, italic, abd bolditalic. MakeATMFont will allow for these styles by reading the TextAttr struct passed to it. I still have to see about rendering these styled fonts with different names, to not confuse the operating system. Question for CATS or whoever takes over for CATS: can several fonts in memory have the same name & size but different style flags? source code: MakeATMFont.c, MakeBMAPFonts.c, MKBmap.c (Adrian Aylward) 22 OCT 94 Success! Damn, after experimenting with MKBmap and being able to render a mixture of fonts, standard encoded and font-specific, and after finding a few post.library quirks, I could write a program that renders fonts and adds them to the system. Also sucessfully merged ATMserver and MakeATMFont to get, what appears to be, a running version of ATM. With the patch in place I can render whole fonts and add them to the system for use, but rendering the whole charset takes 30 seconds on my '030/'882! Gawd awful slow! At least it looks like a working version of Adobe Type Manager! I remind myself to write Adrian Aylward and chastise him for pukey poor coding techniques! I haven't seen so many "gotos" since my days in BASIC on the Commodore 64! source code: ATMpatch.c, ATMserverII.c 23 OCT 94 After realizing I'll need to patch a lot more functions to pass data to the server task, I wrote a general message passer that allocates one port for each patch. Using an extended Message struct (ATMMessage) which includes reply port info, each patch calls ATMSendMsg() with its own ATMMessage struct, which includes its own reply port pointer. It's up to that patch to also clear its memory and send a cleanup call to ATMSendMsg(). However, the command to clean up must be sent through the patch! This is handled differently for each patch, eg: NewOpenDiskFont() will clean up if it sees a TextAttr struct with FPF_REMOVED in its flags. NewText() will have a similar mechanism, possibly with a funny RastPort pointer like 0xFF40544C ("˙ATM"). This might work for all! Hmmm... Will patch SetSoftStyle() to switch TextFont pointers etc to do neat stuff with different type styles. I'll need to patch others but I don't know which ones until later. source code: ATMpatchII.c, ATMserver.c 24 OCT 94 Early... damn damn early. Can't sleep, so I tried editing ATMServerII to handle the ATMMessage structs as ATMServer does. Also uncovered a bug in memory freeing (I was freeing up the fonts OK, but I didn't free the list entries! Stupid, stupid, stupid) Turns out that fixed a problem in the font renderer so it cleaned up better now. Performance is unchanged (30 seconds to draw 223 characters... really) but now it works with the new ATMMessage format. The cornerstone is now in place for the rest of ATM. source code: ATMpatchII.c, ATMserverII.c 11 DEC 94 Talk about asleep for a long time. Been wrestling with the Text() patch on and off for six weeks until I realized a basic concept of Amiga programming: puuting the library base in A6 before making calls!!!!!!!!! Succeeded in patching Text() and OpenDiskFont() properly now, and I dumped my port creator routines for good. Turns out EXEC will re-use memory chunks if you AllocVec() and FreeVec() chunks of the same size. This will put a tiny bit more overhead in processing... Oh well... I don't notice a performance hit on my '030-25 based Amiga 1000. But it does cause Enforcer hits in DPaint IV. What's Electronic Arts doing in there that no one else seems to do? I kept a general ATMSendMsg() function to simplify messaging within any new patches I create. I'm thinking about combining the server and patch processess into one executable, but the idea of sending messages to myself seems silly. Server process can now record used characters and display them when the server exits. source code: ATMpatchIII.c, ATMserver.c 19 MAR 95 After wrestling with a dying hard drive and re-building my computer I managed to complete a re-write of the ATMserver (ATMServerIV). This will be the first official Alpha version, as it will serve as the basis for the Beta 1 I plan. It also fully works! Managed to put much of the crucial external variables in a FontNode struct which will simplify the Text() server function. Remaining external variables must remain because post.library and post.h demand it. I plan on writing a nice letter to Adrian Aylward about better programming techniques on the Amiga, provided he has a fixed address. Added Style search in the FontNode's node name. Currently the server supports ta_Style but I did not test this yet. Many programs just open the plain style then SetSoftStyle() it. I will catch this probably in Beta 2 (possibly in Beta 1 if it works out easily!) by patching SetSoftStyle(), which will just swap the TextFont pointer in the RastPort to a designed style. I also uncovered many nasty bugs in ATMserverIII which seemed to remove any Enforcer hits caused in DPaint IV. Oh yes, a possible compiler bug in DICE 3.0: when using an unsigned short in a structure (pointer-referenced) in a calculation with signed ints, the short often comes out wrong! I had to create a temporary signed int and copy the unsigned short's value to it then calculate using the signed int. 32 hours of hair pulling uncovered this bug. thphth. Ever watch a font get rendered backwards? How about printing Kickstart ROM data? neat. source code: ATMserverIV.c 26 MAR 95 Back on a somewhat regular schedule. I succeeded in a limited Text() patch which generates characters as required! Very impressive except for one bug: It can only use one font at a time. If I change typefaces and change back, it will use the last loaded typeface to fill in any new characters. Not bad really. Managed to generate all of a TextFont except for character data too. Now the pre-rendering takes 1/3 less time (10 seconds for 223 chars is still too long in my opinion though.) I need to work out a safer way of switching typefaces within my server. The obvious techniques won't work (at least they were obvious to a non- PostScript programmer...) as they seem to lock the computer, leaving the server in an infinite loop state and locking the system on the next OpenDiskFont() or Text() call. Perhaps a PostScript wizard can help. source code: ATMserverIVb.c 27 MAR 95 It's amazing what a little imagination can accomplish. After checking the PostScript code that actually goes and GETS a typeface (beginning of MakeATMFont) I copied that code to the beginning of MakeATMChars. This allowed me to SAFELY change typefaces between calls of Text() and properly render characters on demand. YES!!!!! Current copy of ATMServerIVb has lots of commented-out code so I will probably clear that out in IVc. In IVc I can attempt to patch SetSoftStyle() and swap fonts back and forth, allowing for TRUE bolds and TRUE italics! This, and merging ATMPatch, will make up a first Beta 1 release of ATM for the Amiga. source code: ATMserverIVb.c 28 MAR 95 Making daily progress. At this point I'm checking the multiple style capability of ATMserver. After discovering a stupid bug in scanf() which treats the "-" as a white space character, I worked around it to get the typeface filenames I needed. Now it can read multiple styles. I wonder, however, if the Amiga is really capable of handling multiple styles properly. According to ARTM it actually lists four fonts with the same YSize but different styles! But weird things happen as I switch between styles; displays get trashed, ARQ draws funny rotating graphics along window borders, DPaint IV locks up and sometimes will load the wrong style (If I load Times-Italic first it will use it instead of Times Normal). It may be how I'm handling the PostScript interpreter, and it's corrupting areas of memory. I'm pretty sure I'm checking my memory usage but I need Mungwall and a serial terminal to know for sure. source code: ATMserverIVb.c 31 MAR 95 Getting closer. Uncovered a bug that would cause funny char drawing in characters above ASCII 127 (using signed chars instead of unsigned chars) so when I fixed that I could properly draw the extended characters. It also looks like either intuition or graphics.library can't handle multiple styles properly. Certainly intuition can't. I'll try writing a better font test program (that uses graphics and diskfont calls instead). Managed to get Sushi running so I can trap Mungwall hits. So far I'm not trashing memory but I noticed some ROM routines will access unused memory (0xABADCAFE) so I have to wonder how well the system is equipped for multiple styled fonts. Worst case I can keep the alternate styles in RAM but not add them to the font list, then switch them using SetFont() in any SetSoftStyle() patch I write. source code: ATMserverIVb.c, ImageTesting.c 1 APR 95 Looks like Intuition's the April Fool. Either that or there are nasty bugs in ImageTesting.c. When I use graphics.library instead of Intuition to draw text I don't get any Enforcer hits or accesses to unused memory. And I thought Intuition used graphics.library properly! SetSoftStyle() patch finshed and rather impressive! Now the system can load and swap fonts as needed. Biggest drawbacks are how Intuition uses SetSoftStyle() so often and when a program loads a font and SetSoftStyle()'s it by default (like how DPaint IV does!) Also fixed a bug; because Intuition calls SetSoftStyle() and Text() one after another I have to search quickly in the patches, and get out fast! The result is the mouse pointer will freeze for a fraction of a second as Intuition draws menus and Workbench draws disk windows. Not too bad on the '030 but I don't want to see it on a 68000! I will try to complete the single executable (patches and server in one) for release as Beta 1. I still need to write a Text() handler process and read about Exec Semaphores. Perhaps the server can share the fontlist with this handler to speed up searches for non-ATM fonts, but this won't be complete until Beta 2. source code: simplewbwindow.c, ATMserverIVc.c, ATMpatchIII.c 2 APR 95 Found a curious bug in DPaint IV. It likes to ignore any font changes I make in SetSoftStyle() and probably just SetFont()s the original style back. It often won't display any style changes until you actually use the font. But when you use it it still works. Beta 1 release complete. Managed to merge the patch and server processes into one executable and I started distribution. Time to see how stable the system REALLY is. I never had the opportunity to test this program on Release 3 but my testing squad will. I know EA did some fixes in DPaint IV so maybe a fixed version will work better. I also need to see how other programs (like Excellence!) react. Plenty of problems I need to fix for Beta 2! The most obvious is how ATM handles italic and oblique typefaces. I will need to pay closer attention to the bounding box info and position the characters better, so tails won't get chopped off etc, and to offset the gross spacing of italic chars by using negative CharKern values. Beta 2 also needs the auxillary Text() handler process to eliminate the crazy freezing that Intuition does. But now that everything is in the same executable I can try performing searches through the list from the patches (using Exec Semaphores). source code: ATMbeta1.c 14 APR 95 Managed to introduce two changes. The first fixes the italic tail-chop problem by using the Amiga's version of "kerning", using negative charKern values for certain characters, and by modifying the PostScript chop calls a bit. Next I plan to compare the character spacing to that of an established application (probably PPage 3.0). The second introduces signal semaphores into ATM. The patches can now search the font list themselves, and won't send ATMMessages unless they find fonts in the list. Currently only the Text() and SetSoftStyle() patches do so, and this drastically cuts down on the mouse freezing Intuition causes by calling SetSoftStyle() and Text() in rapid succession (but noes not completely eliminate them...) and this consequentially should allow terminal software to work better. For Beta 2 release I will compare the spacing info and see if I can improve on the spacing for italic typefaces. I may have to resort to the AFMs for that, as well as for the bounding box info. Beta 2 documentation should include typeface adding instructions too. I won't do a nice installer or control panel until I'm sure the rendering engine works perfectly, and only for release in Beta 3. source code: ATMbeta1b.c 22 APR 95 Added ability to get spacing info and baseline from AFM files. This and a bit of magic fixed my gross italic spacing. I don't have accurate AFMs for TimesNewRoman so I get a bit of character chopping. Other Oblique faces seem to work OK. Spacing now closely matches Professionl Page's except the space character seems smaller in the .AFMs. All this reduces setup time to four seconds, enough time to scan the AFM and read the typeface into PostScript VM. Nice Control Panel won't happen in time for Beta 2 release tomorrow so I'll settle for the command line for now. The rendering engine MUST work perfectly, and I must know what applications really, really, work. Must send beta 2s to Gold Disk and O.I.C. and perhaps to other "big" Amiga software houses (if there is such a thing now...) source code: ATMbeta1c.c 29 APR 95 On tuesday I go for training for Microsoft Windows '95. Yeah right. Fixed a couple of nasties. ATM would not correctly set styles when a program used the suggested routine in ARKM:Libraries. Fixed that somewhat but now I have a problem with DPaint IV again; looks like it calls OpenFont() to read existing fonts from memory. When Excellence! left BoldItalic fonts in memory, DPaint found them. So it looks like I need to patch OpenFont() in a similar manner to OpenDiskFont(). Or maybe I just need to complete the AvailFonts() patch; that should avoid this particular problem. It also appears Excellence! doesn't use ALT keys for international characters. This isn't my bug however. Thphth. sourcecode: ATMbeta1d.c 1 MAY 95 Received a fax from Softwood (makers of Final Copy) and looks like they're interested in ATM! Yahhh! Worked on determining how AvailFonts() really behaves if I follow Commodore's suggested procedure (call AvailFonts() with a zero buffer, get the size, then call again to get the font list). 3 MAY 95 Received ten letters from users wanting to beta-test ATM. Among them are former C= employees, software houses with connections to ESCOM AG, and old friends in Winnipeg. Even one from as far away as The Netherlands. God, I love The Internet. AvailFonts() does work with a zero buffer. Perhaps I can improve the fcn slightly by reducing how often it goes out to the disk to check for fonts. I can gather the existing diskfonts, determine how much RAM the header takes, then fail any calls with a smaller buffer. I'll still call the original fcn for RAM fonts and other fonts. The idea is to insert ATM TextAttrs into the list, rather than using faked .font files, so apps know the ATM fonts exist. I must include AvailFonts() and fix the new DPaint style bug before I begin distributing Beta 3 to my new testers! 6 MAY 95 Finally corrected the style problem. I had to make sure ATM works with programs that follow Commodore's suggested style scheme (OpenDiskFont with SetSoftStyle's enable bits taken from the new font) and those that blatantly open the Normal style then SetSoftStyle. By changing the font within the Text() patch I could do this and please both kinds of programs. I still build replacement styles but will change styles just before drawing characters. With any luck I can now begin the AvailFonts() patch and prepare a shippable Beta 3 by tomorrow. Fixing the style problem gives me new hope. source code: ATMbeta2.c 7 MAY 95 Began working on the AvailFonts() patch. I managed to insert ATM TextAttrs into the list but I find I over-write memory by a few bytes (Mungwall) and read un-initalized memory too (Enforcer hits reading 0xDEADF00D). I'll correct this by just inserting TextAttrs (and not names or tags) into the list, and just have them point to names and tags stored in my executable's memory space. That'll avoid the hassles of setting aside more RAM etc for extraneous data. However, the ATM fonts look like they show up in the system list. Excellence! will identify the ATM fonts but curiously it won't open them. This is most likely because ATM looks for files with the .atm extension and I omitted that. Yes, sure enough that was all it was. Now Excellence! can recognize fonts that don't have the .font extension in FONTS: (meaning my ATM fonts) and open them, and use them. Impressive. So, I need to double-check my memory usage and clean up the patch a bit, but Beta 3 release will be reality within this week. source code: ATMbeta3.c 8 MAY 95 Persistence pays off today. After discovering stupid errors (like writing to TextAttr structs instead of AvailFonts structs like I'm SUPPOSED to) I succeeded in patching AvailFonts(). Now when an app calls AvailFonts() to get a font list, it gets all the ATM fonts too. Also fixed a bug in font listing; if there was only one ATM font it would exit with a bogus error. Fixed. ATM Beta 3 release begins today. Need to write new documentation to reflect the changes and such, but that will finish by tonight. Now I need to see just how perfect the font engine REALLY is. With any luck, I can begin work on the user interface and improve PostScript rendering speed, with a little help from a PostScript guru out there, somewhere. sourcecode: ATMbeta3.c 13 MAY 95 Released ATM Beta 3. Discovered a bug of Prefs/Fonts vs DPaint IV; when I run Prefs/Font to select a font for Workbench, cancel, then run DPaint to select a font for typing, it GURUs (Processor exception 4). Weird. It only happens if I run Prefs/Font. On a related note, Excellence! will display multiple entries of the same font, one entry for each font I preview back in Prefs/Font. Maybe DPaint's choking on multiple identical TextAttrs or something. What is Prefs/Font (or most likely, asl.library) doing that I'm not accounting for? Fixed a silly style bug; if a program follows the ARKM:Libraries font opening rules it might not display any characters! This is because I search for styles not present yet. Fixed. Picked up a uuEncoder so I can send patches out easier via Internet. when I get my full access back on The Lounge (now "Dark Delusions") I can spread the patches. sourcecode: ATMbeta3a.c 25 MAY 95 Beta test reports beginning to trickle in. Marcel Offermans from Holland is the most co-operative, uncovering a few nasty bugs: ATM fonts showing up as "fixed width", and the panic exit problem. I thought the lack of a FPF_PROPORTIONAL caused the problem with Prefs/Font, to no avail. At least I have much of a "Beta3b" up and running with these bugs fixed. All but one anyways... being the panic-exit. It looks like I need to "reboot" the PostScript interpreter after an error, because it just doesn't want to operate properly after a PS error. It's a simple matter, but it's still a pain. Interactive PS never did that. Maybe the suggested hwgpost.library corrects that. Regarding this new library... I E-MAILed the author, who incidenally, wrote his library based on the source from post.library 1.7. Apparently he included some gateways to Display PostScript, which might make ATM useless. Nahh. Also introduced a safety feature, which forbids exiting until all ATM fonts have an opencount of zero. This should fix a problem Marcel had with one app that displayed some neato fonts (like " .font", "#.font", "*.font", etc) after he exited and restarted ATM. When I complete Beta 3B I'll begin distributing patches uuEncoded via E-MAIL. sourcecode: ATMbeta3b.c 31 MAY 95 Completed more patches to ATM Beta3b. Fixed the "j" chopping and "'", but still get chopping with Courier at small sizes. Much better, though. I'll improve it further. Time to start spreading this new version around. I hope I get a response from SoftWood sometime soon, because I don't work for Seanix anymore. Thphth. Will probably return to Winnipeg around 30 JUN 95. But that won't stop me from finishing ATM. I have 30 days to find a new home, possibly find new work in Winnipeg, and lots of extra time to complete the ATM user interface. Received original versions of Times, Helvetica, Symbol, and Courier, so I can fix my spacing bugs. Turns out I glitched back in MakeATMFont(), so that's fixed. sourcecode: ATMbeta3b.c 23 JUN 95 Three weeks later, looking for work. Managed to complete a makeshift Shell detachment for ATM (just a Execute("Run "argv[0], 0, 0) to do it) but it does the job. Also completed a command receiving mechanism. For now it just looks for -exit which causes ATM to unload. Wrestled with some nasty Enforcer hits but fixed that. Got a real Internet address now, so I'll start distributing Beta3d to my beta testers. sourcecode: ATMbeta3d.c 28 JUN 95 Searching for work. Fixed duplicate font name problem with Excellence! vs Prefs/Font but DPaint still don't work. Apparently it's a bug with my copy of DPaint, because DPaint IV AGA doesn't do it according to beta testers. SoftWood doesn't have time to test ATM but they might be interested in marketing it. The font engine's pretty much bug-proof, now all I need is a nice way of installing fonts and a nice control panel. Also picked up a GUI editor for gadtools.library. That should simplify the ATM interface construction considerably. Plans for releasing a "crippleware" ATM in mind... such crippling includes: no fancy installer for fonts, force user to use post.library instead of hwgpost.library, use un-optimized PostScript code. Full commercial release of ATM should have: capability to use hwgpost, nice font installer, lots of options via an ATM control panel commodity (actually not many options; just font install/remove and edit sizes available to AvailFonts()), and use optimized PS code to make the commercial version faster. 30 JUN 95 Distributed new ATMbeta3d. Constructed mailing list on Vancouver Freenet for further ATM transmissions etc. Now I have to start handling the gadtools editor and new GUI I began constructing. Geez, Intuition isn't my forte on The Amiga... I need to get working on that. 7 JUL 95 (Happy birthday sister Lou) Received acknowledgement from comp.binaries.amiga moderator, possibility that beta3d might not pass the requirements, because they don't like beta software on the net. I make sure that 3d worked well and didn't trash the system though. Now working on Beta 4. This Beta introduces many parameters to ATM that match the options I plan on using in ATM Control Panel: -Enable/Disable soft styles on ATM type -Show only ATM typefaces/Show all Amiga & ATM typefaces -Show/Hide trace messages (same as OPTTRACE) -Show/Hide all PS command (same as OPTDEBUG) -Change shown point sizes for apps (Default 72 max, increment 6) -Rebuild ATM font list in memory (suitable after user adds typefaces) These options will all work from the command line or from ATM Control Panel. Working on separate "Prefs" style program, the ATM Control Panel. This will send parameter switches to the ATM main executable. Look and feel will be a cross between Amiga Prefs programs and ATM Control Panel for MS-Windows. The Beta4 executable is almost finished except for the soft style switch. I will pass this executable and IFF pictures of the new interface to beta testers when complete. I hope Beta 4 will have optimised PS code before I release it, but I still can't get any help from PS programmers out there. Maybe I'll just dump a section of ATM's source onto comp.lang.postscript and see if I can get help there. Still to come are legal issues; I never received any acknowledgement from Adobe Systems regarding their trademark. I have to wonder if they even care. Adobe Type Manager for The Amiga is now one year into its development. Happy Birthday. sourcecode: ATMbeta4a.c 19 JUL 95 Thanks to a friend across the Internet in comp.lang.postscript I managed to whittle down the PS code needed to draw chars in the MakeATMChars() function. Drawing the whole charset now only takes 8 seconds, beating out CG fonts by a whole four seconds! Thphth! Also fixed a problem in KS 3.0. In KS 3.0, OpenDiskFont() does not call OpenFont() after it loads a font. So, I have to check the open font count by traversing the system font list instead. This works fine. Still angered by a problem my AvailFonts() patch causes in some apps, now in FW III it will GURU 8100 FF00 for an unknown reason. It's for sure in exec.library. I need serious CATS help though none exists. ATM seems to loose 3432 bytes every time it runs. I am freeing all memory I allocate. At first I thought it was because I wasn't StripFont()ing all ATM fonts before removing them, but that wasn't it. The one big loss of 3328 bytes is unexplainable!!! Maybe post.library did this. I will release Beta 4B to beta testers this coming morning when Freenet is quieter. sourcecode: ATMbeta4b.c 2 AUG 95 A long time between entries indeed. I included a low memory handler that patches to Expunge() from diskfont.library, which dumps unopened fonts and restarts the PS interpreter to clear unused typefaces from PostScript VM. This version I sent to Amiga Computing Magazine for publication in their October issue. Name change: Adobe Systems says No Way Jose to Amiga ATM. Thphth. I'll just call it something different: Amiga Typeface Engine (ATE). There. The name will probably change one more time. I still get requests for ATMbeta3d though. They're still going out there. Doenloaded HWGpost beta 6 from AmiNet courtesy of a new co-worker at In-Line support. Yes, I'm employed again! Windows 95 TCP/IP rules unfortunately. At least Microsoft got something right. Losing more memory! Geez, now it's 12 KB lost. I think that was post doing that. I hope HWG's post will fix this memory loss. Accomodating HWG Post will require a PS re-write and re-defining many postlib structs I use, and it will show up in Beta 5. Mr HWG (Heinz Wrobel... where did the "G" come from I wonder...) will probably get the very first copy of ATE beta 5. sourcecode: ATEbeta4c.c 9 AUG 95 ATEbeta5 goes to beta testers and Mr Wrobel finds an Enforcer hit... fixed that. Beta5a is gone out and Mr Wrobel doesn't like the hacking job I did so far. He and one other person suggests the bullet route; where diskfont.lib calls a rendering engine library to build diskfonts. This is already done in type1.library, but this takes 30 seconds to draw an entire font... After arguing with HWG over this for the past week, I'm beginning to think of a hybrid plan... Build a rendering library as per type1, and as a user option build a Text() "daemon" as he calls it, which draws glyphs into the diskfont as needed, but only as an OPTION, because some apps still don't call Text() to do their drawing (IE: Video Toaster...) The only problem I see with this approach is maintaining a fontnode list externally. When such a lib builds an "empty" font, It could send a message to the Text() daemon with the TextFont pointer, then the daemon would make a FontNode and fill in the TextFont as necessary. I wonder just how safe that is... what happens when diskfont.lib wants to expunge a bunch of fonts while the daemon renders? And the daemon should still provide true styles if apps cheat via SetSoftStyle(). Wow... that could prove quite an undertaking... but then again... my original ATM idea was quite an undertaking... :) hwgpost wasn't causing my memory loss it turns out... I need to check deeper in the lists and find out where all these little bits of RAM are going to... I should post this crazy hybrid idea to the rest of the testers and see what they think. sourcecode: atebeta5a.c 25 FEB 96 (No ATE development since AUG 95 because of serious employment!) (sigh) How can I be having too much fun working on Windows NT to be working on ATE? Makes about no sense at all. ATEbeta5b is complete and still has little bits of RAM left over, but I'm convinced it's not my fault. In the time between ATEbeta4c and now, I whipped up a Beta4d which removes post V17 dependancies and released it to comp.binaries.amiga. I also posted a message on comp.sys.amiga.announce asking for help, and tomorrow I will release this source code to those who replied. My plea for help showed up in Amiga Report magazine, so maybe one day this will show up on comp.sources.amiga and Aminet to let others dabble and hack. To those who dabble and hack: if you finish it, release it, and make it great!