Latex3: Mudança de caixa para cirílico

u8: И -> IeC {CYRI}

Não faria mais sentido extrair И de u8: И e procurar a caixa
informações em alguma matriz?

@blefloch
Sim!

O que são esses comandos u8: ... afinal? Eles são necessários?

@blefloch
Sim!

ou talvez não Chris. Pode-se ter que lidar com a notação ^^ naquele lugar em vez de И, mas no geral eu concordo que parece ser o melhor ponto de partida

O que são esses comandos u8: ... afinal? Eles são necessários?

você deve saber :-) seu nome está no arquivo que contém esse código. Sim, eles são necessários: no pdftex LaTeX vê os bytes, analisa-os e constrói um único csname a partir deles \u8:... que contém o LICR para aquele utf8 char que no caso acima é \IeC {\CYRI } ou se o \u8:... não está definido responde sem representação Unicode para ...

você deve saber :-) seu nome está no arquivo que contém esse código.
Mas nem tudo pelo que posso ser responsável é necessário :-).

Eu concordo que devo olhar o código original! Pelo menos para descobrir de onde veio o:.

Mas devo parar agora, para o caso de irritar certa pessoa por exibir minhas opiniões em um local público :-).

@blefloch Existem algumas coisas necessárias. A primeira é localizar um par / tripleto / quarteto UTF-8 e agarrá-lo inteiro, em vez de símbolo por símbolo. Isso é fácil: verifique se há tokens de caracteres ativos iguais ao ponto de partida inputenc . A segunda fase é saber como alterá-los. A razão pela qual mencionei a abordagem \IeC{...} é que não precisamos de _novos_ dados: é a mesma maneira que \MakeUppercase trata e usa os dados \@uclclist que estamos já coletando.

O motivo pelo qual mencionei a abordagem IeC {...} é que não precisamos de novos dados:
Bem, você pode precisar de um pouco mais se quiser cobrir absolutamente todos os caracteres que mudam de caixa (talvez nem todos tenham LICRs).

Usar números e tabelas Unicode é esteticamente mais atraente, é claro. Mas se 'tabelas de nomes' funcionar por enquanto. . .

Para cirílico, grego, armênio, etc etc, é possível usar novos LICRs da forma cyr {}, um pouco como sotaques?

@ car222222 O problema surgiu porque há lugares em que \MakeUppercase atuais funcionam e \text_uppercase:n não funcionam, o que se resume a coisas que passam por u8:... . É por isso que eu estava começando com isso. Se quisermos o intervalo Unicode completo em pdfTeX (factível), precisaremos armazenar os dados manualmente em um array de inteiros.

Se quisermos o intervalo Unicode completo em pdfTeX (factível), precisaremos armazenar os dados manualmente em um array de inteiros.

Dado que o pdfTeX deliberadamente fornece apenas caracteres utf8 se for suportado pelas codificações de fonte carregadas, é questionável primeiro alterar a caixa e depois descobrir que o resultado é um caractere não suportado. É claro que, se todos os dados estiverem dentro do formato, não haverá carga extra (além do tamanho ocupado por ele) e a preparação inicial.

é questionável primeiro alterar o caso e depois descobrir que o resultado é um caractere sem suporte.

Não acho isso muito problemático. As letras minúsculas e maiúsculas estão na mesma codificação, então você só obteria um erro em um alfa maiúsculo se começar com o alfa minúsculo não suportado.

Em 18/02/20 15:49, Ulrike Fischer escreveu:

it is questionable to first case change and then find that the
result is an unsupported character.

Não acho isso muito problemático. As letras minúsculas e maiúsculas estão no
mesma codificação, então você só obteria um erro em um alfa maiúsculo se você
comece com o alfa minúsculo sem suporte.

Mesmo que exista uma codificação com alfa minúsculo, mas não maiúsculo
alfa (isso pode ser plausivelmente o caso para alguns dos sotaques mais raros),
obter um erro de Unicode char não configurado parece melhor do que
obtendo acidentalmente o caractere minúsculo.

Eu concordo com Ulrike e Bruno. Mas não consigo imaginar um caso realista (trocadilho intencional) em que os caracteres maiúsculos e minúsculos não estão disponíveis / indisponíveis simultaneamente.

Dado que o pdfTeX deliberadamente só fornece caracteres utf8 se compatível com as codificações de fonte carregadas

Quer dizer o quê? O pdfTeX não 'fornece caracteres', não é? E 'codificações de fontes carregadas' é um conceito LaTeX, não um motor.

Talvez isso signifique que, da maneira como configuramos originalmente o material utf8 para LaTeX, os LICRs foram apenas (e os mapeamentos foram fornecidos apenas 'para codificações conhecidas' e, em seguida, carregados apenas para codificações carregadas.

É verdade, mas não há necessidade de manter essas restrições atualmente, não é?
Certamente, agora podemos fornecê-los facilmente para qualquer subconjunto de Unicode que desejarmos e, neste contexto, só precisamos cobrir todos os 'caracteres casable'.

Aviso: Nunca gostei muito dessa restrição a codificações conhecidas :-).

    Given that pdfTeX deliberately only provides utf8 chars if
    supported by the loaded font encodings

Quer dizer o quê? O pdfTeX não 'fornece caracteres', não é? E
'codificações de fonte carregadas' é um conceito LaTeX, não um motor.

significando pdflatex e escrevendo pdftex

Talvez isso signifique que da forma como originalmente configuramos o material utf8 para
LaTeX, LICRs foram apenas (e os mapeamentos foram fornecidos apenas 'para
codificações 'e, em seguida, carregados apenas para codificações carregadas.

sim, o que foi um Good Thing TM porque manteve o mundo LaTeX livre de
tofu e personagens faltando

É verdade, mas não há necessidade de manter essas restrições atualmente, não é?
Certamente agora podemos fornecê-los facilmente para qualquer subconjunto de Unicode que
desejar e, neste contexto, só precisamos cobrir todos os 'caracteres casable'.

sim existe. se você não tem os glifos para escrever os caracteres,
é inútil fazer isso, é por isso que afirmar que você pode fazer Unicode como
como xetex ou luatex (latex) faz e então apenas gerando buracos ans Não
avisos char XXX no log é um retrocesso para o pdflatex
solução, imho

Aviso: Nunca gostei muito dessa restrição a codificações conhecidas :-).

bem, contanto que você escreva em inglês, geralmente não importa se você
escreva em outras línguas e seu documento será corrompido sem
te avisando que sim

Pode haver motivos para não carregar LICRs para personagens não representáveis.

Mas aqui estamos falando apenas sobre como definir esses LICRs e caracteres maiúsculos, observe os 'caracteres'.
Nada a ver com sua composição, então as codificações / fontes disponíveis não são relevantes.
Caso de uso: o formulário com alta freqüência deve ser usado apenas em um marcador de pdf, nunca para ser editado (pelo TeX, pelo menos!)

Depois de examinar o problema um pouco mais, parecia mais fácil lidar com ele usando uma lista fixa de mapeamentos em vez de tentar fazer as coisas olhando dentro de chars ativos. Dei uma olhada rápida em quantos pontos de código existem com dados de mudança de caixa: cerca de 2.000. Isso é provavelmente um pouco demais para fazer todos eles, então, por enquanto, escolhi os gregos e cirílicos que são cobertos por T2 / LGR . Os pensamentos são bem-vindos.

que tal a ideia de armazená-los todos em uma matriz?

O problema com o uso de um array interno é que não podemos torná-lo esparso, então o tamanho dependeria do ponto de código do valor final a ser armazenado. Também há uma pequena perda de desempenho no ponto de uso, pois teríamos que extrair, converter em bytes e construir os caracteres ativos, em vez de fazer isso uma vez no momento do carregamento.

Além disso, voltando ao assunto 'quais codepoints têm glifos', até onde eu sei, os gregos e cirílicos mais os latinos já cobertos são de longe os mais úteis

Bem, para os gregos e para os cirros são os mais úteis, sim! Mas não para o resto do mundo?
Das heisst: como você mediu essa utilidade?

Eu acho que o total fica tão grande devido aos muitos derivados latinos ao redor, ou não?
2000 é aproximadamente 30+ alfabetos típicos, eu acho.

'Utilitário' aqui estava apenas começando com 'o que funciona atualmente no pdfTeX', então 'quais codificações estão disponíveis'. Não tenho certeza do que exatamente todos os mapeamentos cobrem: é possível que haja falsos positivos. Presumivelmente, existem para começar todas as variantes matemáticas (itálico, sanserif, ...).

Muito dele tem sotaque latino / cirílico / grego, então há copico, armênio, húngaro antigo, cherokee, etc. Certamente não 30 alfabetos, mas provavelmente pelo menos 10.

Lista completa de scripts:

• Latim (> 700 codepoints!) Incl. versões de largura total
• grego
• cóptico
• cirílico
• Armênio
• Georgiano
• Cherokee
• Glagolítico
• Deseret
• Osage
• Húngaro antigo
• Warang
• Medefaidrin
• Adlam

!! Latim (> 700 codepoints!) Incl. versões de largura total
Sim, sem mencionar as versões "sobrescrito circulado",
e tenho certeza de que deve haver emojis em letras minúsculas no Unicode agora :-).

@ car222222 Felizmente, não há letras circuladas;) São principalmente várias combinações de versões de acentos.

@josephwright, mas você realmente deve implementar \text_lowercase:n{\emoji{Man}} = \emoji{Boy} ;-)

O que você acha de uma cobertura futura? Ou vamos com o que eu configurei para o presente?

O tratamento de \.I İ no MWE acima é diferente no pdfLaTeX (também em comparação com os motores Unicode), mas admito que İ é provavelmente um caso complicado no caso genérico de código de mudança.

Então eu tentei o trocador de caso turco

\documentclass{article}
\usepackage{fontspec}
\usepackage{libertinus}
\usepackage{expl3}

\ExplSyntaxOn
\def\test{\text_lowercase:nn{tr}}
\ExplSyntaxOff

\begin{document}
\test{\.I İ \CYRI И}
\end{document}

( L3 programming layer <2020-02-25> ) e LuaLaTeX e XeLaTeX não estão felizes

! Undefined control sequence.
<inserted text> ı

@moewew Hmm, isso é um pouco estranho: vou buscar está classificado

@moewew Problema específico com turco: agora corrigido

O que você acha de uma cobertura futura? Ou vamos com o que eu configurei para o presente?

Eu começaria com o presente e estenderia quando necessário

OK, acho que é a melhor posição e também significa que podemos manter os problemas em andamento. Vou encerrar aqui e adições específicas podem ser abordadas em novas questões.