Latex3: Changement de casse pour le cyrillique

u8:И ->IeC {CYRI }

Ne serait-il pas plus logique d'extraire И de u8:И et de rechercher la casse
informations dans certains intraray?

@blefloch
Oui!

Quelles sont ces commandes u8:... de toute façon ? Sont-ils nécessaires ?

@blefloch
Oui!

ou peut-être pas Chris. On peut avoir à gérer la notation ^^ à cet endroit au lieu de И mais dans l'ensemble je suis d'accord que cela semble être le meilleur point de départ

Quelles sont ces commandes u8:... de toute façon ? Sont-ils nécessaires ?

vous devriez savoir :-) votre nom est sur le fichier qui contient ce code. Oui, ils sont nécessaires: dans pdftex, LaTeX voit les octets les analyse et construit un seul csname à partir d'eux \u8:... qui contient le LICR pour ce caractère utf8 qui dans le cas ci-dessus est \IeC {\CYRI } ou si le \u8:... n'est pas défini répond sans représentation Unicode pour ...

vous devriez savoir :-) votre nom est sur le fichier qui contient ce code.
Mais tout ce dont je peux être responsable n'est pas nécessaire :-).

Je suis d'accord, je devrais regarder le code d'origine! Au moins pour savoir d'où vient le :.

Mais je devrais arrêter maintenant au cas où je mettrais en colère une certaine personne en affichant mes opinions dans un lieu aussi public :-).

@blefloch Il y a deux ou inputenc . La deuxième phase est de savoir comment les changer de boîtier. La raison pour laquelle j'ai mentionné l'approche \IeC{...} est que nous n'avons pas besoin de _nouvelles_ données : c'est de la même manière que \MakeUppercase gère et utilise donc les données \@uclclist nous sommes collectionne déjà.

La raison pour laquelle j'ai mentionné l'approche IeC{...} est que nous n'avons alors pas besoin de nouvelles données :
Eh bien, vous aurez peut-être besoin d'un peu plus si vous voulez couvrir absolument tous les caractères qui changent de casse (ils n'ont peut-être pas encore tous les LICR.)

L'utilisation de nombres et de tableaux Unicode est bien sûr plus attrayante sur le plan esthétique. Mais si les « tables des noms » fonctionnent pour le moment. . .

Pour le cyrillique, le grec, l'arménien, etc etc, est-il possible d'utiliser de nouveaux LICR de la forme cyr{}, un peu comme les accents ?

@car222222 Le problème est survenu car il y a des endroits où le \MakeUppercase actuel fonctionnera que \text_uppercase:n , ce qui se résume à des choses qui passent par u8:... . C'est pourquoi j'ai commencé par ça. Si nous voulons la plage Unicode complète dans pdfTeX (faisable), nous devrons stocker les données manuellement dans un tableau d'entiers.

Si nous voulons la plage Unicode complète dans pdfTeX (faisable), nous devrons stocker les données manuellement dans un tableau d'entiers.

Étant donné que pdfTeX ne fournit délibérément des caractères utf8 que s'il est pris en charge par les codages de police chargés, il est discutable de changer d'abord la casse et de constater ensuite que le résultat est un caractère non pris en charge. Bien sûr, si toutes les données sont à l'intérieur du format, il n'y a pas de charge utile supplémentaire (autre que la taille qu'elles prennent) et la préparation initiale.

il est discutable de changer d'abord la casse et de constater ensuite que le résultat est un caractère non pris en charge.

Je ne trouve pas cela très problématique. Les minuscules et les majuscules sont dans le même encodage, vous n'obtiendrez donc une erreur sur un alpha majuscule que si vous commencez avec l'alpha minuscule non pris en charge.

Le 18/02/20 15h49, Ulrike Fischer a écrit :

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

Je ne trouve pas cela très problématique. Les minuscules et les majuscules sont dans le
même encodage, vous n'obtiendrez donc une erreur sur un alpha majuscule que si vous
commencez par l'alpha minuscule non pris en charge.

Même s'il existe un encodage avec alpha minuscule mais pas majuscule
alpha (cela pourrait être le cas pour certains des accents les plus rares),
obtenir une erreur de caractère Unicode non configuré semble mieux que
obtenir accidentellement le caractère minuscule.

Je suis d'accord avec Ulrike et Bruno. Mais je n'arrive pas à imaginer un cas réaliste (jeu de mots voulu) où les caractères majuscules et minuscules ne sont pas à la fois disponibles/indisponibles simultanément.

Étant donné que pdfTeX ne fournit délibérément des caractères utf8 que s'il est pris en charge par les encodages de police chargés

Ce qui signifie? pdfTeX ne "fournit pas de caractères", n'est-ce pas ? Et « encodages de polices chargées » est un concept LaTeX, pas un moteur.

Cela signifie peut-être que dans la façon dont nous avons initialement configuré les éléments utf8 pour LaTeX, les LICR n'étaient que (et les mappages n'étaient fournis que «pour les encodages connus», puis chargés uniquement pour les encodages chargés.

C'est vrai, mais il n'est pas nécessaire de maintenir de telles restrictions de nos jours, n'est-ce pas ?
Nous pouvons certainement maintenant les fournir facilement pour n'importe quel sous-ensemble d'Unicode que nous souhaitons, et dans ce contexte, nous n'avons besoin de couvrir que tous les « caractères casables ».

Avis de non-responsabilité : je n'ai jamais été très intéressé par cette restriction aux encodages connus :-).

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

Ce qui signifie? pdfTeX ne "fournit pas de caractères", n'est-ce pas ? Et
'loaded font encodings' est un concept LaTeX, pas un moteur.

sens pdflatex et écriture pdftex

Peut-être que cela signifie que dans la façon dont nous avons initialement configuré les éléments utf8 pour
LaTeX, les LICR n'étaient (et les mappages n'étaient fournis que "pour les
encodings', puis chargé uniquement pour les encodages chargés.

oui, ce qui était une bonne chose TM parce que cela a gardé le monde LaTeX libre de
tofu et caractères manquants

C'est vrai, mais il n'est pas nécessaire de maintenir de telles restrictions de nos jours, n'est-ce pas ?
Nous pouvons certainement maintenant les fournir facilement pour tout sous-ensemble d'Unicode que nous
souhaitez, et dans ce contexte, nous avons seulement besoin de couvrir tous les "caractères casables".

Oui il y a. si vous n'avez pas les glyphes pour composer les caractères, il
est inutile de le faire, c'est pourquoi prétendre que vous pouvez faire unicode comme
comme le fait xetex ou luatex (latex), puis générer des trous et non
les avertissements char XXX dans le journal sont un pas en arrière vers le pdflatex
solution, à mon humble avis

Avis de non-responsabilité : je n'ai jamais été très intéressé par cette restriction aux encodages connus :-).

eh bien, tant que vous écrivez en anglais, cela n'a généralement pas d'importance si vous
écrivez dans d'autres langues et votre document est corrompu sans
vous avertissant que c'est le cas

Il peut y avoir des raisons de ne pas charger les LICR pour les caractères non représentables.

Mais ici, nous ne parlons que de définir ces LICR et les caractères majuscules, notez les « caractères ».
Rien à voir avec leur composition, donc les encodages/polices disponibles ne sont pas pertinents.
Cas d'utilisation : le formulaire en majuscule est uniquement destiné à être utilisé dans un signet pdf, ne doit jamais être composé (par TeX, au moins !)

Après avoir examiné le problème un peu plus, il semblait plus facile de le gérer en utilisant une liste fixe de mappages plutôt que d'essayer de faire des choses en regardant à l'intérieur des caractères actifs. J'ai jeté un coup d'œil rapide au nombre de points de code avec les données de changement de casse : environ 2000. C'est peut-être un peu trop pour tous les faire, donc pour le moment j'ai choisi les grecs et cyrilliques qui sont couverts par T2 / LGR . Pensées bienvenues.

qu'en est-il de l'idée de tous les stocker dans un intraray ?

Le problème avec l'utilisation d'un intarray est que nous ne pouvons pas le rendre clairsemé, donc la taille dépendrait du point de code de la valeur finale à stocker. Il y a aussi un peu de performance au point d'utilisation car nous devrons alors extraire, convertir en octets et construire les caractères actifs, plutôt que de le faire une seule fois au moment du chargement.

De plus, de retour avec l'affaire "quels points de code ont des glyphes", pour autant que je sache, les grecs et cyrlliques ainsi que les latins déjà couverts sont de loin les plus utiles

Eh bien, pour les Grecs et les Cyrilles, ce sont les plus utiles, oui ! Mais pas pour le reste du monde ?
Das heisst : comment avez-vous mesuré cette utilité ?

Je suppose que le total augmente si grand en raison des nombreux dérivés latins, ou non ?
2000 correspond à environ 30+ alphabets typiques, je suppose.

« Utilitaire » ici commençait tout juste avec « ce qui fonctionne actuellement dans pdfTeX », donc « quels encodages sont disponibles ». Je ne suis pas sûr de ce que couvrent exactement tous les mappages : il est possible qu'il y ait des faux positifs. Vraisemblablement, il y a pour commencer toutes les variantes mathématiques (italique, sanserif, ...).

Une grande partie est accentuée en latin/cyrillique/grec, puis il y a le copic, l'arménien, le vieux hongrois, le cherokee, etc. Certainement pas 30 alphabets, mais probablement au moins 10.

Liste complète des scripts :

• Latin (>700 points de code !) incl. versions pleine largeur
• grec
• Copte
• cyrillique
• arménien
• géorgien
• Cherokee
• glagolitique
• Déseret
• Osage
• Hongrois ancien
• Warang
• Médéfaidrine
• Adam

!! Latin (>700 points de code !) incl. versions pleine largeur
Ah oui, sans parler des versions 'superscript cerclé',
et je suis sûr qu'il doit y avoir des emojis en minuscules en Unicode maintenant :-).

@ car222222 Heureusement, pas de lettres encerclées ;) C'est principalement beaucoup, beaucoup de combinaisons de versions d'accent.

@josephwright mais vous devriez vraiment implémenter \text_lowercase:n{\emoji{Man}} = \emoji{Boy} ;-)

Des réflexions sur une couverture supplémentaire? Ou allons-nous avec ce que j'ai mis en place pour le moment ?

La gestion de \.I İ dans le MWE ci-dessus est différente dans pdfLaTeX (également comparée aux moteurs Unicode), mais j'admets que İ est probablement un cas délicat dans le code de changement de cas générique.

J'ai donc essayé le changeur de cas turc

\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> ) et LuaLaTeX et XeLaTeX ne sont pas contents

! Undefined control sequence.
<inserted text> ı

@moewew Hmm, c'est un peu étrange: je vais être trié

@moewew Problème spécifique avec le turc : maintenant corrigé

Des réflexions sur une couverture supplémentaire? Ou allons-nous avec ce que j'ai mis en place pour le moment ?

Je commencerais par le présent et je prolongerais quand le besoin s'en fait sentir

OK, je pense que c'est la meilleure position, et cela signifie également que nous pouvons faire avancer les problèmes. Je vais terminer ici et des ajouts spécifiques peuvent être traités dans de nouveaux numéros.