Stokestack
-
Posts
433 -
Joined
-
Last visited
Everything posted by Stokestack
-
I didn't post this in this forum. I observed the defect in the Mac version, 1.10.4. I cropped some border area from an image and saved it. Upon reopening it, I noticed it has been massively degraded; it looks as if it was downsized by several factors and then scaled back up. Screen shots and original files attached. Take the JPEG file, crop a tiny amount from an edge, and then save it as an Affinity document. Now close and reopen it. WTH? Heisenberg.afphoto
-
I and others have already given examples. Here's yet another: Maybe I've opened several copies of an image that have been rendered at different resolutions, to do some individual tweaks. How do I know which one I'm working on as I click through the tabs? But in the end, it doesn't matter why. I want to see it, and (again, as we've pointed out) other similar applications manage to show it. You might just as well complain that you don't want to see word count in a word processor. So what? Others do, and it's not limiting your workflow one bit. None. Nobody said it was useful in those instances, so why ask?
-
It's really not hard. Photoshop puts the document dimensions in the status bar, in your choice of units of measure. That's all we're asking for. I have no idea what you're on about with "key layers" and your imaginary complications. The document has dimensions; they are shown in the "resize document" dialog. Just show those. This is a solved problem, for everyone except Affinity.
-
Oh noes, look out newcomers! Apologists gonna git you for wanting to see some useful information! But you and the majority of users desperately need to see "memory efficiency and pressure," right genius?
-
Apple applications require a boatload of different-sized icons. Given that there appear to be some Apple-centric export presets, I'm perplexed that there isn't one to export an icon collection. This is an extremely tedious process that has been the same for several years. Look at this nonsense:
-
Let us flag a layer as non-printing
Stokestack replied to Stokestack's topic in Feedback for Affinity Designer V1 on Desktop
Just got a bunch of labels and an Avery template to lay them out. Of course, you have to make the template visible to see where the label boundaries are. Then you make a test print with some text on a couple of labels... and ruin the entire sheet because the template is printed too. Dumbware. -
It shows nothing of the sort. I MANUALLY resized the layers with "pixel alignment" turned on. Furthermore, there's no reason for the underlying layer to be blurred, and certainly not TWICE. And finally, there have been several other demonstrations of this problem earlier in the thread by other people, where none of your alleged explanations holds. And they haven't been explanations anyway; you delight in simply re-stating the problem. If you had an explanation, surely you'd have stated it by now. Keep bleating the same debunked excuses all you want, but this is defective behavior. BYE BYE
-
I don't know why you're talking about that, because it's irrelevant to what you're replying to. Meanwhile, here's a step-by-step illustration of how this problem afflicts users. This example is thrown together for clarity; it shows me putting together a silly file-browser dialog. A more realistic example would be fixing someone's hairdo in a portrait by copying, pasting, and transforming patches of hair, merging each patch down to build up a larger one that could subsequently be copied and pasted and distorted again to expand the patch until complete. But I don't have time to scrounge up an ideal image at the moment, and this one clearly shows that the underlying image is not only degraded, but it's degraded with every merge even though it hasn't been manipulated in any way after its initial placement. Done. To demonstrate the problem, open the file (the "books" layer should be selected) and merge down. Then select the "patch" layer and merge down again. The "dialog" layer gets blurred, twice. blurringHD.mov getBlurred.afphoto
-
That has nothing to do with your "but it does" claim, which was in response to this: So again: How? So... we're supposed to use the option that doesn't work, to prevent the behavior that shouldn't happen.
-
And yet you don't say how. Or a bug.
-
It doesn't matter how many times anyone repeatedly observes the situation. So what? The same sequence of steps in any other image-manipulation program that I can find does not produce this blurring. So it must be possible to do it right. Even Photo doesn't always do it. You can paste an image over another, resize its layer, and merge down without blurring in many instances. So the resizing theory really doesn't hold up.
-
Thanks, but I never scaled these images, and "pixel alignment" was ON in Photo when I composed the document. Not to mention that any resampling need only be done once, on one of the mismatched elements. Yes, these are screen shots with no extra manipulation other than cutting, pasting, and positioning. Their DPI should be the same. Nor did I enter non-integer values for anything. Also, why would I "rasterize" a bitmap? This is not a reasonable step to expect anyone to guess. Nor have I seen it required in any other image-manipulation application for these simple layer operations. I appreciate your escalation of the issue.
-
Thanks for the follow-up. I'm happy to provide a file. In this one, select the top layer and merge down. Then do it again. The image degrades further each time. And you'll note that these images are captured from a screen and cut & pasted into this document with no transformations. So there should be none of the much-debated resampling or DPI-related shenanigans. Not to mention that the hand-drawn portion was drawn right on top of the image, and merging it still causes degradation. PhotoMergeDegrades.afphoto
-
That is just wrong. What is the "correct" resolutioon? "If DPI or position do not match exactly, the merge process produces blurriness by design, unavoidable" Wrong. Only ONE of the images need be resampled, to match the other one. In every case where I've encountered this bug, I was merging a small area down onto a much larger (and non-resized) image. There is no reason the entire large image should be altered.
-
The only part that needs to be "blurred" is the one being merged down; and even then only if it has been resized, or moved by fractional pixels. Once the chunk to be merged is brought into pixel alignment and DPI conformity with the underlying layer, each of its pixels can be mathematically blended with the one directly below it. Any other pixels in the composition should be untouched.
-
That doesn't make sense. The defect is that the entire image is blurred. To address (the coherent portion of) your concern, only the overlaying chunk need be resampled and merged down. Meanwhile, I encountered this yet again and had to abandon Affinity Photo. It can't be trusted with this basic function. I got Pixelmator, which handles this operation just fine; even when the merged item has been stretched.
-
I just tried importing an Illustrator file, and found all the text is garbled. I have a variation of the original font used; I'm prompted to approve replacement of missing fonts when I open the AI file. It doesn't matter if I do so or not, the garbled text is the same. I'll provide the original file if I can remove proprietary info; I don't have AI anymore. The left is imported from the AI file by Sketch (which does so un-editably). The right is Designer 1.10.1 under Mac OS. After a lot of screwing around with numerous versions of the "Source Sans" font used here, it looks like the version of that font used to create the document is critical to reproducing the problem. "Source Sans Variable" most likely came with the Adobe suite, but Adobe also made it available as open source. But the open-source ones seem to have been revised and aren't recognized as the one in the AI file (I can only find a "Pro" version and "3VF" version). I've attached the one used in the AI file. I suggest creating an Illustrator document that uses it, and try importing it into Designer. Let me know if that doesn't repro it for you, and I'll try to get you a file. SourceSansVariable-Roman.otf
-
The panel shows that you're setting a dimension precisely, not scaling. So yes, it is wrong. To provide scaling, you provide a scale field or function. Expecting users to guess at wholly un-indicated and unprecedented behavior is ridiculous. You can keep jumping through hoops to defend this defective and obscure design, but there's no reason for it. There are well-understood and explicit ways to provide all the functionality we're talking about, but Serif ignored them... to no benefit.
-
Wrong. I said THE BEHAVIOR OF DESIGNER here is, and you know it. Nobody said THE DESIRED FUNCTION is preposterous, which you also know because I already noted that it's an expected and desirable feature of any application like this. In fact, if Designer worked the way other applications do (and I expected and described), you would have that functionality: objects being scaled in place without changing their relative spacing. Did you watch the video? That's exactly what happened in Sketch. Let's head off any feigned confusion: You'd select all the objects, go to the Transform panel, and enter some value for Scale. The objects would scale in place. The change of relative spacing in Designer is another side effect of the dumb transformation of the bounding box around the objects instead of the objects themselves. You can continue to float strawmen and play dumb here, but the fact is that even you didn't know how this inept UI worked; but now you're pretending that it's a broadly understood and demanded implementation of a function. It's not even named correctly, so no... it isn't. --END--
-
Who said that was preposterous? No one. Strawman down. There's no indication that the current "method" will do that kind of scaling, so it doesn't address your desire for it anyway. After all, you did not realize that the Transform panel behaved this way either; why would anyone else guess it? Our mutual experience with Affinity's design here supports the contention that it's obscure. Preposterous is up to the observer, but yeah I'd say it's preposterous. We already have a way to resize things proportionally: scale. This is an expected and well-understood feature of an untold number of graphics applications. Why do you ignore that?
-
Just ran into this again today. I was pasting a copied area to fill a gap in a layer and then merging down, and it degraded the entire image. Pathetic. There should be no higher priority bug than this one.
-
Did you not watch the video? If selected items have disparate values for particular parameters, those fields should either be blank or say "multi" or "--" or otherwise indicate a discrepancy. This has been a solved problem for years in numerous applications. Again: Did you not watch the video? Everybody except Affinity knows how to handle this situation. Take a look at that comment and think it through. And repeating what the application does isn't a defense of it. Yeah: We know it doesn't work right. Thanks for the confirmation. Let us know when there's a way to set the sizes of multiple objects at once.
-
I'm sure users were clamoring for the most obscure possible resizing functionality on the planet.
-
OK, so the answer is you can't set the dimensions of multiple objects at once. That is pathetic. And the behavior you've discovered is straight-up preposterous.
-
How is it better than what other applications (not necessarily AI, which I got rid of) do? I demonstrated the problems above. How would the functionality be harmed by fixing them?
