Jump to content
You must now use your email address to sign in [click for more info] ×

Export document size is incorrect when using the Include Bleed option


Recommended Posts

Hi,

I had an unexpected behavior when creating a document that was 6.75” x 10.25” with a 0.125” bleed. I tested with other document sizes and the behavior is repeatable.

If the bleed value is not a whole number (in pixels), the exported document size is incorrect when the “Include Bleed” option is selected.

For example, if a 300 DPI document has a 0.125 inch bleed, then this is equivalent to a 37.5 pixels bleed.

When the document is exported, and “Include Bleed” is selected, the size (in pixels) is incorrect — it’s one pixel less than expected.

The size should be equal to the “Dimensions” size (from the “Spread Setup” ) plus 75 pixels (i.e. 37.5 + 37.5). Instead, it is equal to the “Dimensions” size plus 74 pixels. The bleed value of 37.5 appears to get truncated to 37.

 

To recreate the behavior, do the following.

Create a new document.

Set documents units to PIXELS.

Set the PAGE WIDTH = 2025 px.

Set PAGE HEIGHT = 3075 px.

Set the BLEED = 37.5 px on all sides.

This should create a document that is 2100 pixels x 3150 pixels including the bleed. (i.e. 2025 + 37.5 + 37.5 = 2100 and 3075 + 37.5 + 37.5 = 3150).

Select EXPORT from the FILE menu.

Select the PNG file type and check the “Include Bleed” box.

Observe the size is 2099 x 3149 and not 2100 x 3150 as expected.

Thanks,

Matt

Link to comment
Share on other sites

You can't have half a pixel in a raster image.

A pixel is by definition the smallest unit possible.

Each edge of the bleed would need a whole number of pixels.  If you round 37.5 down you wind up with 37 * 2 = 74 pixels total; if you round it up you get 38 * 2 = 76 pixels total, so 75 pixels would not be a technically valid outcome here.  Either 74 or 76 would be equally valid, so what Publisher is giving you seems to be perfectly fine.

 

Link to comment
Share on other sites

Thanks for the response. I understand that a fraction of a pixel isn’t really valid. Whenever a document’s settings result in a value like 37.5, Publisher has to do *something* to make the output size equal to a whole number.

I described this as “unexpected behavior” rather than a bug because it isn’t really clear to me how a fraction of a pixel should be handled.

 

The “unexpected” part is this:

A document that is 6.75” x 10.25” at 300 DPI is exactly 2025 pixels x 3075 pixels.

A bleed of 0.125 on all sides adds exactly 75 pixels to the height and width.

So I would reasonably expect the total exported size to be exactly 7” x 10.5” which is exactly 2100 pixels x 3150 pixels. Instead I see 2099 x 3149.

 

But again, Publisher has to do *something* to solve the “half pixel” problem in situations like this.

So I guess my question is this: does it make sense for Publisher to just truncate the bleed value to a whole number (37 in this case) and lose a whole pixel in the overall size? Or would it make more sense to make one side 37 pixels and the other side 38 pixels? The two sides wouldn’t be exactly even but the overall size would be correct.

If truncating makes the most sense, then maybe the bleed values on the Document Setup page should only display whole pixels.

Link to comment
Share on other sites

9 hours ago, Mokkery said:

would it make more sense to make one side 37 pixels and the other side 38 pixels? The two sides wouldn’t be exactly even but the overall size would be correct.

Yes, but the resulting page image would be a half pixel off center.  :35_thinking:

 

I think again that either approach is valid so it was a judgement call on the part of the developers on how to handle this.

 

9 hours ago, Mokkery said:

If truncating makes the most sense, then maybe the bleed values on the Document Setup page should only display whole pixels.

I suspect this comes from the document units, and if you set the document size in terms of pixels you might be able to get this effect?  I don't have it in front of me at the moment to verify that.

Link to comment
Share on other sites

×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.