Latex3: Unterstützung für HarfTeX

Es gibt zwei neue HarfTeX-spezifische Primitive, \harftexversion und \harftexrevision (die ähnlich wie die entsprechenden LuaTeX-Primitive funktionieren sollten). Alle existierenden LuaTeX-Primitive bleiben unverändert, also sollte \sys_if_engine_luatex_p auch für HarfTeX gelten. Im Allgemeinen soll sich HarfTeX für alle praktischen Zwecke wie LuaTeX verhalten, solange keine HarfTeX-spezifischen Funktionen verwendet werden.

@khaledhosny Nein, \sys_if_engine_luatex_p: sollte für HarfTeX falsch sein, da es _nicht LuaTeX_ ist. Die Schalter sollen für _genau eine_ Engine gelten, oder zumindest war das die Entscheidung bei pTeX/upTeX, wo es wieder viele Überschneidungen gibt.

Unter der Annahme, dass der Rest des Teams damit einverstanden ist, gehe ich kurz über expl3 und passe mich an. Das bedeutet natürlich einen Anstoß für Dinge wie fontspec . Es wird also wahrscheinlich zuerst eine kleine Diskussion geben!

Das musst du selbst entscheiden, das bestreite ich nicht. Was ich damit sagen wollte ist, dass ein solcher Code im Moment denken würde, dass er unter LuaTeX läuft, zum Guten oder zum Schlechten.

@khaledhosny Sicher: Jede Änderung muss sorgfältig vorgenommen werden, damit ein funktionierendes Setup für HarfTeX erhalten bleibt. Ich werde vielleicht die beiden neuen Primitiven zu l3names hinzufügen (ich denke, das Team möchte HarfTeX unterstützen!), werde aber auf alle anderen Änderungen warten, um zu sehen, ob alle anderen mit der konzeptionellen Aufteilung einverstanden sind.

@josephwright Ich bin mir nicht sicher. (Habe noch nicht versucht, harftex zu bauen, aber vorausgesetzt, es unterscheidet sich nicht so sehr von früheren luahbtex-Versuchen, ist der Unterschied zwischen harftex und luatex beim Laden eines kompilierten harbuzz-lua-Moduls in fast allen Fällen nicht relevant.

Leute werden \sys_if_engine_luatex_p: zu bedeuten "kann ich \directlua ? Wenn das für Harftex falsch ist, wird viel Code, der funktionieren könnte, nicht funktionieren.

Ich denke, wir könnten erwägen, dies für beide und einige andere \sys_if wahr zu machen, um sie zu unterscheiden.

@davidcarlisle Wir hatten dies, wie gesagt, mit pTeX und upTeX (OK, in vielerlei Hinsicht sehr unterschiedliches Problem). Dort haben wir die Linie genommen, dass engine_<name> genau eine Engine bedeutet. Wenn wir einen 'unterstützt Lua'-Schalter wollen, sollte es wohl genau Folgendes sagen: \sys_if_lua_enabled:TF ?

@khaledhosny Ich \luatexversion in HarfTeX definieren, sobald Sie mehr Einfluss auf das Projekt haben?

Da HarfTeX meiner Meinung nach _streng additiv_ zu LuaTeX ist (oder?), könnte man alternativ argumentieren, dass es in Ordnung ist, positiv auf LuaTeX zu testen, und dass wir dann einen zweiten Wechsel vornehmen, um zu wissen, ob die 'HarfTeX-Erweiterungen' verfügbar sind . (Im Gegensatz zu pTeX/upTeX: upTeX ist von Anfang an leistungsfähiger als pTeX.)

Ich würde es gerne behalten, so wie LuaTeX \eTeXversion beibehält und auch, weil man vielleicht tatsächlich auf ein bestimmtes LuaTeX-Verhalten basierend auf seiner Version überprüfen möchte, da ich beabsichtige, HarfTeX mit LuaTeX synchron zu halten so viel wie möglich.

Die Dinge könnten sich in Zukunft ändern und es könnte bahnbrechende Veränderungen geben, aber im Moment ist keine geplant.

Am Freitag, 26. April 2019 um 21:48 Uhr, Joseph Wright [email protected]
schrieb:

@davidcarlisle https://github.com/davidcarlisle Wir hatten das wie gesagt
mit pTeX und upTeX (OK, in vielerlei Hinsicht sehr unterschiedliches Thema). Dort nahmen wir
die linie, die motor_bedeutet genau einen Motor. Wenn wir wohl
einen 'unterstützt Lua'-Schalter wollen, sollte genau das sagen:
\sys_if_lua_ aktiviert:TF?

—

ja, aber die unterschiede zwischen ptex und uptex wirken sich stärker aus
Endbenutzerdokumentfunktionalität, luatex und harftex sind die gleiche Quelle
(für die Nicht-Harfbuzz-Bits) und abgesehen von der Schnittstelle zu Fontspec sollte
für fast den gesamten expl3-Code nicht unterscheidbar sein und \expanded zu xetex . hinzufügen
macht einen größeren Unterschied in Bezug auf die Art des Codes, der wahrscheinlich sein wird
Testen der \sys... Fähigkeit, aber xetex+\expanded ist immer noch xetex, wohingegen
luatex+harfbuzz, das mit der ausführbaren Datei verknüpft ist, ist nicht aber luatex mit harfbuzz
über ein kompiliertes lua-Modul geladen wird...
Ich glaube nicht, dass "genau eine Engine" eine ganz klar definierte Sache ist, wir
Sie müssen nur alle booleschen Schalter bereitstellen, die nützlich erscheinen.

Es macht mir nicht viel aus, ich denke, ich würde es vorziehen, \sys_if_engine_luatex_p: wahr zu sein
aber wenn wir es falsch machen, sollten wir empfehlen, dass dies nur für _sehr_ niedrig verwendet wird
Levelcode und der meiste Paketcode sollte \sys_if_engine_something_p verwenden:
die wir bereitstellen sollten das gilt für beides

Ich habe keine starke Meinung zu den booleschen Werten.
Mit eindeutigen \sys_if_engine_luatex_p: und \sys_if_engine_harftex_p: bedeutet dies, dass die Autoren von LuaTeX-Paketen ihre Arbeit explizit unterstützen müssen, wenn es jemals zu einer Fehlerprüfung oder ähnlichem kommt.

Bei überlappenden booleschen Werten läuft der gesamte Code ohne Modifikation auf beiden Engines weiter, und wenn nur eine Differenz benötigt wird, ist \sys_if_engine_harftex_p: erforderlich.

Wenn das erklärte Ziel von HarfTeX die Beibehaltung der Kompatibilität mit LuaTeX ist, denke ich, dass die letztere Option die pragmatischere Wahl ist. Sollte es jemals zu einer Gabelung kommen, könnten wir eine Neubewertung vornehmen.

Ich schätze, ich lasse die LuaTeX-Tests gerne in Ruhe, solange das derzeitige Verständnis so ist, dass HarfTeX LuaTeX ähnlich behandelt, wie pdfTeX/LuaTeX/XeTeX e-TeX behandelt. Die eine Sache, die wir in Betracht ziehen sollten, ist die Rückgabe für die Zeichenfolgen für den Engine-Namen/die Version. Wie gesagt, irgendwann
wir werden vermutlich auch einen 'HarfTeX-Erweiterungen'-Schalter haben wollen.

Wahrscheinlich sollten wir dokumentieren, dass wir es auch unterstützen.