Path: utzoo!attcan!uunet!lll-winken!ames!ncar!tank!uwvax!astroatc!nicmad!madnix!aaron From: aaron@madnix.UUCP (Aaron Avery) Newsgroups: comp.sys.amiga Subject: Re: Fast fonts... (AkA, FF ) Message-ID: <411@madnix.UUCP> Date: 19 Jan 89 13:44:16 GMT References: <8901180336.AA01749@jade.berkeley.edu> Reply-To: aaron@madnix.UUCP (Aaron Avery) Organization: ASDG Incorporated Lines: 68 In article <8901180336.AA01749@jade.berkeley.edu> CRONEJP@UREGINA1.BITNET (Jonathan Crone) writes: >ARRRGh!!! >I' ve just spent a futile 30 minutes doing my damnedest to >get fast fonts to work on my system. I'm sorry that it was futile, but I spent many more than 30 minutes tracking down a bug in FF. >the font is cleanII, there is a cleanII.font and a cleanII directory >with 8 in it int fonts:, and if I type out the cleanII.font file in >hex mode, it references cleanII/8, so that part is right... > >trying FF cleanII.font results in it saying that it can't open >cleanII.font twice... Well, the *.font format appears to be the way FF wants it. I had it complain twice, too. Well, from what you said above, I would have expected FF to find the font, but probably complain about its being proportional, when it isn't. >finally, getting pissed off, I typed out the FF executible in >hex mode, and I see that there are a whole load of command line options >such as B, 8, 9 , 0 F N Q and 1 >the enhancer manual only mentions the 0 and n options.... I can only add -q, which seems to completely unload the FastFonts code from memory. >What do i do to get FF to substitute cleanII in place of ugly little topaz, Well, I did finally manage to get it to work. I had heard rumblings about this back when 1.3 first came out. It appears that the FontEditor from Commodore has a slight bug in that it will indicate that a font is both a disk-based font and a ROM-based font when it saves a font. This would not be a big problem if FF did things right. However, when FF tries to check to see if the font is proportional, it doesn't check correctly. It should check bit 5 in the ta_Flags variable which is stored with the font. Instead, it ANDs 5 with ta_Flags, thus checking if it's a ROM-based font or a right-to- left printing font. I believe this was a simple, one character typo in the source, but I'm surprised it didn't get caught, as it failed to work with ANY of the 8x8 fonts I had laying around. The way to fix this problem, once you get FF to the point of only complaining about the font being proportional, is to edit the '8' file in the directory. Starting about 100 bytes into the file (pearl is 100, it might differ), you should find something like '000800430008'. The eights should be the same, but the middle value may differ. You need to be sure that bits 0 and 2 are both clear. In this case, setting it to 42 will both work and be correct. All values are in hex. The best program I know of to make this modification is John Hodgeson's NewZap program. Let me know how it all works out. I'm now using my cli and term program with pearl.font and I love it! >what to i do to reset my cli when it gets put into the alternate >charater set when you type an executible without the opt h When the console.device sees a ctrl-O, it will go into the alternate character mode. Typing a ctrl-N should get it back to normal. >Heisenberg might have been here... That's MY quote!!! (Imagine that! I'm not the only one who thought of this!-) -- Aaron Avery, ASDG Inc. "A mime is a terrible thing to waste." -- Robin Williams ARPA: madnix!aaron@cs.wisc.edu {uunet|ncoast}!marque! UUCP: {harvard|rutgers|ucbvax}!uwvax!astroatc!nicmad!madnix!aaron