Bug 12376 - glyph rotation in text/tspan not implemented
Summary: glyph rotation in text/tspan not implemented
Status: RESOLVED DUPLICATE of bug 12698
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P2 Normal
Assignee: Nobody
URL: http://www.carto.net/neumann/webkitsv...
Keywords:
Depends on:
Blocks: 6425
  Show dependency treegraph
 
Reported: 2007-01-23 01:35 PST by Andreas Neumann
Modified: 2007-02-08 09:21 PST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Neumann 2007-01-23 01:35:13 PST
In the provided example each glyph in the word "glyphs" should be rotated (15,30,45,60,75,90) degrees.

At http://www.carto.net/neumann/webkitsvgbugs/glyph_rotation_test.png is the correct rendering from Apache Batik.

Thanks for having a look at this!
Comment 1 Eric Seidel (no email) 2007-01-30 21:51:43 PST
We don't yet have a way to position individual glyphs.  Oliver is the best person to ask about this.
Comment 2 Oliver Hunt 2007-01-30 22:22:28 PST
I thought i already had a bug on this -- but that could be radar :-/

Basically we need to have a separate text rendering path for anything other than simple horizontal text.

My suggested steps would be:
1. In SVGRenderInlineText (i think that's it) override paint, and have it do painting itself; once that's going
2. Allow individual character positioning -- for this you'll need to fix width/height calculation -- eg. make <text x="100" y="100"><tspan dy="10 10 10">foo<tspan>bar</text> -- after that <text x="100" y="100 110 120 130 140 150">foo<tspan x="200">bar</tspan></text>.   This will be difficult as determining the width/height of a text run will require knowledge of the text positioning elements of both parent and preceeding elements.
3. Once you've got that done, adding glyph rotations should be relatively simple  (as you'll already have all the rules and logic setup for accessing per character x/y/dx/dy/etc)


I suspect for anything other than simple text you'll need 
struct SVGChar {
  UChar m_char;
  short angle : 14;
  short orientation : 2;
  float m_x;
  float m_y;
}

You could recalculate angle, x, y during painting but it would probably be very expensive, as the increased memory usage shouldn't be too significant as these will probably not be used too much (and i doubt people will be putting screeds of text in SVG).

You could use lots of special cases to deal with only x/y/angle varying per character, but i doubt it would really be worth it.  It could be worth it to distinguish the case where no angle is specified as applying rotation to the glyphs will probably be expensive

I was hoping scaled ints would work for x/y but we'll probably need float precision (ideally double, but trying to minimise size).  Roatation angle should be fine as a scaled int, lowering the precision to share with glyph orientation.  Glyph orientation will be needed for vertical text, though i'm not yet aware of whether it is possible to determine available glyph orientations on macos.

However once this is done it should allow the painting code to render positioned, rotated, vertical, and path defined text in a generic way.  Doing the layout will still not be incredibly pleasant though. Multipass layout will probably be easier initially (as happens in current layout)
Comment 3 Nikolas Zimmermann 2007-02-08 09:21:35 PST
text rotation is implemented in bug 12698 - tspan should be easy to fix too.

*** This bug has been marked as a duplicate of 12698 ***