Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
OpenHarmony
Third Party Harfbuzz
提交
d18fd8e3
T
Third Party Harfbuzz
项目概览
OpenHarmony
/
Third Party Harfbuzz
大约 1 年 前同步成功
通知
0
Star
18
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
T
Third Party Harfbuzz
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
d18fd8e3
编写于
5月 19, 2009
作者:
B
Behdad Esfahbod
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
[GPOS] CursivePosFormat1
上级
70632add
变更
2
隐藏空白更改
内联
并排
Showing
2 changed file
with
169 addition
and
7 deletion
+169
-7
src/hb-ot-layout-gpos-private.h
src/hb-ot-layout-gpos-private.h
+168
-6
src/hb-ot-layout-private.h
src/hb-ot-layout-private.h
+1
-1
未找到文件。
src/hb-ot-layout-gpos-private.h
浏览文件 @
d18fd8e3
...
...
@@ -532,9 +532,6 @@ ASSERT_SIZE (PairPos, 2);
struct
EntryExitRecord
{
/* TODO */
private:
OffsetTo
<
Anchor
>
entryAnchor
;
/* Offset to EntryAnchor table--from
* beginning of CursivePos
...
...
@@ -551,9 +548,174 @@ struct CursivePosFormat1 {
friend
struct
CursivePos
;
private:
inline
bool
apply
(
APPLY_ARG_DEF
)
const
{
/* TODO */
return
false
;
inline
bool
apply
(
APPLY_ARG_DEF
)
const
{
struct
hb_ot_layout_t
::
gpos_info_t
*
gpi
=
&
layout
->
gpos_info
;
hb_codepoint_t
last_pos
=
gpi
->
last
;
gpi
->
last
=
0xFFFF
;
/* We don't handle mark glyphs here. */
if
(
property
==
HB_OT_LAYOUT_GLYPH_CLASS_MARK
)
return
false
;
unsigned
int
index
=
(
this
+
coverage
)
(
IN_CURGLYPH
());
if
(
HB_LIKELY
(
index
==
NOT_COVERED
))
return
false
;
/* Now comes the messiest part of the whole OpenType
specification. At first glance, cursive connections seem easy
to understand, but there are pitfalls! The reason is that
the specs don't mention how to compute the advance values
resp. glyph offsets. I was told it would be an omission, to
be fixed in the next OpenType version... Again many thanks to
Andrei Burago <andreib@microsoft.com> for clarifications.
Consider the following example:
| xadv1 |
+---------+
| |
+-----+--+ 1 |
| | .| |
| 0+--+------+
| 2 |
| |
0+--------+
| xadv2 |
glyph1: advance width = 12
anchor point = (3,1)
glyph2: advance width = 11
anchor point = (9,4)
LSB is 1 for both glyphs (so the boxes drawn above are glyph
bboxes). Writing direction is R2L; `0' denotes the glyph's
coordinate origin.
Now the surprising part: The advance width of the *left* glyph
(resp. of the *bottom* glyph) will be modified, no matter
whether the writing direction is L2R or R2L (resp. T2B or
B2T)! This assymetry is caused by the fact that the glyph's
coordinate origin is always the lower left corner for all
writing directions.
Continuing the above example, we can compute the new
(horizontal) advance width of glyph2 as
9 - 3 = 6 ,
and the new vertical offset of glyph2 as
1 - 4 = -3 .
Vertical writing direction is far more complicated:
a) Assuming that we recompute the advance height of the lower glyph:
--
+---------+
-- | |
+-----+--+ 1 | yadv1
| | .| |
yadv2 | 0+--+------+ -- BSB1 --
| 2 | -- -- y_offset
| |
BSB2 -- 0+--------+ --
-- --
glyph1: advance height = 6
anchor point = (3,1)
glyph2: advance height = 7
anchor point = (9,4)
TSB is 1 for both glyphs; writing direction is T2B.
BSB1 = yadv1 - (TSB1 + ymax1)
BSB2 = yadv2 - (TSB2 + ymax2)
y_offset = y2 - y1
vertical advance width of glyph2
= y_offset + BSB2 - BSB1
= (y2 - y1) + (yadv2 - (TSB2 + ymax2)) - (yadv1 - (TSB1 + ymax1))
= y2 - y1 + yadv2 - TSB2 - ymax2 - (yadv1 - TSB1 - ymax1)
= y2 - y1 + yadv2 - TSB2 - ymax2 - yadv1 + TSB1 + ymax1
b) Assuming that we recompute the advance height of the upper glyph:
-- --
+---------+ -- TSB1
-- -- | |
TSB2 -- +-----+--+ 1 | yadv1 ymax1
| | .| |
yadv2 | 0+--+------+ -- --
ymax2 | 2 | -- y_offset
| |
-- 0+--------+ --
--
glyph1: advance height = 6
anchor point = (3,1)
glyph2: advance height = 7
anchor point = (9,4)
TSB is 1 for both glyphs; writing direction is T2B.
y_offset = y2 - y1
vertical advance width of glyph2
= TSB1 + ymax1 + y_offset - (TSB2 + ymax2)
= TSB1 + ymax1 + y2 - y1 - TSB2 - ymax2
Comparing a) with b) shows that b) is easier to compute. I'll wait
for a reply from Andrei to see what should really be implemented...
Since horizontal advance widths or vertical advance heights
can be used alone but not together, no ambiguity occurs. */
const
EntryExitRecord
&
record
=
entryExitRecord
[
index
];
hb_position_t
entry_x
,
entry_y
,
exit_x
,
exit_y
;
if
(
last_pos
==
0xFFFF
||
!
record
.
entryAnchor
)
goto
end
;
(
this
+
record
.
entryAnchor
).
get_anchor
(
layout
,
IN_CURGLYPH
(),
&
entry_x
,
&
entry_y
);
if
(
gpi
->
r2l
)
{
POSITION
(
buffer
->
in_pos
)
->
x_advance
=
entry_x
-
gpi
->
anchor_x
;
POSITION
(
buffer
->
in_pos
)
->
new_advance
=
TRUE
;
}
else
{
POSITION
(
gpi
->
last
)
->
x_advance
=
gpi
->
anchor_x
-
entry_x
;
POSITION
(
gpi
->
last
)
->
new_advance
=
TRUE
;
}
if
(
lookup_flag
&
LookupFlag
::
RightToLeft
)
{
POSITION
(
gpi
->
last
)
->
cursive_chain
=
gpi
->
last
-
buffer
->
in_pos
;
POSITION
(
gpi
->
last
)
->
y_pos
=
entry_y
-
gpi
->
anchor_y
;
}
else
{
POSITION
(
buffer
->
in_pos
)
->
cursive_chain
=
buffer
->
in_pos
-
gpi
->
last
;
POSITION
(
buffer
->
in_pos
)
->
y_pos
=
gpi
->
anchor_y
-
entry_y
;
}
end:
if
(
record
.
exitAnchor
)
(
this
+
record
.
exitAnchor
).
get_anchor
(
layout
,
IN_CURGLYPH
(),
&
gpi
->
anchor_x
,
&
gpi
->
anchor_y
);
buffer
->
in_pos
++
;
return
true
;
}
private:
...
...
src/hb-ot-layout-private.h
浏览文件 @
d18fd8e3
...
...
@@ -47,7 +47,7 @@ struct _hb_ot_layout_t {
}
new_gdef
;
/* TODO full-matrix transformation? */
struct
{
struct
gpos_info_t
{
unsigned
int
x_ppem
,
y_ppem
;
hb_16dot16_t
x_scale
,
y_scale
;
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录