When normalize coordinate, return instead of assert() when divide by 0

When normalize coordinate, return instead of assert() when divide by 0

BUG=382988
R=tsepez@chromium.org

Committed: https://pdfium.googlesource.com/pdfium/+/fda0d42

[Tom Sepez, 2014-08-04 17:09:38]

https://codereview.chromium.org/433293002/diff/1/core/include/fxcrt/fx_coordi...
File core/include/fxcrt/fx_coordinates.h (right):

https://codereview.chromium.org/433293002/diff/1/core/include/fxcrt/fx_coordi...
core/include/fxcrt/fx_coordinates.h:159: if (fLen < 0.0001f) {
Isn't .0001f a kinda large value for near-zero? I'd expect you could get a few
more sig digits here.

Do we want to set both x and y to something (like 0.0) when the length is 0?

[Bo Xu, 2014-08-04 18:48:09]

https://codereview.chromium.org/433293002/diff/1/core/include/fxcrt/fx_coordi...
File core/include/fxcrt/fx_coordinates.h (right):

https://codereview.chromium.org/433293002/diff/1/core/include/fxcrt/fx_coordi...
core/include/fxcrt/fx_coordinates.h:159: if (fLen < 0.0001f) {
On 2014/08/04 17:09:38, Tom Sepez wrote:
> Isn't .0001f a kinda large value for near-zero? I'd expect you could get a few
> more sig digits here.
> 
> Do we want to set both x and y to something (like 0.0) when the length is 0?

For some fuzz test, the x, and y are set to be really large values like over
1e20. After some matrix transformation, the fLen is computed to -1.#IND0004 or
-1.#INF0004. In these situations, I think we should leave these values there for
later application processing but not change to zero.

I can check with the devs on the 0.0001f, but this number is for the objects
spacing in PDF and 0.00001f is a reasonable "0" for a spacing in the PDF world.

[Tom Sepez, 2014-08-05 17:21:17]

OK, LGTM then.

[Bo Xu, 2014-08-08 02:01:42]

Committed patchset #1 manually as fda0d42 (presubmit successful).