provident-pali v0.1.4
俭约巴利 provident-pali
A visually and memory compact, intuitive Pali script transliteration scheme.
看更多、输入快、兼容性好、省空间的巴利语转写方案。
演示
https://dhamma.github.io/provident-pali
传统的转写方案
巴利语可以用多种字母（Tipitaka-App 的Pali Script Converter 提供了十七种）来转写。其中以一百多年前在雅典制定、以拉丁字母为基础的 国际梵语转写字母 (IAST) 已成为保存梵文及巴利文电子文本的主流标准。（对巴利语而言，新世纪的ISO 15919 和 IAST 只有 ṁ/ṃ 的小差异，可等同视之。）
相对于传统的天城体、僧伽罗文、缅文、泰文、老挝文，IAST有几个好处
- 熟悉ABC的人，入门容易。
- 符合Unicode标准。
占用的空间较小。(UTF-8格式)
約為其他字母一半，主要原因是其他的字母佔3bytes，abc 只佔 1 byte。
但IAST也有几个缺点：
使用了带变音符号的字母，输入不太方便。
由于英文在数字时代的强势地位，主流的输入方法，只会考虑同时输入本国文字和英文，很难找到可以同时输入“俄文和中文”、“藏文和中文”的输入法，在可预见的未来，不太可能同时输入巴利文（变音符号）和中文。
以本人为例，为了输入巴利字母，单机上必须安装巴利语的键盘配置，还得记忆快速键（如
Ctrl+Y=ñ）。在安卓和iOS上，也是极为不便，ñ 长按荧幕键盘可得，但尤其是下面带一点的d (ḍ),t (ṭ)，得打开一个预先备好的文本，覆制和粘贴。由于输入的麻烦，很多巴利单词被有意或无意地省掉变音符号，如 Pāḷi 常作 或 Pāli 或 Pali，这种情况或可视为Pāḷi为了融入网络世界的妥协。但 pañña, paṇṇa, panna 是三个不同的字，省去变音符号的后果是灾难性、不可逆转的失真。
巴利转写字母零散地分布在Unicode的三个区，处理不便。
小于 U+7F 的 ASCII 区 (UTF-8 以1byte 保存），小于 U+0400 的西欧字母区，如 ñ U+00F1, ī U+012B 以2bytes 保存, 大于 U+0400 以 3 bytes 保存的， ṭ U+1E6D, ḍ U+1E0D。
在IAST 方案中，有吐气的音加上了h，而h本身又是辅音。 也就是说，搜寻“ha”會同時找到 bha, pha, tha 等等，必须额外滤掉。 将一個巴利字母编码成多个拉丁字母，是不妥当設計。(即，IAST 非 prefix code)
一来这是以拉丁字母为本位的思路作祟，二来由于近百年前技术手段的限制， 梵文字母必须尽可能利用西文机械打字机，而键盘上的字母空间极为有限，不可能塞进太多梵文字母。
而在数字世界，除了键盘之外，这些限制都不复存在，我们能够从巴利语本质来思考较佳的编码策略。
字母的编码，在信息系统占据非常核心的位置，设想如果当年字母编码工作由印度人主导，他们觉得 w 这个字母既然在印度文中不存在，而且看起来、听起来和v都差不多，连名字中也有double，那使用 vv 来表达 w 看似没什麽问题，而这样的后果是，互连网就只能简写为 “vvvvvv”，让世人每回打网址，至少要多敲三个键。
我认为 IAST 就是个削足适履的方案，它对巴利语在数字世界的负面作用极大，而多数人都视而不见。
俭约巴利转写方案
这个方案最初的动机，除了输入的不便，主要是从对罗马转写在小型设备上，显得不够紧凑的不满开始的。
除了罗马转写之外，其他书写巴利语的字母，都是受到古印度书写方式影响而创造的。它们的元音是标注在辅音之上或之下，而不是横向延展。由于元音的数量占了一半弱，一般来说，句子的宽度大约是罗马转写的60~70%。
天城体、泰文、藏文看起来都很紧凑；僧伽罗文、缅文和老挝字母，於由贝叶媒材的横向纤维纹路特性，特意将字母设计得圆滚滚，优势较不明显。
如果将元音都以
上标来表示，拉丁字母也会很省空间，Unicode也有完善的变音符支持机制，但我不考虑使用`它们，一来还是没有解决输入的问题，二来如果引进更多的字母，程序处理麻烦更大。
设计思路
视觉上的紧凑性。手机上可以同时看更多的内容。
输入的易学与便利（换言之，只用键盘上的字母，就没有创造新的输入方法的必要，這是受 Harvard-kyoto 和 Velthuis方案的启发 ）。
快速学习：已熟悉罗马转写者，在几分钟之内就能够了解规则。
更好地符合巴利语的规律，每个巴利字母对应的单一字码，视觉上对应一个音节，学习上直观，搜寻和排序也更简单。
- 更省保存空间（UTF-8保存，比罗马转写省30%以上）
编码规则
巴利语不需要大小写，所以只保留小写a-z。从编码的角度，就是将0x41~0x5A这个英文大写字母区段，赋与新的意义。
就象传统巴利写本一样，省略辅音後的a，除了a之外的元音，以英文大写字母表示，视觉上呈现为不占水平空间的变音符，这样单一字母原则上都发一个音节。对初学者来说，省去了切分音节的过程。
吐气音(带h的) ，以相应的大写表示，如kh以
K表示，gh以G表示，字形呈现则是中间多带一个h的第二笔弯钩。其余还有CJTDPB，共8个。V是连音符(Virama)，只要辅音中间无母音，就必须用V连起来。在支持合文（ligature）的系统上，常见的组合会在视觉上更紧凑（如ss，nn，会垂直叠起），否则辅音之会有小的加号表示中间无元音。元音在词首出现，继续使用小写。 anatta 记作：
antVt。即首字母沿用 a,ā,i,ī,u,ū,e,o，字中间的元音，以A表示ā長音 ,I表i ,IA表ī ,U表u ,UA表ū,E表e,O表o 表示。如 sāsana 编码为sAsn，套上字体呈现为 s̄sn 。软颚音 ṅ 只出现在 k, kh, g, gh 之前，与卷舌 ṇ 也永远不会在k,kh,g,gh 之前，因此两者共用编码
N。例：saṅgha 记为是sNG。字体会将 软颚音化入 k 和 g ，变成上方的黑点。vaṇṇa 记为vNVN。ḷ 以
L表示。ṃ 记作
M，显下在右下方，ṃ 只出现在元音之后。最后五个字母 ḍ
F, ḍhQ, ṭW, ṭhX,ñY。助记法是F是 d 之后首个巴利语中没用到的英文本母，然后是Q，而t之后还没用到的是W，之后是X。ñ的发音是nYa。单字如果不是以元音或ṃ 结尾，必须補 V 。例 yad 记作
ydV，mahant 记作mhnVtV。梵文字母
母音相连: â
aa, îii, ûuu擦音 : ṣS, śZ止韵 : ḥH响音 : ṛRṝRAḹLA
与其他类似方案之比较
WX Notation
与本方案最接近，但并没有考虑到字体呈现，它主要是做为输入及计算机内部处理之用。
因为占用了英文小写的f,q,w,x ，因此它无法与 IAST（不含大写字母）兼容。
此外，它还保留了短元音a，占空间较本方案大（但比IAST小）。
它对印地语及其他方言的考虑周详，但本方案只关注巴利语。
参考材料： https://shivamrana.me/2019/03/wx_notation/
Velthuis 与 ITRANS
用到 ascii 标点符号，不利与标志语言協作。
本系统的利益与代价
利益：
画面增加两倍以上内容。
同样的空间显示更多内容或更大字体，同样的内容更省画面。 减少卷动，让思绪更集中。
节省 30% 左右的储存空间。
不依赖输入法
输入大字只须按 Shift ，无论在任何设备上，都提供了输入大写字母的能力。
字型大约 100KB
加上字体之后，就呈现为紧凑的巴利文。在缺少相应的字体，本方案呈现为大小写字母混编的文本。
无论在编码层次和视觉层面，小写字母和标点符号都完全不变。故与所有的标记语法（如网页HTML，XML等）兼容。
只要不用大写字母，本字体与国际转写(IAST)兼容，只套用一种字体（即纯文本模式），两者可以同时呈现，让过渡非常顺畅。
可轻易转换成缅文泰文等转写方式，比从IAST转换简单许多。
代价：牺牲与英文大写字母，在纯文本模式意义下的兼容性。 换言之，对Word, PDF, HTML 可以同时指定多种字形的文档没有问题。
但如果转成纯文本，比方说“剪贴薄操作”会抛弃文本的样式（字体大小、颜色粗细等设置），则有大小写的英文和本方案可能会生成歧义，如果是以中文为主的文档，只用小写字母（或大写字母转成小写字母不影响意义，如汉语拼音），则没有影响。
API
fromIAST
import {fromIAST,toIAST} from "provident-pali"
fromIAST('buddha')==='bUdVD'
//keep the text inside <> intact
fromIAST('<span>dhammaṃ</span>',{format:'xml'})==='<span>DmVmM</span>'<!-- in html file //-->
<script src="providentpali.js"></script>
providentpali.fromIAST()
providentpali.toIAST()toIAST
toIAST('BgvA')==='bhagavā'
//keep the text inside <> intact
toIAST('<div>sNVGM</div>',{format:'xml'})==='<div>saṅghaṃ</div>'