Align Stroke To and Snap To are incompatible.

[M***@adobeforums.com]

This has always bothered me. I am wondering if anyone can defend ID's current stroking behaviour. If not it should be fixed.

Changing the stroke alignment on an object changes the dimensions of the object. Does this ever make sense?

If anyone begins to answer in the affirmative, then they should immediately go to jail, do not pass go. There they should be forced to ponder the quirky behaviour of snap to as it relates to stroke.

Regardless of which stroke alignment is used, a frame will always snap with the stroke to the inside. This means that if a centred alignment is snapped to guides, changing to align stroke to inside will result in a box half a stroke away from the guide, changing to align stroke to outside will result in a stroke centred on the guide. But repositioning any of these to snap to your guides again, will result in the stroke being inside.

The only stroke alignment that changes to what it should in relation to a guide is align stroke to inside. But the user still loses the ability to snap to a guide if the stroke alignment is changed.

This shouldn't have needed this lengthy explanation. This is how snap to guide should work:

Stroke aligned to inside: outside edge of stroke snaps to guide.
Stroke aligned to centre: centre of stroke snaps to guide.
Stroke aligned to outside: inside edge of stroke snaps to guide.

Does anything else make sense?

[G***@adobeforums.com]

You are confusing the "object" with the "path". They are not the same.
And your main argument is "I can't imagine anyone using this" which always is one of the worst bases for decisions in software engineering.

Regardless of which stroke alignment is used, a frame will always snap
with the stroke to the inside




This is not so. When you use the direct selection tool, you align the path.

That the path stays the same as default when you switch the stroke alignment seems proper to me.. You are right though that there should be an option, when switching alignment, to move the path so that the object-bounds stay the same. One could do this with a script.

[G***@adobeforums.com]

While trying to write that script I thought "All this looks terribly familiar..." and, what do you know, I had done this only two months ago...
<http://indesign-faq.de/index.php/wackelnde-konturausrichtung/>

Wring it through babelfish if the german is any bother. :)

[P***@adobeforums.com]

Changing the stroke alignment on an object changes the dimensions of the
object. Does this ever make sense?




In one sense it does. You have the option to include, or not, the stroke weight in the object dimension calculations. The difference is including the dimension reports the size of the object bounding box while not including it reports the size of the path bounding box.

Suppose you draw a frame, which by default has no stroke at all, and you need it to be a particular size. You place an image or graphic at 100% (or any other size, but the point here is you want the image to retain the size for some reason). Now you decide to add a stroke.

If the option to include stroke weight is on, aligning the stroke to the outside or center has the effect of increasing the reported object dimension, but it doesn't move or resize anything. Aligning the stroke to center or inside will obscure a bit of the content along the edge, but will not change the size.

If you un-select include stroke weight in the dimensions, you see the same things, but the reported dimensions never differ.

So it seems to me that what you are asking is that the frame be resized if you are including the stroke weight in the dimensions so that the object bounding box remains constant. That might be a worthy option, but it brings up the question of how do you deal with the content?

Do you shrink the content when you force the frame to shrink by moving the stroke from inside to outside? What about when you increase the stroke weight? Shrinking the content by a fixed amount in both directions will change the aspect ratio for anything other than a square or circular frame. Is that acceptable? Probably not, so you might say just crop the image.

What about when you go the other direction? Stroke aligned to the outside and then reduced in weight, for example. Do you stretch the image?

What will the meaning be of the fit content to frame commands? Do they mean fit to the path, or to the inside of the stroke? Do you update the fit automatically if the stroke weight changes?

I agree that the current behavior is a pain when snapping and then editing a stroke, or when trying to align objects on opposite sides of a guide, but if you understand that changing the status of the include stroke weight option is changing what is displayed in the x/y coordinate fields you can use them to position either the path or the bounding box with absolute precision. Or as Gerald mentioned, you can select the frame, switch to the direct select tool and grab the center handle (to avoid selecting the content) and the snap behavior will switch to the path.

Peter

[M***@adobeforums.com]

Gerald,

You are confusing the "object" with the "path". They are not the same.




Acknowledged and my comments were based on using the selection tool. But isn't switching to the direct selection tool a step backward? You're dealing with anchor points rather than frame edges.

And your main argument is "I can't imagine anyone using this" always is
one of the worst bases for decisions in software engineering.




Not exactly true. It's I can't imagine anyone preferring this over an alternative. I am in no way suggesting some kind of arbritrary engineering limitation. In fact, I could argue that the engineers commited your sin already and poopooed the need for a more intuitive behaviour.

That the path stays the same as default when you switch the stroke alignment
seems proper to me.




I would only buy that if the path snapped to the guide.

Peter,

I suspected this could get to be a rather confusing discussion and I'm afraid your examples, coupled with all the possible variations, are just too difficult to respond to here. I think the current logic is too convoluted and loses track of what is most important.

What will the meaning be of the fit content to frame commands? Do they
mean fit to the path, or to the inside of the stroke?




For example, how does this enter the picture? Why and how would the current straight forward behaviour need to be changed? Any inside stroke implies that the content is going to be covered. Isn't that why you use it?

You seem to be complicating the issue by worrying about measurements returned in the info palette. I recognize that measurements vary by how they're taken, but how the measurement is taken doesn't change the dimensions of an object, only the measurement.

Really I think all that I'm advocating is this: the selection tool should be able to snap the path to a guide regardless of the stroke alignment. With this one option, I could deal with everything else.

[P***@adobeforums.com]

Really I think all that I'm advocating is this: the selection tool should
be able to snap the path to a guide regardless of the stroke alignment.
With this one option, I could deal with everything else.




Perhaps I misunderstood what you were complaining about. Are you saying that the path, rather than the bounding box, should always snap, so that, say, if you have two frames, both with 8pt strokes, but one aligned inside and one outside, when you snap them to the same guide the visual edge would not be aligned?

For example, how does this enter the picture? Why and how would the current
straight forward behaviour need to be changed? Any inside stroke implies
that the content is going to be covered. Isn't that why you use it?




This may be more of my misunderstanding. I thought you meant that if an object was snapped to a guide, changing the stoke weight or alignment would not alter the the overall outside dimension or position. By necessity that would mean the actual size of the frame (path) would need change, and you'd have to deal with that change in some fashion.

Peter

[M***@adobeforums.com]

when you snap them to the same guide the visual edge would not be aligned?




Yes. If you snap two boxes with stroke weight centred to the same guide, it should appear as a single stroke. You shouldn't have to resort to the direct selection tool and the problems that entails (selecting the appropriate anchor points and contraining their movement).

By necessity that would mean the actual size of the frame (path) would
need change, and you'd have to deal with that change in some fashion.




No, the most simple-minded interpretation of align stroke to outside means the frame stays where it is and the stroke is put outside. Same for inside, and if there is content in the frame the stroke will overlap that content. It seems to me that Adobe's current fixation with precision measurements is missing the forest for the trees.

[P***@adobeforums.com]

Yes. If you snap two boxes with stroke weight centred to the same guide,
it should appear as a single stroke.




But that wasn't exactly what I asked. You get that behavior now. I asked what you wanted when one stroke was aligned inside, and one outside the frame.

No, the most simple-minded interpretation of align stroke to outside means
the frame stays where it is and the stroke is put outside. Same for inside,
and if there is content in the frame the stroke will overlap that content.
It seems to me that Adobe's current fixation with precision measurements
is missing the forest for the trees.




Now I think you are misunderstanding me. What you describe is the current behavior. I.e. if you have a frame with an 8pt stroke aligned inside, and and you change the stroke alignment to outside, the apparent, or "visual" or "printed" dimension will grow by 16 pts in each direction. Nothing will happen to the content.

If you want the frame to print the same size regardless of where the stroke is aligned (and I gather that is not the case, although I originally did think so), then the frame dimension must be changing size with the change in stroke alignment.

You shouldn't have to resort to the direct selection tool and the problems
that entails (selecting the appropriate anchor points and constraining
their movement).




You don't have to select any points. Click on the center spot, as you would do if you were trying to move a frame you just selected behind something else and wanted to move it. I admit this is a pain, but it does work.

I think what you want is an option to let the user decide if snapping is to the object bounding box or to the object path, and I think that would be a good thing. I wouldn't, however, want to lose the ability to snap the bounding box. I'm sure that well over 90% of the time I'm more interested in snapping the "visible" outer edge of an object to a known point than I am in snapping the the object path if it happens to be inside or centered in the stroke.

And I get the sense that you don't like to use the coordinate fields for positioning, but I will say one more time that if you deselect "Dimensions include stroke weight" in the control panel or Transform panel menu, the numbers you are looking at are for the path, regardless of where the stroke might be aligned. Pick one of the outer spots in the proxy when you've selected an object with a stroke that is aligned anywhere but inside, change the status of that option, and you will see the numbers change. It's your choice whether you want to use what is available.

Peter

[M***@adobeforums.com]

But that wasn't exactly what I asked.




It still describes the behaviour; by extrapolation your example would also yeild a single stroke. If you wanted both strokes to show, resulting in a double thickness, both would have to have the same alignment, i.e. both inside, or both outside. This is simple and intuitive: opposing alignments cancel, same alignments multiply.

Now I think you are misunderstanding me. What you describe is the current
behavior.




I don't think I misunderstood. That's why I answered, No. The behaviour of the content is fine and as it should be. The content should always be defined by the path. Any behaviour change such as you were hinting at (Do you shrink the content when you force the frame to shrink by moving the stroke from inside to outside?) would be horrendous. For the behaviour modifications I propose, we can safely ignore considerations of the frame's content. But I will say this in clarification. Traditionally printing has always preferred a situation where the border of a quad slightly overprints the content; a centred stroke both protected against content printing outside the border and against a white line forming inside of the border. The idea that the content scale to accommodate a stroked border – that a quad should be reduced something like 99.873% just so that the outside two or three rows of screen dot would NOT be overprinted — will never make sense to me on any level.

You don't have to select any points.




"(selecting the appropriate anchor points and contraining their movement)" Perhaps I should have said "and/or." But really, I not inclinded to entertain arguments that amount to "the more awkward, unintuitive, and difficult way that you say you shouldn't have to use isn't as bad as you think." Yes it is. Moving objects around in your layout and snapping them to guides should be done by the selection tool. The direct selection tool is micro management and intended for manipulating content in relation to the object.

I'm sure that well over 90% of the time I'm more interested in snapping
the "visible" outer edge of an object




That simply doesn't make sense to me. First, and I repeat, the most simple-minded interpretation of align stroke to outside means the …stroke is put outside. What advantage is there to having three different choices if all three have the same result when snapped to a margin? You may as well stick with Quark's simple one choice: the border is always inside the item. Having different behaviours for the different doesn't restrict you. Use align border to inside 90% of the time.

And I get the sense that you don't like to use the coordinate fields for
positioning




Not necessarily true, just not relevant to the topic. I am talking about the behaviour of snap to as it is affected by the stroke alignment. There is no need to confuse the issue. If I have guides in place, and an object selected, there is no simpler way to position that object than by using snap. Or at least there shouldn't be.

[G***@adobeforums.com]

That simply doesn't make sense to me.




With that we are back at the beginning. This entire discussion is based upon you not being able to imagine that practically everyone else is working the way they do.

Currently InDesign offers two tools to either align the path or the object (i.e. the visible bounds). You want to change that so that only the path can be aligned thus effectively making InDesign less flexible.

Sentences like "Moving objects (...) should be done by the selection tool." in connection with "The stroke is not part of the object" are not conceptually sound.

So it all amounts to "I think differently and InDesign should adapt to me and not the other way round. I don't care that most users are happy about the way it is."

Ah well. Good luck.

[M***@adobeforums.com]

This entire discussion is based upon you not being able to imagine that
practically everyone else is working the way they do.




That is not a fair assessment of my comment; it is virtually the opposite of what I said. I did not say I can't imagine wanting to do something a certain way; I said I see no reason to restrict all three alignments to one certain behaviour, even if it is what you want 90% time, because working the way you want is one of the available options in my suggestion.

There is absolutely nothing in what I say that would result in InDesign becoming less flexible. That is another misrepresentation of what I suggest.

not conceptually sound.




If you are going to quote me, please stick to what I say. Putting quotes around your comments as if it's something I said is deceitful. But I can tell by your rather acromonius conclusion that you aren't interested in honestly discussing the merits of the current snap to behaviour, you're in pious defense mode and have suddenly become most users and self-appointed defender of the faith.

[P***@adobeforums.com]

Using your criteria for snapping to the path, rather than the outside of the stroke, you wind up with this:
<http://www.pixentral.com/show.php?picture=1rLzIlzjaSgPrKJXW0vC9SrNT75Iv0>

I don't see anything "cancelling" or looking aligned to another frame here. In the kind of work I do this would be a disaster.

Peter

[M***@adobeforums.com]

Peter,

I am curious why your example shows the the frame with the stroke aligned to centre to be outside the margin and right off the page. Are you suggesting that would happen some how?

Otherwise your example shows what I would expect when snapping a frame with the stroke alignment on the outside to a margin. The stroke would be outside the the margin. Nothing disastrous would happen because if you wanted the stroke to stay inside the margin as your middle example, you use the stroke alignment that works to that end. You still have the behaviour you expect by choosing that stroke alignment. I'm guessing that most people use align stroke to the inside most of the time and wouldn't even notice the difference in behaviour. New converts from Quark may not even consider the other alignments, you think?

The behaviour I advocate is not radical at all. Corel users, at least, should be familiar with it. All I'm suggesting is that snapping to a guide honours the stroke alignment the user chooses for the frame.

To get a feeling for why this may be preferable, you could try this. Draw a box with a nice fat border. Drag out a horizontal and verticle guide. Drag and snap that box to the intersection of those guides. Alt-drag a copy to each of the other corners. 99.9% of the time when butting frames together at a guide you would want consistent borders inside and out. (That's where the cancelling was meant to refer to.)

[M***@adobeforums.com]

I'm guessing that most people use align stroke to the inside most of the
time




That is probably incorrect. I was thinking in terms of users coming from Quark and PageMaker where that was the only option. But I myself prefer the centred stoke by default, that's what prompted me to question the logic of the current behaviour in the first place.

The thing that prompted me to write is probably a better example than the one above. I had a grid into which I was tiling frames with the same centred stroke. Draw the frames to the grid and all is well. Where borders meet, they overlap, and are consistent. But if you alt-drag frames, snap won't position them properly. They will be off by the thickness of the border. Makes positioning them properly a bit of a pain.

What if, when Dimensions include stroke weight is unchecked, that also applied to the Snap?

[P***@adobeforums.com]

I am curious why your example shows the the frame with the stroke aligned
to centre to be outside the margin and right off the page. Are you suggesting
that would happen some how?




No, I was just using the margin guide as a convenient place to snap. It could have been anywhere on the page. The one on the left was simply to show that the width of the stroke crosses the guide in either direction, and you said, at some point, I believe, that using a snap to path approach would cause overlapping strokes to cancel and become a single stroke. That could only be true for your preferred center-aligned default.

Otherwise your example shows what I would expect when snapping a frame
with the stroke alignment on the outside to a margin. The stroke would
be outside the the margin. Nothing disastrous would happen because if
you wanted the stroke to stay inside the margin as your middle example,
you use the stroke alignment that works to that end. You still have the
behaviour you expect by choosing that stroke alignment.




You presume that all content would be created by me, and that I would have control over stroke alignment. I occasionally work for newspapers and magazines in the production departments where you get content created by many different users with different ideas about how frames should be created. These people often have no clue, or care, about where the path is. They do care that the visual edges should align.

The thing that prompted me to write is probably a better example than
the one above. I had a grid into which I was tiling frames with the same
centred stroke. Draw the frames to the grid and all is well. Where borders
meet, they overlap, and are consistent. But if you alt-drag frames, snap
won't position them properly. They will be off by the thickness of the
border. Makes positioning them properly a bit of a pain.




Quite true, and I agree wholeheartedly about that particular scenario, which is why I would probably use step and repeat to make the copies, or the distribute area in the alignment panel to adjust the positioning after alt dragging.

What if, when Dimensions include stroke weight is unchecked, that also
applied to the Snap?




<http://www.adobe.com/cfusion/mmform/index.cfm?name=wishform>

Peter

[P***@adobeforums.com]

I'm guessing that most people use align stroke to the inside most of the
time





That is probably incorrect. I was thinking in terms of users coming from
Quark and PageMaker where that was the only option.




I may be way off on this, but my recollection is that when you applied a stroke in Quark it actually scaled the content, at least in version 4. I have memories of being bitten by this.

Peter

[M***@adobeforums.com]

That could only be true for your preferred center-aligned default.




It also applies to opposites. An outside border would be on the opposite side of the guide and would overlap an inside border snapped to the same guide.

You presume that all content would be created by me,




I suppose I was making that assumption, and Adobe may have been thinking of your situation when they coded this behaviour. But the current behaviour is based on an assumption as well: that when a frame is snapped to a margin or a guide, a consistent behaviour is desired regardless of formatting applied to that frame. That is erroneous. I don't think Abobe adequately considered the possible situations and made the behaviour unnecessarily restrictive (or cumbersome if you prefer). As far as I know, InDesign is the only application to have this behaviour. I used Corel as an example, but I could have just as well used Illustrator.

which is why I would probably use step and repeat to make the copies,
or …




These solutions also come with assumptions. What if, as in my case, the frames already existed, had varying content, and merely needed to be rearranged? Ironically, the fact that they were originally set up using step and repeat could be considered part of the problem. The step was based on the grid and did not include the stroke because I wanted the stroke to overlap. Step and Repeat and Distribution are useful tools, but they don't supplant Drag and Snap as the most common way to rearrange objects on a page.

So is the attached link an indication of your endorsement? Do you any other comments? I can't see it being a big thing to link the snap behaviour with the measured dimensions of the object, but who knows? And to be honest, after all this I don't know if want to try to explain this to Adobe.

------------------

when you applied a stroke in Quark it actually scaled the content




Been years since I worked in Quark. Current version does not scale the content.

Going through Quark's preferences to check that out, I see that it does have the option to apply Framing (border, stroke) Outside. But being a preference you can't actually change the framing, you have to remove it, change the preference, and reapply.

[P***@adobeforums.com]

So is the attached link an indication of your endorsement?




I don't know that I'd call it an endorsement, nor that one coming from me would carry any weight. :) That link is the official way to make your feelings known.

I would say, though that this discussion hasn't attracted a lot of other participants, and none who think your desired default behavior is better than the current one. You might get more action in the feature requests forum where there would be some cross-platform viewers, too.

I'm broadly in favor of almost any user controllable option, but there always needs to be a default state and I'd hate for this one to change. I gather, also, that Adobe engineers can at times be reluctant to add too much complexity in an effort to avoid spooking the newbies. Whether this would be "too complex" is outside my range of knowledge. The only way to make a change like this to happen, though, it to put it through official channels.

I suspect I'm more stoic than you -- probably older -- and I pretty much just go with the flow. There are lots of little annoyances and inconveniences in InDesign, as with other programs, and I often kick myself for not having thought about something like stroke alignment and snapping issues before I create or duplicate a lot of elements only to discover that I should have done something a little differently. When that happens I shrug, make a mental note, and do what I have to to get back on track. Once in a while I make a feature request or complain about a changed behavior, knowing full well that my input will take at least one development cycle to yield results, if at all.

Peter

[P***@adobeforums.com]

But the current behaviour is based on an assumption as well: that when
a frame is snapped to a margin or a guide, a consistent behaviour is desired
regardless of formatting applied to that frame. That is erroneous. I don't
think Adobe adequately considered the possible situations and made the
behaviour unnecessarily restrictive (or cumbersome if you prefer). As
far as I know, InDesign is the only application to have this behaviour.
I used Corel as an example, but I could have just as well used Illustrator.




First, I would say that one should design software default behavior for the more general conditions, or the perceived most common usage, and I think that's what's been done in this case.

Second, I believe there is a fundamental difference between snapping in an illustration program like CorelDraw or Illustrator, where you are dealing in minute detail with discreet paths and points, and snapping in a layout application, where you are dealing with containers that hold other content. The current behavior treats the container, and it's visual boundaries, as the primary object of concern in InDesign, as I think it should.

Peter

[M***@adobeforums.com]

Thanks for the input. I purposely did not post this as a feature request because at the time I didn't have any idea of how to frame it as a feature. I was focused on behaviour and even then not sure of all the ramifications that had to be considered. If there is too much input conversations get tangled, and in the the feature request forum people are more likely to dig in their heels and only read what they want.

And I acknowledge that page layout and illustration programs don't have to behave the same and often shouldn't, but I really do think something is amiss when you can draw a frame to a grid and can't simply move and snap it to another location in that same grid. Nonetheless, I'll sit on it for a while before taking any steps.