几个排版概念已经如何在Processing中估算它们的位置。

几个排版的概念

Processing中有几个跟文字有关的API让我很困惑。比如它有获取文字所占长度的textWidth()，但没有对应的获取高度的textHeight()。另外textAscent()和textDescent()两个函数又是干嘛的呢？API里的描述是：

Returns descent of the current font at its current size. This information is useful for determining the height of the font below the baseline.

看到这里大概能猜到，baseline应该是字符对齐的线，而descent和ascent大概是下和上的边界跟baseline的距离。但是这几条线之间有什么关系，他们又是怎么算的呢？试着把它们画出来是这样的。

Default Vertical Alignment

可一旦给他们设定对齐方式之后，奇怪的事情便发生了。将文字设为顶端对齐，然后三条线的计算方式不变，得到的结果是这样的。

1
textAlign(LEFT, TOP);

Top Vertical Alignment

底部对齐是这样的。

1
textAlign(LEFT, BOTTOM);

Bottom Vertical Alignment

好吧，那改成居中试一下。

1
textAlign(LEFT, CENTER);

Center Vertical Alignment

结果都完全走样了。从上面几张图来看，TOP和BOTTOM这两种对齐的上边线和下边线的位置还是可以算出来的，但是CENTER则让人摸不着头脑。这几个概念到底是什么呢？有没有明确的可以调用的计算公式呢？

维基上有这么一张图：

Typography Line

参考术语表排版业应该是这样定义这几个术语的：

  • Baseline 字符主体下部对齐的线，也是人们感受文字位置同一行时不可见的那条线。英文字体一般这条线都会对得齐，但维基也说了：

    In some scripts, parts of glyphs lie below the baseline.

  • x-height 小写字母主体上部水平对齐线，x的顶部或者t的横线会刚好对齐，但像i或者n等有尖端或弧度的线，则会略微向上穿透，这点可以从上图看出。维基上讲x-height一般跟mean line是一致的，而且：

    The mean line, also called the midline, is half the distance from the baseline to the cap height.

    但很多字体为了表现效果，常常使x-height偏移mean line的位置。因此，这条线的位置是字体相关的，若API没有提供相关功能，则只能估算。

  • cap height 大写字母主体上部水平对齐线。如上图的字母S。

  • ascent 是字符的上边界，向上突出最多的字母突出部分也不会超过这条线。

  • descent 同理，是字符的下边界。

本文把这五个概念合称为字形五线。有了这几个概念，再来研究Processing是怎么算出它们的位置的，以及文字是怎么对齐的。

默认对齐

Processing中的textAscent()和textDescent()来自于类PApplet，追溯源代码，发现最终取值于字体类PFont的成员变量：

1
2
3
4
5
6
7
8
9
10
11
12
13
/**
 * The ascent of the font. If the 'd' character is present in this PFont,
 * this value is replaced with its pixel height, because the values returned
 * by FontMetrics.getAscent() seem to be terrible.
 */
protected int ascent;

/**
 * The descent of the font. If the 'p' character is present in this PFont,
 * this value is replaced with its lowest pixel height, because the values
 * returned by FontMetrics.getDescent() are gross.
 */
protected int descent;

这是字符size为1时的ascent和descent的值，代码实际返回的是：

1
textFont.ascent() * textSize;

从代码上看，这个返回值与字体大小相关，但是实际上下面这张图里代码返回的明显不是会与字形接触到的边界：

1
2
3
4
5
6
7
8
text("Righteously",80,200);
stroke(255,100,0);
strokeWeight(2);
line(0,200,this.width,200);
stroke(0,255,100);
line(0,200-textAscent(),this.width,200-textAscent());
stroke(100,0,255);
line(0,200+textDescent(),this.width,200+textDescent());

Text Default Vertical Alignment

但使用Wiki示例的字体后则完美对齐：

1
textFont(createFont("Adobe Caslon Pro", 1));

Adobe Caslon Pro

因此，就目前本人使用的processing-2.2.1版本来说，ascent与descent值仅与字体大小有关，而不受字体类型的影响，并且返回的是各自相对baseline的位移，而不是具体的坐标值。这就意味着Processing返回的值与用户使用的字体无关，使用API只能得出字形的上限和下限，无法精确地计算出实际字形中上述几条线的位置。下面以默认对齐为例来计算字形五线的位置。下图的三段文字的字体分别是微软雅黑、Adobe Caslon Pro和Times New Roman Italic，大小均为75，代码与结果如下（请忽略语法错误，懒得重新截图了）：

1
2
3
4
5
6
7
8
9
10
String chineseStr = "尺寸不是问题！";
String englishStr1 = "Er... Size is not an problem";
String englishStr2 = "Even it's OBLIQUE!";
float x1 = 100, x2 = 100, x3 = 100, y1= 100, y2 = 300, y3 = 500;
textFont(createFont("MSYH", 75));
text("尺寸不是问题！", x1, y1);
textFont(createFont("Adobe Caslon Pro", 75));
text(englishStr1, x2, y2);
textFont(createFont("Times New Roman Italic", 75));
text(englishStr2, x3, y3);

Not at all #1

在Processing中，baseline对齐就是默认的对齐方式，假设文字text(string, x, y)则：

  • baseline = y

  • descent = y + textDescent()

  • ascent = y - textAscent()

是显而易见的，把这三条线画出来效果如下：

Not at all #2

这三种字体中，只有Adobe Caslon Pro能够严丝合缝地对齐，而微软雅黑和斜体的Times New Roman上部都留有大量空白，而中文字符甚至不跟baseline对齐。另外，假设一行文字的总高度为textHeight，则：

  • textHeight = textDescent() + textAscent()

如果能画出给定文字的四条边界（左右边界较好理解，这里不赘述，可参考textWidth方法），那么也就可以算出给定四边界下合适的文字大小是多少了，这就可以解决我的问题了。另外，字形五线的另外两条可能就更不准确了。

1
2
3
4
5
6
7
8
/**
The vertical alignment is based on the value of textAscent(),
which many fonts do not specify correctly. It may be necessary to use a
hack and offset by a few pixels by hand so that the offset looks
correct. To do this as less of a hack, use some percentage of
textAscent() or textDescent() so that the hack works even
if you change the size of the font.
*/

好吧，那就根据这个来大概估算一下cap height和x-height的位置吧。首先是cap height，按定义，它应该位于大写字母S的顶部，但是很不幸地维基的描述至少在Processing里是不准确的，大写S实际上跟小写的b与l一样，顶端位于ascent的位置。不同的字体cap height的位置实在是差别太大。

Not at all #3

对于Adobe Caslon Pro字体来说，仔细看大写字母E其实是略低于ascent位置的，而这才是它cap height的真正位置。

Not at all #4

但这个差距实在太小了，以至于在75的字符大小下仍然只有一像素的间隙，因此说Adobe Caslon Pro字体的cap height = ascent是合适的。而对于另外两种字体来说，取下面这个公式是合适的：

  • capHeight = y - 0.74 * textAscent()

Not at all #5

而对于x-height，维基上说是位于baseline到cap height距离的一半。但经过实验实际上只有中间那种字体符合这个描述，同时也可观察到，三种字体的x-height是比较接近的，因此可以假设这里实际上应该是baseline到ascent距离的一半，效果如下：

Not at all #6

可以看出前两种字体是越过了那条金线的，但是考虑到x-height的位置也是跟字体密切相关的，并且实验用的字符尺寸实际上非常大，因此以下计算是合适的：

  • xHeight = y - 0.5 * textAscent()

其他对齐方式

查看Processing的源代码，可以发现textAlign()调用的是类PGraphics中的方法，在这个类里，垂直对齐的默认值是baseline对齐：

1
2
/** The current vertical text alignment (read-only) */
public int textAlignY = BASELINE;

而当用户使用text(String, float, float)方法显示字符时，该方法内部会根据当前的对齐方式做如下处理:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// If multiple lines, sum the height of the additional lines
   float high = 0; //-textAscent();
   for (int i = start; i < stop; i++) {
     if (chars[i] == '\n') {
       high += textLeading;
     }
   }
if (textAlignY == CENTER) {
// for a single line, this adds half the textAscent to y
// for multiple lines, subtract half the additional height
//y += (textAscent() - textDescent() - high)/2;
y += (textAscent() - high)/2;
} else if (textAlignY == TOP) {
// for a single line, need to add textAscent to y
// for multiple lines, no different
y += textAscent();
} else if (textAlignY == BOTTOM) {
// for a single line, this is just offset by the descent
// for multiple lines, subtract leading for each line
y -= textDescent() + high;
//} else if (textAlignY == BASELINE) {
// do nothing
}

考虑单行的情况，则high为0，函数里会重新计算y的值，这意味着实际的字形五线产生了偏移。若由用户传入y值算出的baseline为y，而重新计算得到的baseline为y’，则CENTER对齐下这五条线的坐标如下：

  • y' = y + textAscent() / 2

  • descent' = y' + textDescent() = y + textAscent() / 2 + textDescent()

  • ascent' = y' - textAscent() = y - textAscent() / 2

  • capHeight' = y' - 0.74 * textAscent() = y - 0.24 * textAscent()

  • xHeight' = y' - 0.5 * textAscent() = y

下图是重新计算后画出的字形五线，其中白色的是用户传入的初始y值：

Not at all #7

其它对齐方式可同理算出，此处不再赘述。

多行对齐

首先使用Adobe Caslon Pro字体以及默认对齐方式来显示多行字符字符，可以看出，此时Processing相关函数返回的值只是字符第一行的相关值，以下是代码和结果：

1
2
3
4
5
6
7
8
9
textSize(60);
text("Live high, \nlive righteously. \nJust take it easy~",40,100);
strokeWeight(2);
stroke(255,100,0);
line(0,100,this.width,100);
stroke(0,255,100);
line(0,100-textAscent(),this.width,100-textAscent());
stroke(100,0,255);
line(0,100+textDescent(),this.width,100+textDescent());

Multiple lines text

Adobe Caslon Pro字体刚好能填充Ascent到Descent之间的空间，因此由上图可以看出两行字符之间其实是有留空的。这里就设计到一个叫textLeading的概念了。textLeading意味着两行文字之间的留白，把它的值设分别设为0和textAscent() + textDescent()是这样的：

1
textLeading(0);

TextLeading 0

1
2
textLeading(textAscent() + textDescent());
//textSize(float)函数会将textLeading重置为默认值

TextLeading A+D

而这个值它在Processing中的默认是textLeading = (textAscent() + textDescent()) * 1.275f。有上一节的源代码，可以很容易得出整段多行文本的上下边界，以默认对齐为例，假设文本有n行，textLeading值为lead，用户传入text的坐标为(x, y)，文本上边界为multi_ascent，下边界为multi_descent，第k行文字的baseline、ascent和descent为baseline_k、ascent_k和descent_k，则：

  • multi_ascent = y - textAscent()

  • multi_descent = y + textDescent() + lead * (n - 1)

  • baseline_k = y + lead * (k - 1)

  • ascent_k = y + lead * (k - 1) - textAscent()

  • descent_k = y + lead * (k - 1) + textDescent()

应用

能够算出这些线的坐标之后，给定一串字符，设定好大小、位置、对齐方式之后，可以很容易地算出能紧密包围这串文字的矩形位置。另一方面，对于给定的矩形与对齐方式，也不难反推出在矩形中显示这串字符合适的大小是多少。进一步地，如果需要将文字与圆、椭圆或者多边形关联，可以先计算出这些图形的内接矩形，再将其与文字关联，这部分内容将另文讨论。