Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!lll-tis!ames!nrl-cmf!cmcl2!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.sys.apple Subject: Re: VT220, GS+ (actually, just GS+) Message-ID: <7463@brl-smoke.ARPA> Date: 19 Mar 88 02:19:09 GMT References: <8803061316.aa29780@SMOKE.BRL.ARPA> <37@fizban.Fizban.MN.ORG> <7438@brl-smoke.ARPA> <490@n8emr.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 18 In article <490@n8emr.UUCP> lwv@n8emr.UUCP (Larry W. Virden) writes: >Yet isnt it true that the Mac family all use the same fonts? I am confused as >to how they do this if altering the resolution on the IIgs would cause major >problems with software, fonts, etc.? I don't know how the Mac II does this, if it does. The basic problem would be that the fonts are defined as bit-maps and if the resolution were doubled the 10-point bit-map (for example) would come out as 5-point on the display. The programming problem is more basic, in that the current GS display memory is contiguously allocated and addressed by software on the assumption that there are 200 scan lines per screen. There was no allowance made for more, so existing software could not find it. I suppose if one could arrange for the other 200 scans to be interlaced from a separate area of memory, then if it were set to all-black the appearance would mimic that of the current GS display, and any software written to know about the additional interlaced frame could stuff bits there to produce a higher-resolution image. Unfortunately this complicates programming of access to the display bitmap.