Latex3: Смена регистра на кириллицу

u8: И -> IeC {CYRI}

Разве не имеет смысла извлекать И из u8: И и искать регистр
информация в каком-то интаррие?

@blefloch
Да!

Что это вообще за команды u8: ...? Они нужны?

@blefloch
Да!

или, может быть, не Крис. Возможно, придется иметь дело с обозначением ^^ в этом месте вместо И, но в целом я согласен, что это похоже на лучшую отправную точку

Что это вообще за команды u8: ...? Они нужны?

вы должны знать :-) ваше имя находится в файле, который содержит этот код. Да, они необходимы: в pdftex LaTeX видит байты, анализирует их и строит из них одно csname \u8:... которое содержит LICR для этого символа utf8, который в приведенном выше случае равен \IeC {\CYRI } или если \u8:... не определено отвечает без представления Unicode для ...

вы должны знать :-) ваше имя находится в файле, который содержит этот код.
Но не все, за что я могу отвечать, нужно :-).

Я согласен, мне следует посмотреть исходный код! По крайней мере, чтобы узнать, откуда взялся:.

Но я должен остановиться сейчас, если я разозлю кого-то, высказав свое мнение в таком общественном месте :-).

@blefloch Тут нужно кое-что. Первый - обнаружить пару / триплет / квартет UTF-8 и получить ее целиком, а не по отдельности. Это достаточно просто: проверьте наличие активных токенов char, равных начальной точке inputenc . Второй этап - узнать, как их изменить. Причина, по которой я упомянул использование подхода \IeC{...} заключается в том, что нам не нужны _new_ данные: это точно так же, как \MakeUppercase обрабатывает их и поэтому использует \@uclclist data, которые мы уже собираю.

Причина, по которой я упомянул использование подхода IeC {...}, заключается в том, что нам не нужны новые данные:
Что ж, вам может понадобиться немного больше, если вы хотите охватить абсолютно каждого персонажа, который меняет регистр (возможно, не все они еще имеют LICR).

Использование чисел и таблиц Unicode, конечно, эстетически более привлекательно. Но если «Таблицы имен» пока работают. . .

Для кириллицы, греческого, армянского и т. Д. И т. Д. Можно использовать новые LICR в форме cyr {}, немного похоже на акценты?

@ car222222 Проблема возникла из-за того, что есть места, в которых текущий \MakeUppercase будет работать, а \text_uppercase:n - нет, что сводится к вещам, которые проходят через u8:... . Вот почему я начал с этого. Если нам нужен полный диапазон Unicode в pdfTeX (выполнимо), нам нужно сохранить данные вручную в целочисленном массиве.

Если нам нужен полный диапазон Unicode в pdfTeX (выполнимо), нам нужно сохранить данные вручную в целочисленном массиве.

Учитывая, что pdfTeX намеренно предоставляет символы utf8 только в том случае, если они поддерживаются загруженными кодировками шрифтов, сомнительно сначала изменить регистр, а затем обнаружить, что результатом является неподдерживаемый символ. Конечно, если все данные находятся внутри формата, тогда нет никакой дополнительной полезной нагрузки (кроме занимаемого ею размера) и начальной подготовки.

сомнительно сначала изменить регистр, а затем обнаружить, что результатом является неподдерживаемый символ.

Я не считаю это проблемой. Строчные и прописные буквы имеют одну и ту же кодировку, поэтому вы получите ошибку на заглавной альфа, только если начнете с неподдерживаемой строчной альфы.

18.02.20 15:49 Ульрике Фишер написала:

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

Я не считаю это проблемой. Строчные и прописные буквы находятся в
та же кодировка, поэтому вы получите ошибку на заглавной альфе, только если вы
начните с неподдерживаемого альфа-символа в нижнем регистре.

Даже если существует кодировка с альфа-буквой в нижнем регистре, но не в верхнем регистре
альфа (вероятно, это относится к некоторым из более редких акцентов),
получение ошибки Unicode char не настроено кажется лучше, чем
случайно получил символ в нижнем регистре.

Я согласен с Ульрикой и Бруно. Но я не могу представить себе реалистичный случай (каламбур), в котором символы верхнего и нижнего регистра недоступны / недоступны одновременно.

Учитывая, что pdfTeX намеренно предоставляет символы utf8, только если они поддерживаются загруженными кодировками шрифтов

Это означает, что? pdfTeX вообще не «предоставляет символы», не так ли? А «загруженные кодировки шрифтов» - это концепция LaTeX, а не движок.

Возможно, это означает, что в том способе, которым мы изначально настраивали материал utf8 для LaTeX, были только LICR (а сопоставления предоставлялись только «для известных кодировок», а затем загружались только для загруженных кодировок.

Верно, но в наши дни нет необходимости сохранять такие ограничения, не так ли?
Теперь мы, безусловно, можем легко предоставить их для любого подмножества Unicode, которое мы пожелаем, и в этом контексте нам нужно только охватывать все «символьные символы».

Отказ от ответственности: мне никогда не нравилось это ограничение на известные кодировки :-).

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

Это означает, что? pdfTeX вообще не «предоставляет символы», не так ли? А также
«загруженные кодировки шрифтов» - это концепция LaTeX, а не движок.

значение pdflatex и написание pdftex

Может быть, это означает, что так, как мы изначально настроили материал utf8 для
LaTeX, LICR были только (а сопоставления предоставлялись только для известных
encodings ', а затем загружается только для загруженных кодировок.

да, это была хорошая вещь TM, потому что это держало мир LaTeX свободным от
тофу и отсутствующие символы

Верно, но в наши дни нет необходимости сохранять такие ограничения, не так ли?
Теперь мы, безусловно, можем легко предоставить их для любого подмножества Unicode, которое мы
желаем, и в этом контексте нам нужно только охватить всех «обслуживаемых персонажей».

Да, есть. если у вас нет глифов для набора символов, это
это бессмысленно, поэтому утверждать, что вы можете использовать Unicode как
как xetex или luatex (латекс), а затем просто генерирует дыры и нет
Предупреждения char XXX в журнале - это шаг назад к pdflatex
решение, имхо

Отказ от ответственности: мне никогда не нравилось это ограничение на известные кодировки :-).

ну, пока вы пишете по-английски, обычно не имеет значения,
напишите на других языках, и ваш документ будет поврежден без
предупреждаю вас, что это так

Вполне могут быть причины не загружать LICR для непредставимых символов.

Но здесь мы говорим только об определении этих LICR и символов верхнего регистра, обратите внимание на «символы».
Ничего общего с их набором, поэтому имеющиеся кодировки / шрифты не актуальны.
Пример использования: улучшенная форма предназначена только для использования в закладках pdf, никогда не должна быть набрана (по крайней мере, с помощью TeX!)

Посмотрев на проблему немного подробнее, показалось, что легче справиться с ней, используя фиксированный список сопоставлений, чем пытаться делать что-то, заглядывая внутрь активных символов. Я быстро посмотрел, сколько существует кодовых точек с данными с изменением регистра: около 2000. Возможно, это многовато для их всех, поэтому в настоящее время я выбрал греческие и кириллические, которые покрываются T2 / LGR . Мысли приветствуются.

как насчет идеи хранить их все в массиве?

Проблема с использованием intarray заключается в том, что мы не можем сделать его разреженным, поэтому размер будет зависеть от кодовой точки последнего сохраняемого значения. Также есть небольшая производительность в точке использования, так как нам пришлось бы извлекать, преобразовывать в байты и затем создавать активные символы, а не делать это один раз во время загрузки.

Кроме того, возвращаясь к вопросу о том, какие кодовые точки имеют глифы, насколько мне известно, греческий и кирлический, а также уже рассмотренные латинские, на сегодняшний день являются наиболее полезными.

Что ж, для греков и кириллов они самые полезные, да! Но не для остального мира?
Das heisst: как вы измерили эту полезность?

Думаю, из-за большого количества латинских производных общая сумма становится такой большой, или нет?
Думаю, 2000 год - это примерно 30+ типичных алфавитов.

«Утилита» здесь только начиналась с «что сейчас работает в pdfTeX», значит «какие кодировки доступны». Я не уверен, что именно охватывают все сопоставления: возможно, есть ложные срабатывания. Предположительно для начала есть все математические варианты (курсив, сансериф, ...).

Во многих из них есть латинский / кириллица / греческий акцент, затем есть копический, армянский, древневенгерский, чероки и т. Д. Конечно, не 30 алфавитов, но, вероятно, не менее 10.

Полный список скриптов:

• Латинский (> 700 кодовых точек!), Вкл. полноширинные версии
• Греческий
• Коптский
• Кириллица
• Армянский
• Грузинский
• Чероки
• Глаголица
• Deseret
• Осейдж
• Древневенгерский
• Варанг
• Медефайдрин
• Адлам

!! Латинский (> 700 кодовых точек!), Вкл. полноширинные версии
Ах да, не говоря уже о версиях с надстрочными буквами в кружках,
и я уверен, что в Unicode уже должны быть эмодзи в нижнем регистре :-).

@ car222222 К счастью, нет обведенных букв;) В основном это много-много комбинационных версий с акцентом.

@josephwright, но вам действительно стоит реализовать \text_lowercase:n{\emoji{Man}} = \emoji{Boy} ;-)

Мысли о дальнейшем освещении? Или мы пойдем с тем, что я настроил на данный момент?

Обработка \.I İ в приведенном выше MWE отличается в 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 Конкретная проблема с турецким

Мысли о дальнейшем освещении? Или мы пойдем с тем, что я настроил на данный момент?

Я бы начал с подарка и расширил, когда возникнет необходимость

Хорошо, я думаю, что это лучшая позиция, а также означает, что мы можем продолжать решать проблемы. Я закрою здесь, и конкретные дополнения могут быть рассмотрены в новых выпусках.