Latex3: Groß-/Kleinschreibung für Kyrillisch ändern

u8:И ->IEC {CYRI}

Könnte es nicht sinnvoller sein, И aus u8:И zu extrahieren und Fall nachzuschlagen
Informationen in einem Intarray?

@blefloch
Jawohl!

Was sind das überhaupt für u8:...-Befehle? Werden sie benötigt?

@blefloch
Jawohl!

oder vielleicht nicht Chris. An dieser Stelle muss man sich vielleicht mit ^^ Notation statt mit И befassen, aber im Großen und Ganzen stimme ich zu, dass das der bessere Ausgangspunkt zu sein scheint

Was sind das überhaupt für u8:...-Befehle? Werden sie benötigt?

Sie sollten es wissen :-) Ihr Name steht in der Datei, die diesen Code enthält. Ja, sie werden benötigt: in pdftex sieht LaTeX Bytes, analysiert sie und erstellt daraus einen einzelnen csname \u8:... der die LICR für dieses utf8-Zeichen enthält, das im obigen Fall \IeC {\CYRI } oder wenn die \u8:... ist nicht definiert antwortet ohne Unicode-Darstellung für ...

Sie sollten es wissen :-) Ihr Name steht in der Datei, die diesen Code enthält.
Aber nicht alles, wofür ich verantwortlich sein könnte, wird benötigt :-).

Ich stimme zu, dass ich mir den Originalcode ansehen sollte! Zumindest um herauszufinden, woher das : kam.

Aber ich sollte jetzt aufhören, falls ich eine bestimmte Person verärgere, indem ich meine Meinung an einem so öffentlichen Ort präsentiere :-).

@blefloch Es werden ein paar Dinge benötigt. Die erste besteht darin, ein UTF-8-Paar/Triplett/Quartett zu erkennen und es im Ganzen zu erfassen, anstatt Token für Token. Das ist ganz einfach: Suchen Sie nach aktiven Zeichen-Token, die dem Startpunkt von inputenc . Die zweite Phase besteht darin, zu wissen, wie die Groß-/Kleinschreibung geändert werden kann. Der Grund, warum ich den Ansatz von \IeC{...} , ist, dass wir keine _neuen_ Daten benötigen: Es ist die gleiche Art und Weise, wie \MakeUppercase sie behandelt und daher die \@uclclist Daten verwendet, die wir sind schon sammeln.

Der Grund, warum ich den IEC{...}-Ansatz erwähnt habe, ist, dass wir keine neuen Daten benötigen:
Nun, Sie benötigen möglicherweise etwas mehr, wenn Sie absolut jeden Charakter abdecken möchten, der die Groß-/Kleinschreibung ändert (Sie haben möglicherweise noch nicht alle LICRs.)

Die Verwendung von Zahlen und Unicode-Tabellen ist natürlich ästhetisch ansprechender. Aber wenn 'Namenstabellen' vorerst funktioniert. . .

Ist es für Kyrillisch, Griechisch, Armenisch usw. möglich, neue LICRs der Form cyr{}, ein bisschen wie Akzente?

@car222222 Das Problem trat auf, da es Orte gibt, an denen das aktuelle \MakeUppercase funktioniert, an denen \text_uppercase:n nicht funktioniert, was auf Dinge zurückzuführen ist, die über u8:... laufen. Deshalb habe ich damit angefangen. Wenn wir den gesamten Unicode-Bereich in pdfTeX (machbar) haben möchten, müssen wir die Daten manuell in einem Integer-Array speichern.

Wenn wir den gesamten Unicode-Bereich in pdfTeX (machbar) haben möchten, müssen wir die Daten manuell in einem Integer-Array speichern.

Da pdfTeX bewusst nur utf8-Zeichen bereitstellt, wenn dies von den geladenen Schriftcodierungen unterstützt wird, ist es fragwürdig, zuerst die Groß-/Kleinschreibung zu ändern und dann festzustellen, dass das Ergebnis ein nicht unterstütztes Zeichen ist. Wenn sich die gesamten Daten innerhalb des Formats befinden, gibt es natürlich keine zusätzlichen Nutzdaten (außer der von ihnen eingenommenen Größe) und die anfängliche Vorbereitung.

Es ist fragwürdig, zuerst die Groß-/Kleinschreibung zu ändern und dann festzustellen, dass das Ergebnis ein nicht unterstütztes Zeichen ist.

Das finde ich nicht sehr problematisch. Klein- und Großbuchstaben haben dieselbe Codierung, sodass Sie nur einen Fehler bei einem großen Alpha erhalten, wenn Sie mit dem nicht unterstützten Kleinbuchstaben beginnen.

Ulrike Fischer schrieb am 18.02.20 15:49:

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

Das finde ich nicht sehr problematisch. Klein- und Großbuchstaben stehen im
die gleiche Kodierung, sodass Sie nur dann einen Fehler bei einem Großbuchstaben erhalten, wenn Sie
Beginnen Sie mit dem nicht unterstützten Kleinbuchstaben Alpha.

Auch wenn es eine Kodierung mit Kleinbuchstaben Alpha aber nicht Großbuchstaben gibt
alpha (dies könnte für einige der selteneren Akzente plausibel der Fall sein),
Es scheint besser, einen Fehler zu erhalten, wenn Unicode-Zeichen nicht eingerichtet sind
versehentlich das Kleinbuchstabenzeichen erhalten.

Ich stimme Ulrike und Bruno zu. Aber ich kann mir keinen realistischen Fall vorstellen (Wortspiel beabsichtigt), bei dem die Groß- und Kleinbuchstaben nicht gleichzeitig verfügbar / nicht verfügbar sind.

Da pdfTeX bewusst nur utf8-Zeichen bereitstellt, wenn dies von den geladenen Schriftkodierungen unterstützt wird

Bedeutung was? pdfTeX liefert überhaupt keine Zeichen, oder? Und 'Loaded Font Encodings' ist ein LaTeX-Konzept, kein Engine-Konzept.

Vielleicht bedeutet es, dass in der Art und Weise, wie wir das utf8-Zeug für LaTeX ursprünglich eingerichtet haben, nur LICRs vorhanden waren (und Mappings nur für "bekannte Kodierungen" bereitgestellt und dann nur für geladene Kodierungen geladen wurden.

Stimmt, aber solche Einschränkungen müssen heutzutage nicht mehr eingehalten werden, oder?
Wir können sie jetzt sicherlich problemlos für jede beliebige Untermenge von Unicode bereitstellen, und in diesem Zusammenhang müssen wir nur alle 'Großbuchstaben' abdecken.

Haftungsausschluss: Diese Beschränkung auf bekannte Kodierungen hat mir nie besonders gefallen :-).

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

Bedeutung was? pdfTeX liefert überhaupt keine Zeichen, oder? Und
'Loaded Font Encodings' ist ein LaTeX-Konzept, kein Engine-Konzept.

Bedeutung pdflatex und pdftex schreiben

Vielleicht bedeutet es, dass wir das UTF8-Zeug ursprünglich so eingerichtet haben, für das wir
LaTeX, LICRs waren nur (und Mappings wurden nur "für bekannte" bereitgestellt
Kodierungen' und wird dann nur für geladene Kodierungen geladen.

Ja, das war eine gute Sache TM, denn das hielt die LaTeX-Welt frei von
Tofu und fehlende Zeichen

Stimmt, aber solche Einschränkungen müssen heutzutage nicht mehr eingehalten werden, oder?
Wir können sie jetzt sicherlich problemlos für jede Teilmenge von Unicode bereitstellen, die wir
möchten, und in diesem Zusammenhang brauchen wir nur alle 'Casable Characters' abzudecken.

ja da ist. Wenn Sie nicht die Glyphen haben, um die Zeichen zu setzen,
Es ist sinnlos, dies zu tun, weshalb zu behaupten, dass Sie Unicode als tun können
wie xetex oder luatex (latex) und dann nur Löcher erzeugen ans No
char XXX Warnungen im Log ist ein Rückschritt zum pdflatex
Lösung, imho

Haftungsausschluss: Diese Beschränkung auf bekannte Kodierungen hat mir nie besonders gefallen :-).

Nun, solange du Englisch schreibst, ist es normalerweise egal, ob du
Schreiben Sie in anderen Sprachen und Ihr Dokument wird beschädigt, ohne
warnt dich, es tut

Es kann durchaus Gründe geben, LICRs für nicht darstellbare Zeichen nicht zu laden.

Aber hier sprechen wir nur über die Definition dieser LICRs und Großbuchstaben, beachten Sie 'Zeichen'.
Hat nichts mit dem Setzen zu tun, daher sind die verfügbaren Codierungen/Schriften nicht relevant.
Anwendungsfall: Die großgeschriebene Form ist nur für die Verwendung in einem PDF-Lesezeichen bestimmt und darf niemals gesetzt werden (zumindest von TeX!)

Nachdem wir uns das Problem ein wenig genauer angesehen hatten, schien es einfacher, es mit einer festen Liste von Zuordnungen zu lösen, anstatt zu versuchen, Dinge durch einen Blick in aktive Zeichen zu tun. Ich habe mir kurz angeschaut, wie viele Codepunkte es mit Falländerungsdaten gibt: ungefähr 2000. Das ist möglicherweise ein bisschen viel, um sie alle zu erledigen, also habe ich für den Moment griechische und kyrillische genommen, die von T2 abgedeckt werden. LGR . Gedanken willkommen.

Wie wäre es mit der Idee, sie alle in einem Intarray zu speichern?

Die Sache mit der Verwendung eines Intarrays ist, dass wir es nicht spärlich machen können, daher würde die Größe vom Codepunkt des endgültigen zu speichernden Werts abhängen. Es gibt auch einen kleinen Leistungseinbruch am Point-of-Use, da wir dann die aktiven Zeichen extrahieren, in Byte konvertieren und konstruieren müssten, anstatt dies einmal zur Ladezeit zu tun.

Auch zurück mit dem Geschäft mit 'welche Codepunkte haben Glyphen', soweit ich weiß, sind die griechischen und kyrillischen sowie die bereits behandelten lateinischen bei weitem die nützlichsten

Nun, für die Griechen und Kyriller sind sie die nützlichsten, ja! Aber nicht für den Rest der Welt?
Das heißt: wie haben Sie diesen Nutzen gemessen?

Ich schätze, die Summe wird durch die vielen Latein-Derivate so groß, oder nicht?
2000 sind ungefähr 30+ typische Alphabete, denke ich.

'Utility' begann hier nur mit 'was funktioniert derzeit in pdfTeX', also 'welche Kodierungen sind verfügbar'. Ich bin mir nicht sicher, was genau alle Mappings abdecken: Es ist möglich, dass es falsch positive Ergebnisse gibt. Vermutlich gibt es für den Anfang alle mathematischen Varianten (kursiv, sanserif, ...).

Vieles davon ist lateinisch/kyrillisch/griechisch akzentuiert, dann gibt es Copic, Armenian, Altungarisch, Cherokee usw. Sicherlich nicht 30 Alphabete, aber wahrscheinlich mindestens 10.

Vollständige Liste der Skripte:

• Latein (>700 Codepunkte!) inkl. Versionen mit voller Breite
• griechisch
• koptisch
• kyrillisch
• Armenisch
• georgisch
• Cherokee
• glagolitisch
• Wüste
• Osage
• Alt-Ungarisch
• Warang
• Medefaidrin
• Adlam

!! Latein (>700 Codepunkte!) inkl. Versionen mit voller Breite
Ah ja, ganz zu schweigen von "eingekreisten hochgestellten" Versionen,
und ich bin mir sicher, dass es mittlerweile Emojis in Kleinbuchstaben in Unicode geben muss :-).

@car222222 Zum Glück keine eingekreisten Buchstaben;) Es sind hauptsächlich viele, viele Kombinationen von Akzentversionen.

@josephwright aber du solltest wirklich \text_lowercase:n{\emoji{Man}} = \emoji{Boy} implementieren ;-)

Gedanken zur weiteren Berichterstattung? Oder gehen wir mit dem, was ich für die Gegenwart eingerichtet habe?

Die Handhabung von \.I İ im obigen MWE ist in pdfLaTeX anders (auch im Vergleich zu den Unicode-Engines), aber ich gebe zu, dass İ im generischen Falländerungscode wahrscheinlich ein kniffliger Fall ist.

Also habe ich es mit dem türkischen Kofferwechsler versucht

\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> ) und LuaLaTeX und XeLaTeX sind nicht glücklich

! Undefined control sequence.
<inserted text> ı

@moewew Hmm , das ist schon etwas seltsam: Ich kriege sortiert

@moewew Spezifisches Problem mit Türkisch: jetzt behoben

Gedanken zur weiteren Berichterstattung? Oder gehen wir mit dem, was ich für die Gegenwart eingerichtet habe?

Ich würde mit der Gegenwart beginnen und bei Bedarf erweitern

OK, ich denke, das ist die beste Position und bedeutet auch, dass wir die Probleme am Laufen halten können. Ich schließe hier und spezifische Ergänzungen können in neuen Ausgaben behandelt werden.