QuickDraw GX

مع مرور ثمانينيات القرن الماضي، بدأت القيود المعمارية لبرنامج QuickDraw تفرض قيودًا على شركة Apple ومطوري الطرف الثالث. ^{[ 3 ]}

• تعتمد جميع هياكل البيانات العامة في QuickDraw على فضاء إحداثيات صحيح مكون من 16 بت، دون أي دعم للإحداثيات الكسرية. ^{[ 4 ]}
• كانت إضافة ميزات جديدة إلى QuickDraw بالغة الصعوبة بسبب عدم وجود آلية لإخفاء البيانات في واجهة برمجة التطبيقات (API). كان هيكل البيانات المركزي في QuickDraw هو GrafPort، وهو هيكل يعرض جميع متغيراته. والأسوأ من ذلك، أن هيكل GrafPort صُمم ليتم تضمينه مباشرةً في هياكل بيانات مطوري الطرف الثالث، مما حال دون إضافة Apple لمتغيرات جديدة. أما QuickDraw الملون، الذي طُرح عام 1987، فكان حلاً ترقيعياً ضخماً فوق QuickDraw الأصلي بالأبيض والأسود. وقد زاد هذا من تعقيد تطوير تطبيقات الألوان لأجهزة Mac. ^{[ 4 ]} على سبيل المثال، لم يكن QuickDraw يدعم بسهولة تحويلات الرسومات المتقدمة مثل الدوران والقص، وكان من المستحيل إضافة أنواع بيانات جديدة مثل المنحنيات. ^{[ 5 ]}

يبدو أن نظام GX قد بدأ بطريقة غير مباشرة، حيث كان في الأصل نظامًا لخطوط الخطوط الخارجية يُضاف إلى نظام التشغيل Mac OS. تضمن محرك عرض الخطوط عددًا من الإضافات المفيدة، أبرزها نظام إحداثيات النقطة الثابتة ومجموعة متنوعة من أوامر رسم المنحنيات. كما تضمن النظام آلية لدمج خطوط PostScript Type 1 الموجودة في تنسيقه الداخلي، مما أضاف إصدارات معاينة نقطية لعرض سريع على الشاشة. لاحقًا، توسع دور هذا المشروع عندما اتفقت شركتا آبل ومايكروسوفت على التعاون لإنشاء بديل لخطوط PostScript، التي كانت باهظة الثمن، مما أدى إلى ظهور مشروع TrueType استنادًا إلى جهود آبل القائمة.

مشروع آخر، بدا في البداية غير ذي صلة، سعى إلى معالجة مشاكل التحويل من برنامج QuickDraw إلى صيغ إخراج الطباعة المختلفة. فبينما كان المطورون سابقًا مضطرين لكتابة أكوادهم الخاصة لتحويل عرض QuickDraw على الشاشة إلى PostScript للطباعة، فإن نظام التشغيل سيوفر هذه التحويلات في بنية الطابعة الجديدة. إضافةً إلى ذلك، صُمم النظام الجديد عمدًا ليكون مرنًا قدر الإمكان، إذ يدعم ليس فقط طابعات QD وPS، بل أيضًا معايير أخرى محتملة مثل PCL من Hewlett-Packard . كما يدعم النظام "طابعات سطح المكتب" (الطابعات التي تظهر كأيقونات على سطح مكتب المستخدم)، وهي ميزة طال انتظارها كانت مفقودة في QD، وأضاف مربعات حوار وعناصر تحكم محسّنة للطباعة.

ليس من الواضح متى تم دمج المشاريع، لكن هذا كان نمطًا شائعًا في شركة آبل آنذاك. انخرط مديرو المستوى المتوسط ​​في صراعٍ محموم على النفوذ خلال معظم أواخر الثمانينيات وأوائل التسعينيات، حيث جمعوا المشاريع في "مشاريع ضخمة" تحتوي على قدرٍ كافٍ من التعليمات البرمجية المهمة لجعلها "غير قابلة للإلغاء". وللأسف، غالبًا ما أدى ذلك إلى تأخير المشاريع بشكلٍ كبير؛ فتأخر أحد المكونات عن الموعد المحدد أجبر على تأجيل المجموعة بأكملها حتى يتم إصدارها "كاملة". كان برنامج QuickDraw GX أحد هذه المشاريع، وقد أدت التأخيرات وتغييرات التوجه في تقنية TrueType وغيرها من المشاكل إلى تأخير كبير في طرح GX.

بدأت مناقشات تقنية GX بالظهور في العديد من المجلات التجارية حوالي عام 1992، ولا سيما مجلة التطوير الخاصة بشركة آبل . في ذلك الوقت، بدا أن الإصدار وشيك، ربما أواخر عام 1992 أو أوائل عام 1993.

صدرت GX مبدئيًا في يناير 1994 تقريبًا، كحزمة منفصلة. ثم أُدمج الإصدار 1.1.1 مع نظام التشغيل System 7.5 في وقت لاحق من ذلك العام، ولم يحقق نجاحًا. كانت الحزمة كبيرة الحجم لدرجة أنها أرهقت ذاكرة معظم أجهزة ماكنتوش الموجودة آنذاك، ولم تكن مزايا مثل "يمكنك الآن الطباعة إلى PostScript" مقنعة بالنظر إلى أن العديد من البرامج الأخرى كانت تدعم هذه الميزة بالفعل. تجاهل المستخدمون والمطورون GX عمومًا، ولم يظهر سوق لهذا النظام أبدًا.

لا يزال سبب فشل برنامج GX في السوق مجهولاً. فمن جهة، كان حجمه كبيرًا جدًا، إذ كان يستهلك وحده ذاكرةً تعادل حجم ذاكرة نظام التشغيل. ^{[ 6 ]} كما شكلت السرعة عائقًا، ما حدّ من إمكانية تشغيله على أجهزة ماك المزودة بمعالج موتورولا 68020 أو أحدث. ونظرًا لأن قاعدة مستخدمي ماك آنذاك كانت لا تزال تضم أعدادًا كبيرة من الأجهزة التي تعمل بمعالج 68000، مثل ماك بلس ، فقد حدّت هذه المتطلبات من عدد الأجهزة التي يمكن تشغيله عليها. عند إصداره لأول مرة، أشارت إحدى المراجعات إلى أن "برنامج QuickDraw GX ليس مناسبًا للجميع، ويتطلب ذاكرة وصول عشوائي (RAM) أكبر مما يتوفر في العديد من أجهزة ماك". ^{[ 7 ]}

بالإضافة إلى ذلك، كانت واجهة برمجة التطبيقات (API) للنظام ضخمة للغاية، لدرجة أنها ملأت عدة كتب. لم يكن تنفيذ برنامج GX بالأمر الهين، على الرغم من أنه كان من المفترض أن يكون التطوير أسهل. لم تكن هذه مشكلة في بنية GX نفسها، بل كانت أثرًا جانبيًا لطبيعة النظام "الشاملة" - وهي مشكلة عانت منها معظم منتجات Apple في تلك الحقبة (انظر PowerTalk على سبيل المثال). ونتيجة لذلك، كان إقبال المطورين محدودًا؛ إذ تطلب استخدام النظام في البرامج جهدًا كبيرًا، ولم يكن التطبيق الناتج يعمل إلا على مجموعة فرعية من قاعدة المستخدمين المثبتة. لم يتجاوز عدد البرامج القائمة على GX (مقارنةً بالبرامج المتوافقة مع GX) ستة برامج، بما في ذلك Typestry من Pixar ^{[ 8 ]} و UniQorn من Softpress ^{[ 9 ]} .

بالإضافة إلى ذلك، تسبب تغيير أنظمة الطباعة في مشاكل حقيقية خطيرة. فبينما لم تكن طباعة PostScript سهلة قط، إلا أن المطورين، على مر السنين منذ إصدار طابعة LaserWriter الأصلية ، قد جمعوا مكتبة من الحلول للمشاكل الشائعة. ومع تغيير بنية GX، توقف معظم هذه الحلول عن العمل. كما تطلب الأمر برامج تشغيل جديدة خاصة بـ GX للطابعات، ولم توفر Apple برامج تشغيل لجميع طابعاتها ، ناهيك عن طابعات الجهات الخارجية. كانت مشاكل الطباعة متفشية، ويصعب حلها لدرجة أن المستخدمين غالبًا ما كانوا يتخلون عن النظام بسبب الإحباط.

كان إقبال المستخدمين على GX شبه معدوم، كما هو الحال مع معظم التقنيات الجديدة التي أطلقتها آبل في أوائل التسعينيات. ربما كان من الممكن أن ينتشر استخدامه على نطاق واسع كجزء من مشروع كوبلاند ، لكن كوبلاند لم يُطلق أبدًا. على الرغم من استمرار آبل في التأكيد على أن GX هو مستقبل الرسومات على أجهزة ماك، إلا أنه بحلول عام ١٩٩٥ كان من الواضح أنها لم تعد تدعمه بقوة، مما أثار استياء مؤيديه.

أسقط نظام التشغيل Mac OS 8 دعم بنية الطباعة GX، مع بقاء بنيتي إدارة النصوص وإدارة الألوان. أصبحت عناصر من بنية إدارة النصوص جزءًا من مواصفات TrueType، بينما أصبحت عناصر من بنية إدارة الألوان جزءًا من مواصفات اتحاد الألوان الدولي . مع ظهور نظام التشغيل Mac OS X، لا تزال أجزاء من GX موجودة في خدمات Apple Type Services for Unicode Imaging (ATSUI)، وفي ColorSync ، الذي يتطابق تنسيق ملفاته مع التنسيق الأصلي المُطور لـ GX.

يعتمد QuickDraw GX على نموذج كائني التوجه، حيث تكون كائنات الرسومات واعية بحالتها ومسؤولة عنها. على عكس QuickDraw، لا توجد "حالة" عامة، إذ يمكن لكل أمر رسم إعادة بناء الحالة من البيانات المخزنة بداخله أو من كائنات "أصلية" مختلفة. على سبيل المثال، يمكن للمبرمج إنشاء كائن redBoxيضبط اللون أولاً إلى الأحمر، ثم يرسم مربعًا. من تلك اللحظة، لم يعد البرنامج بحاجة إلى تحديد اللون صراحةً قبل الرسم، إذ سيقوم نظام GX تلقائيًا بضبط لون الرسم بشكل صحيح عند طلب رسم مربع redBox، وإعادة ضبطه عند الانتهاء. ولأن هذه الحالة كانت خاصة، وتُرسل إلى GX عند الحاجة، فقد سمح GX نظريًا لنظام التشغيل Mac OS بدعم الذاكرة المحمية، حيث لم تعد الحالة تُشارك مباشرةً بين البرامج ونظام الرسومات.

يختلف هذا اختلافًا كبيرًا عن برنامج QuickDraw الأصلي، حيث كان المبرمج مسؤولاً عن جميع تغييرات الحالة. على سبيل المثال، إذا رُسم مربع أحمر ثم سلسلة من الخطوط، فستظهر الخطوط باللون الأحمر أيضًا ما لم يُغير المبرمج اللون صراحةً أولًا. ميزة هذا الأسلوب هي تقليل عدد الأوامر اللازمة لضبط الحالة؛ إذ يُمكن للمبرمج تنظيم الرسم لرسم مجموعات من الكائنات ذات الأنماط المتشابهة في الوقت نفسه، وبالتالي توفير الوقت. أما عيب هذا الأسلوب فهو سهولة نسيان تغيير الحالة، مما قد يُسبب مشاكل، لدرجة أن المبرمجين غالبًا ما كانوا يحفظون ويستعيدون الحالة الكاملة قبل كل أمر رسم، مما قد يُؤدي إلى انخفاض الأداء.

كانت حالة الرسم في GX هرمية. يتم إنشاء وضع رسم افتراضي مع كل نافذة، كما هو الحال في QD، وتستخدم كائنات الرسم التي لا تخضع لأي تغييرات أخرى في الحالة هذه الإعدادات الافتراضية. يمكن للمبرمج بعد ذلك تغيير الحالة في الكائنات نفسها، كما في مثالنا redBox، أو بدلاً من ذلك تغيير حالة الرسم بالكامل عن طريق تعيين الحالة في كائن النافذة. يمكن تجميع كائنات GX بسهولة في مجموعات، وهي نفسها كائنات، مما يسمح بتعيين الحالة لكائن معقد بأكمله.

كان أحد مكونات حالة الرسم العامة هو مصفوفةgxMapping 3×3 التي تُتيح التعبير عن التحويلات الخطية في بُعدين، بما في ذلك تشوهات المنظور . كانت جميع كائنات GX مرتبطةً بتخطيط ضمن حالة الرسم الخاصة بها، مما يسمح بإجراء عمليات مثل التدوير والانتقال. وعلى الرغم من أن هذه الحالة كانت مُخزّنة في مصفوفة الكائن، إلا أن GX وفّرت أيضًا أوامر "تغليف" مثل "تدوير" لتسهيل استخدام واجهة برمجة التطبيقات (API) .gxMapping

على عكس برنامج QuickDraw، سمح برنامج QuickDraw GX باستخدام الإحداثيات الكسرية. مع ذلك، كانت هذه القيم من نوع الفاصلة الثابتة ، وليست من نوع الفاصلة العائمة . في الفترة التي كان يجري فيها تطوير GX (أواخر الثمانينيات إلى أوائل التسعينيات)، كان استخدام حسابات الفاصلة العائمة لا يزال يُؤثر سلبًا على الأداء بشكل ملحوظ.

تم بناء بنية الرسومات GX حول عدد من أنواع الكائنات الجاهزة مسبقًا، على الرغم من توفر مجموعة كاملة من استدعاءات واجهة برمجة التطبيقات (API) لفحصها ومعالجتها:

• يُعرّف gxShape الهندسة الأساسية للشكل (على سبيل المثال، إحداثيات نقاط التحكم لمنحنى، أو محتوى النص لكائن نصي).
• يُعرّف نمط gxStyle تفاصيل هندسة الشكل الأساسية، مثل سمك الخط، وأنماط الفتح والإغلاق، ونمط التعبئة، ونوع خط النص.
• يحدد gxInk كيفية حساب قيم البكسل عند عرض الشكل: إلى جانب تحديد لون أساسي للشكل، يتضمن هذا أيضًا بنية وضع نقل مفصلة يمكنها تحديد مجموعة واسعة من وظائف قيمة البكسل الأولية والنهائية للوجهة.
• يمثل gxFont خطًا ، إما خطًا مثبتًا للاستخدام على مستوى النظام، أو خطًا مثبتًا ديناميكيًا بواسطة التطبيق الحالي لاستخدامه الخاص. تسمح استدعاءات واجهة برمجة التطبيقات (API) بالاستعلام عن خصائص الخط، بما في ذلك تحديد الترميزات التي قد يدعمها (يونيكود، ترميزات خاصة بلغة معينة، إلخ).
• كان ملف تعريف gxProfile عبارة عن تمثيل لملف تعريف ألوان ColorSync، والذي يُستخدم كجزء من تحديد لون للرسم. وقد دمجت GX دعمًا كاملاً لمطابقة الألوان في جميع مراحل عملية الرسم، بالإضافة إلى دعم مواصفات الألوان غير RGB (مثل HSV و YUV و CIE XYZ).
• تحدد دالة gxTransform العلاقة بين الشكل وجهاز العرض. فإلى جانب مسار القص ودالة gxMapping اللتين تُحوّلان الشكل قبل عرضه على جهاز الإخراج، تُحدد هذه الدالة أيضًا معلومات اختبار النقر التي تتحكم في استجابات نقرات المستخدم داخل منطقة الشكل.
• يمثل gxViewDevice كتلة من ذاكرة البكسل التي يتم فيها عرض الرسم. قد تكون هذه الكتلة شاشة عرض فعلية، أو كتلة ذاكرة خارج الشاشة. يدعم GX جميع تخطيطات بكسل QuickDraw ؛ مما يسمح لكل من جهاز عرض GX و QuickDraw GrafPort بالإشارة إلى نفس البكسلات، وبالتالي يسمح للتطبيقات بدمج مجموعتي استدعاءات الرسم.
• كان gxViewPort وجهة منطقية للرسم. يمكن لـ gxTransform تحديد قائمة تضم أكثر من واحد من هذه الوجهات؛ وسيتم رسم الشكل في جميعها في GXDrawShapeاستدعاء واحد.
• تمثل مجموعة gxViewGroup الاتصال بين أجهزة العرض ومنافذ العرض. يحتوي كل منفذ عرض على gxMapping يحدد علاقته بنظام الإحداثيات العالمي لمجموعة العرض؛ ويحتوي كل جهاز عرض على gxMapping يحدد موقعه وحجم وحدات البكسل الخاصة به بالنسبة لإحداثيات مجموعة العرض. توجد مجموعة عرض واحدة مُعرَّفة مسبقًا تحتوي على جميع أجهزة العرض الظاهرة على الشاشة (وتتوافق منافذ عرضها فعليًا مع النوافذ الظاهرة على الشاشة)؛ ويمكن للتطبيقات إنشاء مجموعات عرض خاصة بها لأجهزة العرض ومنافذ العرض غير الظاهرة على الشاشة.
• تسمح علامة gxTag بإضافة معلومات مُعرَّفة من قِبل التطبيق إلى معظم أنواع الكائنات المذكورة أعلاه. لكل علامة رمز نوع OSType ، ولكن يمكن إضافة عدة علامات من نفس النوع إلى نفس الكائن.

تم دمج خصائص الطباعة الخاصة بـ GX في شكل 3 أنواع من gxShape:

• كانت أشكال النصوص هي الأبسط: فقد احتوت على سلسلة واحدة من النصوص معروضة بنمط خط واحد.
• كانت أشكال الرسوم المتحركة وسيلة لاستخدام أشكال الأحرف (" الرسوم المتحركة ") كهندسة خالصة، على سبيل المثال كمسارات قص .
• كانت أشكال التخطيط الأكثر تعقيدًا. إذ يمكن تقسيمها إلى عدة أقسام بأنماط خطوط مختلفة، وحتى بتشفيرات لغوية واتجاهات نصية مختلفة. وهكذا، كان من الممكن تضمين سلسلة من النصوص العربية، مكتوبة من اليمين إلى اليسار، داخل سلسلة خارجية من النصوص اللاتينية المكتوبة من اليسار إلى اليمين. أطلقت أشكال التخطيط العنان للإمكانيات الكاملة للاستبدالات السياقية، والتباعد بين الأحرف، والتنويعات، وجميع القدرات الأخرى لخطوط TrueType GX. وكان قيدها الرئيسي هو اقتصارها على سطر نصي واحد.

كما وفرت واجهة برمجة التطبيقات GX وظائف اختبار النقر، بحيث إذا نقر المستخدم على شكل تخطيط في منتصف حرف متصل ، أو في المنطقة الواقعة بين تغيير اتجاه النص، فإن GX نفسها ستوفر الذكاء لتحديد موضع الحرف في النص الأصلي الذي يتوافق مع النقر.

كان هناك تمييز هام في لغة GX بين الحرف والرمز ، وهو تمييز موجود أيضًا في معيار يونيكود. الحرف هو رمز مجرد من مجموعة أحرف نظام الكتابة، مثل الحرف "f" في أنظمة الكتابة اللاتينية. أما الرمز فهو شكل رسومي محدد من خط معين، سواء كان يمثل حرفًا واحدًا أو مجموعة أحرف. فعلى سبيل المثال، احتوى خط Hoefler Text على رموز لتمثيل الحرفين "f" و"l". كما احتوى على رمز آخر لتمثيل الربط "f" و"l" ، والذي يمكن تركيبه تلقائيًا (بدلاً من الرموز الفردية) أينما ورد الحرفان المجردان "f" و"l" متتاليين في النص الأصلي.

كان هذا التمييز مهمًا لأن هذه الاستبدالات السياقية تحدث أثناء عملية العرض، دون أي تغييرات على سلسلة الأحرف الأصلية. وبالتالي، لم يكن لها أي تأثير على تحرير النص أو البحث فيه. تحتوي ملفات خطوط PostScript Type 1 على مطابقة واحدة لواحد فقط، وبما أن الوصلات عبارة عن مطابقة متعددة لواحد، فلا يمكن إدراجها في التصميم دون تغيير سلسلة الأحرف الأصلية. على سبيل المثال، يتم وضع الوصلة ffi في موضع الحرف Y الكبير في منتجات خطوط Adobe، ويتم تكوين "Adobe Offices" بكتابة "Adobe O" <تغيير الخط> "Y" <تغيير الخط> "ces". في التخطيط، تكون سلسلة الأحرف مكسورة، وفي ملفات PDF المُنشأة من PostScript المتدفق، لا يمكن إعادة بناء الأحرف f+f+i إلا إذا كان اسم الرمز يتبع قائمة تسمية الرموز.

يمكن التحكم في عمليات الاستبدال السياقية عن طريق تمكين أو تعطيل خيارات التكوين لخط TrueType GX في WorldText على قرص Mac OS 9 أو في TextEdit في Mac OS X. تحتوي الخطوط عادةً على ميزات تسمى "الوصلات الشائعة" (مثل مثال "fl")، و"الوصلات النادرة" (مثل وصلات ME وMD النقشية)، و"s غير الطرفية القديمة" (للاستبدال التلقائي للحرف "s" بالشكل القديم الذي يشبه الحرف "f"، باستثناء نهايات الكلمات)، وحتى خيارات بين مجموعات منفصلة تمامًا من تصميمات الأحرف، مثل الأشكال الأكثر والأقل زخرفة.

تُطبَّق قواعد إجراء الاستبدالات السياقية كآلات حالة مُدمجة في الخط، ويتم تفسيرها بواسطة مدير تخطيط الخطوط LLM، وهو نظير وحدة إدارة الألوان CMM لخدمات ColorSync. سمحت إدارة النصوص في نظام التشغيل لبرنامج QuickDraw GX بقبول سلاسل الأحرف بأي مزيج من أنظمة الكتابة والنصوص، وتكوين السلاسل تلقائيًا، سواءً كان الترميز Unicode 1.0 أو ترميزات 8  بت و8/16 بت. 

ومن الميزات الأخرى المثيرة للاهتمام "تنوعات" الخطوط، والتي كانت بمثابة المكافئ في GX لخطوط " النسخ الرئيسية المتعددة " من Adobe. فبينما كانت خطوط Adobe تتطلب من المستخدم إنشاء "نسخة" من الخط صراحةً عن طريق تحديد قيم محاور التنوع قبل استخدامه، سمح GX للمستخدم بتحديد الخط مباشرةً لنمط التخطيط، ثم تغيير قيم المحاور ديناميكيًا وملاحظة التأثير على تخطيط النص فورًا.

أصبحت هذه التقنية جوهر ما ستتبناه مايكروسوفت وأدوبي في عام 2016، من خلال تطويرها لخطوط OpenType المتغيرة .

كان ديف جي. أوبستاد مهندس محرك الطباعة وجداول التشكيل في خطوط أبل. ثم أصبح قائدًا تقنيًا في شركة مونوتيب إيميجينج. ومن بين الذين عملوا على ترو تايب جي إكس:

• إريك مادير
• سامبو كاسيلا
• مايك ريد
• أرلو