[Webkit-unassigned] [Bug 19128] New: SVG fonts don't work with medial Arabic characters
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Mon May 19 13:16:45 PDT 2008
http://bugs.webkit.org/show_bug.cgi?id=19128
Summary: SVG fonts don't work with medial Arabic characters
Product: WebKit
Version: 526+ (Nightly build)
Platform: PC
OS/Version: Windows XP
Status: UNCONFIRMED
Severity: Normal
Priority: P2
Component: SVG
AssignedTo: webkit-unassigned at lists.webkit.org
ReportedBy: myrdred at gmail.com
To repro, go to LayoutTests/svg/W3C-SVG-1.1/fonts-glyphs-02-t.svg. Note big
ugly blank rectangles where none should exist.
Simplified repro case is:
<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" >
<defs>
<font horiz-adv-x="500">
<font-face font-family="SVGFont" />
<missing-glyph d="M0 500L250 750L500 500"/>
<glyph unicode="ښ" arabic-form="initial" d="M0 500L250 0L500
500"/>
<glyph unicode="ښ" arabic-form="medial" d="M0 500L250 0L500
500"/>
<glyph unicode="ښ" arabic-form="terminal" d="M0 500L250 0L500
500"/>
</font>
</defs>
<g font-family="SVGFont" font-size="80">
<text font-face="SVGFont" font-size="80" x="100"
y="100">ښښښ</text>
</g>
</svg>
This should output three downward-pointing triangles (one for each character in
the <text> element) but it outputs two downward triangles with an upward
triangle between them. Glyphs with arabic-form "medial" don't work. Here's the
problem.
SVGGlyphElement.h:
struct SVGGlyphIdentifier {
...
// SVG Font depends on exactly this order.
enum ArabicForm {
None = 0,
Isolated,
Terminal,
Initial,
Medial
};
...
ArabicForm arabicForm : 3;
ArabicForm has values 0 to 4 inclusive, so it looks like a 3-bit bitfield
should be more than sufficient. But enumerations are signed types, so the
bitfield is also signed, so rather than ranging from 0..7, it ranges from
-4..3. You can verify this:
void main() {
enum foo { ZERO, ONE, TWO, THREE, FOUR };
struct bar { foo f : 3; } b;
b.f = FOUR;
cout << "FOUR = " << FOUR << endl;
cout << "b.f = " << b.f << endl;
cout << "FOUR == b.f = " << (FOUR==b.f) << endl;
}
...which outputs:
FOUR = 4
b.f = -4
FOUR == b.f = 0
The simplest solution is to bump the size of the bitfield up by one. This
should have zero impact on performance, since the next data member should be
byte-aligned (at least) anyway.
Sure would be nice if the compiler warned of the potential integer overflow.
--
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
More information about the webkit-unassigned
mailing list