Artboard size is different than output size

[Andy05]

19 minutes ago, R C-R said:

I don't know what you mean by "this." As the OP's example in the first post shows, the artboard is not being cropped. Instead, it is being enlarged to include what would otherwise be lost if it was cropped to eliminate the 0.2 px X position offset.

So wanted or not, it must do one or the other (crop or enlarge) during export. Either one of necessity changes the dimensions. There is no way to avoid this when fractional pixels are involved. The only way to avoid that is -- as both @MEB & @Old Bruce have mentioned -- is to eliminate all the fractional pixel parts (in X, Y, W, & H), either by rounding up or down to the nearest whole pixel value.

See my quote and you'll see what I meant by "this". You showed two solutions, crop or resize. We're on the same level that far. But those are two different solutions actually: crop = correct and resize = wrong. A resized export can never be the correct solution. That's what I meant since the very beginning.

[R C-R]

Just now, Andy05 said:

But those are two different solutions actually: crop = correct and resize = wrong. A resized export can never be the correct solution. That's what I meant since the very beginning.

You seem to be ignoring that both solutions resize the export! One makes it larger & the other smaller. So if a resized export is wrong, neither one can be a correct solution.

[Andy05]

2 minutes ago, R C-R said:

You seem to be ignoring that both solutions resize the export! One makes it larger & the other smaller. So if a resized export is wrong, neither one can be a correct solution.

Not at all. As for the "off-pixel" row (which isn't "fully covered due to the fraction of a pixel placement"), here's where the app might decide what to do (not on the absolute dimensions)! The app has several options here:

It could fill the pixel row with

• canvas background colour (if set)
• transparency (if set for canvas)
• semi-transparent (on canvas colour or without canvas colour) depending on the fraction of content on that pixel row.

The pixel row which exceeds the canvas' dimensions needs to get cut off (cropped).

Again: Placing something beyond the canvas' dimensions, is something which might have been done on purpose. The auto-resize of the canvas "by design" is simply not the correct solution. Just because pixels is the lowest possible unit in this scenario, it doesn't mean that the software should override the user's settings.

[R C-R]

2 minutes ago, Andy05 said:

The pixel row which exceeds the canvas' dimensions needs to get cut off (cropped).

You cannot assume this is what every user would want every time the location of an artboard (or any other object) is not pixel-aligned. It is quite possible some part of an object that would be cropped is an important or desired part of the design so it should be included rather than cropped out.

[Andy05]

8 minutes ago, R C-R said:

You cannot assume this is what every user would want every time the location of an artboard (or any other object) is not pixel-aligned. It is quite possible some part of an object that would be cropped is an important or desired part of the design so it should be included rather than cropped out.

Seriously now? Ok, if your really important 1px object is missing, you'll notice that immediately when looking at your image. Whereas you might not notice that you work with an image in your layouts, which isn't 100% the size you expected it to be.

Say what you want, auto-resizing an image on export is an absolute no-go.

[R C-R]

9 minutes ago, Andy05 said:

Say what you want, auto-resizing an image on export is an absolute no-go.

Say what you want, there is no way to export an image to anything other than to whole pixel dimensions, which by definition involves resizing it if it is not 100% aligned to whole pixel boundaries to begin with.

So for example, consider a vector rectangle shape pixel aligned to the top left edge of the artboard. So far so good, but what if that shape has a 1 px, center-aligned stroke applied to it? One half of each pixel of the stroke along the edge would be cropped off the output unless the dimensions of the output were each increased by one pixel. The same thing would happen if the stroke was center aligned & its width was set to any odd number of pixels, or to any non-integer width -- either the export's dimensions have to be increased to include all of the stroke, or lop off (crop out!) all of the stroke width that does not fit within the artboard's dimensions.

It all boils down to this: there are many situations where either the exported document or some object(s) in it must be resized. The Affinity apps give the user several ways to control that.

[Andy05]

11 minutes ago, R C-R said:

Say what you want, there is no way to export an image to anything other than to whole pixel dimensions, which by definition involves resizing it if it is not 100% aligned to whole pixel boundaries to begin with.

And that's where you're wrong. The solution is simple, I stated the options already. Crop the image (and objects) and pick one of the options for the "semi-covered" pixel row(s), because:

11 minutes ago, R C-R said:

So for example, consider a vector rectangle shape pixel aligned to the top left edge of the artboard. So far so good, but what if that shape has a 1 px, center-aligned stroke applied to it? One half of each pixel of the stroke along the edge would be cropped off the output unless the dimensions of the output were each increased by one pixel. The same thing would happen if the stroke was center aligned & its width was set to any odd number of pixels, or to any non-integer width -- either the export's dimensions have to be increased to include all of the stroke, or lop off (crop out!) all of the stroke width that does not fit within the artboard's dimensions.

Yes, they would get cropped off. And you'll notice that immediately when you work with the exported images. So, you'll see that something was off in your work. But a resized image might go unnoticed and could cause trouble later on in the layouts. 

It's way better if the exported image looks weird and off rather than "looking good", but it's (maybe unnoticed) of a different size. Neither crop nor resize might give the result you want, but you'll notice the problems with a cropped image more easily than with a slightly resized one.

That's not rocket science to understand, is it?

EDIT: BTW, great example, you gave! What if I use 501px stroke width in your example? By your logic, the app has to take those off-canvas pixels into account, too. (Why stop at 1px? Either the app is supposed to crop to objects' outer limits or not.)

[R C-R]

1 minute ago, Andy05 said:

It's way better if the exported image looks weird and off rather than "looking good", but it's (maybe unnoticed) of a different size.

Some users would agree with that; others would not, in large part because it depends on what the export is intended for.

[Andy05]

12 minutes ago, R C-R said:

Some users would agree with that; others would not, in large part because it depends on what the export is intended for.

Nice, that you didn't try to explain, why expanding the image to show your strictly needed 1px oversized objects is far more important than my 501px. Probably because you've notice the hole in your logic eventually? The app is not supposed to decide how far it should extend an image. That's what I said from the very beginning. And which you obviously still don't get.

[ashf]

I think artboards should be always aligned to pixel grid and integer pixel size regardless of the snapping setting when the document unit is pixel.

[R C-R]

1 hour ago, Andy05 said:

Nice, that you didn't try to explain, why expanding the image to show your strictly needed 1px oversized objects is far more important than my 501px.

The app expands the export dimensions to include all of the stroke, whatever its size & position, if any of it would otherwise be cropped out. It is more than reasonable to assume that if the design includes a stroke, whatever its width, no part of it should be eliminated unless a user explicitly wants to do that.

In fact, if the stroke was very large & a large part of an edge or two of it was cropped out of the export, it would typically be very noticeable, & likely to be considered an unwanted result.

1 hour ago, ashf said:

I think artboards should be always aligned to pixel grid and integer pixel size regardless of the snapping setting when the document unit is pixel.

Consider that the document units can be changed at any time, as can the dimensions of any artboard. It is also possible to distribute artboards, & to rotate or skew them, just like with any other workspace objects. They can even be converted to curves & made into non-rectangular shapes, & with the "Lock Children" option disabled, used to reshape everything in them in one go.

Artboard child objects can be freely moved between artboards or moved entirely off any of them. Artboards can even be placed inside other artboards.

There are many ways artboards can be used within an Affinity document besides for making simple single-layer rasterized exports.

[Andy05]

1 minute ago, R C-R said:

In fact, if the stroke was very large & a large part of an edge or two of it was cropped out of the export, it would typically be very noticeable, & likely to be considered an unwanted result.

You are really, really stretching your arguments very thin now in your desperate attempt to have the final say, don't you? NO WAY any app should extend an image to all objects, strokes or whatever which are outside of the canvas. This is utterly nonsense, really. Oh wait! I know your next reply! »Designing and placing (parts of) objects outside of the canvas or an artboard is something, which almost never happens! Only a handful of users ever do that in very rare circumstances.«

Yes, you're right. No one ever places anything beyond the canvas' borders and of course, no one ever cares about automatically resized images during the export.  

Also, with your last reply about artboards as children of other artboards you even contradicted yourself in so many ways, I really wonder why you didn't notice this yourself. As you couldn't nest artboards into each other if the app would always extend each of them to the outer dimensions of any object, genius! All nested artboards would always have the minimum size of all objects if the app would follow your "resize is wanted by design"-logic...

BTW: Feel free to reply once more so you'll have your final say in this discussion (which seems to be so overly important to you) as you reached a point now, where it becomes ridiculous to me to waste a single more word on this issue. 

[R C-R]

1 minute ago, Andy05 said:

NO WAY any app should extend an image to all objects, strokes or whatever which are outside of the canvas.

Any app should always include all parts of every object contained in one of its native format documents. Anything else would be absurd. What it exports to a different document format is a different matter, one that should be left to the user to control.

[Andy05]

8 hours ago, R C-R said:

Any app should always include all parts of every object contained in one of its native format documents. Anything else would be absurd. What it exports to a different document format is a different matter, one that should be left to the user to control.

Ok, I obviously have to jump in a final time as you just create new scenarios to your liking in order to find at least a tiny "proof" for your abstruse arguments.

This is where you failed (yet again):

• Firstly, this discussion was not about saving into a native export.
• Secondly, even if it would have been about saving into a native export—of course, the objects out of bounds have to be saved as well. But that doesn't mean that the dimension of the artboards or canvas should get extended to make them fit in a native file format either, does it?

I just marked the important part in your quote, where you basically confirmed that the apps should not override the user's settings. That's what I said and you denied since you tried to jump into this thread! That's what all the discussion was about—and now you're "trying to win" the discussion by changing sides and join my initial argumentation? LOL

Seriously, you should just admit that your "resize on export is a feature"-statement was simply nonsense. Because it is, no matter what obscure new scenarios you need to create now.

Seriously done with this discussion now, I guess I proved my point clearly for any other person than you and latter would be a mission impossible.

[R C-R]

10 hours ago, Andy05 said:

Firstly, this discussion was not about saving into a native export.

What do you mean by "native export"? If a native format file is exported, it is exported to another (non-native) file format. Thus, there is no such thing as a "native export."

As for what you emphasized in red about user control, as @MEB & many others have explained in this & countless other topics, the user has complete control of where to place & how to size objects, including moving/setting them to whole pixel values, so that when exporting to a raster image format, nothing needs to be cropping away nor do the export dimensions need to be increased to include whatever might otherwise be cropped away.

This is how it always has worked since the very first Affinity app was released. Most users seem to understand why it was designed that way, or at least accept that when exact export dimensions are desired it is important to keep everything pixel-aligned.

[Andy05]

Native file save. Sorry for using the wrong expression. But that doesn't render my argument invalid and still proves you wrong.

Secondly, 

1 hour ago, R C-R said:

As for what you emphasized in red about user control, as @MEB & many others have explained in this & countless other topics, the user has complete control of where to place & how to size objects, including moving/setting them to whole pixel values, so that when exporting to a raster image format, nothing needs to be cropping away nor do the export dimensions need to be increased to include whatever might otherwise be cropped away.

Are you kidding me? That's what I said from the beginning! And that's what you denied to accept. That is what all the discussion is about, Einstein! The software should not increase dimension. But you said, it should. Even if an object is misplaced, the app should NOT change the dimensions of an image.

Now you said it should not. So you basically proved yourself wrong since the start of your discussion. Since you finally proved my point by just repeating my intitial claim:

Please, write down "Even if an object is misplaced, the app should NOT change the dimensions of an image." 100 times. And no cheating by using power duplicate!

 

[R C-R]

2 hours ago, Andy05 said:

The software should not increase dimension. But you said, it should.

Read it again, more carefully. I said that when positions & sizes are set to whole pixel values, then the dimensions do not change.

[Andy05]

8 hours ago, R C-R said:

Read it again, more carefully. I said that when positions & sizes are set to whole pixel values, then the dimensions do not change.

Read yourself. You said, the user has control over it. Not that he (has to) use(s) it. Just because the user has control, it doesn't mean that the software should expand the image if the user doesn't make use of this control he has.

See? Your initial claim (which the discussion started) is still utter nonsense.

But I'm really done for good now. I even got several private mails in the meantime from other users that it's not worth wasting time with arguing against you as it seems to be commonly known that you will just go on and on and on and on even though you're wrong. 

In order to not get tempted to reply anymore, I found the useful function of blocking users' comments here in the fora. Welcome in my killfile, you're my first guest in there.

[Dan C]

Please try to keep threads civil and on-topic for the OP's question.

We seriously appreciate the work and support that all of our regulars and community members alike provide here and we'd like to keep the forums as open and welcoming as possible, so please try to keep this to a minimum - many thanks.

[R C-R]

10 hours ago, Andy05 said:

Just because the user has control, it doesn't mean that the software should expand the image if the user doesn't make use of this control he has.

If a user does not use the controls provided to set everything to whole pixel values, then the software will expand the dimensions of the export to compensate for that when needed.

Note that Illustrator may do the same thing, thus the advice here to make sure to remove fractional pixels. It is the same as the advice given for Affinity because that is how these apps handle exports.