SkPDF: clean up uses of deprecated calls in SkPDFFont

SkPDF: clean up uses of deprecated calls in SkPDFFont

BUG=skia:3585
Committed: https://skia.googlesource.com/skia/+/bf51cfdbd9e41a2e9e2d16dc8d97ac74d9dd84da

[hal.canary, 2015-04-27 12:22:55]

The CQ bit was checked by halcanary@google.com to run a CQ dry run

[commit-bot: I haz the power, 2015-04-27 12:23:05]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1110533002/1

[hal.canary, 2015-04-27 12:23:09]

halcanary@google.com changed reviewers:
+ tomhudson@google.com

[hal.canary, 2015-04-27 12:23:09]

PTAL

[commit-bot: I haz the power, 2015-04-27 12:26:56]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-04-27 12:26:56]

Dry run: This issue passed the CQ dry run.

[hal.canary, 2015-05-01 11:48:12]

ping

[tomhudson, 2015-05-01 15:06:20]

lgtm

https://codereview.chromium.org/1110533002/diff/1/src/pdf/SkPDFFont.cpp
File src/pdf/SkPDFFont.cpp (right):

https://codereview.chromium.org/1110533002/diff/1/src/pdf/SkPDFFont.cpp#newco...
src/pdf/SkPDFFont.cpp:1061: this->insertObjRef("FontDescriptor",
SkRef(descriptor.get()));
Minor frustration: while reviewing it's easy to do point-by-point analysis of
the changes you made in this CL, but it's hard to
(1) spot places you perhaps should have changed and didn't.
(2) understand why you're SkRef()ing here, .detaching() other places, etc. Just
tracking lifetimes makes me wish for semantic Hungarian.

https://codereview.chromium.org/1110533002/diff/1/src/pdf/SkPDFFont.cpp#newco...
src/pdf/SkPDFFont.cpp:1167: this->insertObject("W", widths.detach());
It's a bit weird seeing a *conditional* detach(), but I suppose that if the
conditional is false you don't want the data and the AutoTUnref will take care
of it at the end of the scope.

https://codereview.chromium.org/1110533002/diff/1/src/pdf/SkPDFFont.cpp#newco...
src/pdf/SkPDFFont.cpp:1232: SkAutoTUnref<SkPDFStream> fontStream(new
SkPDFStream(fontData.get()));
Not detach()ing the fontData?

[hal.canary, 2015-05-05 17:17:24]

https://codereview.chromium.org/1110533002/diff/1/src/pdf/SkPDFFont.cpp
File src/pdf/SkPDFFont.cpp (right):

https://codereview.chromium.org/1110533002/diff/1/src/pdf/SkPDFFont.cpp#newco...
src/pdf/SkPDFFont.cpp:1061: this->insertObjRef("FontDescriptor",
SkRef(descriptor.get()));
On 2015/05/01 15:06:20, tomhudson wrote:
> Minor frustration: while reviewing it's easy to do point-by-point analysis of
> the changes you made in this CL, but it's hard to
> (1) spot places you perhaps should have changed and didn't.
> (2) understand why you're SkRef()ing here, .detaching() other places, etc.
Just
> tracking lifetimes makes me wish for semantic Hungarian.

I'll try to fix.

https://codereview.chromium.org/1110533002/diff/1/src/pdf/SkPDFFont.cpp#newco...
src/pdf/SkPDFFont.cpp:1167: this->insertObject("W", widths.detach());
On 2015/05/01 15:06:20, tomhudson wrote:
> It's a bit weird seeing a *conditional* detach(), but I suppose that if the
> conditional is false you don't want the data and the AutoTUnref will take care
> of it at the end of the scope.

Acknowledged.

https://codereview.chromium.org/1110533002/diff/1/src/pdf/SkPDFFont.cpp#newco...
src/pdf/SkPDFFont.cpp:1232: SkAutoTUnref<SkPDFStream> fontStream(new
SkPDFStream(fontData.get()));
On 2015/05/01 15:06:20, tomhudson wrote:
> Not detach()ing the fontData?

The SkPDFStream interface has not changed yet.

[hal.canary, 2015-05-05 17:17:35]

The CQ bit was checked by halcanary@google.com

[hal.canary, 2015-05-05 17:17:35]

The patchset sent to the CQ was uploaded after l-g-t-m from tomhudson@google.com
Link to the patchset: https://codereview.chromium.org/1110533002/#ps20001
(title: "detach")

[commit-bot: I haz the power, 2015-05-05 17:18:13]

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

[commit-bot: I haz the power, 2015-05-05 17:24:16]

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