Latex3: 西里尔字母的大小写更改

u8:И -> IeC {CYRI }

从 u8:И 中提取 И 并查找 case 不是更有意义吗
一些intarray中的信息？

@blefloch
是的！

这些 u8:... 命令是什么？ 他们需要吗？

@blefloch
是的！

或者也许不是克里斯。 人们可能不得不在那个地方处理^^符号而不是 И 但总的来说我同意这看起来是更好的起点

这些 u8:... 命令是什么？ 他们需要吗？

您应该知道 :-) 您的名字在包含该代码的文件上。 是的，它们是必需的：在 pdftex 中，LaTeX 看到字节分析它们并从中构造一个单独的 csname \u8:... ，它保存该 utf8 字符的 LICR，在上述情况下为\IeC {\CYRI }或\u8:...未定义响应没有 Unicode 表示...

您应该知道 :-) 您的名字在包含该代码的文件上。
但并非我可能负责的所有事情都是需要的:-)。

我同意我应该看看原始代码！ 至少要找出 : 的来源。

但是我现在应该停下来，以防我在这样的公共场所表达我的意见激怒某个人:-)。

@blefloch需要做几件事。 第一个是发现一个 UTF-8 对/三重奏/四重奏并将其全部抓取，而不是逐个标记。 这很容易：检查等于inputenc起点的活动字符标记。 第二阶段是知道如何改变它们。 我提到采用\IeC{...}方法的原因是我们不需要 _new_ 数据：这与\MakeUppercase处理它们的方式相同，因此使用我们正在使用的\@uclclist数据已经收集。

我提到采用 IeC{...} 方法的原因是我们不需要新数据：
好吧，如果您想完全涵盖每个更改大小写的字符，您可能需要更多一些（它们可能还没有全部具有 LICR。）

当然，使用数字和 Unicode 表在美学上更有吸引力。 但是，如果“名称表”现在有效。 . .

对于西里尔文、希腊文、亚美尼亚文等，是否可以使用 cyr{ 形式的新 LICR}，有点像口音？

@car222222问题出现了，因为有些地方当前\MakeUppercase会起作用而\text_uppercase:n不会，这归结为通过u8:...进行的事情。 这就是为什么我从这个开始。 如果我们想要 pdfTeX 中的完整 Unicode 范围（可行），我们需要手动将数据存储在整数数组中。

如果我们想要 pdfTeX 中的完整 Unicode 范围（可行），我们需要手动将数据存储在整数数组中。

鉴于 pdfTeX 故意仅提供 utf8 字符，如果加载的字体编码支持，则首先更改大小写然后发现结果是不受支持的字符是有问题的。 当然，如果整个数据都在格式内，那么就没有额外的有效载荷（除了它占用的大小）和初始准备。

先改变大小写然后发现结果是一个不受支持的字符是有问题的。

我不觉得这很成问题。 小写字母和大写字母采用相同的编码，因此如果您以不受支持的小写字母开头，您只会在大写字母 alpha 上出现错误。

在 2/18/20 下午 3:49，Ulrike Fischer 写道：

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

我不觉得这很成问题。 小写和大写在
相同的编码，所以你只会在大写字母上出现错误，如果你
从不受支持的小写字母 alpha 开始。

即使存在小写字母而不是大写字母的编码
alpha（这可能是一些罕见的口音的情况），
得到未设置 Unicode 字符的错误似乎比
不小心得到了小写字符。

我同意 Ulrike 和 Bruno 的观点。 但我无法想象一个现实的情况（双关语），其中大写和小写字符不能同时可用/不可用。

鉴于 pdfTeX 故意只提供 utf8 字符，如果加载的字体编码支持

那是什么意思？ pdfTeX 根本不“提供字符”，是吗？ 并且“加载的字体编码”是 LaTeX 概念，而不是引擎概念。

也许这意味着在我们最初为 LaTeX 设置 utf8 东西的方式中，LICRs 只是（并且只为“已知编码”提供映射，然后只为加载的编码加载。

是的，但现在没有必要保持这样的限制，是吗？
我们现在当然可以轻松地为我们希望的任何 Unicode 子集提供它们，在这种情况下，我们只需要涵盖所有“可转换字符”。

免责声明：我从来没有非常热衷于对已知编码的限制:-)。

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

那是什么意思？ pdfTeX 根本不“提供字符”，是吗？ 和
“加载的字体编码”是 LaTeX 的概念，而不是引擎的概念。

意义 pdflatex 和写作 pdftex

也许这意味着按照我们最初设置 utf8 的方式
LaTeX, LICRs 是唯一的（并且只提供了“已知的映射”
encodings'，然后仅加载已加载的编码。

是的，这是一件好事 TM 因为这让 LaTeX 世界没有
豆腐和缺失的字符

是的，但现在没有必要保持这样的限制，是吗？
我们现在当然可以轻松地为我们使用的任何 Unicode 子集提供它们
希望，在这种情况下，我们只需要涵盖所有“casable characters”。

就在这里。 如果你没有字形来排版它
这样做毫无意义，这就是为什么声称您 cn 将 unicode 作为
就像 xetex 或 luatex (latex) 一样，然后只生成孔 ans No
日志中的 char XXX 警告是向 pdflatex 倒退的一步
解决方案，恕我直言

免责声明：我从来没有非常热衷于对已知编码的限制:-)。

好吧，只要你会写英文，通常不会有什么问题
用其他语言编写，您的文档会在没有损坏的情况下损坏
警告你它确实如此

不为无法表示的字符加载 LICR 很可能是有原因的。

但在这里我们只讨论定义这些 LICR 和大写字符，注意“字符”。
与排版它们无关，因此可用的编码/字体无关紧要。
用例：uppecased 形式仅用于 pdf 书签，永远不会排版（至少由 TeX ！）

在对问题进行了更多研究之后，使用固定的映射列表来处理它似乎比尝试通过查看活动字符来做事更容易。 我快速查看了有多少个代码点具有大小写变化的数据：大约 2000。完成所有这些代码点可能有点多，因此目前我选择了T2涵盖的希腊语和西里尔语代码点LGR 。 欢迎提出想法。

将所有这些都存储在一个 intarray 中的想法怎么样？

使用 intarray 的问题是我们不能使其稀疏，因此大小将取决于要存储的最终值的代码点。 在使用点也有一些性能影响，因为我们必须提取、转换为字节并构造活动字符，而不是在加载时执行一次。

此外，回到“什么代码点有字形”的业务，据我所知，希腊语和西尔尔语以及已经涵盖的拉丁语是迄今为止最有用的

嗯，对希腊人和西里尔人来说，他们是最有用的，是的！ 但不是对世界其他地方？
Das heisst：你是​​如何衡量这个效用的？

我猜由于周围有许多拉丁衍生物，总数变得如此之大，或者不是？
我猜 2000 是大约 30 多个典型的字母表。

这里的“实用程序”只是从“当前在 pdfTeX 中起作用的内容”开始，因此“可以使用哪些编码”。 我不确定所有映射到底涵盖了什么：可能存在误报。 大概一开始就有所有的数学变体（斜体、无衬线体……）。

很多是拉丁文/西里尔文/希腊文重音，然后是 Copic、亚美尼亚文、古匈牙利文、切诺基文等。 当然不是 30 个字母，但可能至少有 10 个。

完整的脚本列表：

• 拉丁语（> 700 个代码点！）包括。 全宽版本
• 希腊语
• 科普特
• 西里尔
• 亚美尼亚语
• 格鲁吉亚语
• 切诺基
• 格拉哥里语
• 沙漠
• 奥沙
• 老匈牙利语
• 瓦朗
• Medefaidrin
• 阿德拉姆

!! 拉丁语（> 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土耳其语的特定问题：现已修复

关于进一步报道的想法？ 还是按照我目前的设置？

我会从现在开始，并在需要时扩展

好的，我认为这是最好的位置，也意味着我们可以保持问题的进展。 我会在这里结束，具体的补充可以在新问题中解决。