Add postscript path

Add postscript path

This patch adds the additional functions required to make postscript
printing functional. The most significant additions are are two added
compression functions and a new API for setting the postscript level.

Not currently called from Chromium, Chromium patch to come.

BUG=

Review-Url: https://codereview.chromium.org/2612243005
Committed: https://pdfium.googlesource.com/pdfium/+/db7647083d0a5cd2221b94faa15c149214d21725

[rbpotter, 2017-01-09 19:23:09]

Description was changed from

==========
Add postscript path

This patch adds the additional functions required to make postscript
printing functional. The most significant additions are are two added
compression functions and a new API for setting the postscript level.

Not currently called from Chromium, Chromium patch to come.

BUG=
==========

to

==========
Add postscript path

This patch adds the additional functions required to make postscript
printing functional. The most significant additions are are two added
compression functions and a new API for setting the postscript level.

Not currently called from Chromium, Chromium patch to come.

BUG=
==========

[rbpotter, 2017-01-09 19:23:09]

rbpotter@chromium.org changed reviewers:
+ dsinclair@chromium.org, tsepez@chromium.org

[rbpotter, 2017-01-09 19:47:51]

This is the second chunk of the postscript printing code (new additions to
enable different encoding functions and to allow for selection between
postscript and normal/GDI printing from Chromium).

[Tom Sepez, 2017-01-09 20:18:20]

https://codereview.chromium.org/2612243005/diff/20001/core/fxcodec/codec/ccod...
File core/fxcodec/codec/ccodec_basicmodule.h (right):

https://codereview.chromium.org/2612243005/diff/20001/core/fxcodec/codec/ccod...
core/fxcodec/codec/ccodec_basicmodule.h:18: bool RunLengthEncode(const uint8_t*
src_buf,
Can we add unit_tests and/or fuzzers for these?

https://codereview.chromium.org/2612243005/diff/20001/core/fxcodec/codec/fx_c...
File core/fxcodec/codec/fx_codec.cpp (right):

https://codereview.chromium.org/2612243005/diff/20001/core/fxcodec/codec/fx_c...
core/fxcodec/codec/fx_codec.cpp:119: uint32_t est_size = 4 * src_size / 3 + 4;
Can we get a better estimate by first rounding up src_size to a multiple of 3,
eg.

est_size = 4 * ((src_size + 2) / 3) + 1

https://codereview.chromium.org/2612243005/diff/20001/core/fxcodec/codec/fx_c...
core/fxcodec/codec/fx_codec.cpp:128: while (run_end < src_size) {
I'm having trouble following all of this, maybe it's clearer as a state machine
where we pick up one new byte on each iteration and do something.  Maybe not. 
Hmm.

https://codereview.chromium.org/2612243005/diff/20001/core/fxcodec/codec/fx_c...
core/fxcodec/codec/fx_codec.cpp:129: uint32_t max_len = run_start + 128 <
src_size ? 128 : src_size - run_start;
nit: maybe std::min(src_size - run_start, 128);

https://codereview.chromium.org/2612243005/diff/20001/core/fxcodec/codec/fx_c...
core/fxcodec/codec/fx_codec.cpp:130: while (x == y && ((run_end - run_start) <
max_len - 1))
Can max_len be 0 here?
nit: overparenthesized.

https://codereview.chromium.org/2612243005/diff/20001/core/fxcodec/codec/fx_c...
core/fxcodec/codec/fx_codec.cpp:132: // Reached end with matched run. Update
variables to expected values.
nit: maybe blank line here.

https://codereview.chromium.org/2612243005/diff/20001/core/fxcodec/codec/fx_c...
core/fxcodec/codec/fx_codec.cpp:151: out[(run_end - run_start)] = x;
nit: overparenthesized, couple places.

https://codereview.chromium.org/2612243005/diff/20001/core/fxcodec/codec/fx_c...
core/fxcodec/codec/fx_codec.cpp:178: static const uint64_t a[4] = {256 * 256 *
256, 256 * 256, 256, 1};
Can we put these into an empty namespace up top, lose the static, and use more
descriptive names?

https://codereview.chromium.org/2612243005/diff/20001/core/fxcodec/codec/fx_c...
core/fxcodec/codec/fx_codec.cpp:193: // 2 character new lines each 75 output
chars = 2*5*src/(4*75), + 2
nit: this might read clearer without = = 2*5*src/(4*75), and if we wrote "plus"
instead of "+" in the comment.

https://codereview.chromium.org/2612243005/diff/20001/core/fxcodec/codec/fx_c...
core/fxcodec/codec/fx_codec.cpp:203: uint64_t val = (uint64_t)(src_buf[pos]) *
A85Encode::a[0] +
nit: casst not needed, we're multiplying a uint8_t by a uint64_t, which will
promote to uint64_t.  Also, can't we just assemble this with some shifts rather
than multiplying?

https://codereview.chromium.org/2612243005/diff/20001/core/fxcodec/codec/fx_c...
core/fxcodec/codec/fx_codec.cpp:203: uint64_t val = (uint64_t)(src_buf[pos]) *
A85Encode::a[0] +
Wouldn't this also fit into a uint32_t ?

https://codereview.chromium.org/2612243005/diff/20001/core/fxcodec/codec/fx_c...
core/fxcodec/codec/fx_codec.cpp:213: uint64_t c1 = val / A85Encode::b[0];
I would imagine we just take c = val % 85 and val = val / 85 at each step rather
using these big constants.  We may have to assign in the opposite order ...

https://codereview.chromium.org/2612243005/diff/20001/core/fxcodec/codec/fx_c...
core/fxcodec/codec/fx_codec.cpp:230: *out = '\r';
nit: 
*out++ = '\r';
*out++ = '\n';
line_length = 0;

https://codereview.chromium.org/2612243005/diff/20001/core/fxge/win32/fx_win3...
File core/fxge/win32/fx_win32_device.cpp (right):

https://codereview.chromium.org/2612243005/diff/20001/core/fxge/win32/fx_win3...
core/fxge/win32/fx_win32_device.cpp:1395: } else {
nit: else after return not needed.

https://codereview.chromium.org/2612243005/diff/20001/fpdfsdk/fpdfview.cpp
File fpdfsdk/fpdfview.cpp (right):

https://codereview.chromium.org/2612243005/diff/20001/fpdfsdk/fpdfview.cpp#ne...
fpdfsdk/fpdfview.cpp:445: g_pdfium_print_postscript_level = postscript_level;
Do we want to validate this and return an error if the level doesn't make sense?

[rbpotter, 2017-01-10 20:28:24]

Made changes and added unit tests for the encoding functions. I will look into
fuzzers for them now, but since it may take time (I haven't written fuzzers
before), I wanted to get the rest of the changes + tests up so that you can take
another look.

https://codereview.chromium.org/2612243005/diff/20001/core/fxcodec/codec/ccod...
File core/fxcodec/codec/ccodec_basicmodule.h (right):

https://codereview.chromium.org/2612243005/diff/20001/core/fxcodec/codec/ccod...
core/fxcodec/codec/ccodec_basicmodule.h:18: bool RunLengthEncode(const uint8_t*
src_buf,
On 2017/01/09 20:18:19, Tom Sepez wrote:
> Can we add unit_tests and/or fuzzers for these?

I added some unit tests. Will look into fuzzers.

https://codereview.chromium.org/2612243005/diff/20001/core/fxcodec/codec/fx_c...
File core/fxcodec/codec/fx_codec.cpp (right):

https://codereview.chromium.org/2612243005/diff/20001/core/fxcodec/codec/fx_c...
core/fxcodec/codec/fx_codec.cpp:119: uint32_t est_size = 4 * src_size / 3 + 4;
On 2017/01/09 20:18:19, Tom Sepez wrote:
> Can we get a better estimate by first rounding up src_size to a multiple of 3,
> eg.
> 
> est_size = 4 * ((src_size + 2) / 3) + 1

Done.

https://codereview.chromium.org/2612243005/diff/20001/core/fxcodec/codec/fx_c...
core/fxcodec/codec/fx_codec.cpp:129: uint32_t max_len = run_start + 128 <
src_size ? 128 : src_size - run_start;
On 2017/01/09 20:18:19, Tom Sepez wrote:
> nit: maybe std::min(src_size - run_start, 128);

Done.

https://codereview.chromium.org/2612243005/diff/20001/core/fxcodec/codec/fx_c...
core/fxcodec/codec/fx_codec.cpp:130: while (x == y && ((run_end - run_start) <
max_len - 1))
On 2017/01/09 20:18:19, Tom Sepez wrote:
> Can max_len be 0 here?
> nit: overparenthesized.

Should not be. run_end is always at least one ahead of run_start, so since
run_end < src_size, run_start + 1 < src_size, so src_size - run_start > 1. The
case of a length 1 input is handled above to prevent a possible issue with this,
and leftover single bytes are handled after the loop.

https://codereview.chromium.org/2612243005/diff/20001/core/fxcodec/codec/fx_c...
core/fxcodec/codec/fx_codec.cpp:132: // Reached end with matched run. Update
variables to expected values.
On 2017/01/09 20:18:19, Tom Sepez wrote:
> nit: maybe blank line here.

Done.

https://codereview.chromium.org/2612243005/diff/20001/core/fxcodec/codec/fx_c...
core/fxcodec/codec/fx_codec.cpp:151: out[(run_end - run_start)] = x;
On 2017/01/09 20:18:20, Tom Sepez wrote:
> nit: overparenthesized, couple places.

Done.

https://codereview.chromium.org/2612243005/diff/20001/core/fxcodec/codec/fx_c...
core/fxcodec/codec/fx_codec.cpp:178: static const uint64_t a[4] = {256 * 256 *
256, 256 * 256, 256, 1};
On 2017/01/09 20:18:20, Tom Sepez wrote:
> Can we put these into an empty namespace up top, lose the static, and use more
> descriptive names?

Done.

https://codereview.chromium.org/2612243005/diff/20001/core/fxcodec/codec/fx_c...
core/fxcodec/codec/fx_codec.cpp:193: // 2 character new lines each 75 output
chars = 2*5*src/(4*75), + 2
On 2017/01/09 20:18:19, Tom Sepez wrote:
> nit: this might read clearer without = = 2*5*src/(4*75), and if we wrote
"plus"
> instead of "+" in the comment.

Done.

https://codereview.chromium.org/2612243005/diff/20001/core/fxcodec/codec/fx_c...
core/fxcodec/codec/fx_codec.cpp:203: uint64_t val = (uint64_t)(src_buf[pos]) *
A85Encode::a[0] +
On 2017/01/09 20:18:19, Tom Sepez wrote:
> nit: casst not needed, we're multiplying a uint8_t by a uint64_t, which will
> promote to uint64_t.  Also, can't we just assemble this with some shifts
rather
> than multiplying?

Done.

https://codereview.chromium.org/2612243005/diff/20001/core/fxcodec/codec/fx_c...
core/fxcodec/codec/fx_codec.cpp:203: uint64_t val = (uint64_t)(src_buf[pos]) *
A85Encode::a[0] +
On 2017/01/09 20:18:19, Tom Sepez wrote:
> Wouldn't this also fit into a uint32_t ?

Done.

https://codereview.chromium.org/2612243005/diff/20001/core/fxcodec/codec/fx_c...
core/fxcodec/codec/fx_codec.cpp:203: uint64_t val = (uint64_t)(src_buf[pos]) *
A85Encode::a[0] +
On 2017/01/09 20:18:19, Tom Sepez wrote:
> nit: casst not needed, we're multiplying a uint8_t by a uint64_t, which will
> promote to uint64_t.  Also, can't we just assemble this with some shifts
rather
> than multiplying?

Changed this to shifts, but had to keep the cast to make that work.

https://codereview.chromium.org/2612243005/diff/20001/core/fxcodec/codec/fx_c...
core/fxcodec/codec/fx_codec.cpp:213: uint64_t c1 = val / A85Encode::b[0];
On 2017/01/09 20:18:19, Tom Sepez wrote:
> I would imagine we just take c = val % 85 and val = val / 85 at each step
rather
> using these big constants.  We may have to assign in the opposite order ...

Done. I was trying to avoid calling %, but this is a lot cleaner.

https://codereview.chromium.org/2612243005/diff/20001/core/fxcodec/codec/fx_c...
core/fxcodec/codec/fx_codec.cpp:230: *out = '\r';
On 2017/01/09 20:18:19, Tom Sepez wrote:
> nit: 
> *out++ = '\r';
> *out++ = '\n';
> line_length = 0;

Done.

https://codereview.chromium.org/2612243005/diff/20001/core/fxge/win32/fx_win3...
File core/fxge/win32/fx_win32_device.cpp (right):

https://codereview.chromium.org/2612243005/diff/20001/core/fxge/win32/fx_win3...
core/fxge/win32/fx_win32_device.cpp:1395: } else {
On 2017/01/09 20:18:20, Tom Sepez wrote:
> nit: else after return not needed.

Done.

https://codereview.chromium.org/2612243005/diff/20001/fpdfsdk/fpdfview.cpp
File fpdfsdk/fpdfview.cpp (right):

https://codereview.chromium.org/2612243005/diff/20001/fpdfsdk/fpdfview.cpp#ne...
fpdfsdk/fpdfview.cpp:445: g_pdfium_print_postscript_level = postscript_level;
On 2017/01/09 20:18:20, Tom Sepez wrote:
> Do we want to validate this and return an error if the level doesn't make
sense?

Done.

[Tom Sepez, 2017-01-10 21:08:42]

I like your tests.

https://codereview.chromium.org/2612243005/diff/20001/core/fxcodec/codec/fx_c...
File core/fxcodec/codec/fx_codec.cpp (right):

https://codereview.chromium.org/2612243005/diff/20001/core/fxcodec/codec/fx_c...
core/fxcodec/codec/fx_codec.cpp:203: uint64_t val = (uint64_t)(src_buf[pos]) *
A85Encode::a[0] +
On 2017/01/10 20:28:24, rbpotter wrote:
> On 2017/01/09 20:18:19, Tom Sepez wrote:
> > nit: casst not needed, we're multiplying a uint8_t by a uint64_t, which will
> > promote to uint64_t.  Also, can't we just assemble this with some shifts
> rather
> > than multiplying?
> 
> Changed this to shifts, but had to keep the cast to make that work.

Right.  When we go to shifts, we lose the other big unsigned operand, so the
default promotion of uint8_t will now fit into a signed int, and we may end up
shifting into a sign bit ...

https://codereview.chromium.org/2612243005/diff/40001/core/fxcodec/codec/fx_c...
File core/fxcodec/codec/fx_codec_a85_unittest.cpp (right):

https://codereview.chromium.org/2612243005/diff/40001/core/fxcodec/codec/fx_c...
core/fxcodec/codec/fx_codec_a85_unittest.cpp:50: EXPECT_EQ(dest_buf[i],
expected_out[i]);
nit: I like to write
EXPECT_EQ(dest_buf[i], expected_out[i]) << " at " << i;

So when this fails, we know the index that caused the issue.

https://codereview.chromium.org/2612243005/diff/40001/core/fxcodec/codec/fx_c...
core/fxcodec/codec/fx_codec_a85_unittest.cpp:51: delete (dest_buf);
FX_Free() is the inverse of FX_Alloc() and needs to be called throughout in
place of delete.

https://codereview.chromium.org/2612243005/diff/40001/core/fxcodec/codec/fx_c...
File core/fxcodec/codec/fx_codec_rle_unittest.cpp (right):

https://codereview.chromium.org/2612243005/diff/40001/core/fxcodec/codec/fx_c...
core/fxcodec/codec/fx_codec_rle_unittest.cpp:80: delete (dest_buf);
FX_Free() here too and throughout.

https://codereview.chromium.org/2612243005/diff/40001/core/fxge/win32/cfx_psr...
File core/fxge/win32/cfx_psrenderer.cpp (right):

https://codereview.chromium.org/2612243005/diff/40001/core/fxge/win32/cfx_psr...
core/fxge/win32/cfx_psrenderer.cpp:459: if ((/*m_PSLevel == 2 || */ flags &
FXRENDER_IMAGE_LOSSY) &&
Just remove it, we have source control if we want to go back in time ...

https://codereview.chromium.org/2612243005/diff/40001/public/fpdfview.h
File public/fpdfview.h (right):

https://codereview.chromium.org/2612243005/diff/40001/public/fpdfview.h#newco...
public/fpdfview.h:254: //          True if successful, false if unsucessful
(indicates invalid input).
nit: (typically invalid input)
since we don't know all the reasons this might blow up.

[rbpotter, 2017-01-11 20:34:50]

Added fuzzers. Let me know if I missed something when writing them. Also fixed
comments from last patchset. 

Also, is there any way to build and run the fuzzers in a pdfium standalone repo?
I had to build/test them from a chromium directory.

https://codereview.chromium.org/2612243005/diff/40001/core/fxcodec/codec/fx_c...
File core/fxcodec/codec/fx_codec_a85_unittest.cpp (right):

https://codereview.chromium.org/2612243005/diff/40001/core/fxcodec/codec/fx_c...
core/fxcodec/codec/fx_codec_a85_unittest.cpp:50: EXPECT_EQ(dest_buf[i],
expected_out[i]);
On 2017/01/10 21:08:41, Tom Sepez wrote:
> nit: I like to write
> EXPECT_EQ(dest_buf[i], expected_out[i]) << " at " << i;
> 
> So when this fails, we know the index that caused the issue.

Done.

https://codereview.chromium.org/2612243005/diff/40001/core/fxcodec/codec/fx_c...
core/fxcodec/codec/fx_codec_a85_unittest.cpp:51: delete (dest_buf);
On 2017/01/10 21:08:41, Tom Sepez wrote:
> FX_Free() is the inverse of FX_Alloc() and needs to be called throughout in
> place of delete.

Done.

https://codereview.chromium.org/2612243005/diff/40001/core/fxcodec/codec/fx_c...
File core/fxcodec/codec/fx_codec_rle_unittest.cpp (right):

https://codereview.chromium.org/2612243005/diff/40001/core/fxcodec/codec/fx_c...
core/fxcodec/codec/fx_codec_rle_unittest.cpp:80: delete (dest_buf);
On 2017/01/10 21:08:41, Tom Sepez wrote:
> FX_Free() here too and throughout.

Done.

https://codereview.chromium.org/2612243005/diff/40001/core/fxge/win32/cfx_psr...
File core/fxge/win32/cfx_psrenderer.cpp (right):

https://codereview.chromium.org/2612243005/diff/40001/core/fxge/win32/cfx_psr...
core/fxge/win32/cfx_psrenderer.cpp:459: if ((/*m_PSLevel == 2 || */ flags &
FXRENDER_IMAGE_LOSSY) &&
On 2017/01/10 21:08:41, Tom Sepez wrote:
> Just remove it, we have source control if we want to go back in time ...

This was actually commented out to test something, should actually stay the way
it was. Sorry about that.

https://codereview.chromium.org/2612243005/diff/40001/public/fpdfview.h
File public/fpdfview.h (right):

https://codereview.chromium.org/2612243005/diff/40001/public/fpdfview.h#newco...
public/fpdfview.h:254: //          True if successful, false if unsucessful
(indicates invalid input).
On 2017/01/10 21:08:41, Tom Sepez wrote:
> nit: (typically invalid input)
> since we don't know all the reasons this might blow up.

Done.

[Tom Sepez, 2017-01-11 21:09:08]

Correct, the only way to build the fuzzers is part of a chromium checkout, not a
standalone checkout.  Changing this would require pulling a lot of custom stuff
into the pdfium checkouts ...

https://codereview.chromium.org/2612243005/diff/80001/core/fxcodec/codec/fx_c...
File core/fxcodec/codec/fx_codec_a85_unittest.cpp (right):

https://codereview.chromium.org/2612243005/diff/80001/core/fxcodec/codec/fx_c...
core/fxcodec/codec/fx_codec_a85_unittest.cpp:70: EXPECT_EQ(dest_size,
expected_size);
nit: typically we write this as 
  EXPECT_EQ(9u, dest_size)
with the expected first as a literal (with the unsigned u modifier) if needed.

[Tom Sepez, 2017-01-11 21:09:18]

lgtm

[rbpotter, 2017-01-11 22:06:17]

The CQ bit was checked by rbpotter@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-11 22:06:18]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-11 22:08:08]

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

[commit-bot: I haz the power, 2017-01-11 22:08:09]

Dry run: Try jobs failed on following builders:
  linux_xfa_asan_lsan on master.tryserver.client.pdfium (JOB_FAILED,
https://build.chromium.org/p/tryserver.client.pdfium/builders/linux_xfa_asan_...)
  win_xfa on master.tryserver.client.pdfium (JOB_FAILED,
https://build.chromium.org/p/tryserver.client.pdfium/builders/win_xfa/builds/...)

[rbpotter, 2017-01-11 22:22:35]

The CQ bit was checked by rbpotter@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-11 22:22:38]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-11 22:36:46]

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

[commit-bot: I haz the power, 2017-01-11 22:36:47]

Dry run: Try jobs failed on following builders:
  linux_asan_lsan on master.tryserver.client.pdfium (JOB_FAILED,
https://build.chromium.org/p/tryserver.client.pdfium/builders/linux_asan_lsan...)

[rbpotter, 2017-01-11 22:38:12]

The CQ bit was checked by rbpotter@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-11 22:38:16]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-11 22:54:26]

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

[commit-bot: I haz the power, 2017-01-11 22:54:27]

Dry run: This issue passed the CQ dry run.

[rbpotter, 2017-01-11 22:56:00]

Think this is ready to land. Let me know if there are any remaining issues.

https://codereview.chromium.org/2612243005/diff/80001/core/fxcodec/codec/fx_c...
File core/fxcodec/codec/fx_codec_a85_unittest.cpp (right):

https://codereview.chromium.org/2612243005/diff/80001/core/fxcodec/codec/fx_c...
core/fxcodec/codec/fx_codec_a85_unittest.cpp:70: EXPECT_EQ(dest_size,
expected_size);
On 2017/01/11 21:09:08, Tom Sepez wrote:
> nit: typically we write this as 
>   EXPECT_EQ(9u, dest_size)
> with the expected first as a literal (with the unsigned u modifier) if needed.

Done.

[rbpotter, 2017-01-11 23:03:15]

The CQ bit was checked by rbpotter@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-11 23:03:23]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-11 23:16:53]

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

[commit-bot: I haz the power, 2017-01-11 23:16:54]

Dry run: This issue passed the CQ dry run.

[rbpotter, 2017-01-12 18:31:17]

The CQ bit was checked by rbpotter@chromium.org

[rbpotter, 2017-01-12 18:31:17]

The patchset sent to the CQ was uploaded after l-g-t-m from tsepez@chromium.org
Link to the patchset: https://codereview.chromium.org/2612243005/#ps160001
(title: "Get rid of extra declarations")

[commit-bot: I haz the power, 2017-01-12 18:31:29]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-12 18:31:43]

CQ is committing da patch.

Bot data: {"patchset_id": 160001, "attempt_start_ts": 1484245877065110,
"parent_rev": "e7fb8eb3e9f220a5f0c852f0238ab8d536a8bc9d", "commit_rev":
"db7647083d0a5cd2221b94faa15c149214d21725"}

[commit-bot: I haz the power, 2017-01-12 18:31:47]

Description was changed from

==========
Add postscript path

This patch adds the additional functions required to make postscript
printing functional. The most significant additions are are two added
compression functions and a new API for setting the postscript level.

Not currently called from Chromium, Chromium patch to come.

BUG=
==========

to

==========
Add postscript path

This patch adds the additional functions required to make postscript
printing functional. The most significant additions are are two added
compression functions and a new API for setting the postscript level.

Not currently called from Chromium, Chromium patch to come.

BUG=

Review-Url: https://codereview.chromium.org/2612243005
Committed:
https://pdfium.googlesource.com/pdfium/+/db7647083d0a5cd2221b94faa15c149214d2...
==========

[commit-bot: I haz the power, 2017-01-12 18:31:48]

Committed patchset #9 (id:160001) as
https://pdfium.googlesource.com/pdfium/+/db7647083d0a5cd2221b94faa15c149214d2...

[Lei Zhang, 2017-02-25 02:01:26]

On 2017/01/11 21:09:08, Tom Sepez wrote:
> Correct, the only way to build the fuzzers is part of a chromium checkout, not
a
> standalone checkout.  Changing this would require pulling a lot of custom
stuff
> into the pdfium checkouts ...

Though we do build the fuzzer .cc files, because we had too many PDFium DEPS
roll failures when we didn't. See https://codereview.chromium.org/2481933003