Latex3: دعم HarfTeX

تم إنشاؤها على ٢٦ أبريل ٢٠١٩  ·  12تعليقات  ·  مصدر: latex3/latex3

في الوقت الحالي ، ندعم خمسة محركات (pdfTeX و XeTeX و LuaTeX و e-pTeX و e-upTeX). مشروع HarfTeX شيء يجب أن نفكر فيه على الأرجح.

نحن بحاجة إلى معالجة شيئين. أولاً ، نحتاج إلى علامة أن HarfTeX قيد الاستخدام: khaledhosny ونأمل أن \sys_if_engine... : بالنسبة إلى e-pTeX و e-upTeX ، يحتاج اختبار كلاهما إلى \bool_lazy_or:nnTF ، لذلك ربما ينتهي بنا الأمر مع

\bool_lazy_or:nnT
  { \sys_if_engine_luatex_p: }
  { \sys_if_engine_harftex_p: } 
  {
    % Code using Lua
  }

أو ربما نحتاج إلى اختبار محدد.

expl3 feature-request

ال 12 كومينتر

هناك نوعان من الأساسيات الجديدة الخاصة بـ HarfTeX ، \harftexversion و \harftexrevision (والتي يجب أن تعمل بشكل مشابه لأساسيات LuaTeX المقابلة). يتم الاحتفاظ بجميع بدائل LuaTeX الحالية دون تغيير ، لذا يجب أن يكون \sys_if_engine_luatex_p صحيحًا بالنسبة لـ HarfTeX أيضًا. بشكل عام ، القصد من HarfTeX هو التصرف مثل LuaTeX لجميع الأغراض العملية ، طالما لم يتم استخدام ميزات خاصة بـ HarfTeX.

khaledhosny لا ، \sys_if_engine_luatex_p: يجب أن يكون خطأ بالنسبة لـ HarfTeX لأنه _not LuaTeX_. من المفترض أن تكون المفاتيح صحيحة بالنسبة لمحرك واحد تمامًا ، أو على الأقل كان هذا هو القرار مع pTeX / upTeX ، حيث يوجد مرة أخرى الكثير من التداخل.

بافتراض أن باقي أعضاء الفريق يوافقون على هذا ، سأقوم بتمرير سريع فوق expl3 وأقوم بالتعديل. بالطبع ، هذا يعني دفعة لأشياء مثل fontspec . لذلك من المحتمل أن يكون هناك مناقشة صغيرة على الأقل أولاً!

الأمر متروك لك لتقرر ، أنا لا أجادل في ذلك. ما قصدت قوله هو أنه في الوقت الحالي ، قد يعتقد هذا الرمز أنه كان يعمل تحت LuaTeX ، للأفضل أو للأسوأ.

khaledhosny بالتأكيد: يجب إجراء أي تغيير بعناية بحيث يحافظ على إعداد عمل لـ HarfTeX. ربما سأضيف الأساسيين الجديدين إلى l3names (أعتقد أن الفريق يريد دعم HarfTeX!) ، لكنني سأنتظر أي تغييرات أخرى لمعرفة ما إذا كان الجميع يوافقون على التقسيم المفاهيمي.

josephwright لست متأكدا. (لم تحاول بناء harftex حتى الآن ولكن بافتراض أنها لا تختلف كثيرًا عن تجارب luahbtex السابقة ، فإن الفرق بين harftex و luatex تحميل وحدة harbuzz lua المجمعة ليست ذات صلة في جميع الحالات تقريبًا.

سيستخدم الأشخاص \sys_if_engine_luatex_p: ليعني "هل يمكنني استخدام \directlua ؟ إذا كان هذا خطأ بالنسبة إلى harftex ، فلن يعمل الكثير من التعليمات البرمجية التي يمكن أن تعمل.

أعتقد أنه يمكننا التفكير في جعل ذلك صحيحًا لكلٍّ من \sys_if للتمييز بينهما.

davidcarlisle كان لدينا هذا كما أقول مع pTeX و upTeX (حسنًا ، مشكلة مختلفة جدًا من نواح كثيرة). هناك ، اتخذنا السطر القائل بأن engine_<name> يعني محركًا واحدًا بالضبط. يمكن القول ، إذا أردنا تبديل "يدعم Lua" ، فيجب أن يقول بالضبط: \sys_if_lua_enabled:TF ؟

khaledhosny أفترض أنه بمجرد حصولك على المزيد من النفوذ على المشروع لن تحدد \luatexversion في HarfTeX؟

بدلاً من ذلك ، نظرًا لأن HarfTeX أعتقد أن _مضيفًا بشكل صارم_ إلى LuaTeX (صحيح؟) ، قد يجادل المرء بأنه لا بأس من اختباره إيجابيًا لكونه LuaTeX ، وأننا بعد ذلك مفتاح ثانٍ لمعرفة ما إذا كانت "ملحقات HarfTeX" متاحة . (على النقيض من pTeX / upTeX: upTeX أكثر قدرة من pTeX من get-go.)

أرغب في الاحتفاظ بها ، بنفس الطريقة التي تحتفظ بها LuaTeX بـ \eTeXversion ، وأيضًا لأن المرء قد يرغب بالفعل في التحقق من سلوك LuaTeX معين بناءً على نسخته حيث أنوي إبقاء HarfTeX متزامنًا مع LuaTeX بقدر المستطاع.

قد تتغير الأشياء في المستقبل وقد تكون هناك تغييرات مفاجئة ، لكن لم يتم التخطيط لأي شيء في الوقت الحالي.

يوم الجمعة ، 26 أبريل 2019 الساعة 21:48 ، جوزيف رايت [email protected]
كتب:

davidcarlisle https://github.com/davidcarlisle كان لدينا هذا كما أقول
مع pTeX و upTeX (حسنًا ، مشكلة مختلفة جدًا من نواحٍ عديدة). هناك أخذنا
الخط الذي المحرك_يعني محرك واحد بالضبط. يمكن القول ، إذا كنا
تريد مفتاح تبديل "يدعم Lua" ، يجب أن يقول بالضبط ما يلي:
تمكين \ sys_if_lua_

-

نعم ، لكن الاختلافات بين ptex و uptex أكثر انتشارًا
وظائف مستندات المستخدم النهائي ، luatex و harftex هي نفس المصدر
(للبتات غير harfbuzz) وبصرف النظر عن التفاعل مع fontspec
لا يمكن تمييزه عن جميع أكواد expl3 تقريبًا ، مضيفًا \ موسعًا إلى xetex
يُحدث فرقًا أكبر من حيث نوع الكود الذي من المحتمل أن يكون
اختبار قدرة \sys... لكن xetex + \ expand لا يزال xetex ، بينما
luatex + harfbuzz المرتبط بالملف التنفيذي ليس سوى luatex with harfbuzz
تحميلها عبر وحدة lua مترجمة ...
لا أعتقد أن "محركًا واحدًا بالضبط" هو شيء محدد جيدًا ، نحن
تحتاج فقط إلى توفير أي مفاتيح منطقية تبدو مفيدة.

لا أمانع كثيرًا ، أعتقد أنني أفضل \ sys_if_engine_luatex_p: أن يكون صحيحًا
ولكن إذا جعلناها خاطئة ، فيجب أن نوصي باستخدامها فقط من أجل _very_ منخفضة
يجب أن يستخدم كود المستوى ومعظم كود الحزمة \ sys_if_engine_something_p:
والتي يجب أن نقدمها وهذا صحيح لكليهما

ليس لدي رأي قوي حول المنطقية.
مع تمييز \ sys_if_engine_luatex_p: and \ sys_if_engine_harftex_p: هذا يعني أن مؤلفي حزمة LuaTeX بحاجة إلى إضافة دعم صريح لعملهم إذا كان هناك أي خطأ في التحقق من الأخطاء أو ما شابه ذلك.

مع القيم المنطقية المتداخلة ، يستمر تشغيل جميع التعليمات البرمجية بدون تعديل على أي محرك ، وإذا كان الاختلاف مطلوبًا فقط ، فسيكون \ sys_if_engine_harftex_p: مطلوبًا.

إذا كان الهدف المعلن لـ HarfTeX هو الاحتفاظ بالتوافق مع LuaTeX ، أعتقد أن الخيار الأخير هو الخيار الأكثر واقعية. إذا كان هناك أي تشعب ، فيمكننا إعادة التقييم.

أعتقد أنني سعيد بترك اختبارات LuaTeX بمفردها طالما أن الفهم الحالي هو أن HarfTeX تتعامل مع LuaTeX تمامًا مثل pdfTeX / LuaTeX / XeTeX. الشيء الوحيد الذي قد نرغب في التفكير فيه هو العودة لسلاسل اسم / إصدار المحرك. كما قلت ، في مرحلة ما
من المفترض أيضًا أننا نريد مفتاح "امتدادات HarfTeX".

ربما يجب أن نوثق أننا ندعمها أيضًا.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات