PDF坐标系统的反直觉设计：为什么原点在左下角而不是左上角
文章摘要
探讨PDF采用PostScript坐标系的历史原因，分析CTM（当前变换矩阵）的工作机制，以及这套反人类设计如何影响现代PDF生成和渲染的实现细节。
PDF坐标系的反直觉设计
当PostScript的遗产遇上现代图形编程
去年帮一个客户调试PDF生成的bug，他说用Canvas API画出来的图表，转成PDF后上下颠倒了。我看了代码，发现他直接把Canvas坐标映射到了PDF，完全没考虑坐标系差异。这不怪他——几乎所有现代图形系统都是原点在左上角，唯独PDF反着来。
为什么原点在左下角？
答案要追溯到1984年。PDF的前身PostScript语言诞生于施乐PARC实验室，当时的设计哲学是"像数学家一样思考"——笛卡尔坐标系，Y轴向上为正。这符合数学直觉，但与计算机图形学的主流（屏幕从上往下扫描）背道而驰。
到了1993年PDF诞生时，Adobe为了兼容PostScript打印机和现有的排版工具链，直接继承了这套坐标系。一个技术决策，影响了后续30年。
坐标系的实际表现
假设你要在A4纸（595×842点）上画一条从左上角到右下角的线，在不同系统里的代码：
ctx.moveTo(0, 0);
ctx.lineTo(595, 842);
ctx.stroke();0 842 m
595 0 l
S注意PDF里的Y坐标：左上角是842，左下角才是0。这就是为什么很多生成库需要做y = pageHeight - y的转换。
CTM：变换矩阵的魔法
PDF通过Current Transformation Matrix（当前变换矩阵）来处理所有的坐标变换。这是个3×3矩阵，但实际上只用6个参数：
[a b 0] [x] [a*x + c*y + e]
[c d 0] × [y] = [b*x + d*y + f]
[e f 1] [1] [ 1 ]在PDF content stream里写作：a b c d e f cm
举几个常见操作：
1 0 0 1 tx ty cm
sx 0 0 sy 0 0 cm
cos(θ) sin(θ) -sin(θ) cos(θ) 0 0 cm
实战案例：翻转坐标系
最常见的需求：我想用"正常"的坐标系（原点在左上角）来绘制PDF。解决方案是在页面开始时插入一个翻转变换：
% 保存当前图形状态
q
% 翻转Y轴并平移到顶部
1 0 0 -1 0 842 cm
% 现在可以用"正常"坐标系绘图了
0 0 m % 这是左上角
100 100 l % 向右下方画线
S
% 恢复图形状态
Q分解一下这个矩阵1 0 0 -1 0 842：
• a=1, b=0 → X轴保持不变
• c=0, d=-1 → Y轴翻转（乘以-1）
• e=0, f=842 → 向上平移842点（页面高度）
这样操作后，你的(0,0)就指向左上角了，而且Y轴向下为正，符合直觉。
翻转坐标系后，文字也会倒过来！如果你要渲染文本，要么单独再翻转一次文字，要么在绘制文字时临时恢复原始坐标系。大部分PDF库（如ReportLab）内部就是这么干的。
图片坐标的特殊情况
PDF里插入图片更诡异。图片总是占据一个1×1的"单位正方形"，然后通过CTM缩放到目标尺寸。比如你想在(100, 100)位置放一张200×150的图片：
q % 保存状态
200 0 0 150 100 100 cm % 缩放到200×150，移动到(100,100)
/Im1 Do % 绘制图片
Q % 恢复状态注意这里的Y坐标还是相对于左下角的。如果你已经翻转了全局坐标系，图片会上下颠倒，需要额外处理：
q
200 0 0 -150 100 250 cm % 注意d=-150（负数翻转），f=250
/Im1 Do
Q各大库的处理方式
实用建议
1. 选择高层API
除非你在做底层PDF操作，否则用ReportLab、PDFKit这种自动处理坐标系的库，省心。
2. 统一坐标系
如果团队有多个PDF生成模块，统一约定用哪种坐标系，别混用。混用的代码维护起来是灾难。
3. 封装变换逻辑
如果必须直接操作content stream，把坐标变换封装成函数，别到处写变换矩阵。
PDF的坐标系设计确实反直觉，但理解了CTM的工作原理后，你会发现它其实挺优雅的——所有复杂的变换都可以用一个6元组表达。只是这个优雅是为PostScript打印机设计的，而不是为2025年的Web开发者。历史包袱，懂的都懂。