# provident-pali
> A visually and memory compact, intuitive Pali script transliteration scheme.
Latest version **0.1.4** (published 2023-09-01) · ISC license · 0 weekly downloads
## Install
```sh
npm install provident-pali
pnpm add provident-pali
yarn add provident-pali
bun add provident-pali
```
## Health
**Score 20/100 (F)** — status: abandoned.
Positive: esm support; no vulnerabilities.
Warnings: low downloads; no types; pre 1.0.
Negative: abandoned; low maintenance score.
## Facts
| | |
|---|---|
| Version | 0.1.4 |
| Published | 2023-09-01 |
| First published | 2021-08-14 |
| Weekly downloads | 0 |
| License | ISC |
| TypeScript types | none |
| Module format | ESM + CommonJS |
| Dependencies | 0 |
| Unpacked size | 249.1 KB |
| Known vulnerabilities | 0 |
| Install scripts | no |
| GitHub stars | 0 |
| Maintainers | yapcheahshen |
## Links
- npm: https://www.npmjs.com/package/provident-pali
- Repository: https://github.com/dhamma/provident-pali
- Homepage: https://github.com/dhamma/provident-pali#readme
- Issues: https://github.com/dhamma/provident-pali/issues
- npm.io page: https://npm.io/package/provident-pali
## Recent versions
- 0.1.4 (latest) — 2023-09-01
- 0.1.3 — 2023-02-06
- 0.1.2 — 2022-04-02
- 0.1.1 — 2022-04-02
- 0.1.0 — 2022-03-27
- 0.0.9 — 2022-03-02
- 0.0.7 — 2021-12-07
- 0.0.6 — 2021-12-06
- 0.0.5 — 2021-12-06
- 0.0.4 — 2021-08-22
- 0.0.3 — 2021-08-14
- 0.0.2 — 2021-08-14
- 0.0.1 — 2021-08-14
## README
# 俭约巴利 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有几个好处
1. 熟悉ABC的人，入门容易。
2. 符合Unicode标准。
3. 占用的空间较小。(UTF-8格式)
約為其他字母一半，主要原因是其他的字母佔3bytes，abc 只佔 1 byte。
但IAST也有几个缺点：
1. 使用了带变音符号的字母，输入不太方便。
由于英文在数字时代的强势地位，主流的输入方法，只会考虑同时输入本国文字和英文，很难找到可以同时输入“俄文和中文”、“藏文和中文”的输入法，在可预见的未来，不太可能同时输入巴利文（变音符号）和中文。
以本人为例，为了输入巴利字母，单机上必须安装巴利语的键盘配置，还得记忆快速键（如 `Ctrl+Y`=ñ）。在安卓和iOS上，也是极为不便，ñ 长按荧幕键盘可得，但尤其是下面带一点的d (ḍ),t (ṭ)，得打开一个预先备好的文本，覆制和粘贴。
2. 由于输入的麻烦，很多巴利单词被有意或无意地省掉**变音符号**，如 *Pāḷi* 常作 或 *Pāli* 或 *Pali*，这种情况或可视为*Pāḷi*为了融入网络世界的妥协。但 *pañña*, *paṇṇa*, *panna* 是三个不同的字，省去变音符号的后果是灾难性、不可逆转的失真。
3. 巴利转写字母零散地分布在Unicode的三个区，处理不便。
小于 **U+7F** 的 ASCII 区 (UTF-8 以1byte 保存），小于 **U+0400** 的西欧字母区，如 ñ **U+00F1**, ī **U+012B** 以2bytes 保存, 大于 **U+0400** 以 3 bytes 保存的， ṭ **U+1E6D**, ḍ **U+1E0D**。
4. 在IAST 方案中，有吐气的音加上了h，而h本身又是辅音。
也就是说，搜寻“ha”會同時找到 bha, pha, tha 等等，必须额外滤掉。
将一個巴利字母编码成多个拉丁字母，是不妥当設計。(即，IAST 非 prefix code)
一来这是以拉丁字母为本位的思路作祟，二来由于近百年前技术手段的限制，
梵文字母必须尽可能利用西文机械打字机，而键盘上的字母空间极为有限，不可能塞进太多梵文字母。
而在数字世界，除了键盘之外，这些限制都不复存在，我们能够从巴利语本质来思考较佳的编码策略。
字母的编码，在信息系统占据非常核心的位置，设想如果当年字母编码工作由印度人主导，他们觉得 w 这个字母既然在印度文中不存在，而且看起来、听起来和v都差不多，连名字中也有double，那使用 vv 来表达 w 看似没什麽问题，而这样的后果是，互连网就只能简写为 “vvvvvv”，让世人每回打网址，至少要多敲三个键。
我认为 IAST 就是个削足适履的方案，它对巴利语在数字世界的负面作用极大，而多数人都视而不见。
## 俭约巴利转写方案
1. 这个方案最初的动机，除了输入的不便，主要是从对罗马转写在小型设备上，显得不够紧凑的不满开始的。
除了罗马转写之外，其他书写巴利语的字母，都是受到古印度书写方式影响而创造的。它们的元音是标注在辅音之上或之下，而不是横向延展。由于元音的数量占了一半弱，一般来说，句子的宽度大约是罗马转写的60~70%。
天城体、泰文、藏文看起来都很紧凑；僧伽罗文、缅文和老挝字母，於由贝叶媒材的横向纤维纹路特性，特意将字母设计得圆滚滚，优势较不明显。
2. 如果将元音都以`上标`来表示，拉丁字母也会很省空间，Unicode也有完善的变音符支持机制，但我不考虑使用`它们，一来还是没有解决输入的问题，二来如果引进更多的字母，程序处理麻烦更大。
### 设计思路
1. 视觉上的紧凑性。手机上可以同时看更**多**的内容。
2. 输入的易学与便利（换言之，只用键盘上的字母，就没有创造新的输入方法的必要，這是受 Harvard-kyoto 和 Velthuis方案的启发 ）。
3. **快**速学习：已熟悉罗马转写者，在几分钟之内就能够了解规则。
4. 更**好**地符合巴利语的规律，每个巴利字母对应的单一字码，视觉上对应一个音节，学习上直观，搜寻和排序也更简单。
5. 更**省**保存空间（UTF-8保存，比罗马转写省30%以上）
## 编码规则
1. 巴利语不需要大小写，所以只保留小写a-z。从编码的角度，就是将0x41~0x5A这个英文大写字母区段，赋与新的意义。
2. 就象传统巴利写本一样，省略辅音後的a，除了a之外的元音，以英文大写字母表示，视觉上呈现为不占水平空间的变音符，这样单一字母原则上都发一个音节。对初学者来说，省去了切分音节的过程。
3. 吐气音(带h的) ，以相应的大写表示，如kh以`K`表示，gh以`G`表示，字形呈现则是中间多带一个h的第二笔弯钩。其余还有`C` `J` `T` `D` `P` `B`，共8个。
4. `V` 是连音符(Virama)，只要辅音中间无母音，就必须用`V`连起来。在支持合文（ligature）的系统上，常见的组合会在视觉上更紧凑（如ss，nn，会垂直叠起），否则辅音之会有小的加号表示中间无元音。
5. 元音在词首出现，继续使用小写。 anatta 记作：`antVt` 。即首字母沿用 a,ā,i,ī,u,ū,e,o，字中间的元音，以 `A`表示ā長音 , `I`表i , `IA`表ī , `U`表u , `UA`表ū, `E`表e, `O`表o 表示。如 sāsana 编码为 `sAsn` ，套上字体呈现为 s̄sn 。
6. 软颚音 ṅ 只出现在 k, kh, g, gh 之前，与卷舌 ṇ 也永远不会在k,kh,g,gh 之前，因此两者共用编码 `N` 。例：saṅgha 记为是 `sNG`。字体会将 软颚音化入 k 和 g ，变成上方的黑点。vaṇṇa 记为 `vNVN`。
8. ḷ 以 `L` 表示。
9. ṃ 记作 `M` ，显下在右下方，ṃ 只出现在元音之后。
10. 最后五个字母 ḍ `F` , ḍh `Q` , ṭ `W` , ṭh `X` ,ñ `Y`。助记法是 `F` 是 d 之后首个巴利语中没用到的英文本母，然后是`Q`，而t之后还没用到的是`W`，之后是 `X` 。ñ的发音是nYa。
11. 单字如果不是以元音或ṃ 结尾，必须補 V 。例 yad 记作 `ydV` ，mahant 记作 `mhnVtV`。
12. 梵文字母
母音相连: â `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 标点符号，不利与标志语言協作。
## 本系统的利益与代价
1. 利益：
1. 画面增加两倍以上内容。
同样的空间显示更多内容或更大字体，同样的内容更省画面。
减少卷动，让思绪更集中。
2. 节省 30% 左右的储存空间。
3. 不依赖输入法
输入大字只须按 Shift ，无论在任何设备上，都提供了输入大写字母的能力。
4. 字型大约 100KB
加上字体之后，就呈现为紧凑的巴利文。在缺少相应的字体，本方案呈现为大小写字母混编的文本。
5. 无论在编码层次和视觉层面，小写字母和标点符号都完全不变。故与所有的标记语法（如网页HTML，XML等）兼容。
6. 只要不用大写字母，本字体与国际转写(IAST)兼容，只套用一种字体（即纯文本模式），两者可以同时呈现，让过渡非常顺畅。
7. 可轻易转换成缅文泰文等转写方式，比从IAST转换简单许多。
2. 代价：牺牲与英文大写字母，在纯文本模式意义下的兼容性。
换言之，对Word, PDF, HTML 可以同时指定多种字形的文档没有问题。
但如果转成纯文本，比方说“剪贴薄操作”会抛弃文本的样式（字体大小、颜色粗细等设置），则有大小写的英文和本方案可能会生成歧义，如果是以中文为主的文档，只用小写字母（或大写字母转成小写字母不影响意义，如汉语拼音），则没有影响。
## API
### fromIAST
```javascript
import {fromIAST,toIAST} from "provident-pali"
fromIAST('buddha')==='bUdVD'
//keep the text inside <> intact
fromIAST('dhammaṃ',{format:'xml'})==='DmVmM'
```
```html
providentpali.fromIAST()
providentpali.toIAST()
```
### toIAST
```javascript
toIAST('BgvA')==='bhagavā'
//keep the text inside <> intact
toIAST('sNVGM
',{format:'xml'})==='saṅghaṃ
'
```
---
_Source: https://npm.io/package/provident-pali · Machine-readable twin of the npm.io package page. Health data is recomputed on every publish._