Latex3: キリル文字のケース変更

u8：И-> IeC {CYRI}

u8：ИからИを抽出し、ケースを検索する方が理にかなっていますか？
いくつかのintarrayの情報？

@blefloch
はい！

とにかくこれらのu8：...コマンドは何ですか？ それらは必要ですか？

@blefloch
はい！

または多分クリスではありません。 その場所でИの代わりに^^表記を処理する必要があるかもしれませんが、全体として、それがより良い出発点のように見えることに同意します

とにかくこれらのu8：...コマンドは何ですか？ それらは必要ですか？

あなたは知っておくべきです:-)あなたの名前はそのコードを含むファイルにあります。 はい、彼らが必要です：pdfTeXのラテックスは、バイトを見て、それらを分析し、そこから単一csnameを構築\u8:...上記の場合であることのutf8文字のためLICRを保持する\IeC {\CYRI }かをもし\u8:...が定義されていないため、Unicode表現なしで応答します...

あなたは知っておくべきです:-)あなたの名前はそのコードを含むファイルにあります。
しかし、私が責任を負う可能性のあるすべてが必要なわけではありません:-)。

元のコードを確認する必要があることに同意します。 少なくとも：がどこから来たのかを知るために。

しかし、私がそのような公共の場所で私の意見を表示することによって特定の人を怒らせる場合に備えて、私は今やめるべきです:-)。

@blefloch必要なものがいくつかあります。 1つ目は、UTF-8ペア/トリプレット/カルテットを見つけて、トークンごとではなく全体を取得することです。 これは非常に簡単です。 inputenc開始点に等しいアクティブなcharトークンを確認してください。 2番目のフェーズは、ケースを変更する方法を知ることです。 \IeC{...}アプローチを採用することに言及した理由は、_new_データが必要ないためです。これは、 \MakeUppercaseがそれらを処理するのと同じ方法であるため、現在の\@uclclistデータを使用します。すでに収集しています。

IeC {...}アプローチを採用することに言及した理由は、新しいデータが必要ないためです。
大文字と小文字が変わるすべてのキャラクターを完全にカバーしたい場合は、もう少し必要になるかもしれません（まだすべてのキャラクターがLICRを持っているわけではないかもしれません）。

もちろん、数字とUnicodeテーブルを使用する方が美的に魅力的です。 しかし、「名前の表」が今のところ機能する場合。 。 。

キリル文字、ギリシャ語、アルメニア語などの場合、cyr {の形式の新しいLICRを使用することは可能ですか。}、アクセントに少し似ていますか？

@ car222222この問題は、現在の\MakeUppercaseが機能し、 \text_uppercase:nが機能しない場所があるために発生しました。これは、 u8:...経由するものに帰着します。 だから私はこれから始めました。 pdfTeX（実行可能）で完全なUnicode範囲が必要な場合は、データを整数配列に手動で格納する必要があります。

pdfTeX（実行可能）で完全なUnicode範囲が必要な場合は、データを整数配列に手動で格納する必要があります。

pdfTeXがロードされたフォントエンコーディングでサポートされている場合にのみ意図的にutf8文字を提供することを考えると、最初に大文字と小文字を変更してから、結果がサポートされていない文字であることがわかります。 もちろん、データ全体がフォーマット内にある場合、追加のペイロード（データが占めるサイズ以外）と初期準備はありません。

最初に大文字と小文字を変更してから、結果がサポートされていない文字であることに気付くのは疑わしいです。

これはそれほど問題ではないと思います。 小文字と大文字は同じエンコーディングであるため、サポートされていない小文字のアルファで開始した場合にのみ、大文字のアルファでエラーが発生します。

2/18/20 15:49に、UlrikeFischerは次のように書いています。

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

これはそれほど問題ではないと思います。 小文字と大文字は
同じエンコーディングなので、大文字のアルファでエラーが発生するのは、
サポートされていない小文字のアルファから始めます。

大文字ではなく小文字のアルファを使用したエンコーディングが存在する場合でも
アルファ（これは、まれなアクセントのいくつかに当てはまる可能性があります）、
Unicode文字が設定されていないというエラーを取得する方が良いようです
誤って小文字を取得しました。

私はウルリケとブルーノに同意します。 しかし、大文字と小文字の両方が同時に使用可能/使用不可にならない現実的なケース（しゃれを意図したもの）を想像することはできません。

pdfTeXは、ロードされたフォントエンコーディングでサポートされている場合にのみ、意図的にutf8文字を提供します。

何を意味します？ pdfTeXは「文字を提供しません」ね。 また、「ロードされたフォントエンコーディング」はLaTeXの概念であり、エンジンの概念ではありません。

おそらく、LaTeX用にutf8を最初に設定した方法では、LICRのみが提供されていました（マッピングは「既知のエンコーディングに対してのみ」提供され、ロードされたエンコーディングに対してのみロードされました）。

本当ですが、最近はそのような制限を守る必要はありませんね。
確かに、必要なUnicodeのサブセットに簡単に提供できるようになりました。このコンテキストでは、すべての「大文字」をカバーするだけで済みます。

免責事項：私は既知のエンコーディングへのその制限にあまり熱心ではありませんでした:-)。

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

何を意味します？ pdfTeXは「文字を提供しません」ね。 と
「ロードされたフォントエンコーディング」はLaTeXの概念であり、エンジンの概念ではありません。

pdflatexを意味し、pdftexを書く

多分それは私達が最初にutf8のものをセットアップした方法でそれを意味します
LaTeX、LICRのみでした（そしてマッピングは既知の場合にのみ提供されました '
エンコーディング 'そしてロードされたエンコーディングに対してのみロードされます。

はい、それはLaTeXの世界を自由に保つためのGood ThingTMでした
豆腐と行方不明の文字

本当ですが、最近はそのような制限を守る必要はありませんね。
確かに、Unicodeのサブセットに簡単に提供できるようになりました。
希望し、このコンテキストでは、すべての「ケーブル文字」をカバーするだけで済みます。

はいあります。 文字をタイプセットするためのグリフがない場合は、
そうすることは無意味です、それがあなたが次のようにユニコードを行うと主張する理由です
xetexまたはluatex（latex）のように、穴を生成するだけです。
ログ内のcharXXX警告は、pdflatexへの一歩後退です
解決策、私見

免責事項：私は既知のエンコーディングへのその制限にあまり熱心ではありませんでした:-)。

ええと、あなたが英語を書いている限り、あなたが
他の言語で書くとあなたの文書は
警告します

表現できない文字のLICRをロードしない理由があるかもしれません。

ただし、ここでは、これらのLICRの定義と大文字の文字についてのみ説明しています。「文字」に注意してください。
それらを植字することとは何の関係もないので、利用可能なエンコーディング/フォントは関係ありません。
ユースケース：大文字のフォームはPDFブックマークでのみ使用され、タイプセットされることはありません（少なくとも、TeXによって！）

問題をもう少し調べた後、アクティブな文字の内部を調べて何かをしようとするよりも、マッピングの固定リストを使用して問題を処理する方が簡単であるように見えました。 大文字と小文字を変更するデータを含むコードポイントがいくつあるかを簡単に調べました。約2000です。すべてを実行するには少し多すぎる可能性があるため、今のところ、 T2カバーされているギリシャ語とキリル文字を選択しました。 LGR 。 考えは大歓迎です。

それらすべてをintarrayに格納するというアイデアはどうですか？

intarrayを使用する場合、スパースにすることはできないため、サイズは格納される最終値のコードポイントによって異なります。 また、ロード時に1回実行するのではなく、抽出してバイトに変換し、アクティブな文字を作成する必要があるため、使用時点でパフォーマンスが少し低下します。

また、「どのコードポイントにグリフがあるか」というビジネスに戻ると、私が知る限り、ギリシャ語とキリル文字に加えて、すでにカバーされているラテン文字がはるかに便利です。

ええと、ギリシャ人とキリルにとって、彼らは最も便利です、そうです！ しかし、世界の他の地域ではありませんか？
Das heisst：このユーティリティをどのように測定しましたか？

ラテン語の派生物がたくさんあるので、合計が非常に大きくなると思いますか？
2000年は約30以上の典型的なアルファベットだと思います。

ここでの「ユーティリティ」は、「現在pdfTeXで機能するもの」で始まったばかりなので、「使用可能なエンコーディング」です。 すべてのマッピングが正確に何をカバーしているかはわかりません。誤検知がある可能性があります。 おそらく、最初はすべての数学の変形（イタリック、サンセリフなど）があります。

その多くはラテン語/キリル文字/ギリシャ語がアクセントになっています。次に、コピック、アルメニア語、ロヴァーシュ文字、チェロキー文字などがあります。確かに30のアルファベットではありませんが、おそらく少なくとも10のアルファベットです。

スクリプトの完全なリスト：

• ラテン語（> 700コードポイント！） 全幅バージョン
• ギリシャ語
• コプト語
• キリル
• アルメニア語
• ジョージア語
• チェロキー
• グラゴル文字
• デザレット
• オセージ
• 古いハンガリー語
• ワラン
• メデファイドリン
• アドラム

!! ラテン語（> 700コードポイント！） 全幅バージョン
ああ、そうです、「丸で囲まれた上付き文字」バージョンは言うまでもなく、
そして、Unicodeには小文字の絵文字が必要だと確信しています:-)。

@ car222222幸いなことに丸で囲まれた文字はありません;）それは主にアクセントバージョンを組み合わせることがたくさんあります。

@josephwrightですが、実際には\text_lowercase:n{\emoji{Man}} = \emoji{Boy}を実装する必要があります;-)

さらなる報道についての考え？ それとも、私が現在設定したものを使用しますか？

上記のMWEでの\.I İの処理は、pdfLaTeXでは異なります（Unicodeエンジンとも比較されます）が、 İは、一般的なケース変更コードではおそらくトリッキーなケースであることを認めます。

だから私はトルコのケースチェンジャーを試しました

\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> ）とLuaLaTeXとXeLaTeXは満足していません

! Undefined control sequence.
<inserted text> ı

@moewewうーん、それは少し奇妙です：私はソートされます

@moewewトルコ語

さらなる報道についての考え？ それとも、私が現在設定したものを使用しますか？

私はプレゼントから始めて、必要が生じたときに延長します

OK、それが最良のポジションだと思います。また、問題を動かし続けることができるという意味でもあります。 ここで閉じます。特定の追加は、新しい問題で対処できます。