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

Stokestack

Members
  • Posts

    433
  • Joined

  • Last visited

Everything posted by Stokestack

  1. It does when one of the suggestions to be able to see the white objects you're trying to export is to put a colored object behind them. This changes the document and will affect printing.
  2. 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.
  3. 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.
  4. 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?
  5. Which is why people have been requesting (and other similar software has) a way to set the color of the canvas, and even more importantly a way to set objects as non-printing.
  6. 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! 🙄
  7. Aaaand we're back to the ol' problem of not being able to set the canvas color AND you can't set objects as non-printing/non-exporting, so in a case like this without the black square you wouldn't be able to see the shapes you were working with or exporting.
  8. 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!
  9. There seems to be a lot of solved problems that Serif still struggles with.
  10. 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?
  11. 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
  12. 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.
  13. And yet no one can explain what this "well thought out use" is. Carry on, apologists.
  14. 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
  15. 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.
  16. 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.
  17. Huh. Maybe you can point that one out for us. The screen shot below is with the Pixel tool selected. Meanwhile, the question stands.
  18. For the umpteenth time I just used the (backward) eyedropper tool to select a color, then started drawing... in the wrong color. If someone uses the eyedropper to pick a color, doesn't it stand to reason that the vast majority of the time he intends to use that color right away?
  19. Thanks for the follow-up! Fortunately, Halloween survived... or did it? pumpkins.mov
×
×
  • 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.