Update pdfium/annots/annotation_square_fill_negative_border_expected.pdf.0.png.

Update pdfium/annots/annotation_square_fill_negative_border_expected.pdf.0.png.

R=thestig@chromium.org

Committed: https://pdfium.googlesource.com/pdfium_tests/+/7f07c2223bfb8114dc5060ecdc51793bba1c90d4

[jaepark, 2016-08-08 17:18:28]

jaepark@google.com changed reviewers:
+ thestig@chromium.org

[jaepark, 2016-08-08 17:18:28]

Updated test case after modifying implementation about negative border width in
https://codereview.chromium.org/2219683002/ .

[Lei Zhang, 2016-08-08 19:36:19]

It's not obvious to the eyeball what the difference is.

[jaepark, 2016-08-08 21:52:03]

On 2016/08/08 19:36:19, Lei Zhang wrote:
> It's not obvious to the eyeball what the difference is.

There is a small difference due to floating point operation.

Although deflating with negative number (discussed in
https://codereview.chromium.org/2219683002/) increases the area of the rectangle
in all four sides, the rectangle is bounded by the "Rect" field in annotation
dictionary when actually drawn using the AP stream. So, if the rect specified in
the AP stream is larger than the size of the "Rect" field, it will just try to
fill the whole "Rect". When doing this operation, there can be floating point
rounding difference, which is causing a slight difference when rendered.

[Lei Zhang, 2016-08-08 22:21:32]

lgtm

[jaepark, 2016-08-08 22:41:08]

Description was changed from

==========
Update pdfium/annots/annotation_square_fill_negative_border_expected.pdf.0.png.
==========

to

==========
Update pdfium/annots/annotation_square_fill_negative_border_expected.pdf.0.png.

R=thestig@chromium.org

Committed:
https://pdfium.googlesource.com/pdfium_tests/+/7f07c2223bfb8114dc5060ecdc5179...
==========

[jaepark, 2016-08-08 22:41:10]

Committed patchset #1 (id:1) manually as
7f07c2223bfb8114dc5060ecdc51793bba1c90d4 (presubmit successful).