agl specification
Version 2.9
© 1997-2019 Adobe.
يتم منح الإذن بموجب هذا ، مجانًا ، لأي شخص يحصل على نسخة من ملف الوثائق هذا لاستخدام نسخ ونسخها ونشرها وتوزيعها و/أو بيعها من الوثائق ، والسماح للآخرين بفعل الشيء نفسه ، بشرط:
لا يُسمح بأي تعديل أو تحرير أو تغيير آخر لهذا المستند ؛ و
يجب إدراج إشعار حقوق الطبع والنشر أعلاه ويجب تضمين إشعار الإذن هذا في جميع نسخ الوثائق.
يتم منح الإذن بموجب هذا ، مجانًا ، لأي شخص يحصل على نسخة من ملف الوثائق هذا ، لإنشاء أعمال مشتقة خاصة بها من محتوى هذا المستند لاستخدام ونسخ أو نشر وتوزيع و/أو بيع و/أو بيع الأعمال المشتقة ، والسماح للآخرين بفعل الشيء نفسه ، شريطة أن يتم تمثيل العمل المستمد من أن تكون نسخة أو نسخة من هذه الوثيقة.
لن يكون Adobe مسؤولاً عن أي طرف عن أي خسارة في الإيرادات أو الربح أو عن الأضرار غير المباشرة أو العرضية أو الخاصة أو التبعية أو الأخرى أو غيرها من الأضرار المماثلة ، سواء كانت تستند إلى الضرر (بما في ذلك على سبيل المثال لا الحصر إهمال أو مسؤولية صارمة) ، أو عقد أو أسباب قانونية أو منصفة أخرى حتى لو كان قد تم إخطار Adobe أو لديها سبب لمعرفة إمكانية مثل هذه الأدوار. يتم توفير مواد Adobe على أساس "كما هو". يتنازل Adobe على وجه التحديد من جميع الضمانات الصريحة أو القانونية أو الضمنية المتعلقة بمواد Adobe ، بما في ذلك على سبيل المثال لا الحصر تلك المتعلقة بالتسويق أو اللياقة لغرض معين أو عدم تعبير أي حقوق طرف ثالث فيما يتعلق بمواد Adobe.
لا يحمل Adobe أي براءات اختراع حول موضوع هذه المواصفات.
إصدار المستند 2.9. آخر تحديث 21 أغسطس 2019
الغرض من مواصفات قائمة Adobe Glyph هو وصف حساب سلسلة أحرف Unicode من سلسلة من أسماء الحروف المرئية. يتم تحقيق ذلك من خلال تحديد رسم خرائط من أسماء Glyph إلى سلاسل أحرف Unicode.
يهدف التعيين إلى تحويل تسلسل من الأسماء الحربية إلى نص عادي مع الحفاظ على الدلالات الأساسية. على سبيل المثال ، سيتم تعيين اسم "A" ، اسم "العاصمة الصغيرة" ، واسم الرحم لمتغير "A" "A" إلى نفس الأشعة فوق البنفسجية ( قيمة Unicode ). يعد هذا مفيدًا في نسخ النص في بعض البيئات ، وهو مفيد أيضًا لإجراء عمليات البحث النصية التي ستتطابق مع جميع أسماء الهربس في السلسلة الأصلية التي تتوافق مع "A".
يقع خارج نطاق هذه المواصفات لتحديد مجموعة أسماء الحرب الرمزية القانونية. تحدث أسماء الرسول الرسومية في العديد من السياقات المختلفة ، كل منها له تعريفه الخاص لما يشكل اسمًا قانونيًا. تفترض هذه المواصفات فقط أن اسم الرحم يتوافق مع تسلسل محدود بشكل تعسفي لأحرف Unicode.
تتكون المواصفات من AGL ( قائمة Adobe Glyph ) ، والتي توفر رسم خرائط لأسماء Glyph محددة لقيم Unicode ، جنبًا إلى جنب مع قواعد لتحلل وتفسير أسماء الحربية. نظرًا لأنه من المتوقع أن يتم تنفيذ هذه المواصفات في العديد من البرامج ، وأن مراجعة جميع التطبيقات التي تستخدمها من غير المرجح أن تكون هذه المواصفات مستقرة ، مما يعني أنه لا يتم مراجعته أبدًا بطريقة جوهرية. على وجه الخصوص ، من المفترض أنه لن يتم إضافة التعيينات إلى AGL. أيضا ، لا يُقصد من AGL بمثابة دليل لاختيار أسماء الهربس للخطوط الجديدة. لهذا الغرض ، يوجد AGLFN ( قائمة Adobe Glyph للخطوط الجديدة ) (انظر القسم 6).
تدعم هذه المواصفات النطاق الكامل لقيم العددية Unicode ، U+0000 من خلال U+10FFFF. لا يعتمد على ذخيرة الأحرف لإصدار Unicode معين ؛ وبالتالي ، فإنه ينطبق على الإصدارات السابقة والحالية والمستقبلية لمعيار Unicode.
يتم تشجيع منتجي الخطوط بشدة على احترام هذه المواصفات عند تسمية الرسوم الرسومية لخطوطهم. يتم تشجيع مستهلكي الخط على اتباع هذه المواصفات عند محاولة استخلاص المحتوى من أسماء الرسول الرمزية.
لخريطة اسم الرسوم الرمزية لسلسلة أحرف ، اتبع الخطوات الثلاث أدناه:
قم بإسقاط جميع الأحرف من اسم الرحم بدءًا من الحدوث الأول للفترة (توقف U+002E الكامل) ، إن وجدت.
اقسم السلسلة المتبقية إلى سلسلة من المكونات ، باستخدام خط السفلي (U+005F LINE) كحدد.
قم بتخطيط كل مكون لسلسلة أحرف وفقًا للإجراء أدناه ، وتسلسل تلك الأوتار ؛ والنتيجة هي سلسلة الأحرف التي يتم تعيين اسم الرسول الرسمية لها.
إذا كان الخط هو ZAPF dingbats (postscript fontname: zapfdingbats ) ، والمكون في قائمة ITC ZAPF Dingbats glyph ، ثم قم بتخطيطها إلى الحرف المقابل في تلك القائمة.
خلاف ذلك ، إذا كان المكون في AGL ، فقم بتخطيطه إلى الحرف المقابل في تلك القائمة.
خلاف ذلك ، إذا كان المكون من النموذج "uni" (U+0075 ، U+006e ، و U+0069) متبوعًا بتسلسل من الأرقام السداسية ذات الحالة الكبيرة (0–9 و A - F ، بمعنى U+0030 من خلال U+0039 و U+0041 من خلال U+0046) النطاقات 0000 إلى D7FF أو E000 من خلال FFFF ، ثم تفسير كل منها على أنها قيمة قياسية أحادية الرمز وقم بتخطيط المكون إلى السلسلة المصنوعة من القيم العددية. لاحظ أن القيود المفروضة على النطاق والرقم تعني أنه لا يمكن استخدام بادئة اسم "UNI" إلا مع الأشعة فوق البنفسجية في المستوى الأساسي متعدد اللغات (BMP).
خلاف ذلك ، إذا كان المكون من النموذج "u" (U+0075) متبوعًا بتسلسل من أربعة إلى ستة أرقام سداسية عشرية (0–9 و A - F ، وهذا يعني U+0030 من خلال U+0039 و U+0041 من خلال u+0046) ، ويمثل هذه الأرقام قيمة في RAVES 0000 من خلال D7FF أو E000 من خلال قم بتخطيط المكون إلى السلسلة المصنوعة من هذه القيمة العددية.
خلاف ذلك ، قم بتخطيط المكون إلى سلسلة فارغة.
يحتوي اسم "lcommaaccent" على مكون واحد ، يتم تعيينه إلى السلسلة U+013B بواسطة AGL.
يحتوي اسم "UNI20AC0308" على مكون واحد ، يتم تعيينه إلى السلسلة U+20ac U+0308.
يحتوي اسم "U1040C" على مكون واحد ، يتم تعيينه إلى السلسلة U+1040C.
يحتوي اسم "UNID801DC0C" على مكون واحد ، يتم تعيينه إلى سلسلة فارغة. لا D801 ولا DC0C في المجموعة المناسبة. لا يمكن استخدام هذا النموذج لتعيين الشخصية التي يتم التعبير عنها كـ D801 DC0C في UTF-16 ، وتحديداً U+1040C. يمكن تعيين هذا الحرف بشكل صحيح باستخدام اسم Glyph "U1040C".
يحتوي اسم "UNI20AC" على مكون واحد ، يتم تعيينه إلى سلسلة فارغة (لاحظ الحالة الصغيرة "A" و "C").
يحتوي اسم "LCommaaccent_Uni20AC0308_U1040C.Alternate" على ثلاثة مكونات ، وهي "lcommaaccent" و "UNI20AC0308" و "U1040C". يتم تعيينه إلى السلسلة u+013b u+20ac u+0308 u+1040c.
بشكل عام ، يمكن تعيين أسماء متعددة إلى نفس السلسلة. على سبيل المثال ، المكونات 'lcommaaccent' و 'Uni013b' و 'U013b' جميع الخريطة إلى السلسلة u+013b.
يطلق اسم "foo" على سلسلة فارغة ، لأن "Foo" ليس في AGL ، ولأنه لا يبدأ بـ "U".
يتم تقليل الاسم ".notdef" إلى سلسلة فارغة من خلال الخطوة الأولى ، ويتم تعيينها إلى سلسلة فارغة بحلول الفقرة الأخيرة من الخطوة الثالثة.
تدعم هذه المواصفات تعيين أسماء الرسول الرمزية إلى سلاسل تحتوي على قيم PUA. على سبيل المثال ، أسماء "OgoneKsmall" و "UNIF6FB" كلا الخريطة إلى السلسلة التي تتوافق مع U+F6FB.
لا تشمل هذه المواصفات ، ولا تفترض أي استخدام معين PUA ؛ إنه يسمح فقط بتسمية الحروف الرسومية بحيث تشمل سلاسل الأحرف المستعادة نقاط رمز PUA. الأمر متروك للمنتجين والمستهلكين لأسماء الرسول الرمزية لإنشاء اتفاق حول استخدام PUA.
يجب أن يلاحظ مصممي الخطوط أن إنشاء هذه الاتفاقية مع مستخدمي الخطوط العامة للأغراض العامة قد يكون أمرًا صعبًا. من المحتمل أن جميع الأدوات التي تتلاعب بسلاسل الأحرف المصممة من أسماء Glyph ستنفذ استخدام PUA بشكل صحيح ، وقد يؤدي ذلك إلى وظائف غير صحيحة أو غير متوقعة. لذلك يوصى ، بالنسبة للخطوط للأغراض العامة ، أن تتحول جميع أسماء Glyph إلى سلاسل لا تحتوي على نقاط رمز PUA.
تطورت هذه المواصفات مع مرور الوقت. يرجى الرجوع إلى القسم 7 ( تغييرات المستند ) للتغييرات.
بالنسبة إلى الحروف الرسومية التي تتوافق مع الأحرف في معيار Unicode ، يوصى بتحديد الأسماء باستخدام بادئة "UNI" للأحرف في المستوى الأساسي متعدد اللغات (BMP) ، وبادئة "U" الأقصر للأحرف في الطائرات الإضافية الـ 16 ، وفقًا للقواعد 2.
هذا لا يعني أن الخطوط غير صالحة إذا تم إجراؤها دون استخدام بادئات "UNI" و "U" لأسماء الرحم. مع مجموعة واحدة من الاستثناءات ، تعمل جميع أسماء Glyph في AGL حاليًا في جميع البيئات المعروفة ، بالإضافة إلى أسماء مع بادئة "UNI". الاستثناءات هي أسماء Glyph AGL المرتبطة بنقاط رمز PUA. وتشمل هذه جميع الرؤساء وأسماء الغطاء الصغيرة. سيؤدي استخدام هذه الأسماء ، لغرض البحث عن النص ، إلى قيادة بعض التطبيقات الحالية إلى تعيين أسماء مثل "Asmall" إلى قيمة PUA المحددة في AGL ، بدلاً من الأشعة فوق البنفسجية لـ "A". نوصي الآن بتسمية هذه الحروف الرسومية وفقًا للقواعد المحددة في هذا القسم. يتم توفير مجموعة فرعية من AGL التي تستبعد الأسماء المرتبطة بـ PUA بواسطة AGLFN ( قائمة Adobe Glyph للخطوط الجديدة ).
إذا تمثل الرسوم الحرارية المتعددة في خط نفس الحرف في معيار Unicode ، مثل "A" و "A.Swash" ، فيمكن تمييزها باستخدام نفس الاسم الأساسي مع اللواحق المختلفة. لا تشارك اللاحقة (جزء من اسم الرسوم الهاربة التي تتبع الفترة الأولى) في حساب تسلسل الأحرف. يمكن استخدامه من قبل مصممي الخطوط للإشارة إلى خصائص خاصة للرسوم الرسومية. قد تحتوي اللاحقة على فترات أو أي شخصيات أخرى مسموح بها. على سبيل المثال ، يمكن تسمية الغطاء الصغير "A" "UNI0041.SC" أو "A.SC".
إذا كان هناك العديد من المتغيرات من نفس الرسول الرسومية الأساسية ، فيجب أن تتضمن اللواحق المتغيرة أرقامًا ثابتة ذات طول ثابت صفريًا ، بحيث إذا تم فرز أسماء الرسول الرمزية ، يمكن الحفاظ على الترتيب المقصود. على سبيل المثال ، إذا كان لدى "Ampersand" Glyph 23 نموذجًا بديلاً ، فسيتم تسميتها "Ampersand.ALT01" من خلال "Ampersand.ALT23" ، بدلاً من "Ampersand.alt" ، إلى جانب "Ampersand.ALT1" من خلال "Ampersand.alt22". توفر هذه القاعدة فقط راحة طفيفة لتطوير الخطوط واختبارها. كما هو مذكور أعلاه ، لا تشارك هذه اللواحق الاسم الرمزية في حساب تسلسل الأحرف.
لا تقوم هذه المواصفات بتوحيد أي من اللواحق. أي لاحقة تعسفية ستعمل لأغراض البحث عن النص. للراحة أثناء التطوير والاختبار ، يستخدم Adobe اسم ميزة تخطيط Opentype الأنسب باعتباره لاحقة. على سبيل المثال ، يمكن تسمية غطاء صغير "A" "A.SMCP" ، وهو نموذج أولي "A.Init" ، ونموذج نهائي "A.Fina" ، وشكل swash "A.SWSH". إذا كان هناك نماذج إضافية من الإزاحة ، فيمكن تسمية "A.SWSH1" و "A.SWSH2" وما إلى ذلك. فيما يلي أمثلة على اللواحق المستخدمة في خطوط Adobe:
بالنسبة إلى الحروف الرسومية التي لا تتوافق مع أي حرف في معيار Unicode ، لن يكون للاسم أي فائدة تقنية. يمكن تعيين أي اسم ، طالما لن يتم تفسير الاسم على أنه ذات قيمة دلالية وفقًا للقواعد الواردة في هذا المستند. تتمثل الممارسة من فريق تطوير النوع في Adobe في أنه إذا كان هناك أي علامة وصفية مفيدة للحبوب ، فقم بتسميتها وفقًا لذلك ، مثل "Mouse" ، "Signforsale" ، "ChristmastreeBall12" ، وما إلى ذلك. بخلاف ذلك ، قم بتسميةها على أنها متغيرة لـ "Orn" (قصيرة للزخرفة) ، مثل "Orn001" و "Orn123" وما إلى ذلك.
بالنسبة إلى الرسوم الحرارية التي تمثل أربطة أحرف Unicode القياسية ، هناك تنسيقان مقترحان لأسماء الأسلوب الرمزي ، على النحو التالي:
الوصفية يتم التعبير عن التحلل من خلال الانضمام إلى أسماء الحروف الرسومية لأحرف Unicode القياسية ، بالترتيب ، باستخدام خط السفار السفلي (U+005F LINE). يجب أن تحدد أسماء الأحرف الرسومية للأحرف البادئات "UNI" أو "U" واستخدام أرقام سداسية عشرية ، كما هو موضح أعلاه ، أو باسم AGL. على سبيل المثال ، يجب تسمية "Off I 'Rigature" O_F_F_I ".
الأشعة فوق البنفسجية مع البادئة "UNI" يتم التعبير عن اسم الرسوم الهزلية باعتباره البادئة "UNI" متبوعة بتسلسلين أو أكثر من أربعة أرقام سداسية كبيرة. يحدد كل تسلسل من أربعة أرقام سداسية عشرية كبيرة قيمة قياسية Unicode داخل BMP ، بالترتيب. على سبيل المثال ، يجب تسمية حرف العاصمة اللاتينية EZH مع CircleFlex and Grave ، التي ليست في Unicode ، "UNI01B703020300 '، لأن حرف رأس المال اللاتيني EZH هو U+01B7 ، الجمع بين لهجة محيط هو U+0302 ، والجمع بين لهجة الخطيرة هي u+0300. يمكن تسمية الرباط من الحروف الرسومية المسماة "T.Swash" و "H" "T_H.Swash". سيكون "T.Swash_H" غير صحيح لأنه سيتم تفسير ذلك على أنه متغير غليفي لـ "T". تخضع جميع أسماء Glyph إلى الحد الأدنى من 63 حرفًا ، وتتطلب أن تتكون بالكامل من شخصيات من المجموعة التالية: A-Z ، A-Z ، 0–9 ، ". (الفترة ؛ u+002e التوقف الكامل) ، و '_' (الخط السفلي ؛ u+005f line line). قد تفرض بعض التطبيقات القديمة حداثة طولها 31 حرفًا.
يتم توفير مراجعة موجزة لبعض مشكلات التنفيذ السابقة والحدود التبعية على أسماء الرسول الرمزية في أسماء Glyph المستند والتطبيقات الحالية (استنادًا إلى الإصدار 1.1 ، بتاريخ 2003-01-31) المعروضة أدناه:
مقدمة تم تأريخ هذه المقالة بقوة ، حيث تحتوي على تعليقات حول التطبيقات الحالية. يرجى وضع هذا في الاعتبار إذا قراءته بعد أكتوبر من عام 2002.
أين ولماذا يتم استخدام أسماء الهوامف بعد اتفاقيات التسمية للمقالة (غير متوفرة غير متاحة) ، ستمكّن أسماء Unicode و Glyph حاليًا نسخ النص والبحث في مستندات PDF ( تنسيق المستند المحمول ) تحت مجموعة متنوعة من الظروف من عدم وجود أسماء ، أو أسماء لا تتبع هذه المناورات. في عصر الإنترنت ، حيث يجب أن تكون العديد من المستندات قابلة للبحث من أجل أن تكون مفيدة ، هذا أمر مهم للغاية.
يتم تصنيع العديد من ملفات PDF من ملفات PostScript Printer ، عندما لا تتوفر الخطوط الأصلية التي يشير إليها المستند ، ويجب استخدام بيانات الخط المدمج. في هذه الحالة ، لا يتوفر جدول Unicode "CMAP" لخط Opentype ، والفكرة الوحيدة التي قد يكون لدى منتج PDF حول دلالات الرسول الرسومية هي اسمه.
حتى عند توفر ملف الخط الأصلي ، قد لا يزال هناك رسم حرفي لا يتوافق مباشرة مع حرف في Unicode ، فقد يكون متصلاً بشكل مفيد بحرف Unicode عبر اسمه. على سبيل المثال ، يتيح تسمية البديل المزخرف من "T" كـ "T.ALT" لمنتج PDF أن يلاحظ أن "T.ALT" يحمل نفس الدلالات مثل "T" للبحث والأغراض الأخرى.
في المستقبل ، من المتوقع أن تدعم منتجات Adobe الخاصة بأسلوب Adobe الخاص بالبحث عن سلسلة نصية تستند إلى UniCode عن الحروف الرسومية ، مما يعني أن نطاق فائدة هذه القواعد سيصبح أوسع بكثير.
بالنسبة لخطوط TrueType ، التي قد تكون مفقودة أسماء الرسول الرمزية تمامًا ، سيظل وجود قيمة أحادية الرموز في جدول "CMAP" يتسبب في ارتباط الحربية بشكل صحيح مع حرف Unicode في معظم الحالات. ومع ذلك ، بالنسبة إلى الحروف الرسومية التي لا ترسم من نقطة رمز Unicode ، يتم تطبيق التعليقات السابقة.
لماذا لا ينصح ببادئة "U" بعد للرسوم الرسومية التي يتم ترميزها في BMP Unicode؟ لا يتم دعم البادئة "U" بواسطة إصدارات Acrobat 4 و 5. لقد أصبح مدعومًا من قبل Acrobat الإصدار 6 وما بعده ، وهو أيضًا عند دعم أحرف Unicode خارج BMP ( المستوى الأساسي متعدد اللغات ). أسماء AGL وأسماء الرسول الرمزية التي تستخدم البادئة "UNI" ، جنبا إلى جنب مع "." و "قواعد التحليلية" ، مدعومة بالفعل من قبل الإصدارات Acrobat 4 و 5.
يجب الرجوع إلى قيود الطول والشخصيات على الأسماء الحربية من Western Opentype/CFF و TrueType الخطوط في العديد من تدفقات سير العمل كبيانات خطية اسم. نتيجة لذلك ، لا تزال أسماء Glyph خاضعة لقيود مجموعة الأحرف التي يتم فرضها من خلال تطبيقات المواصفات من النوع 1 وتطبيقات مترجم PostScript. على الرغم من أن كلاهما يحدد أن اسمًا بالغ الأزياء لم يكن أقل من 31 حرفًا ، في الممارسة العملية ، وخاصة في البيئات الحديثة ، يمكن أن تكون أسماء الرسول الرمزية تصل إلى 63 حرفًا ، ولكن يجب ألا تبدأ برقفة أو فترة ، ويجب أن تتألف تمامًا من أحرف من المجموعة المحدودة التالية:
الاستثناء الوحيد لهذه المتطلبات هو glyph. notdef.
على سبيل المثال ، "Twocents" و "A1" و "_" هي أسماء حربية صالحة ، لكن "2Cents" و ".Twocents" ليست كذلك.
تصفية أجهزة الصراف الآلي وزوج kerning للعديد من التطبيقات ، تم توفير دعم Kerning في Opentype Fonts إلى حد محدود من قبل الإصدارات Windows و Macintosh من ATM ( Adobe Type Manager ). ينشأ هذا القيد لأن معظم التطبيقات التي لم تكن على دراية أوبنتوس تفترض أن جميع أزواج Kerning في الخط يمكن أن تناسب بشكل معقول هي جدول واحد ، وأنه لن يكون هناك أكثر من بضعة آلاف من أزواج Kerning. توفير المزيد من أزواج Kerning مما تسبب في تعطل مثل هذه التطبيقات. مع وجود kerning المستندة إلى الفصل بدعم من Opentype Layout ، حتى الخط الذي يحتوي على 220 حربية فقط يتجاوز هذا الحد ، إذا تم تخزينه جيدًا. من أجل السماح باستخدام خطوط Opentyoe هذه دون تحطيم العديد من التطبيقات الحالية ، دعم ATM Kerning عبر واجهات برمجة التطبيقات القائمة على نظام التشغيل Legacy من خلال توسيع نطاق Kerning المستند إلى الفصل بشكل كامل إلى قائمة بأزواج اسم Glyph الواحدة ، ثم تصفية هذه القائمة من خلال قائمة بأسماء بارزة. إذا لم يكن اسم الرحم على جانبي زوج Kerning موجودًا في قائمة المرشحات ، فقد تم حذف زوج Kerning بأكمله. لم تعد قائمة تصفية زوج Kerning لـ Windows 95 و Mac OS 9 ، إلى جانب ذلك لنظام التشغيل Windows NT و Windows 2000.
الإصدار 2.9 (21 أغسطس ، 2019) تحديث التحرير.
الإصدار 2.8 (9 أغسطس ، 2018) تم تعديل طول الأسماء الحربية من 31 إلى 63 حرفًا لتعكس الممارسات والتطبيقات الحالية ، إلى جانب ملاحظة أن بعض التطبيقات القديمة قد تفرض حدًا من 31 حرفًا.
الإصدار 2.7 (12 أغسطس 2017) تم إلغاء المستند الخارجي بعنوان أسماء Glyph والتطبيقات الحالية ، مع تغييرات التحرير ، إلى القسم 6.
الإصدار 2.6 (28 مارس 2015) مراجعة التحرير البسيطة المتعلقة بترحيله إلى جيثب.
الإصدار 2.5 (10 نوفمبر 2010) مراجعة التحرير البسيطة المتعلقة بجعلها مواصفات مفتوحة.
الإصدار 2.4 (24 سبتمبر 2003) مراجعة طفيفة. عنوان URL المدبب لأسماء Adobe Glyph لخطوط جديدة إلى مراجعة جديدة.
الإصدار 2.3 (17 أبريل 2003) مراجعة طفيفة. تمت إضافة جملة قصيرة لتوضيح أنه لا يمكن استخدام بادئة "UNI" إلا مع قيم BMP Unicode.
الإصدار 2.2 (31 يناير 2003) مراجعة طفيفة. تمت إضافة رابط إلى قائمة أسماء الأنبوبية التي يجب استخدامها عند إنشاء خطوط جديدة ، وأكد أن الإصدار 2.0 AGL لا يعني لهذا الغرض ، كما أنه لا يتعلق بترميز الرسوم الحرارية في خط.
الإصدار 2.1 (4 نوفمبر 2002) مراجعة طفيفة ، وتوسيع القسم لتعيين أسماء الهربس في خطوط جديدة.
الإصدار 2.0 (20 سبتمبر 2002) المراجعة الرئيسية ، التي تركز المستند على تحويل أسماء الأسماك إلى قيم العددية Unicode ؛ إضافة العديد من الأسماء إلى AGL ؛ تحديث قائمة ZapfdingBats إلى Unicode الإصدار 3.2.
الإصدار 1.1 (17 ديسمبر 1998) مراجعة المستند بالكامل بشكل عام. تحديث معظم الجداول وملفات البيانات. تمت إضافة قسم حول اختيار أسماء Glyph. تم توسيع رمز Pseudo لاستخراج الدلالات ليشمل Ligatures غير unicode والمتغيرات الغليفية. تمت إضافة قسم عن توفير تصميمات منفصلة للمغاوات المزدوجة. تم إزالته عن التناقضات مع WGL4 (لم يعد قابلاً للتطبيق ؛ تم تحديث WGL4).
الإصدار 1.0 (10 نوفمبر 1997) الإصدار الأول.
