我的 locale 是 zh_CN.UTF-8 ，但我仍然能观察到这样的现象。
从前的 Pango 有，现在带了 Cairo 的 Pango 仍然有。
基于上述判断，我们可否修改 Pango，使其将所有公共字符都当作 lang:en 来看待行不行？
我觉得将数字和标点符号当成lang:en不太好，因为这样背离了Unicode范围的划分。
我还是考虑在Pango进行字体适配之前，通过fontconfig将虚拟字体族强行替换为备选的第一种字体。也就是说，如果fontconfig中sans serif的第一个备选字体是Bitstream Vera Sans，那么sans serif字体和Bitstream Vera Sans字体在任何情况下的显示效果就是一样的。当然，如果Bitstream Vera Sans没有我想要显示的字符，再通过fontconfig搜索下一款匹配的字体，这是另外一回事。
那么，何以标点符号的字体会随着前后文变化呢？按你的说法，fontconfig 将标点映射到了 locale 相关的第一个字体，那也不该变化呀。
所以这件事我很奇怪。Pango应该是先将字符串划分成一段一段，分隔符可能是空格或者其它的，每段再去映射字体。如果这一段只有一个1，那么就被映射到了中文字体上；如果这一段是1st，就被映射到了英文字体上。
很遗憾，依然无法重现。
还是自动选择了中文字体。
你这个适配结果是肯定不对的。无论如何，一段英文的字符串不可能被适配到一款中文字体上。你出现了这样的结果，表明你的fonts.conf进行了较大的改动，请使用fontconfig自带的设置文件。或者使用新建用户来进行测试。
所以这件事我很奇怪。Pango应该是先将字符串划分成一段一段，分隔符可能是空格或者其它的，每段再去映射字体。如果这一段只有一个1，那么就被映射到了中文字体上；如果这一段是1st，就被映射到了英文字体上。
你的这个解释是合理的。当“2”单独去请求时，将不带lang参数，于是fontconfig返回一个中文字体。而当“2nd”共同去请求，就会带上lang:en。
我能理解这就是 Pango 的人所追求的那种“一致性”，它本身并不难理解。比如说，假设，一个欧洲文字符串“abé”，它就应该整个地被用一个欧洲文字体显示，而不应该前2个字母用英文字体，第三个字母单独地用欧洲文字体。
我怎么什么都没有看出来呢？
谁能给个明白点的图看看
对于这个我们计划要写的 patch，我希望的效果是，对于一段中英文混排的文本，当中、英文分别使用不同字体时，标点符号和数字无论出现在什么位置、有怎样的上下文，都与英文保持一致，使用英文字体显示。大家对此可有意见？
为便于大家理解，我再上传一张截图，希望更明确地表明我们的困惑。
注意看图，同样都是大于号，图里的TypeI和TypeII被映射到了不同的字体。最可怕的是，如果出现了TypeII的情况，你在后面打上一个字母，就会立刻变成TypeI的情况。
这种标点符号和数字随上下文变化的适配方案，是Pango作为一个底层库不应该出现的结果。另外，这个问题直接导致了Pango可能会计算错特定字符串宽度，使得xchat、pango-firefox显示错乱。
试了一下，在fontconfig中将中文字提到英文前面，选字体时选择英文字体，似乎可以不出现这种情况。这么做比较笨，不过没有patch前我先暂时用一下。
只要选择实际字体，不选择虚拟字体族，就肯定不会出现这种问题。
这确实是个难题，这种问题是否仅出现在简体中文上呢？其他的亚洲语种里有没有这个问题？
从x11_yao的图上看，似乎是优先使用中文字体中相同编号的符号。
问题似乎是将这些标准的英文符号也划到区域符号中去了。如果使它对某一个范围的符号，强制使用sans中的首选字体呢？或者加一个选项，屏蔽某种字体的某些符号？
的确是这样，那只要选择实际的中英文字体即可了。
那就暂时如此，等各位的patch ;)
这个跟字体的语言没有关系，跟locale有关系。因为数字和标点符号不属于任何一个Unicode语言范围，所以这些字符的映射由上下文和locale决定。