Latex3: Suporte para HarfTeX

Existem duas novas primitivas específicas do HarfTeX, \harftexversion e \harftexrevision (que devem funcionar de forma semelhante às primitivas LuaTeX correspondentes). Todas as primitivas LuaTeX existentes são mantidas inalteradas, então \sys_if_engine_luatex_p deve ser verdadeiro para HarfTeX também. Em geral, a intenção é que o HarfTeX se comporte como o LuaTeX para todos os fins práticos, desde que nenhum recurso específico do HarfTeX seja usado.

@khaledhosny Não, \sys_if_engine_luatex_p: deve ser falso para HarfTeX, pois _não é LuaTeX_. As opções devem ser verdadeiras para _exatamente um_ motor, ou pelo menos essa foi a decisão com pTeX / upTeX, onde novamente há muita sobreposição.

Supondo que o resto da equipe concorde com isso, farei um rápido repasse de expl3 e ajustarei. Claro, isso significa um golpe para coisas como fontspec . Portanto, é provável que haja pelo menos uma pequena discussão primeiro!

Isso cabe a você decidir, não estou discutindo com isso. O que eu quis dizer é que agora esse código pensaria que estava rodando no LuaTeX, para melhor ou pior.

@khaledhosny Claro: qualquer alteração precisará ser feita com cuidado para que ele mantenha uma configuração de trabalho para o HarfTeX. Eu talvez adicionarei os dois novos primitivos a l3names (acho que a equipe quer oferecer suporte ao HarfTeX!), Mas irei esperar por quaisquer outras alterações para ver se todos os outros concordam com a divisão conceitual.

@josephwright Não tenho certeza. (Ainda não tentei construir o harftex, mas assumindo que não é tão diferente dos testes luahbtex anteriores, a diferença entre o harftex e o luatex carregando um módulo harbuzz lua compilado não são relevantes em quase todos os casos.

as pessoas usarão \sys_if_engine_luatex_p: para significar "posso usar \directlua ? se isso for falso para harftex, muitos códigos que poderiam funcionar não funcionarão.

Acho que poderíamos considerar tornar isso verdadeiro para ambos e alguns outros \sys_if para distingui-los.

@davidcarlisle Tínhamos isso como eu disse com pTeX e upTeX (OK, questão muito diferente em muitos aspectos). Lá, pegamos a linha de que engine_<name> significa exatamente um motor. Indiscutivelmente, se quisermos um switch 'suporta Lua', devemos dizer exatamente isso: \sys_if_lua_enabled:TF ?

@khaledhosny Suponho que quando você conseguir mais alavancagem no projeto, não vai definir \luatexversion no HarfTeX?

Como alternativa, como o HarfTeX é, eu acho, _estritamente aditivo_ ao LuaTeX (certo?), Pode-se argumentar que está tudo bem se o teste for positivo por ser LuaTeX e que então faremos uma segunda opção puramente para saber se as 'extensões HarfTeX' estão disponíveis . (Compare com pTeX / upTeX: upTeX é mais capaz do que pTeX desde o início.)

Eu gostaria de mantê-lo, da mesma forma que o LuaTeX mantém \eTeXversion , e também porque alguém pode realmente querer verificar se há um determinado comportamento do LuaTeX com base em sua versão, pois pretendo manter o HarfTeX sincronizado com o LuaTeX tanto quanto possível.

As coisas podem mudar no futuro e pode haver mudanças significativas, mas nada está planejado agora.

Na sexta-feira, 26 de abril de 2019 às 21:48, Joseph Wright [email protected]
escreveu:

@davidcarlisle https://github.com/davidcarlisle Tínhamos isso como eu disse
com pTeX e upTeX (OK, problema muito diferente em muitos aspectos). Lá, nós pegamos
a linha que motor_significa exatamente um motor. Indiscutivelmente, se nós
deseja um switch 'suporta Lua', ele deve dizer exatamente isso:
\ sys_if_lua_ enabled: TF?

-

sim, mas as diferenças entre ptex e uptex são mais abrangentes afetando
funcionalidade de documento do usuário final, luatex e harftex são a mesma fonte
(para os bits não harfbuzz) e além da interface com fontspec deve
ser indistinguível para quase todo o código expl3, adicionando \ expandido a xetex
faz mais diferença em termos do tipo de código que provavelmente será
testando \sys... capacidade, mas xetex + \ expandido ainda é xetex, enquanto
luatex + harfbuzz vinculado ao executável não é senão luatex com harfbuzz
carregado por meio de um módulo lua compilado é ...
Não acho que "exatamente um motor" seja algo completamente bem definido, nós
só precisa fornecer quaisquer opções booleanas que pareçam úteis.

Não me importo muito, acho que prefiro \ sys_if_engine_luatex_p: ser verdade
mas se torná-lo falso, devemos recomendar que seja usado apenas para _muito_ baixo
o código de nível e a maioria dos códigos de pacote devem usar \ sys_if_engine_something_p:
que devemos fornecer, é verdade para ambos

Não tenho uma opinião forte sobre os booleanos.
Com distinto \ sys_if_engine_luatex_p: e \ sys_if_engine_harftex_p: isso significa que os autores do pacote LuaTeX precisam adicionar suporte explicitamente ao seu trabalho se houver uma verificação de erro ou algo semelhante.

Com os booleanos sobrepostos, todo o código continua a ser executado sem modificação em qualquer um dos mecanismos e, se uma diferença for necessária, somente será \ sys_if_engine_harftex_p: obrigatório.

Se o objetivo declarado do HarfTeX é manter a compatibilidade com o LuaTeX, acho que a última opção é a escolha mais pragmática. Se houver uma bifurcação, podemos reavaliar.

Acho que estou feliz em deixar os testes do LuaTeX em paz, contanto que o entendimento atual seja que o HarfTeX está tratando o LuaTeX da mesma forma que o pdfTeX / LuaTeX / XeTeX trata o e-TeX. A única coisa que devemos considerar é retornar para as strings de nome / versão do mecanismo. Como eu disse, em algum momento
presumivelmente, também desejaremos uma troca de 'extensões HarfTeX'.

Provavelmente devemos documentar que também o apoiamos.