Support x,y lists on tspan for positioning native font glyphs

[GoogleCodeExporter]

To reproduce: View 
http://www.svgmaker.com/svgweb/samples/tspanxlist.html?svg.render.forceflash=tru
e

SVG file embedded via <object>

Expected output: The second line should be spaced similarly to the first line.

Actual output: each tspan in line two is positioned as if <tspan x="0" ..>

Using: Beholder

The first line in the example is for reference and has each character
positioned with a tspan per character.  The second line has a tspan per
word with x lists to position each character within the word. 

eg. <tspan x="198,234,290,351,412,473" y="333">tspan </tspan>

The third line is also for reference and has a tspan per word with a single
x value to position the first character of the word.

eg. <tspan x="198" y="434">tspan </tspan>

Original issue reported on code.google.com by k...@svgmaker.com on 7 Nov 2009 at 5:41

[GoogleCodeExporter]

I think the broken behavior of line 2 is the result of the return value from
SVGColors.cleanNumber. The list of values is concatenated and a single number
evaluated from that.  A slight change to cleanNumber could make line 2 
positioned
like line 3. While not perfect, it would be an improvement.

  static public function cleanNumber(num:*):Number {
      var numString:String = String(num);
      if (isColor(numString)) {
          return SVGColors.getColor(numString);
      }
      numString = numString.split(',')[0];   // ********************
      numString = numString.replace(/[^0-9\.-]+/sig,'');
      return Number(numString);
  }

This partial fix is probably only useful for x lists in the context of lines of 
words
(which is our main use case).

Original comment by k...@svgmaker.com on 7 Nov 2009 at 5:44

[GoogleCodeExporter]

Partially fixed in r986.
We do not currently support glyph coordinates for native fonts. A workaround is 
to
use SVG fonts. As was noted in the comments above, the first value was not being
parsed properly. That is fixed in r986 and the first coordinate will be used 
for the
entire native text field.

Original comment by grick23@gmail.com on 15 Nov 2009 at 7:19

• Changed title: Support x,y lists on tspan for positioning native font glyphs
• Changed state: Accepted
• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

> A workaround is to use SVG fonts.

SVG fonts don't work with x,y lists.

http://www.svgmaker.com/svgweb/samples/tspanxlist.svgfonts.html?svg.render.force
flash=true

Same as the original example except using SVG fonts.  Currently using 
Gelatinous-Cube.

Original comment by k...@svgmaker.com on 23 Nov 2009 at 10:53

[GoogleCodeExporter]

That's right, thanks. I had implemented it but I left it commented out because 
it did
not work.

x, y lists for SVGFonts has been implemented in r1010.

Original comment by grick23@gmail.com on 28 Nov 2009 at 9:43

[GoogleCodeExporter]

X,Y lists for system fonts is a core requirement for our product to work with 
SVG WEB.  
Is anyone implementing X,Y lists for system fonts?  Is there an ETA?

Original comment by mkid...@gmail.com on 8 Dec 2009 at 3:51

[GoogleCodeExporter]

@mkidson: Fonts are more on Ricks side, but I don't believe there is an ETA for 
this
feature yet. Rick will have to give the definitive answer.

Original comment by bradneub...@gmail.com on 8 Dec 2009 at 7:15

[GoogleCodeExporter]

I'll take a look at this over the weekend.

Original comment by grick23@gmail.com on 10 Dec 2009 at 10:30

[GoogleCodeExporter]

Would anyone mind if we implement a solution and submit the code?  What is the 
procedure to review the submission and have it accepted or rejected? 

Original comment by mkid...@gmail.com on 21 Dec 2009 at 9:51

[GoogleCodeExporter]

Hi mkidson. The procedure is to generate a patch and attach it to this bug. 
Also make
sure to test your patch with both the native renderer and the Flash renderer, 
as well
as testing on at least one version of Internet Explorer.

Once I see a patch Rick and/or I will review it and either provide feedback on 
things
that need to be changed or apply it ourselves and check it into the Subversion
repository.

Thanks for your help!

Original comment by bradneub...@gmail.com on 21 Dec 2009 at 10:59

[GoogleCodeExporter]

The one other thing I should mention is that your patch should work with Flash 
9+ (it
shouldn't require Flash 10).

Original comment by bradneub...@gmail.com on 21 Dec 2009 at 11:49

[GoogleCodeExporter]

Attached is a patch which implements x,y lists for native font glyphs.  All 
changes
are in SVGTextNode.as.

Essentially, the text for the node is broken up into an array of TextFields - 
one for
each x,y list value.

Other changes include performing the layout (and other attribute handling) code 
for
svg fonts and native fonts in the same place in parseChildren().  Previously the
TextField positioning etc was done in setAttributes().

This patch also incorporates improvements on the TextField size handling in the 
patch
for Issue 440 (which fixes Issue 264).

This patch also fixes the placement and size problems in Issue 447.

Original comment by k...@svgmaker.com on 28 Jan 2010 at 6:14

Attachments:

• xylists.diff

[GoogleCodeExporter]

Thanks for the patch!

Original comment by bradneub...@gmail.com on 5 Feb 2010 at 4:39

• Added labels: Patch

[GoogleCodeExporter]

I think Rick is in the best position to review this patch, since he wrote the 
font handling 
code.

Original comment by bradneub...@gmail.com on 5 Feb 2010 at 4:40

[GoogleCodeExporter]

Is there some testing we could perform to help get this patch evaluated?  What 
can we 
do to help?

Original comment by mkid...@gmail.com on 16 Feb 2010 at 11:30

[GoogleCodeExporter]

Hi mkidson, the patch looks good to me but Rick is the owner of this code, 
he'll have 
to give the final approval. Some things you can do though:

* Run through the samples in samples/javascript-samples/*.html and make sure 
they still run.
* Use the demo viewer at samples/demo.html and step through the files in there 
and 
make sure they haven't regressed.

These are things that both Rick and I would have to do, and if you do them 
yourselves that will help us know that things work correctly.

Did you end up using any Flash 10 specific features in your code? That's 
important 
to know.

Since this is around native font glyphs, have you tested to make sure your code 
works cross-platform (Linux, Mac, and Windows)? That's another step we'd have 
to 
do and if you do that for us it will speed things up.

Original comment by bradneub...@gmail.com on 16 Feb 2010 at 6:29

[GoogleCodeExporter]

Sorry I've been away. I'll make it my first priority to incorporate this patch.

Original comment by grick23@gmail.com on 20 Feb 2010 at 4:04

• Added labels: Priority-High
• Removed labels: Priority-Low

[GoogleCodeExporter]

Thanks, Rick.

I have run through the the samples/demo.html files, as Brad indicated, with a
Vista/Flash 10 system.  No problems so far.  Mac and Linux next.

There are no Flash 10 specific features in the patch.

Original comment by k...@svgmaker.com on 21 Feb 2010 at 9:50

[GoogleCodeExporter]

I ran the demo.html files on OSX 10.5.8/Safari/Flash 10 and on Ubuntu
9.10/Firefox/Flash 10.  Most of the sample svg files have no text.  For those 
that
contain text, I didn't encounter any regressions.

The patch does contain code changes for svg fonts as well as native fonts so I
checked for regressions there as well.

Are there any javascript examples which modify text nodes? or text element 
attributes?

Original comment by k...@svgmaker.com on 23 Feb 2010 at 4:02

[GoogleCodeExporter]

Patch integrated in r1048:
Support x,y lists on tspan for positioning native font glyphs
by supporting multiple text fields per tspan.
Support font sizes outside the limited range that flash supports
by scaling flash fonts using a normalized size in order.

Big thanks go to ken@svgmaker.com who provided this patch,
helped test it, and waited patiently for integration.

Original comment by grick23@gmail.com on 27 Feb 2010 at 11:00

• Changed state: Fixed