Latex3: Soporte para HarfTeX

Hay dos nuevas primitivas específicas de HarfTeX, \harftexversion y \harftexrevision (que deberían funcionar de manera similar a las primitivas correspondientes de LuaTeX). Todas las primitivas existentes de LuaTeX se mantienen sin cambios, por lo que \sys_if_engine_luatex_p debería ser cierto para HarfTeX. En general, la intención de HarfTeX es comportarse como LuaTeX para todos los propósitos prácticos, siempre que no se utilicen funciones específicas de HarfTeX.

@khaledhosny No, \sys_if_engine_luatex_p: debería ser falso para HarfTeX ya que _no es LuaTeX_. Los conmutadores están destinados a ser verdaderos para _exactamente un_ motor, o al menos esa fue la decisión con pTeX / upTeX, donde nuevamente hay mucha superposición.

Suponiendo que el resto del equipo esté de acuerdo con esto, haré un pase rápido sobre expl3 y ajustaré. Por supuesto, eso significa una repercusión para cosas como fontspec . ¡Por lo tanto, es probable que primero haya al menos una pequeña discusión!

Depende de usted decidir, no estoy discutiendo con eso. Lo que quise decir es que en este momento dicho código pensaría que se está ejecutando bajo LuaTeX, para bien o para mal.

@khaledhosny Seguro: cualquier cambio deberá realizarse con cuidado para que mantenga una configuración funcional para HarfTeX. Quizás agregue las dos nuevas primitivas a l3names (¡creo que el equipo quiere admitir HarfTeX!), Pero esperaré cualquier otro cambio para ver si todos los demás están de acuerdo con la división conceptual.

@josephwright No estoy seguro. (No he intentado construir harftex todavía, pero suponiendo que no sea tan diferente de las pruebas anteriores de luahbtex, la diferencia entre harftex y luatex que cargan un módulo harbuzz lua compilado no son relevantes en casi todos los casos.

la gente usará \sys_if_engine_luatex_p: para decir "¿puedo usar \directlua ? Si eso es falso para harftex, una gran cantidad de código que podría funcionar no funcionará.

Creo que podríamos considerar hacer eso cierto para ambos y algunos otros \sys_if para distinguirlos.

@davidcarlisle Tuvimos esto como digo con pTeX y upTeX (OK, un problema muy diferente en muchos sentidos). Allí, tomamos la línea de que engine_<name> significa exactamente un motor. Podría decirse que si queremos un modificador 'compatible con Lua', debería decir exactamente eso: \sys_if_lua_enabled:TF ?

@khaledhosny Supongo que una vez que obtenga más apalancamiento en el proyecto, ¿no definirá \luatexversion en HarfTeX?

Alternativamente, dado que HarfTeX es, supongo, _estrictamente aditivo_ a LuaTeX (¿verdad?), Se podría argumentar que está bien que dé positivo por ser LuaTeX, y que luego hagamos un segundo cambio puramente para saber si las 'extensiones de HarfTeX' están disponibles. . (Contrasta con pTeX / upTeX: upTeX es más capaz que pTeX desde el principio).

Me gustaría mantenerlo, de la misma manera que LuaTeX mantiene \eTeXversion , y también porque uno podría querer verificar cierto comportamiento de LuaTeX en función de su versión, ya que tengo la intención de mantener HarfTeX sincronizado con LuaTeX cuanto más se pueda.

Las cosas pueden cambiar en el futuro y puede haber cambios importantes, pero no hay ninguno planeado en este momento.

El viernes 26 de abril de 2019 a las 21:48, Joseph Wright [email protected]
escribió:

@davidcarlisle https://github.com/davidcarlisle Tuvimos esto como digo
con pTeX y upTeX (OK, un tema muy diferente en muchos sentidos). Allí tomamos
la línea que motor_significa exactamente un motor. Podría decirse que si
quiere un interruptor 'compatible con Lua', debería decir exactamente eso:
\ sys_if_lua_ habilitado: TF?

-

sí, pero las diferencias entre ptex y uptex son más generalizadas y afectan
funcionalidad de documento de usuario final, luatex y harftex son la misma fuente
(para los bits que no son harfbuzz) y además de la interfaz con fontspec, debería
ser indistinguible para casi todo el código expl3, agregando \ expandido a xetex
hace más diferencia en términos del tipo de código que probablemente será
probando la capacidad \sys... pero xetex + \ expandido sigue siendo xetex, mientras que
luatex + harfbuzz vinculado al ejecutable no es sino luatex con harfbuzz
cargado a través de un módulo lua compilado es ...
No creo que "exactamente un motor" sea algo completamente bien definido,
solo necesito proporcionar los interruptores booleanos que parezcan útiles.

No me importa mucho, creo que prefiero \ sys_if_engine_luatex_p: to be true
pero si lo hacemos falso, deberíamos recomendar que solo se use para _muy_ bajo
el código de nivel y la mayoría del código de paquete debe usar \ sys_if_engine_something_p:
que debemos proporcionar que sea cierto para ambos

No tengo una opinión sólida sobre los booleanos.
Con distintos \ sys_if_engine_luatex_p: y \ sys_if_engine_harftex_p: esto significa que los autores de paquetes LuaTeX deben agregar explícitamente soporte a su trabajo si alguna vez hay una verificación de error o similar.

Con booleanos superpuestos, todo el código continúa ejecutándose sin modificaciones en ninguno de los motores, y si solo se necesita una diferencia, entonces es \ sys_if_engine_harftex_p: required.

Si el objetivo declarado de HarfTeX es mantener la compatibilidad con LuaTeX, creo que la última opción es la más pragmática. Si alguna vez hay una bifurcación, podríamos reevaluar.

Supongo que estoy feliz de dejar las pruebas de LuaTeX en paz siempre y cuando el entendimiento actual sea que HarfTeX está tratando a LuaTeX de manera muy similar a como pdfTeX / LuaTeX / XeTeX tratan a e-TeX. Lo único que podríamos querer considerar es regresar para las cadenas de nombre / versión del motor. Como dije, en algún momento
presumiblemente también querremos un interruptor de 'extensiones HarfTeX'.

Probablemente deberíamos documentar que también lo apoyamos.