Stokestack
Members-
Posts
433 -
Joined
-
Last visited
Everything posted by Stokestack
-
Thanks for the reply, and the link to that other topic. But that's a screen shot, not a printout. There's another long thread of people requesting a "non-printing" button on layers, so we can do simple things like making templates and working around the inability to set the canvas color. It's only related to exporting (in this thread, anyway) because any change you make to your composition to work around Designer's export limitations may mess up your workarounds for its printing limitations, and vice versa.
-
This appears to be the least painful method of doing what I want. Thanks. It still means having a colored object behind everything else, which you have to remember to turn off if you want to print without it (see the lengthy threads requesting a "do not print" option on layers). But for exporting it's not too bad.
-
Thanks.I expect that this will affect child objects too, though, won't it? If so, you can't do this to an artboard. So this means creating a rectangle that's the same size as the canvas, setting its color, moving it to the back of your composition, and then setting it to non-exporting in the Export persona.... right?
-
Thanks for the suggestions. The transparent background is a pretty lame workaround if you're working with white or light-grey objects. There's no excuse for not letting us set the canvas color, but people have already complained about this and nothing has been done. The grouping suggestion turned out to be unnecessary. I started a new drawing similar to the example above, and discovered in the Export persona that there's a "create slice" option in the context menu... but only when you're NOT using the Slice tool! 🙄
-
Such a simple task: I just want to export an icon with no extra pixels around it. The document has space around the icon. At first I could find no succinct and exact way to either get rid of the surrounding canvas, or select all the objects and create a slice, artboard, or any other discrete entity that can then be selected in the Export persona. But, if you select the "artboard" tool, there is an option on the toolbar to "insert artboard," and next to it you can change the size to "selection." Again, this is a fairly obscure rigmarole in place of, say, a context menu on the canvas or in the layer list that would allow you to "create artboard from selection." Also, there doesn't appear to be a way to resize an artboard by dragging and snapping its edges to objects, even with the "artboard tool." True? And then there's the fact that the creation of artboards itself is (in this case) a workaround to a crippled "slicing tool." I would have expected the slicing tool in the Export persona to be able to do the same thing with slices. But nope; it doesn't appear that you can even make it snap to objects. Is there some better way that I'm missing? Thanks!
-
Objects to "No Print"
Stokestack replied to Ray C's topic in Feedback for Affinity Publisher V1 on Desktop
There seems to be a lot of solved problems that Serif still struggles with. -
Yeah, keep ignoring (or simply regurgitating) the problem. So fun! And, as has been shown repeatedly, you CAN capture color in the sampler, and sample from other windows, and blah blah blah with conventional color samplers found in other applications... while not having to guess at the existence of a yet another variant of the same control hidden amongst tools... while TWO color samplers are on the screen already. The application presents a color tool or two almost all the time. It's right there on the screen: a color control. There is no reason that a user would go hunting around for another one, much as they don't go hunting for yet another gradient "tool" when gradient fills are applied from, yes, THE COLOR PANEL. And sure enough, this leads to one person after another asking why there's no way to change the angle of a gradient fill. There's no reason to keep bleating that there's a way to do it, because nobody should be expected to guess that it exists hidden away somewhere when the application already presents a mockery of standard tools that we're used to in numerous other applications in decades of use. The whole "saving the color for later" excuse really wins the lameness award here. The color sampler could work the way most users expect AND serve this edge case with almost no change: Dragging the little color well onto an object to capture its color can stay just the way it is, and the eyedropper could actually become a standard eyedropper that would set the active color. See how easy it would be to address all of our preferred modes of operation?
-
Exactly. And yet that's what Photo does. Glad we agree on this. No matter how many times you claim otherwise, nobody has given an example of why #2 is more useful than standard color-picker behavior (setting the active color). More importantly, no one has given a reason why "saving the sampled color for later" comes at the expense of obscurity and extra steps for #3. If your "workflow" is so useful in regard to this tool, why don't you share it with us? We may all stand to benefit from it. And nobody is asking for your workflow to be made impossible or even less convenient; that red herring is such a tired, played-out whine in these forums that there's no reason to float it again. But you did: Where? In fact, I already pointed out a universally understood way to accomplish what you want, which doesn't involve guessing at the existence of a third nonsensically hidden tool when the UI presents one that is common to a large number of applications but defies standard (or even common-sense) behavior. Also unexplained in this entire discussion: Why would the user start hunting around for yet another color picker when there's one (if not two) right there on the screen in front of his face already? How many more specious arguments can you make? I see that the whole "can't pick colors from other windows" argument just disappeared, and rightly so. Here's how a proper color picker works, right out of the application window and even onto the desktop: properColorPicker.mov
-
You can do that with "normal" color samplers too. That has nothing to do with neglecting to set the current color upon sampling. That's the entire issue, for which no one has provided a justification for. Think it through: What is the most-common use case? 1. You want to sample a color and do nothing with it, ever (this would apply to the toolbar color picker, which doesn't doesn't set the current color and doesn't save the sample) 2. You want to sample a color and do nothing with it until later 3. You want to set the color of something (or the current working color) by sampling the color of something else Anyone who argues that #3 isn't the most-common scenario, and not coincidentally is the default in the vast, vast majority of graphics applications, forfeits all credibility. And if you want to sample a color without changing the color of anything, there's a simple, and most importantly obvious solution that is standard across entire operating systems: deselect all. That is much more realistic and discoverable than expecting people to guess that there's a third color picker buried amongst the tools on the tool palette, when the application displays two others most of the time.
-
The only colors picked or applied were the ones applied to the text. So if you find they don't match the ones in the pickers, you have your problem. Yeah, and? That's the whole issue here: When you select an object and then use the eyedropper to pick a color for it... it's not applied. If it were, it'd be "saved for later," satisfying everyone's use case. And the picker in the toolbar doesn't "save it for later" or apply it: a new level of uselessness. Hahah, you're kidding, right? Try it: It's the same picker. Screen Recording 2021-12-08 at 12.17.05 PM.mov
-
Except we don't. We have three different tools for the same function, at least two of which behave in an ineffective and cumbersome manner that no one has been able to justify. Nope. Put some text on the canvas. A color well appears in the toolbar. Change the text's color. Make another text object. Change that text's color to something different using the toolbar color well. Now select the original text. Then select the second text. See the color in the toolbar color well changing? Screen Recording 2021-12-08 at 9.51.28 AM.mov When you have something selected and you invoke a color picker, it's connected to the selected item. That's why it's "its" color well, and there needn't be any confusion caused if you roam around the screen with the eyedropper (well, in this case the circle next to the eyedropper). Oh, and I just noticed this in the "main" color picker: It actually does save the last-used colors, so the whole "picking a color for later" argument is truly out the window. We're still left without any explanation of why the eyedropper doesn't change the color of the selected item. That's especially true of the toolbar one, because it discards the selected color when you close the dialog and doesn't "keep it for later." So the behavior is entirely indefensible.
-
Hahaha, I thought you were kidding. But no! Unbelievable. Yet another redundant and disjointed function buried in the Tools palette, joining other oft-complained-about functions like the gradient angle (missing from the actual gradient control panel). Why on earth would people go hunting around for another color picker, when there's one right there on the screen all the time? Mmm, nope, that doesn't work either. The toolbar color well is twice as dumb: Not only does it not set the color of the object whose color-well you invoked it from, but it also discards the color after every use. So no, you can't justify this dumb behavior by saying "it's ready for later use." Not that that was a valid excuse anyway, since nothing precludes the thing from setting the active color AND saving it for later use. In fact, that's what many color-pickers do. This is ridiculous.