- 我有一个粗略(99.99%)圆形的svg路径
- 沿着这条路径,我使用“textpath”svg 元素放置文本
- 我希望文本的结尾尽可能准确地与开头相遇(理想情况下是像素完美),以便形成一个连续的文本循环
这是代码的摘录(删除了所有文本值):
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
version="1.1" viewBox="0 0 480 480" preserveAspectRatio="xMidYMid" height="100%"
width="100%">
<defs>
<style type="text/css">
/* for some reason, SVG font import doesn't work in Chrome or Firefox! */
@font-face {
font-family: Libertine;
src: url(LinLibertine_R.svg#LinLibertineO);
}
@font-face {
font-family: Libertine2;
src: url(LinLibertine_Rah.ttf);
}
/* Chrome seems to round to the nearest 0.5 em; also, does not display em-widths consistently with Firefox (though px-widths are consistent) */
.ex1 {
font: 0.85em Libertine2;
}
.measurement {
font: 1.0em monospace;
}
</style>
<text id="day1">...</text>
<text id="day2">...</text>
<text id="day3">...</text>
<text id="day4">...</text>
<text id="day5">...</text>
<text id="day6">...</text>
<text id="day7">...</text>
</defs>
<g transform="translate(240,240)">
<g transform="translate(-240,-240)">
<circle r="1" cx="240" cy="27" fill="black" />
<path id="circle" d="M 240,20 a 220,220, 0 1,1 -0.0001,0.0000 Z"
fill="none" stroke="red" stroke-width="0" />
<path id="inner-circle" d="M 240,40 a 200,200, 0 1,1 -0.0001,0.0000 Z"
fill="none" stroke="red" stroke-width="0" />
<text class="ex1" fill="black">
<!-- this RTL text-along-path is displayed backwards (ie sdrawkcab) in
Chrome; manual CSS overrides (e.g. unicode-bidi) cause blank/white screen
-->
<textPath xlink:href="#circle" method="stretch">...</textPath>
</text>
<text class="measurement" fill="grey">
<textPath xlink:href="#inner-circle" method="stretch">A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 G0 G1 G2 G3 G4 G5 G6 G8 G9</textPath>
</text>
</g>
</g>
</svg>
到目前为止,我能做的最好的事情是通过 CSS 导入字体,这大致标准化了浏览器的宽度。
请注意,Chrome 不会读取经过微调的字体大小值(例如,它似乎将 0.87em 舍入到 0.85em),并且似乎具有与 Firefox 不同的文本渲染引擎,即使字体大小是一致的。例如,1em 的字体大小将上面示例中的内部“测量圆圈”渲染为 Firefox 中刻度“F9”中的 F,而 Chrome 几乎呈现到刻度“F4”的开头,这个问题被简化为在字体大小中使用 px 单位时的单个字符宽度差异。
您还会注意到 Chrome 不正确地呈现从右到左 (RTL) 文本,并且手动 CSS 覆盖(使用 'unicode-bidi' 和 'direction' 指令)导致完全失败(根本没有 SVG 呈现)。
不用说——有很多问题。到目前为止,这是一个有趣的实验,但我们将不胜感激任何对标准化的帮助。
就我自己的解决方案而言;我正在考虑使用 LinuxLibertine svg-font 中的字体规范手动指定每个字符的位置,这是找出呈现不一致的根源的一种非常俗气的替代方法。