为什么 HTML5 canvas 的 "TextMetrics" 对象中的 "width" 和 "actualBoundingBoxLeft + actualBoundingBoxRight" 有区别？
Why is there a difference between "width" and "actualBoundingBoxLeft + actualBoundingBoxRight" in a "TextMetrics" object of a HTML5 canvas?
当我如代码片段所示调用 measureText 时，我得到以下结果：
{
"width": 45.43333435058594,
"actualBoundingBoxLeft": 0,
"actualBoundingBoxRight": 45.35,
"actualBoundingBoxAscent": 18,
"actualBoundingBoxDescent": 0
}
如果 actualBoundingBoxLeft 为零，为什么 width 和 actualBoundingBoxRight 有区别？
c2d = document.getElementById('canvas').getContext('2d');
c2d.direction = 'ltr';
c2d.font = '24px serif';
console.log (c2d.measureText('TeX'));
<canvas id="canvas"></canvas>
希望我能得到你的要求，我会试一试。
width属性给出the text's advance width。 Space 不包括左右轴承。
–宽度属性
行内框的宽度，以 CSS 像素为单位。 （文本的前进宽度。）
– actualBoundingBoxLeft 属性
从textAlign属性给定的对齐点到给定文本的边界矩形左侧的平行于基线的距离，在CSS像素；正数表示从给定对齐点向左移动的距离。
其中也给出了注释：
The sum of this value and the next (actualBoundingBoxRight) can be wider than the width of the inline box (width), in particular with slanted fonts where characters overhang their advance width.
– actualBoundingBoxRight 属性
从textAlign属性给定的对齐点到给定文本的边界矩形右侧的平行于基线的距离，在CSS像素；正数表示从给定对齐点向右移动的距离。
一些例子
使用来自 canvas 的 measuereText 的数据 times f（正常左侧，斜体右侧):
错误：中间和底部宽度线（蓝色的）交换了位置，但没有更新标签。图片中的标签，“中”就是“底”，“底”就是“中”。稍后我会争取时间上传新的
尤其是倾斜的版本更能体现这一点。 textBaseline（灰色水平线）之后的蓝线，从 textAlign（灰色垂直线）开始显示 width 字形的值。那就是字体将“typehead”.
前进了多少
左边界框/右边界框是水平扩展的极端。如果把它看成一个矩形。上升和下降也是如此。他们是极端的向上/向下。但是，作为字体的 "overlap"（字距调整等），它不是代表高级宽度的 width 的一个因素。
方框宽度之和为111 + 39 = 150但width仅为72.28.
至于你的样本，用这么小的字体很难看清。 （相对而言）。将 for 增加到 1024px 或任何可以提供更清晰结果的东西。分数和路径计算是如此之小，以至于人们会错过细微的像素分数。 1024px:
actualBoundingBoxAscent : 747
actualBoundingBoxDescent : 14
actualBoundingBoxLeft : -10
actualBoundingBoxRight : 1933.5
width : 1938.5
考虑到总宽度，差异 (1933.5 + -10 = 1923.5) 仍然很小，但至少存在于服务对象中。
另一个样本 +:
正如人们所观察到的，字形 使文本 比它在绘制像素中所占的要多得多。甚至可能出现字形根本不推进文本的情况。它们仍然可以在文本中独立存在，但它的定义在某种程度上适用于 以前的字形 ...例如 dấu hỏi 或 上面的钩子 宽度为零。
但有些仍然被定义为前进个字符例如：
该示例的另一个有趣之处在于，了解 Descent 是如何为负的（不会低于 textBaseline），并且 Ascent 也存在。从逻辑上看，但可能是一个问题。
可以扩大 canvas 上的测试，但必须仔细观察。自从我在 cavases 上工作以来太久了。这是近距离视图，但尚未验证或检查线条的精确度（精确到像素）。
如果它是正确的，它会显示一个细微的差异，其中 宽度 在 TeX 末尾使用 24px 字体前进。
当我如代码片段所示调用 measureText 时，我得到以下结果：
{
"width": 45.43333435058594,
"actualBoundingBoxLeft": 0,
"actualBoundingBoxRight": 45.35,
"actualBoundingBoxAscent": 18,
"actualBoundingBoxDescent": 0
}
如果 actualBoundingBoxLeft 为零，为什么 width 和 actualBoundingBoxRight 有区别？
c2d = document.getElementById('canvas').getContext('2d');
c2d.direction = 'ltr';
c2d.font = '24px serif';
console.log (c2d.measureText('TeX'));
<canvas id="canvas"></canvas>
希望我能得到你的要求，我会试一试。
width属性给出the text's advance width。 Space 不包括左右轴承。
–宽度属性
行内框的宽度，以 CSS 像素为单位。 （文本的前进宽度。）
– actualBoundingBoxLeft 属性
从textAlign属性给定的对齐点到给定文本的边界矩形左侧的平行于基线的距离，在CSS像素；正数表示从给定对齐点向左移动的距离。
其中也给出了注释：
The sum of this value and the next (actualBoundingBoxRight) can be wider than the width of the inline box (width), in particular with slanted fonts where characters overhang their advance width.
– actualBoundingBoxRight 属性
从textAlign属性给定的对齐点到给定文本的边界矩形右侧的平行于基线的距离，在CSS像素；正数表示从给定对齐点向右移动的距离。
一些例子
使用来自 canvas 的 measuereText 的数据 times f（正常左侧，斜体右侧):
错误：中间和底部宽度线（蓝色的）交换了位置，但没有更新标签。图片中的标签，“中”就是“底”，“底”就是“中”。稍后我会争取时间上传新的
尤其是倾斜的版本更能体现这一点。 textBaseline（灰色水平线）之后的蓝线，从 textAlign（灰色垂直线）开始显示 width 字形的值。那就是字体将“typehead”.
前进了多少左边界框/右边界框是水平扩展的极端。如果把它看成一个矩形。上升和下降也是如此。他们是极端的向上/向下。但是，作为字体的 "overlap"（字距调整等），它不是代表高级宽度的 width 的一个因素。
方框宽度之和为111 + 39 = 150但width仅为72.28.
至于你的样本，用这么小的字体很难看清。 （相对而言）。将 for 增加到 1024px 或任何可以提供更清晰结果的东西。分数和路径计算是如此之小，以至于人们会错过细微的像素分数。 1024px:
actualBoundingBoxAscent : 747
actualBoundingBoxDescent : 14
actualBoundingBoxLeft : -10
actualBoundingBoxRight : 1933.5
width : 1938.5
考虑到总宽度，差异 (1933.5 + -10 = 1923.5) 仍然很小，但至少存在于服务对象中。
另一个样本 +:
正如人们所观察到的，字形 使文本 比它在绘制像素中所占的要多得多。甚至可能出现字形根本不推进文本的情况。它们仍然可以在文本中独立存在，但它的定义在某种程度上适用于 以前的字形 ...例如 dấu hỏi 或 上面的钩子 宽度为零。
但有些仍然被定义为前进个字符例如：
该示例的另一个有趣之处在于，了解 Descent 是如何为负的（不会低于 textBaseline），并且 Ascent 也存在。从逻辑上看，但可能是一个问题。
可以扩大 canvas 上的测试，但必须仔细观察。自从我在 cavases 上工作以来太久了。这是近距离视图，但尚未验证或检查线条的精确度（精确到像素）。
如果它是正确的，它会显示一个细微的差异，其中 宽度 在 TeX 末尾使用 24px 字体前进。