Latex3: Cambio de caja para cirílico

u8: И -> IeC {CYRI}

¿No podría tener más sentido extraer И de u8: И y buscar mayúsculas y minúsculas?
información en algún intarray?

@blefloch
¡Sí!

¿Cuáles son estos comandos de u8: ... de todos modos? ¿Son necesarios?

@blefloch
¡Sí!

o quizás no Chris. Uno puede tener que lidiar con la notación ^^ en ese lugar en lugar de И pero, en general, estoy de acuerdo en que parece el mejor punto de partida

¿Cuáles son estos comandos de u8: ... de todos modos? ¿Son necesarios?

debe saber :-) su nombre está en el archivo que contiene ese código. Sí, son necesarios: en pdftex LaTeX ve bytes, los analiza y construye un solo csname a partir de ellos \u8:... que contiene el LICR para ese carácter utf8 que en el caso anterior es \IeC {\CYRI } o si el \u8:... no está definido responde sin representación Unicode para ...

debe saber :-) su nombre está en el archivo que contiene ese código.
Pero no todo de lo que pueda ser responsable es necesario :-).

¡Estoy de acuerdo en que debería mirar el código original! Al menos para averiguar de dónde vino:

Pero debería detenerme ahora en caso de que enoje a cierta persona al mostrar mis opiniones en un lugar tan público :-).

@blefloch Hay un par de cosas necesarias. La primera es detectar un par / triplete / cuarteto UTF-8 y agarrarlo entero en lugar de token por token. Eso es bastante fácil: verifique si hay tokens de caracteres activos iguales al punto de partida inputenc . La segunda fase es saber cómo cambiarlos. La razón por la que mencioné tomar el enfoque \IeC{...} es que no necesitamos datos _nuevos_: es la misma forma en que \MakeUppercase maneja y, por lo tanto, usa los datos \@uclclist que estamos ya coleccionando.

La razón por la que mencioné tomar el enfoque IeC {...} es que no necesitamos nuevos datos:
Bueno, es posible que necesite un poco más si desea cubrir absolutamente todos los personajes que cambian de mayúsculas y minúsculas (es posible que aún no todos tengan LICR).

El uso de números y tablas Unicode es estéticamente más atractivo, por supuesto. Pero si 'tablas de nombres' funciona por ahora. . .

Para cirílico, griego, armenio, etc., etc., ¿es posible utilizar nuevos LICR de la forma cyr {}, ¿un poco como acentos?

@ car222222 El problema surgió porque hay lugares en los que el \MakeUppercase actual funcionará y que el \text_uppercase:n no funcionará, lo que se reduce a cosas que pasan por u8:... . Por eso comencé con esto. Si queremos el rango Unicode completo en pdfTeX (factible), necesitaremos almacenar los datos manualmente en una matriz de enteros.

Si queremos el rango Unicode completo en pdfTeX (factible), necesitaremos almacenar los datos manualmente en una matriz de enteros.

Dado que pdfTeX deliberadamente solo proporciona caracteres utf8 si son compatibles con las codificaciones de fuentes cargadas, es cuestionable cambiar primero el caso y luego encontrar que el resultado es un carácter no admitido. Por supuesto, si todos los datos están dentro del formato, entonces no hay carga útil adicional (aparte del tamaño que ocupa) y la preparación inicial.

Es cuestionable cambiar primero el caso y luego encontrar que el resultado es un carácter no admitido.

No encuentro esto muy problemático. Las minúsculas y las mayúsculas están en la misma codificación, por lo que solo obtendría un error en una alfa mayúscula si comienza con la alfa minúscula no admitida.

El 18/2/20 3:49 PM, Ulrike Fischer escribió:

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

No encuentro esto muy problemático. Las minúsculas y las mayúsculas están en
misma codificación, por lo que solo obtendría un error en una alfa mayúscula si
comience con el alfa en minúscula no admitido.

Incluso si existe una codificación con alfa en minúsculas pero no en mayúsculas
alfa (este podría ser el caso de algunos de los acentos más raros),
obtener un error de carácter Unicode no configurado parece mejor que
obteniendo accidentalmente el carácter en minúsculas.

Estoy de acuerdo con Ulrike y Bruno. Pero no puedo imaginar un caso realista (juego de palabras) en el que los caracteres en mayúsculas y minúsculas no estén disponibles / no disponibles simultáneamente.

Dado que pdfTeX deliberadamente solo proporciona caracteres utf8 si son compatibles con las codificaciones de fuentes cargadas

¿Que quieres decir? pdfTeX no 'proporciona caracteres' en absoluto, ¿verdad? Y 'codificaciones de fuentes cargadas' es un concepto de LaTeX, no de motor.

Tal vez signifique que en la forma en que originalmente configuramos las cosas utf8 para LaTeX, los LICR eran solo (y las asignaciones se proporcionaron solo 'para codificaciones conocidas' y luego solo se cargaron para codificaciones cargadas.

Es cierto, pero no hay necesidad de mantener tales restricciones en estos días, ¿verdad?
Ciertamente, ahora podemos proporcionarlos fácilmente para cualquier subconjunto de Unicode que deseemos, y en este contexto solo necesitamos cubrir todos los 'caracteres casables'.

Descargo de responsabilidad: nunca me gustó mucho esa restricción a las codificaciones conocidas :-).

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

¿Que quieres decir? pdfTeX no 'proporciona caracteres' en absoluto, ¿verdad? Y
'codificaciones de fuentes cargadas' es un concepto de LaTeX, no de motor.

que significa pdflatex y escribir pdftex

Tal vez signifique que de la forma en que originalmente configuramos las cosas de utf8 para
LaTeX, LICR eran solo (y las asignaciones se proporcionaron solo 'para conocidos
codificaciones 'y luego solo se cargan para las codificaciones cargadas.

sí, lo cual fue algo bueno TM porque mantuvo al mundo LaTeX libre de
tofu y personajes faltantes

Es cierto, pero no hay necesidad de mantener tales restricciones en estos días, ¿verdad?
Ciertamente, ahora podemos proporcionarlos fácilmente para cualquier subconjunto de Unicode que
deseamos, y en este contexto solo necesitamos cubrir todos los 'personajes casables'.

sí hay. si no tiene los glifos para componer los caracteres,
no tiene sentido hacerlo, por lo que afirmar que puede utilizar Unicode como
como hace xetex o luatex (látex) y luego solo genera agujeros y no
char XXX advertencias en el registro es un paso atrás al pdflatex
solución, en mi humilde opinión

Descargo de responsabilidad: nunca me gustó mucho esa restricción a las codificaciones conocidas :-).

bueno, mientras escribas en inglés, por lo general no importa si
escribir en otros idiomas y su documento se corrompe sin
advirtiéndote que lo hace

Es muy posible que haya razones para no cargar LICR para personajes no representables.

Pero aquí solo estamos hablando de definir estos LICR y los caracteres en mayúsculas, tenga en cuenta los 'caracteres'.
Nada que ver con la composición tipográfica, por lo que las codificaciones / fuentes que están disponibles no son relevantes.
Caso de uso: la forma mejorada es solo para usar en un marcador de pdf, nunca para ser tipográfica (¡por TeX, al menos!)

Después de analizar el problema un poco más, parecía más fácil manejarlo usando una lista fija de asignaciones en lugar de intentar hacer cosas mirando dentro de los caracteres activos. Eché un vistazo rápido a cuántos puntos de código hay con datos de cambio de mayúsculas y minúsculas: alrededor de 2000. Eso es posiblemente mucho para hacer todos, así que por el momento he elegido los griegos y cirílicos que están cubiertos por T2 / LGR . Los pensamientos son bienvenidos.

¿qué pasa con la idea de almacenarlos todos en un intarray?

El problema con el uso de un intarray es que no podemos hacerlo escaso, por lo que el tamaño dependería del punto de código del valor final que se almacenará. También hay un pequeño impacto en el rendimiento en el punto de uso, ya que tendríamos que extraer, convertir a bytes y construir los caracteres activos en ese momento, en lugar de hacerlo una vez en el momento de la carga.

Además, de vuelta con el asunto de 'qué puntos de código tienen glifos', hasta donde yo sé, los griegos y cirílicos más los latinos ya cubiertos son, con mucho, los más útiles.

Bueno, para los griegos y los cirilos son los más útiles, ¡sí! ¿Pero no al resto del mundo?
Das heisst: ¿cómo midió esta utilidad?

Supongo que el total aumenta demasiado debido a la gran cantidad de derivados latinos que existen, ¿o no?
2000 son aproximadamente 30+ alfabetos típicos, supongo.

'Utilidad' aquí estaba comenzando con 'lo que funciona actualmente en pdfTeX', entonces 'qué codificaciones están disponibles'. No estoy seguro de qué cubren exactamente todas las asignaciones: es posible que haya falsos positivos. Es de suponer que, para empezar, existen todas las variantes matemáticas (cursiva, sanserif, ...).

Mucho tiene acento latino / cirílico / griego, luego hay copic, armenio, húngaro antiguo, cherokee, etc. Ciertamente no 30 alfabetos, pero probablemente al menos 10.

Lista completa de guiones:

• Latín (> 700 puntos de código) incl. versiones de ancho completo
• griego
• copto
• cirílico
• armenio
• georgiano
• Cherokee
• Glagolítico
• Deseret
• Osage
• Húngaro antiguo
• Warang
• Medefaidrina
• Adlam

!! Latín (> 700 puntos de código) incl. versiones de ancho completo
Ah, sí, sin mencionar las versiones de 'superíndice encerrado en un círculo',
y estoy seguro de que ya debe haber emojis en minúsculas en Unicode :-).

@ car222222 Afortunadamente, no hay letras en un círculo;) Se trata principalmente de muchas, muchas versiones de acento combinadas.

@josephwright pero realmente deberías implementar \text_lowercase:n{\emoji{Man}} = \emoji{Boy} ;-)

¿Pensamientos sobre una mayor cobertura? ¿O vamos con lo que he configurado por el momento?

El manejo de \.I İ en el MWE anterior es diferente en pdfLaTeX (también en comparación con los motores Unicode), pero admito que İ es probablemente un caso complicado en el código de cambio de caso genérico.

Así que probé el cambiador de casos 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> ) y LuaLaTeX y XeLaTeX no están contentos

! Undefined control sequence.
<inserted text> ı

@moewew Hmm, eso es un poco extraño: lo conseguiré está ordenado

@moewew Problema específico con turco: ahora solucionado

¿Pensamientos sobre una mayor cobertura? ¿O vamos con lo que he configurado por el momento?

Comenzaría con el presente y lo extendería cuando surgiera la necesidad.

De acuerdo, creo que esa es la mejor posición y también significa que podemos mantener los problemas en movimiento. Terminaré aquí y las adiciones específicas se pueden abordar en nuevos números.