QuickDraw GX

QuickDraw GX zastąpił silnik graficzny 2D QuickDraw (QD) i Menedżera drukowania w klasycznym systemie Mac OS . Podstawową platformą do rysowania był zorientowany obiektowo , niezależny od rozdzielczości system trybu zachowanego , znacznie ułatwiający programistom wykonywanie typowych zadań (w porównaniu z oryginalnym QuickDraw). Dodatkowo GX dodał różne polecenia rysowania krzywych, których brakowało w QD, a także wprowadził TrueType jako podstawowy system czcionek.

Chociaż GX z pewnością rozwiązał wiele problemów QD, zanim był dostępny, większość programistów i tak opracowała już własne rozwiązania tych problemów. GX również cierpiał z powodu szeregu niezgodności w istniejących programach, zwłaszcza tych, które opracowały własne rozszerzenia QD. To, w połączeniu ze sprzeciwem znacznej części rynku programistów, zwłaszcza PostScriptu , firmy Adobe, oraz brakiem informacji ze strony Apple na temat zalet GX i powodów, dla których użytkownicy powinni go zastosować, doprowadziło do odsunięcia tej technologii na boczny tor.

pierwszym wydaniu i został formalnie „zabity” wraz z zakupem NeXT i ostatecznym przyjęciem modelu obrazowania Quartz w systemie Mac OS X. Wiele funkcji składowych pozostało i są obecnie standardem na obecnej platformie Macintosh; W szczególności TrueType GX , po kilku poprawkach, stał się szeroko stosowanym nowoczesnym standardem w postaci zmiennych czcionek OpenType .

Historia

Problemy z QuickDraw

W miarę upływu lat 80. ograniczenia architektoniczne QuickDraw zaczęły narzucać ograniczenia Apple i zewnętrznym programistom.

• Wszystkie publiczne struktury danych QuickDraw przyjmują 16-bitową przestrzeń współrzędnych w postaci liczb całkowitych, bez możliwości stosowania współrzędnych ułamkowych.
• Dodawanie nowych funkcji do QuickDraw było niezwykle trudne ze względu na brak ukrywania danych w API. Centralną strukturą danych w QuickDraw był GrafPort, struktura z wyeksponowanymi wszystkimi zmiennymi składowymi. Co gorsza, struktura GrafPort została zaprojektowana tak, aby można ją było bezpośrednio osadzić w strukturach danych programistów stron trzecich, więc Apple nie mógł dodawać nowych zmiennych. Kolorowy program QuickDraw, wprowadzony w 1987 r., stanowił ogromną różnicę w stosunku do oryginalnego czarno-białego programu QuickDraw. Zwiększyło to złożoność tworzenia aplikacji kolorowych dla komputerów Mac. Na przykład QuickDraw nie mógł łatwo obsługiwać zaawansowanych transformacji graficznych, takich jak obroty i ścinanie, a wprowadzenie nowych typów danych, takich jak krzywe, było niemożliwe.

Tworzenie GX

Wygląda na to, że GX zaczął się okrężnie, pierwotnie jako system czcionek konturowych, który miał zostać dodany do systemu Mac OS. Silnik renderujący czcionki zawierał szereg ogólnie przydatnych rozszerzeń, w szczególności punktów stałych i różne polecenia rysowania krzywych. System zawierał również system „zawijania” istniejących czcionek PostScript Type 1 we własny format wewnętrzny, który dodał wersje podglądu bitmap w celu szybkiego renderowania na ekranie. Projekt ten przyjął później rozszerzoną rolę, gdy Apple i Microsoft zgodził się współpracować w celu stworzenia alternatywy dla czcionek PostScript, które były niezwykle drogie, tworząc projekt TrueType w oparciu o istniejące wysiłki Apple.

Inny projekt, początkowo pozornie niepowiązany, miał na celu rozwiązanie problemów z konwersją z QuickDraw na różne formaty wyjściowe drukarki. Podczas gdy programiści byli wcześniej zmuszeni do napisania własnego kodu, aby przekonwertować wyświetlanie ekranowe QuickDraw na PostScript w celu drukowania, w nowej architekturze drukarek takie konwersje będą zapewniane przez system operacyjny. Ponadto nowy system został celowo zaprojektowany tak, aby był jak najbardziej elastyczny i obsługiwał nie tylko drukarki QD i PS, ale potencjalnie inne standardy, takie jak PCL firmy Hewlett Packard również. System obsługiwał także „drukarki stacjonarne” (drukarki, które pojawiały się jako ikony na pulpicie użytkownika), czego od dawna brakowało w QD, a także dodał ulepszone okna dialogowe i elementy sterujące drukowania.

Nie jest jasne, kiedy projekty się połączyły, ale był to wówczas powszechny motyw w Apple. Menedżerowie średniego szczebla byli zaangażowani w intensywną wojnę o wpływy przez większą część późnych lat 80. i wczesnych 90., łącząc projekty w „duber-projekty”, które zawierały wystarczająco ważny kod, aby uczynić je „nie do zabicia”. Niestety, często dramatycznie opóźniało to realizację projektów; jeden komponent opóźniony w harmonogramie wymusił opóźnienie całej kolekcji, aby można było je udostępnić w stanie „kompletnym”. QuickDraw GX był jedną z takich ofiar, a opóźnienia i zmiany kierunku w TrueType oraz inne problemy znacznie opóźniły wprowadzenie GX.

publikacjach Apple . W tamtym czasie wydawało się, że premiera jest nieuchronna, być może pod koniec 1992 lub na początku 1993 roku.

Wydaj i używaj

GX został pierwotnie wydany około stycznia 1994 roku jako oddzielny pakiet. Wersja 1.1.1 została dołączona do Systemu 7.5 jeszcze w tym samym roku. To się nie udało. Pakiet był wystarczająco duży, aby obciążyć pamięć większości istniejących Macintosh tamtej epoki, a argumenty w rodzaju „możesz teraz drukować w PostScript” nie były imponujące, biorąc pod uwagę, że wiele istniejących programów dodało już taką obsługę. Użytkownicy i programiści generalnie ignorowali GX, a rynek na system po prostu nigdy się nie pojawił.

Wydaje się, że nie ma jednej przyczyny niepowodzenia GX na rynku, ale z pewnością wiele z nich przyczyniło się do zmniejszenia jego atrakcyjności. Po pierwsze, GX był bardzo duży i sam wymagał tyle samo pamięci, co reszta systemu operacyjnego. Problemem była także prędkość, która ograniczała działanie tylko na komputerach Mac z Motorolą 68020 lub lepszą. Biorąc pod uwagę, że zainstalowana wówczas baza komputerów Mac nadal zawierała dużą liczbę 68 000 komputerów, takich jak Mac Plus wymagania te ograniczały liczbę maszyn, na których można było uruchomić. Kiedy został wydany po raz pierwszy, w jednej z recenzji zauważono: „QuickDraw GX nie jest dla wszystkich i wymaga więcej pamięci RAM, niż ma do dyspozycji wiele komputerów Mac”.

Dodatkowo API systemu było bardzo obszerne i zajmowało kilka ksiąg. Wdrożenie programu GX nie było łatwym zadaniem, mimo że jego rozwój miał być znacznie łatwiejszy. Nie był to problem samej architektury GX, ale efekt uboczny „all inclusive” natury systemu - problem, na który cierpiała większość produktów Apple tamtej epoki (patrz na przykład PowerTalk) . W rezultacie atrakcyjność dewelopera była ograniczona; użycie systemu w programach wymagałoby dużego wysiłku, a powstała aplikacja mogłaby działać tylko na podzbiorze zainstalowanej bazy. Liczba systemów opartych na GX (w przeciwieństwie do GX- kompatybilne ) programy o liczbie mniejszej niż sześć, w tym Typestry firmy Pixar i UniQorn firmy Softpress .

Ponadto zmiana systemów drukowania stwarzała poważne problemy w świecie rzeczywistym. Chociaż drukowanie PostScript nigdy nie było łatwe, przez lata od wydania oryginalnego LaserWriter programiści stworzyli bibliotekę rozwiązań typowych problemów. Wraz ze zmianą architektury GX większość z nich przestała działać. Nowe „sterowniki GX” były również potrzebne dla drukarek, a firma Apple nie dostarczyła sterowników do wszystkich swoich drukarek , nie mówiąc już o drukarkach innych firm. Problemy z drukowaniem były zjawiskiem powszechnym i tak trudne do naprawienia, że ​​użytkownicy często sfrustrowani rezygnowali z korzystania z systemu.

Poziom wykorzystania GX przez użytkowników był bardzo bliski zeru, podobnie jak w przypadku większości nowych technologii wprowadzonych przez firmę Apple na początku lat 90. Mógł być szeroko stosowany w ramach Copland , ale Copland nigdy nie został uruchomiony. Chociaż Apple w dalszym ciągu twierdził, że GX jest przyszłością grafiki na komputerach Mac, w 1995 roku stało się jasne, że nie „naciska” już na niego, co frustrowało jego zwolenników.

Mac OS 8 porzucił obsługę architektury drukowania GX, chociaż architektury zarządzania tekstem i zarządzania kolorami przetrwały. Elementy architektury zarządzania tekstem stały się częścią specyfikacji TrueType, a elementy architektury zarządzania kolorami stały się częścią specyfikacji International Color Consortium . Wraz z pojawieniem się systemu Mac OS X fragmenty GX są dostępne w Apple Type Services for Unicode Imaging (ATSUI) oraz w ColorSync , którego format pliku jest identyczny z oryginalnym formatem opracowanym dla GX.

Opis

Grafika

QuickDraw GX opiera się na modelu obiektowym , w którym obiekty graficzne są świadome swojego stanu i za niego odpowiadają. W przeciwieństwie do QuickDraw nie ma uniwersalnego „stanu”, każde polecenie rysowania może odtworzyć stan na podstawie przechowywanych w nim danych lub różnych obiektów „nadrzędnych”. Na przykład programista może zbudować redBox , który najpierw ustawia kolor na czerwony, a następnie rysuje kwadrat. Od tego momentu program nie musi już jawnie ustawiać koloru przed rysowaniem, sam system GX zawsze poprawnie ustawi kolor rysunku, gdy zostanie poproszony o narysowanie redBoxa i zresetuj go po zakończeniu. Ponieważ ten stan był prywatny i w razie potrzeby wysyłany do GX, GX teoretycznie pozwalał systemowi Mac OS na obsługę chronionej pamięci, ponieważ stan nie był już współdzielony bezpośrednio pomiędzy programami i systemem graficznym.

Kontrastuje to mocno z oryginalnym QuickDraw, gdzie za wszystkie zmiany stanu odpowiedzialny był programista. Na przykład, jeśli ktoś narysuje redBox, a następnie serię linii, linie te również pojawią się na czerwono, chyba że programista najpierw wyraźnie zmieni kolor. Zaletą tego podejścia jest to, że minimalizuje liczbę poleceń potrzebnych do ustawienia stanu; programista może organizować rysowanie tak, aby jednocześnie rysować grupy obiektów o podobnym stylu, oszczędzając w ten sposób czas. Wadą tego podejścia jest to, że łatwo jest „zapomnieć” o zmianie stanu, co może spowodować problemy, do tego stopnia, że ​​programiści często zapisali i odtwarzali cały stan przed każdym poleceniem rysowania, co potencjalnie obniżenie wydajności.

Stan rysunku w GX był hierarchiczny. Domyślny tryb rysowania został utworzony dla każdego okna, tak jak miało to miejsce w przypadku QD, a obiekty rysunkowe bez innych zmian stanu będą korzystać z tych ustawień domyślnych. Programista mógłby wtedy zmienić stan samych obiektów, jak w naszym redBox , lub alternatywnie zmienić stan całego rysunku, ustawiając stan w obiekcie okna. Obiekty GX można łatwo zebrać w grupy, same w sobie obiekty, umożliwiając ustawienie stanu całego złożonego obiektu.

Jedną z części ogólnego stanu rysunku był plik gxMapping . Była to macierz 3 na 3 , która mogła wyrażać dowolne przekształcenia liniowe w dwóch wymiarach, w tym zniekształcenia perspektywy . Wszystkie obiekty GX miały skojarzone mapowanie w ramach stanu rysowania, co pozwalało na takie rzeczy, jak obroty i translacje. Chociaż cały ten stan był przechowywany w gxMapping dla tego obiektu, GX dostarczył również polecenia „opakowania”, takie jak „obróć”, aby ułatwić korzystanie z API .

W przeciwieństwie do QuickDraw, QuickDraw GX umożliwiał współrzędne ułamkowe. Były to jednak stałoprzecinkowe , a nie zmiennoprzecinkowe . W czasie opracowywania GX (od końca lat 80. do początku lat 90.) stosowanie arytmetyki zmiennoprzecinkowej nadal powodowało znaczny spadek wydajności.

Architektura graficzna GX została zbudowana wokół wielu typów gotowych obiektów, chociaż dostępny był pełny zestaw wywołań API do ich badania i manipulowania:

• gxShape definiuje podstawową geometrię kształtu (na przykład współrzędne punktów kontrolnych krzywej lub zawartość tekstową obiektu tekstowego) .
• w gxStyle opracowanie podstawowej geometrii kształtu, takiej jak grubość linii, style zakończeń i połączeń, wzór wypełnienia i czcionka tekstu.
• gxInk określił, w jaki sposób wartości pikseli mają być obliczane podczas renderowania kształtu: oprócz określenia podstawowego koloru kształtu, obejmowało to również skomplikowaną strukturę trybu transferu , która mogła definiować szeroką gamę funkcji początkowej i końcowej docelowej wartości piksela.
• gxFont reprezentował czcionkę, albo zainstalowaną do użytku ogólnosystemowego, albo zainstalowaną w locie przez bieżącą aplikację na własny użytek. Wywołania API umożliwiły sprawdzenie właściwości czcionki, w tym określenie, jakie kodowanie (Unicode, specyficzne dla języka itp.) może obsługiwać.
• gxProfile był reprezentacją profilu kolorów ColorSync, używaną jako część specyfikacji koloru do rysowania . Zintegrowana z GX pełna obsługa dopasowywania kolorów na wszystkich etapach procesu rysowania, a także obsługa specyfikacji kolorów innych niż RGB (takich jak HSV , YUV i CIE XYZ).
• gxTransform określił związek pomiędzy kształtem a urządzeniem wyświetlającym. Oprócz ścieżki przycinania i gxMapping, które przekształcały kształt przed wyświetleniem na urządzeniu wyjściowym, obiekt ten określał również informacje dotyczące testowania trafień , które kontrolowały reakcje na kliknięcia użytkownika w obszarze kształtu.
• gxViewDevice reprezentowało blok pamięci pikseli, w którym renderowany byłby rysunek . Może to być rzeczywisty obraz wyświetlany na ekranie lub blok pamięci poza ekranem. GX obsługiwał wszystkie QuickDraw ; umożliwiło to zarówno urządzeniu przeglądającemu GX, jak i QuickDraw GrafPort wskazanie tych samych pikseli, umożliwiając w ten sposób aplikacjom mieszanie obu zestawów wywołań rysunkowych.
• gxViewPort był logicznym miejscem docelowym do rysowania . GxTransform może określić listę więcej niż jednego z nich; kształt zostanie wciągnięty do nich wszystkich w jednym GXDrawShape .
• gxViewGroup reprezentowała połączenie pomiędzy urządzeniami widokowymi i portami widokowymi . Każdy port widoku miał gxMapping określający jego związek z globalnym układem współrzędnych grupy widoków; a każde urządzenie widokowe miało gxMapping, które określało jego lokalizację i rozmiar pikseli w odniesieniu do współrzędnych grupy widoków. Istniała jedna predefiniowana grupa widoków, która zawierała wszystkie urządzenia wyświetlające na ekranie (i których porty widokowe faktycznie odpowiadały oknom ekranowym); aplikacje mogły swobodnie tworzyć własne grupy widoków dla urządzeń z widokiem poza ekranem i portów widoku.
• gxTag umożliwiał dołączanie dowolnych informacji zdefiniowanych przez aplikację do większości powyższych typów obiektów . Każdy znacznik miał kod typu OSType , ale do tego samego obiektu mogło być dołączonych wiele znaczników tego samego typu.

Typy kształtów

Kształty GX mogą być różnych typów:

• linia prosta określona przez jej punkty końcowe.
• prostokąt zdefiniowany przez jego lewą, prawą, górną i dolną granicę.
• wielokąt zdefiniowany przez sekwencję współrzędnych wierzchołków.
• kształt krzywej był pojedynczą kwadratową krzywą Béziera określoną przez trzy punkty kontrolne.
• kształt ścieżki będący ciągiem kwadratowych krzywych Béziera . Każdy punkt kontrolny miał powiązaną flagę wskazującą, czy znajduje się na krzywej, czy poza krzywą. Punkt na krzywej był punktem końcowym Béziera, natomiast punkt poza krzywą był punktem środkowym Béziera. Jeżeli napotkano dwa kolejne punkty poza krzywą, zakładano, że ukryty punkt na krzywej leży w połowie odległości między nimi. Dwa kolejne punkty na krzywej wyznaczały odcinek linii prostej.
• mapy bitowej zawierał dane rastrowe w dowolnym obsługiwanym formacie pikseli.
• kształt obrazu był zgrupowaniem innych kształtów (ewentualnie obejmującym rekurencyjne kształty obrazu), z możliwością określenia dodatkowych przekształceń mających zastosowanie do całej grupy.
• różne typy kształtów typograficznych opisano w poniższej sekcji Typografia GX.
• dodatkowe typy, które być może nie były bezpośrednio przydatne do rysowania, ale można je było łączyć z innymi kształtami w obliczeniach geometrii: pusty kształt (którego rysowanie nic nie dało); kształt punktowy składający się z pojedynczego punktu; i pełny kształt (o nieskończonym zakresie).

Typografia

Zobacz także: Zaawansowana typografia Apple

Funkcje typograficzne GX zostały zintegrowane w postaci 3 typów gxShape:

• Kształty tekstowe były najprostsze: zawierały pojedynczy ciąg tekstu renderowanego jednym stylem czcionki.
• Kształty glifów były sposobem na wykorzystanie kształtów znaków („ glifów ”) jako czystej geometrii, na przykład jako ścieżek przycinających .
• Kształty układów były najbardziej wyszukane. Można je podzielić na wiele serii z różnymi stylami czcionek, a nawet różnymi kodowaniami językowymi i kierunkami tekstu. W ten sposób możliwe było osadzenie sekwencji tekstu arabskiego, renderowanego od prawej do lewej, w zewnętrznej sekwencji tekstu rzymskiego od lewej do prawej. Kształty układu uwolniły pełną moc podstawień kontekstowych, kerningu, odmian i wszystkich innych możliwości czcionek TrueType GX. Ich głównym ograniczeniem było to, że ograniczały się do jednej linijki tekstu.

Interfejs API GX zapewniał także funkcje testowania trafień, więc na przykład, jeśli użytkownik kliknie kształt układu pośrodku ligatury lub w obszarze pomiędzy zmianą kierunku tekstu, sam GX zapewni inteligentne określenie, który znak pozycja w tekście oryginalnym odpowiadała kliknięciu.

TrueType GX

W GX wprowadzono ważne rozróżnienie pomiędzy znakiem a glifem , rozróżnienie to występuje również w standardzie Unicode. Znak „ f” w systemie pisma łacińskiego. Natomiast glif był określonym kształtem graficznym z określonej czcionki, niezależnie od tego, czy kształt reprezentował pojedynczy znak, czy zestaw znaków. Na przykład czcionka Hoefler Text zawierała glify reprezentujące litery „f” i „l”. Miał również inny glif reprezentujący ligaturę „fl”, który mógł być komponowany automatycznie (zamiast pojedynczych glifów) wszędzie tam, gdzie dwa abstrakcyjne znaki „f” i „l” wystąpiły po kolei w tekście źródłowym.

To rozróżnienie było ważne, ponieważ takie podstawienia kontekstowe miały miejsce w czasie renderowania, bez żadnych zmian w źródłowym ciągu znaków. Nie miały zatem żadnego wpływu na redakcję i wyszukiwanie tekstu. Pliki czcionek PostScript Type 1 mają tylko odwzorowania jeden do jednego, a ponieważ ligatury mają odwzorowania wiele do jednego, nie można ich wstawić do kompozycji bez zmiany źródłowego ciągu znaków, na przykład ligatura ffi jest umieszczana na pozycji dużej litery Y w produktach czcionek Adobe, a „Adobe Offices” tworzy się, wpisując „Adobe O” „T” „ces”. W układzie ciąg znaków jest uszkodzony, a w formacie PDF utworzonym ze strumieniowego PostScriptu znaki f+f+i można zrekonstruować tylko wtedy, gdy nazwa glifu jest zgodna z listą nazewnictwa glifów.

Podstawienia kontekstowe można kontrolować, włączając lub wyłączając opcje kompozycji czcionki TrueType GX w programie WorldText na płycie CD z systemem Mac OS 9 lub w programie TextEdit w systemie Mac OS X. Czcionki często mają funkcje zwane „wspólnymi ligaturami” (np. przykład „fl” ), „rzadkie ligatury” (takie jak ligatury inskrypcyjne ME i MD), „archaiczne nieterminalne s” (do automatycznego zastępowania litery „s” archaiczną formą, która bardziej przypominała „f”, z wyjątkiem końcówek słowa), a nawet wybór pomiędzy całkowicie oddzielnymi zestawami projektów glifów, takimi jak formy mniej i bardziej ozdobne.

Reguły wykonywania podstawień kontekstowych są implementowane jako maszyny stanu wbudowane w czcionkę i interpretowane przez LLM Line Layout Manager, odpowiednik modułu zarządzania kolorami CMM dla usług ColorSync. Zarządzanie tekstem w systemie operacyjnym umożliwiło QuickDraw GX akceptowanie ciągów znaków z dowolną kombinacją systemów zapisu i skryptów oraz automatyczne komponowanie ciągów, niezależnie od tego, czy kodowanie było Unicode 1.0, czy 8-bitowe i 8/16-bitowe.

Inną interesującą funkcją były „wariacje” czcionek, które były odpowiednikiem GX czcionek „ multiple master ” firmy Adobe. Podczas gdy czcionki Adobe wymagały, aby użytkownik jawnie utworzył „instancję” czcionki poprzez określenie wartości osi wariacji, zanim mógł z niej skorzystać, GX umożliwił użytkownikowi określenie czcionki bezpośrednio dla stylu układu, a następnie dynamiczną zmianę wartości osi i natychmiast obserwuj wpływ na układ tekstu.

Technologia ta stała się podstawą tego, co Microsoft i Adobe wdrożą w 2016 roku wraz z opracowaniem czcionek zmiennych OpenType .

Deweloperzy

Cary Clark był architektem i kierownikiem technicznym QuickDraw GX. Pracował nad Color QuickDraw , a następnie został jednym z pierwszych członków Rocket Science Games i WebTV. Keith McGreggor był menadżerem grupy graficznej i głównym twórcą architektury kolorów dla QuickDraw GX, a Robert Johnson był matematykiem-rezydentem.

Inni programiści biorący udział w projekcie to:

• Tomek Dowdy
• Michaela Fairmana
• Davida Van Brinka
• Chrisa Yergę
• Olivera Steele’a
• Dave Dobry
• Pablo Fernicola

TrueType GX

Dave G. Opstad był architektem silnika typograficznego i tabel kształtujących czcionki Apple. Następnie został dyrektorem technicznym w Monotype Imaging. Inni, którzy pracowali nad TrueType GX, to:

• Erica Madera
• Sampo Kasila
• Mike'a Reeda
• Arlo

Linki zewnętrzne

• QuickDraw GX — dokumentacja Apple GX w Internecie