SkPDF: SkPDFString is no longer aware of wide strings.

SkPDF: SkPDFString is no longer aware of wide strings.

Since wide strings are only used in SkPDFDevice, I have moved the
function that manages them to that directory.

Motivation: The SkPDFString will be refactored later along with the
other SkPFObject heirarchy.

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

[hal.canary, 2015-04-07 14:49:26]

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

[hal.canary, 2015-04-07 14:49:27]

PTAL

[tomhudson, 2015-04-07 15:08:24]

LGTM modulo these comments on comments.

(Also FormatString() clearly could be sped up if it's ever a bottleneck, but
until then it should work fine as-is.)

https://codereview.chromium.org/1064013003/diff/20001/src/pdf/SkPDFDevice.cpp
File src/pdf/SkPDFDevice.cpp (right):

https://codereview.chromium.org/1064013003/diff/20001/src/pdf/SkPDFDevice.cpp...
src/pdf/SkPDFDevice.cpp:1055: //  @param value     A string value.
This parameter is now named 'input', not 'value'.
"A string value" is not a useful comment; tell me the *semantics* of the
parameter.

https://codereview.chromium.org/1064013003/diff/20001/src/pdf/SkPDFDevice.cpp...
src/pdf/SkPDFDevice.cpp:1057: //  @param wideChars Indicates if the top byte in
value is significant and
Is the 'top' byte the first byte? If this is only talking about one byte, why is
it plural?

https://codereview.chromium.org/1064013003/diff/20001/src/pdf/SkPDFDevice.cpp...
src/pdf/SkPDFDevice.cpp:1058: //                   should be encoded (true) or
not (false).
Nit: other comments need name of 'input' fixed.

[hal.canary, 2015-04-07 17:32:51]

On 2015/04/07 15:08:24, tomhudson wrote:
> (Also FormatString() clearly could be sped up if it's ever a bottleneck, but
> until then it should work fine as-is.)

It was bugging me, so I re-worked it to allocate memory ahead of time.
The SkString append is conservative in memory allocation.

[hal.canary, 2015-04-07 17:32:57]

https://codereview.chromium.org/1064013003/diff/20001/src/pdf/SkPDFDevice.cpp
File src/pdf/SkPDFDevice.cpp (right):

https://codereview.chromium.org/1064013003/diff/20001/src/pdf/SkPDFDevice.cpp...
src/pdf/SkPDFDevice.cpp:1055: //  @param value     A string value.
On 2015/04/07 15:08:23, tomhudson wrote:
> This parameter is now named 'input', not 'value'.
> "A string value" is not a useful comment; tell me the *semantics* of the
> parameter.

Done.

https://codereview.chromium.org/1064013003/diff/20001/src/pdf/SkPDFDevice.cpp...
src/pdf/SkPDFDevice.cpp:1057: //  @param wideChars Indicates if the top byte in
value is significant and
On 2015/04/07 15:08:23, tomhudson wrote:
> Is the 'top' byte the first byte? If this is only talking about one byte, why
is
> it plural?

Done.

https://codereview.chromium.org/1064013003/diff/20001/src/pdf/SkPDFDevice.cpp...
src/pdf/SkPDFDevice.cpp:1058: //                   should be encoded (true) or
not (false).
On 2015/04/07 15:08:23, tomhudson wrote:
> Nit: other comments need name of 'input' fixed.

Done.

[hal.canary, 2015-04-07 17:33:18]

The CQ bit was checked by halcanary@google.com

[hal.canary, 2015-04-07 17:33:19]

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/1064013003/#ps60001
(title: "optimize SkPDFString::FormatString, stop appending everywhere")

[commit-bot: I haz the power, 2015-04-07 17:33:31]

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

[commit-bot: I haz the power, 2015-04-07 17:40:07]

Committed patchset #4 (id:60001) as
https://skia.googlesource.com/skia/+/bb264b775004be3df72f0bb5ee613761a328a6c3

[tomhudson, 2015-04-07 17:40:21]

lgtm