Don't use writeData to write the document in GM.

Don't use writeData to write the document in GM.

SkStream::writeData writes the length then the data so that it can be re-created with SkStream::readData.

[bungeman-skia, 2013-05-05 22:32:04]

This was causing me to tear my hair out trying to figure out why the XPS
back-end wasn't working. Note that this will change all PDF files as well. It
appears that many viewers just skip some amount of garbage at the beginning of a
file until they find the 'magic'. Windows zip utilities do not do so.

[reed1, 2013-05-06 12:25:43]

lgtm

[bungeman-skia, 2013-05-06 16:07:07]

Committed revision 9013.

[epoger, 2013-05-07 15:30:29]

On 2013/05/05 22:32:04, bungeman1 wrote:
> This was causing me to tear my hair out trying to figure out why the XPS
> back-end wasn't working. Note that this will change all PDF files as well. It
> appears that many viewers just skip some amount of garbage at the beginning of
a
> file until they find the 'magic'. Windows zip utilities do not do so.

You're in good company.  But now that
https://code.google.com/p/skia/issues/detail?id=1167 ('update docs for
SkStream.readData() and SkStream.writeData() to indicate length is included')
has been fixed, hopefully we'll be seeing fewer of these in the future.

This CL obviates Edi's long-stalled https://codereview.chromium.org/12753007/
('Update gm so it doe not write the size of the pdf (writeData writes the length
of the data too)')