QuickDraw GX

QuickDraw GX var en ersättning för QuickDraw (QD) 2D-grafikmotor och Printing Manager i det klassiska Mac OS . Dess underliggande ritplattform var ett objektorienterat upplösningsoberoende system med behållet läge , vilket gjorde det mycket lättare för programmerare att utföra vanliga uppgifter (jämfört med den ursprungliga QuickDraw). Dessutom lade GX till olika kurvritningskommandon som hade saknats från QD, samt introducerade TrueType som sitt grundläggande teckensnittssystem.

Även om GX verkligen åtgärdade många av problemen QD hade, när det var tillgängligt hade de flesta utvecklare redan utvecklat sina egna lösningar på dessa problem ändå. GX led också av att orsaka ett antal inkompatibiliteter i befintliga program, särskilt de som hade utvecklat sina egna QD-tillägg. Detta, i kombination med motstånd från en viktig del av utvecklarmarknaden, särskilt PostScript- ägaren Adobe, och bristande kommunikation från Apple om fördelarna med GX och varför användare bör ta till sig det, ledde till att tekniken ställdes på sidan.

QuickDraw GX såg lite utveckling efter den första releasen och "dödades" formellt med köpet av NeXT och det slutliga antagandet av Quartz -bildmodellen i Mac OS X . Många av dess komponentfunktioner levde kvar och är nu standard i den nuvarande Macintosh-plattformen; TrueType GX i synnerhet har, med några justeringar, blivit en allmänt använd modern standard i form av OpenType Variable Fonts .

Historia

Problem med QuickDraw

När 80-talet fortsatte började QuickDraws arkitektoniska begränsningar sätta gränser för Apple och tredjepartsutvecklare.

  • Alla QuickDraws offentliga datastrukturer antar ett 16-bitars heltalskoordinatutrymme, utan bestämmelser om bråkkoordinater.
  • Att lägga till nya funktioner till QuickDraw var extremt svårt på grund av bristen på data som gömmer sig i API:et. Den centrala datastrukturen i QuickDraw var GrafPort, en struktur med alla medlemsvariabler exponerade. Ännu värre, GrafPort-strukturen designades för att vara direkt inbäddad i tredjeparts utvecklardatastrukturer, så Apple kunde inte lägga till nya variabler. Color QuickDraw, som introducerades 1987, var en enorm kludge ovanpå den ursprungliga svartvita QuickDraw. Detta ökade komplexiteten i att utveckla färgapplikationer för Mac. QuickDraw kunde till exempel inte enkelt stödja avancerade grafiska transformationer som rotationer och skjuvningar, och det var omöjligt att introducera nya datatyper som kurvor.

Skapar GX

GX tycks ha startat på ett cirkulerande sätt, ursprungligen som ett konturteckensnittssystem som skulle läggas till Mac OS. Inkluderat i teckensnittsrenderingsmotorn var ett antal allmänt användbara tillägg, särskilt ett fixpunktskoordinatsystem och en mängd olika kurvritningskommandon. Systemet inkluderade också ett system för att "linda" befintliga PostScript Type 1-teckensnitt till sitt eget interna format, vilket lade till bitmappsförhandsversioner för snabb rendering på skärmen. Detta projekt fick senare en utökad roll när Apple och Microsoft kom överens om att arbeta tillsammans för att bilda ett alternativ till PostScript-teckensnitt, som var extremt dyra, vilket skapade TrueType -satsningen baserat på Apples befintliga ansträngningar.

Ett annat projekt, uppenbarligen orelaterade till en början, försökte lösa problem med konverteringen från QuickDraw till olika utskriftsformat. Medan utvecklare tidigare hade tvingats skriva sin egen kod för att konvertera sin QuickDraw-skärmbild till PostScript för utskrift, skulle sådana konverteringar under den nya skrivararkitekturen tillhandahållas av operativsystemet. även andra standarder som Hewlett Packards PCL . Systemet stödde också "skrivbordsskrivare" (skrivare som dök upp som ikoner på användarens skrivbord), en länge eftersökt funktion som saknas i QD, och lade till förbättrade utskriftsdialoger och kontroller.

Det är inte klart när projekten slogs samman, men detta var ett vanligt tema i Apple på den tiden. Mellanchefer var inblandade i ett intensivt gräskrig under stora delar av slutet av 1980-talet och början av 1990-talet, och samlade projekt till "överprojekt" som innehöll tillräckligt med viktig kod för att göra dem "oavlivningsbara". Tyvärr försenade detta ofta projekten dramatiskt; en komponent som gick efter schemat tvingade hela samlingen att försenas så att de kunde släppas "kompletta". QuickDraw GX var ett sådant offer, och förseningar och riktningsändringar i TrueType och andra problem försenade introduktionen av GX avsevärt.

Diskussioner om GX-teknik började dyka upp i olika facktidskrifter runt 1992, särskilt Apples egen utveckling . När det verkade vara nära förestående, kanske sent 1992 eller början av 1993.

Släpp och använd

GX släpptes ursprungligen omkring januari 1994, som ett separat paket. Version 1.1.1 levererades med System 7.5 senare samma år. Det var inte lyckat. Paketet var tillräckligt stort för att anstränga minnet hos de flesta befintliga Macintosh -datorer av eran, och argument som "du kan nu skriva ut till PostScript" var mindre än imponerande med tanke på att många befintliga program redan hade lagt till sådant stöd. Användare och utvecklare ignorerade i allmänhet GX, och en marknad för systemet dök helt enkelt aldrig upp.

Det verkar inte finnas någon anledning till GX:s misslyckande på marknaden, men säkert konspirerade ett antal av dem för att minska dess överklagande. Dels var GX väldigt stort och krävde i sig lika mycket minne som resten av operativsystemet. Hastighet var också ett problem, vilket begränsade den till att endast köras på Mac-datorer med en Motorola 68020 eller bättre. Med tanke på att den installerade Mac-basen vid den tiden fortfarande innehöll ett stort antal 68 000 baserade maskiner som Mac Plus , begränsade dessa krav antalet maskiner den kunde köras på. När det först släpptes, noterade en recension, "QuickDraw GX är inte för alla och kräver mer RAM än många Mac-datorer har att avvara." [ död länk ]

Dessutom var API:et för systemet mycket stort och fyllde flera böcker. Att implementera ett GX-program var ingen lätt bedrift, även om utvecklingen var tänkt att vara mycket enklare. Detta var inte ett problem med själva GX-arkitekturen, utan en bieffekt av systemets "all inclusive"-karaktär – ett problem som de flesta Apple-produkter från tiden led av (se till exempel PowerTalk) . Som ett resultat blev utvecklarens överklagande begränsad; mycket ansträngning skulle krävas för att använda systemet i program, och det resulterande programmet kunde bara köras på en delmängd av den installerade basen. Antalet GX-baserade (i motsats till GX- kompatibla ) program var mindre än sex, inklusive Pixars Typestry och Softpresss UniQorn .

Dessutom innebar förändringen av utskriftssystem allvarliga problem i den verkliga världen. Även om PostScript-utskrift aldrig hade varit lätt, hade utvecklarna under åren sedan lanseringen av den ursprungliga LaserWriter byggt upp ett bibliotek med lösningar på vanliga problem. Med förändringen i arkitekturen för GX slutade de flesta av dessa att fungera. Nya "GX-drivrutiner" behövdes också för skrivare, och Apple tillhandahöll inte drivrutiner för alla sina egna skrivare, än mindre för tredje part. Utskriftsproblem var endemiska och så svåra att åtgärda att användarna ofta gav upp systemet i frustration.

Användarupptaget av GX var mycket nära noll, vilket var fallet för de flesta av de nya teknikerna som Apple släppte i början av 1990-talet. Det kan ha sett utbredd användning som en del av Copland -projektet, men Copland lanserades aldrig. Även om Apple fortsatte att säga att GX var framtiden för grafik på Mac, var det 1995 klart att de inte längre "pressade" det, vilket frustrerade dess supportrar.

Mac OS 8 tappade stödet för GX-utskriftsarkitekturen, även om arkitekturerna för texthantering och färghantering överlevde. Delar av texthanteringsarkitekturen blev en del av TrueType-specifikationen och delar av färghanteringsarkitekturen blev en del av International Color Consortium- specifikationen. Med tillkomsten av Mac OS X lever delar av GX vidare i Apple Type Services for Unicode Imaging (ATSUI) och i ColorSync , vars filformat är identiskt med originalformatet som utvecklats för GX.

Beskrivning

Grafik

QuickDraw GX bygger på en objektorienterad modell där grafikobjekt är medvetna om och ansvarar för sitt eget tillstånd. Till skillnad från QuickDraw finns det inget universellt "tillstånd", varje ritkommando kan rekonstruera tillståndet från data lagrad i det, eller olika "förälder"-objekt. Till exempel kan en programmerare bygga ett redBox- objekt som först ställer in färgen till rött och sedan ritar en kvadrat. Från och med den tidpunkten behöver programmet inte längre uttryckligen ställa in färgen innan ritning, GX-systemet självt kommer alltid att ställa in ritningsfärgen korrekt när du uppmanas att rita en redBox , och återställa den när den är klar. Eftersom detta tillstånd var privat och skickades till GX om och när det behövdes, tillät GX teoretiskt att Mac OS stödde skyddat minne, eftersom tillståndet inte längre delades direkt mellan programmen och grafiksystemet.

Detta står i stark kontrast till den ursprungliga QuickDraw, där programmeraren var ansvarig för alla tillståndsändringar. Om man till exempel skulle rita en redBox och sedan en serie linjer, skulle linjerna också visas i rött om inte programmeraren uttryckligen ändrade färgen först. Fördelen med detta tillvägagångssätt är att det minimerar antalet kommandon som behövs för att ställa in tillstånd; programmeraren kan organisera ritning för att rita grupper av liknande föremål samtidigt och därmed spara tid. Nackdelen med detta tillvägagångssätt är att det är lätt att "glömma bort" att ändra tillstånd och orsaka problem, så lätt att programmerare ofta sparade och återställde hela tillståndet före varje ritkommando, vilket potentiellt sänker prestandan .

Ritningstillståndet under GX var hierarkiskt. Ett standardritningsläge skapades med varje fönster, som det var under QD, och ritobjekt utan andra tillståndsändringar skulle använda dessa standardvärden. Programmeraren kan sedan ändra tillstånd i själva objekten, som i vårt redBox- exempel, eller alternativt ändra tillståndet för all ritning genom att ställa in tillståndet i fönsterobjektet. GX-objekt kan enkelt samlas in i grupper, själva objekt, vilket gör att tillståndet kan ställas in för ett helt komplext objekt.

En del av det övergripande rittillståndet var gxMapping . Detta var en 3-av-3- matris som kunde uttrycka godtyckliga linjära transformationer i två dimensioner, inklusive perspektivförvrängningar . Alla GX-objekt hade en associerad mappning som en del av dess rittillstånd, vilket möjliggjorde saker som rotationer och translationer. Även om allt detta tillstånd hölls i gxMapping för det objektet, tillhandahöll GX också "wrapper"-kommandon som "rotera" för att göra API :et enklare att använda.

Till skillnad från QuickDraw tillät QuickDraw GX bråkkoordinater. Dessa var dock fastpunktsvärden snarare än flyttal . När GX utvecklades (slutet av 1980-talet till början av 1990-talet), fanns det fortfarande en betydande prestationsstraff för att använda flyttalsaritmetik.

GX-grafikarkitekturen byggdes kring ett antal typer av objekt som var förgjorda, även om en full uppsättning API- anrop var tillgängliga för att undersöka och manipulera dem:

  • en gxShape definierade den grundläggande geometrin för en form (till exempel koordinater för kontrollpunkter för en kurva eller textinnehållet i ett textobjekt).
  • en gxStyle definierade utarbetningar av den grundläggande formgeometrin, såsom linjetjocklek, cap- och sammanfogningsstilar, fyllningsmönster och texttypsnitt.
  • en gxInk specificerade hur pixelvärden skulle beräknas när formen renderades: förutom att ange en grundfärg för formen, inkluderade detta också en utarbetad överföringslägesstruktur som kunde definiera en mängd olika funktioner för det initiala och slutliga destinationspixelvärdet.
  • ett gxFont representerade ett teckensnitt, antingen ett som installerats för systemomfattande användning, eller ett som installerats direkt av det aktuella programmet för eget bruk. API-anrop möjliggjorde utfrågning av egenskaperna för ett teckensnitt, inklusive bestämning av vilka kodningar (Unicode, språkspecifika etc.) det kunde stödja.
  • en gxProfile var en representation av en ColorSync-färgprofil, som användes som en del av specifikationen av en färg för ritning. GX integrerat fullt stöd för färgmatchning i alla skeden av ritprocessen, samt stöd för icke-RGB-färgspecifikationer (som HSV , YUV och CIE XYZ).
  • en gxTransform bestämde förhållandet mellan formen och displayenheten. Förutom urklippsbanan och gxMapping som transformerade formen innan den visades på utenheten, specificerade detta objekt också träfftestningsinformation som kontrollerade svar på användarklick inom formens område.
  • en gxViewDevice representerade ett block av pixelminne i vilket ritningen skulle renderas. Detta kan vara en verklig skärmvisning eller ett minnesblock utanför skärmen. GX stödde alla QuickDraw- pixellayouter; detta gjorde det möjligt för både en GX view-enhet och en QuickDraw GrafPort att peka på samma pixlar, vilket gjorde det möjligt för applikationer att blanda båda uppsättningarna av ritanrop.
  • en gxViewPort var en logisk destination för ritning. En gxTransform kan specificera en lista över mer än en av dessa; formen skulle dras in i dem alla i ett enda GXDrawShape- anrop.
  • en gxViewGroup representerade kopplingen mellan visningsenheter och visningsportar. Varje vyport hade en gxMapping som specificerade dess relation till vygruppens globala koordinatsystem; och varje visningsenhet hade en gxMapping som specificerade dess plats och storleken på dess pixlar med avseende på visningsgruppkoordinater. Det fanns en enda fördefinierad vygrupp som innehöll alla skärmvisningsenheter (och vars visningsportar effektivt motsvarade skärmfönster); applikationer var fria att skapa sina egna visningsgrupper för visningsenheter utanför skärmen och visningsportar.
  • en gxTag gjorde det möjligt att bifoga godtycklig applikationsdefinierad information till de flesta av ovanstående objekttyper. Varje tagg hade en OSType- typkod, men det kan finnas flera taggar av samma typ kopplade till samma objekt.

Formtyper

GX-former kan vara av olika typer:

  • en rät linje definierad av dess ändpunkter.
  • en rektangel som definieras av dess vänstra, högra, övre och nedre gränser.
  • en polygon som definieras av en sekvens av vertexkoordinater.
  • en kurvform var en enda kvadratisk Bézier-kurva definierad av tre kontrollpunkter.
  • en vägform som var en sekvens av kvadratiska Bézier-kurvor . Varje kontrollpunkt hade en tillhörande flagga som indikerar om den var "on-curve" eller "off-curve". En punkt på kurvan var en Bézier-ändpunkt, medan en punkt utanför kurvan var en Bézier-mittpunkt. Om två på varandra följande punkter utanför kurvan påträffades, antogs en implicit punkt på kurvan ligga halvvägs mellan dem. Två på varandra följande punkter på kurvan definierade ett rakt linjesegment.
  • en bitmappsform innehöll rasterdata i något av de pixelformat som stöds.
  • en bildform var en gruppering av andra former (möjligen inklusive rekursiva bildformer), med möjligheten att ange ytterligare transformationer som gäller hela gruppen.
  • de olika typerna av typografiska former beskrivs i avsnittet GX Typografi nedan.
  • ytterligare typer som kanske inte var direkt användbara för att rita, men som kunde kombineras med andra former i geometriberäkningar: den tomma formen (som inte gjorde någonting); punktformen som består av en enda punkt ; och hela formen (av oändlig omfattning).

Typografi

Se även: Apple Advanced Typography

Typografifunktionerna hos GX integrerades i form av tre typer av gxShape:

  • Textformer var de enklaste: dessa innehöll en enda serie text renderad i en enda teckensnittsstil.
  • Glyfformer var ett sätt att använda teckenformer (" glyfer ") som ren geometri, till exempel som urklippsbanor .
  • Layoutformerna var de mest utarbetade. Dessa kan delas upp i flera körningar med olika teckensnittsstilar, till och med olika språkkodningar och textriktningar. Således var det möjligt att bädda in en sekvens av arabisk text, renderad från höger till vänster, i en yttre sekvens av romersk text från vänster till höger. Layoutformer släppte lös den fulla kraften av kontextuella ersättningar, kerning, variationer och alla andra funktioner i TrueType GX-teckensnitt. Deras huvudsakliga begränsning var att de var begränsade till en enda textrad.

GX API tillhandahöll också träfftestningsfunktioner, så att om användaren till exempel klickade på en layoutform i mitten av en ligatur , eller i området mellan en ändring av textriktning, skulle GX själv tillhandahålla smarta funktioner för att avgöra vilket tecken position i originaltexten motsvarade klicket.

TrueType GX

En viktig skillnad i GX gjordes mellan ett tecken och en glyf , en distinktion som också finns i Unicode-standarden. Ett tecken var en abstrakt symbol från teckenuppsättningen i ett skriftsystem, såsom bokstaven "f" i det latinska skriftens skriftsystem. Medan en glyf var en specifik grafisk form från ett visst teckensnitt, oavsett om formen representerade ett enda tecken eller en uppsättning tecken. Så, till exempel, hade Hoefler Text-teckensnittet glyfer för att representera bokstäverna "f" och "l". Den hade också en annan glyf för att representera ligaturen "", som automatiskt kunde komponeras (istället för de individuella glyferna) varhelst de två abstrakta tecknen "f" och "l" förekom i sekvens i källtexten.

Denna distinktion var viktig eftersom sådana kontextuella ersättningar inträffade vid renderingstidpunkten, utan några ändringar i källteckensträngen. De hade alltså ingen inverkan på redigering eller sökning av texten. PostScript Typ 1-teckensnittsfiler har endast en till en-mappning, och eftersom ligaturer är många till en-mappningar, kan de inte infogas i kompositionen utan att ändra källteckensträngen, till exempel placeras ligaturen ffi vid positionen för stor Y i Adobe-typsnittsprodukter och "Adobe Offices" är sammansatt genom att skriva "Adobe O" "Y" "ces". I layouten är teckensträngen bruten, och i PDF gjord från strömmande PostScript kan tecknen f+f+i endast rekonstrueras om namnet på glyfen följer en glyphnamnlista.

Kontextsubstitutioner kan kontrolleras genom att aktivera eller inaktivera kompositionsalternativen för ett TrueType GX-teckensnitt i WorldText på Mac OS 9-CD:n eller i TextEdit i Mac OS X. Teckensnitt har vanligtvis funktioner som kallas "vanliga ligaturer" (som exemplet "fl" ), "sällsynta ligaturer" (som inskriptionella ME- och MD-ligaturer), "arkaiska icke-terminala s" (för att automatiskt ersätta bokstaven "s" med den arkaiska formen som liknade ett "f", utom i ändarna av ord), och till och med val mellan helt separata uppsättningar av glyfdesigner, som mer och mindre utsmyckade former.

Reglerna för att utföra kontextuella ersättningar implementeras som tillståndsmaskiner inbyggda i teckensnittet och tolkas av LLM Line Layout Manager, motsvarigheten till CMM Color Management Module för ColorSync-tjänster. Texthantering i operativsystemet gjorde det möjligt för QuickDraw GX att acceptera teckensträngar med valfri blandning av skrivsystem och skript, och komponera strängarna automatiskt, oavsett om kodningen var Unicode 1.0 eller 8-bitars och 8/16-bitarskodningar.

En annan intressant funktion var typsnittsvariationer som var GX-motsvarigheten till Adobes " multiple master "-teckensnitt. Medan Adobes teckensnitt krävde att användaren uttryckligen skapade en "instans" av teckensnittet genom att ange värden för variationsaxlarna innan de kunde använda det, tillät GX användaren att ange teckensnittet direkt för en layoutstil och sedan dynamiskt variera axelvärdena och observera omedelbart effekten på textens layout.

Denna teknik blev kärnan i vad Microsoft och Adobe skulle ta till sig 2016, med utvecklingen av OpenType Variable Fonts .

Utvecklare

Cary Clark var arkitekt och teknisk ledare för QuickDraw GX. Han hade arbetat på Color QuickDraw och fortsatte med att bli en tidig medlem i Rocket Science Games och WebTV. Keith McGreggor var chef för grafikgruppen och den primära utvecklaren av färgarkitekturen för QuickDraw GX, och Robert Johnson var den bosatta matematikern. [ ytterligare förklaring behövs ]

Andra utvecklare på projektet inkluderar:

  • Tom Dowdy
  • Michael Fairman
  • David Van Brink
  • Chris Yerga
  • Oliver Steele
  • Dave Bra
  • Pablo Fernicola

TrueType GX

Dave G. Opstad var arkitekten bakom typografimotorn och formningstabellerna i Apples typsnitt. Han fortsatte med att bli teknisk ledare på Monotype Imaging. Andra som arbetade på TrueType GX inkluderar:

  • Erik Mader
  • Sampo Kaasila
  • Mike Reed
  • Arlo

externa länkar

Hämtad från " https://en.wikipedia.org/w/index.php?title=QuickDraw_GX&oldid=1130446149 "