[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="&#x069A;" arabic-form="initial" d="M0 500L250 0L500
500"/>
        <glyph unicode="&#x069A;" arabic-form="medial" d="M0 500L250 0L500
500"/>
        <glyph unicode="&#x069A;" 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">&#x069A;&#x069A;&#x069A;</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