[SkSVGDevice] drawTextOnPath() support

[SkSVGDevice] drawTextOnPath() support

R=reed@google.com,mtklein@google.com

Committed: https://skia.googlesource.com/skia/+/a9d9de45c1cd83419b4afc7884359e92bc173009

[reed1, 2015-02-05 01:23:14]

lgtm

What is the idea/plan/roadmap to test our SVG output (via Gold?)

https://codereview.chromium.org/874853003/diff/1/experimental/svg/SkSVGDevice...
File experimental/svg/SkSVGDevice.cpp (right):

https://codereview.chromium.org/874853003/diff/1/experimental/svg/SkSVGDevice...
experimental/svg/SkSVGDevice.cpp:93: SkScalarToFloat(t.getScaleX()),
SkScalarToFloat(t.getSkewY()),
Don't think any of these conversions are necessary. Printf always expands to
doubles anyway, so just passing our variables should be perfectly
legal/efficient.

[mtklein, 2015-02-05 01:30:54]

On 2015/02/05 01:23:14, reed1 wrote:
> lgtm
> 
> What is the idea/plan/roadmap to test our SVG output (via Gold?)

Currently the same plan as the plan for PDF: DM generates and uploads native
.svg and .pdf files,
 then Gold rasterizes them at arbitrary DPI on ingestion so the rest of the
pipeline talks raster.
This will let us do things like diff SVG output against 8888.

DM's generating the native files now.  We just need to get the rasterization in
Gold's ingestion pipeline.

[f(malita), 2015-02-05 01:44:37]

New patchsets have been uploaded after l-g-t-m from reed@google.com

[f(malita), 2015-02-05 01:48:39]

On 2015/02/05 01:30:54, mtklein wrote:
> On 2015/02/05 01:23:14, reed1 wrote:
> > lgtm
> > 
> > What is the idea/plan/roadmap to test our SVG output (via Gold?)
> 
> Currently the same plan as the plan for PDF: DM generates and uploads native
> .svg and .pdf files,
>  then Gold rasterizes them at arbitrary DPI on ingestion so the rest of the
> pipeline talks raster.
> This will let us do things like diff SVG output against 8888.
> 
> DM's generating the native files now.  We just need to get the rasterization
in
> Gold's ingestion pipeline.

Any ideas for that last part? It would be nice to avoid using external viewers -
I wonder what state the Skia SVG parser is in...

https://codereview.chromium.org/874853003/diff/1/experimental/svg/SkSVGDevice...
File experimental/svg/SkSVGDevice.cpp (right):

https://codereview.chromium.org/874853003/diff/1/experimental/svg/SkSVGDevice...
experimental/svg/SkSVGDevice.cpp:93: SkScalarToFloat(t.getScaleX()),
SkScalarToFloat(t.getSkewY()),
On 2015/02/05 01:23:14, reed1 wrote:
> Don't think any of these conversions are necessary. Printf always expands to
> doubles anyway, so just passing our variables should be perfectly
> legal/efficient.

Done.

[f(malita), 2015-02-05 01:48:47]

The CQ bit was checked by fmalita@chromium.org

[commit-bot: I haz the power, 2015-02-05 01:49:11]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/874853003/20001

[commit-bot: I haz the power, 2015-02-05 01:54:53]

Committed patchset #2 (id:20001) as
https://skia.googlesource.com/skia/+/a9d9de45c1cd83419b4afc7884359e92bc173009