When scaling PDF pages to custom sizes the resulting pixmaps are not sized correctly. Reversing this commit fixes the problem. I can provide more details if necessary. --- a/fitz/base_geometry.c +++ b/fitz/base_geometry.c @@ -153,11 +153,10 @@ fz_bbox fz_round_rect(fz_rect f) { fz_bbox i; - /* adjust by 0.001 to compensate for precision errors */ - f.x0 = floorf(f.x0 + 0.001f); - f.y0 = floorf(f.y0 + 0.001f); - f.x1 = ceilf(f.x1 - 0.001f); - f.y1 = ceilf(f.y1 - 0.001f); + f.x0 = floorf(f.x0 + FLT_EPSILON); + f.y0 = floorf(f.y0 + FLT_EPSILON); + f.x1 = ceilf(f.x1 - FLT_EPSILON); + f.y1 = ceilf(f.y1 - FLT_EPSILON); #define SAFE_INT(f) ((f > INT_MAX) ? INT_MAX : ((f < INT_MIN) ? INT_MIN : (int)f)) i.x0 = SAFE_INT(f.x0); i.y0 = SAFE_INT(f.y0); author Tor Andersson <tor.andersson@artifex.com> Wed, 11 Jan 2012 14:31:34 +0000 (15:31 +0100) committer Tor Andersson <tor.andersson@artifex.com> Wed, 11 Jan 2012 15:01:29 +0000 (16:01 +0100) commit 220b6f3565b8ec6da406acc08e8f09128b7c7346 tree 64de28a72978c18d49da2756bb58c73694d7697b tree | snapshot parent 02ffa5b15d37cc86964666c78446433f31a15911 commit | diff
> I can provide more details in necessary. Well, yes please. At least enough information for us to be able to recreate the problem; if we can't recreate the problem it's hard to solve it.
(In reply to comment #1) > > I can provide more details in necessary. > > Well, yes please. At least enough information for us to be able to recreate the > problem; if we can't recreate the problem it's hard to solve it. Ok. Hopefully you can make sense of this. Basically I have an 8.5x11" PDF (612,792 - 0 rotation) that I want to render at 2592x3354. I use the following code: fz_matrix ctm = fz_scale(zoomX, zoomY); //zoomX = 4.2352943 //zoomY = 4.2348485 ctm = fz_concat(ctm, fz_rotate(rotation)); //rotation = 0 bbox = fz_round_rect(fz_transform_rect(ctm, bounds)); //bounds = 0,0,612,792 Th original rect passed into fz_round_rect is this: rect = 0,0,2592.0002,3354.0000 I expect the output after fz_round_rect to be: bbox = 0,0,2592,3354 But it rounds .0002 up to 2593 and outputs this: bbox = 0,0,2593,3354 Reversing the commit above I get the correct rounding.
Thanks Dan. I did some experiments and saw the same thing happen for me when implementing -w and -h in mudraw. We now have 2 separate functions, so fz_round_rect should behave as you want. Thanks. commit 5409d2f3ba310b59074ec590ea69ecd423653d85 Author: Robin Watts <robin.watts@artifex.com> Date: Thu Mar 15 20:12:18 2012 +0000 Bug 692805: BBox rounding issues Currently all conversions from rect to bbox are done using a single function, fz_round_rect. This causes problems, as sometimes we want 'round, allowing for slight calculation errors' and sometimes we want 'round slavishly to ensure we have a bbox that covers the rect'. We therefore split these 2 cases into 2 separate functions; fz_round_rect is kept, meaning "round outwards allowing for slight errors", and fz_bbox_covering_rect is added to mean "give us the smallest bbox that is guaranteed to cover rect". No regressions seen.