《常绿阔叶林中的游标卡尺》 #268
Replies: 2 comments
-
|
先来个交叉索引吧，后续发展： 补充这两天的情况：
其中除了墙里开花墙外香的「警示牌」功能之外，还提到了一个字体「霞鹭文楷」，就是我最近日记截图当中使用的字体。简单说，就是与「Noto Sans/Serif CJK SC」或「Source Han Sans/Serif CN」同样生态位的以简体汉字本位出发的「大字符集」，对应的其它变体还有TC/JP/KR等等。而「霞鹭文楷等宽」就是对应各种「Mono」版的字体。 重点来了：在「文本编辑器」用户看来，「Mono」与「Code」是不一样的——虽然一般都混淆起来，不过总有较真的杠精——邮件列表中还有「Fira Code」的开发者建议某个提出需求的用户考虑「Fira Mono」。 所以，对于今天看到的提出「等宽」或「（Windows内置）等线」这种字体来说，通常「Mono」就可以了，只要保持全角与半角比例为二比一就行。而到了「Code」的时候，要求就高了一些，「文字处理器」用户看上去最敏感的地方就是不和谐的标点符号，比如「盎式引号“”」「波折号——」应该是现状的半角 ， 这里不过多展开技术细节，只提一点职业经历：当初上班的时候，在日语环境下，指定IDE和Text Editor的字体，是「ＭＳ ゴシック」（MS Gothic），注意前面没有「P」。到了如今——确切的说是前几年——与「Noto Sans/Serif CJK JP」或「Source Han Sans/Serif JP」同时推出的日文字型优先的编程字体，唤作「Source Han Code JP」或「源ノ角ゴシック Code」。 这是Adobe官方推出的「Code」字眼的字体，与「Mono」不太一样吧？当然现在项目已经停止了，成果分别合并进「Source Han Mono」和「Source Code Pro」当中，刚好把灰色地带——也就是本篇讨论所反映的情况——躲开。 |
Beta Was this translation helpful? Give feedback.
-
|
补充「保留痕迹（且另加旁白解说）的工作现场“常绿阔叶林”」：
昨天（9/7）一天的饮食当中摄入的营养就是这么算出来的，不排除作者笔误（毕竟这几天字面意义上的浑身不舒服尤其是头疼欲裂），但是基本的流程都列出来了，为了贴上来让各位读者贻笑大方，还特意做了点排版工作。 ——真・自己用的场合连排版都尽量简洁，不能一点没有（磨刀不误砍柴工，否则自己也会看花眼），也不能本末倒置（内部草稿而已，搞那么精致给谁看吖）。 码字至此，当时我就写了 一段日记：
摘抄两段关于「文本」的「文字」：
|
Beta Was this translation helpful? Give feedback.
-
前情提要；
然后是前天（9/3）和昨天（9/4）日记当中记录饮食所用表格的形式之对比：
乍一看没区别，仔细一看：前者在单元格内换行，后者则每格必占据一行一列。
这都是由于Markdown表格不能合并单元格的缘故啊！那么reStructuredText呢？
很遗憾，忙活半天没调（tiáo）出来。因为「Grid Table」里面有「全角」字符，编辑器里面对不齐的空格，Sphinx的编译错误，总有一边不适合你。两头的半途而废结果贴出来让读者们看个乐呵吧：
前者「VSCode」环境中的编辑器字体是「Source Code Pro」，其实换成默认的「Consolas」也一样，编辑器里面总是对不起，并且相差还不是整数倍。后者「Kate」环境中字体是「Fira Code」，看上去就可以对齐了，全角字符的宽度是半角字符的两倍（精确），但是还没找到预览的方式（估计要配置Sphinx）。
导致问题的主要原因，已经标注在图上了，就是因为有些字体「收编字符太过充沛」，尤其是汉语和盎语共同使用同一个码位只凭借字体区分全角半角的「引号“”」「波折号——」之类，总得有一边妥协才行。到后来，各个「民族权力机构＆民族武装力量」颁布的本地化字符集当中，通常把本族人民群众惯用的异族语符号也登录进去，但是肥瘦宽窄要考虑到国情。
比方说图中的「№」就比较典型，本来是彻头彻尾的全角字符，哪怕左右结构的俩「字母偏旁」拆开了写也不至于这么窄，但是为了一些与盎文混合排版时的美观大方（半角语境当中夹杂个全角「符号」看着很别扭），有些字体就自作主张定制了。
另一个例子就是「西格玛」，用作「求和」的数学符号与「合计」的财务符号，不仅仅局限于希腊文语境，只不过由于都是半角字符，这个问题暴露得不明显。而到了使用全角字符的远东，与时俱进输入法候补列表当中就能同时显示出俩来：大写希腊字母「Σ」、本土字符集当中的符号「∑」……读者们能看出区别么？
说了这么多，「严于待人宽于律己」的欢迎学术探讨的「读者」们估计还有个问题：嗤。你这孤苦伶仃可怜废柴草根文盲矬胖老穷光棍汉精神病仆街写手不入流码农数学渣宅男黑客活雷锋烟枪酒鬼饭桶缩卵怂货窝囊废是今天才发现的么？
当然不是，最晚最晚从建立第三个个人博客站点囧斋之書试验技术性文档的时候就发现了，因为明显使用Python技术栈的Jupiter Book也用Sphinx引擎，但是却推出了「MyST Markdown」，这种一看就从reStructuredText借鉴了大批技术细节的「魔改」版本，于是当时就有个尖锐的问题：为啥全套技术栈内部不用原汁原味的自家技术呢？
肯定不是吃饱了撑得慌或者政治挂帅，估计是遇到了难以客服的技术问题，技术本身的「劣根性」问题。
就是这个意思，虽然reStructuredText有「Grid Table」乍一看比Markdown不知高到哪里去了，但就是由于很难处理（或者说标准不统一）不等宽字符，所以除非全字母语境一般不会用作记录包含大批表格的正式文档。
关于「排版依赖の语法」的奇葩性与劣根性，想必业内众所周知，深恶痛绝的绝对不止我一个人。并且这种深恶痛绝是从当代许多赛博朋克中年才俊都没出生的时候就开始了：Makefile的Tab缩进依赖。
就说用Jupiter Book写「書」的时候，目录文件「
.yml」也是个排版依赖的缩进列表，稍微对不齐——通常不是个别行而是一整块于是难以发现——立刻就编译错误了，搞定了之后才有继续补充内容的可能性。前情提要（内嵌）：
顺便，《囧斋之書》进度停滞并不奇怪，这就是「试验性」站点的特点：发现不能简单切换文档内部代码执行的核心，于是许多计划（比如文档内部直接嵌入GNU Octave代码）都要搁置，另外还需要解决大批相关问题——比方说今天提到的「Jupiter Book（以及其它系列重要技术）为何使用很像reStructuredText的MyST Markdown格式乍一看“脱裤子放屁多此一举”」——其中蕴含的充沛政治和意识形态内容以及引领的激烈政治和意识形态斗争新动向。
就事论事，想必耍蛇多年的从情报工学神童到赛博朋克中坚的根红苗正忠君爱国的百善の新时代中国特色社会主义接班人，比我更有发言权，有苦说不出还是其它什么感想，「装蒜与否都是个人自由」，只要不至于恼羞成怒气急败坏然后运作「“海里有人”“海边有人”“手眼通中央军委/政法委”」的人脉玩啥「烽火戏诸侯」「一骑红尘妃子笑」公器私用就行……就为了条python，真不值。
Beta Was this translation helpful? Give feedback.
All reactions