fde101

A curious side-effect of this feature is that the embedded image data that came from the pixel layer shows up in resource manager with a blank name. If you "make linked" it will then save it as a TIFF file with a name like "_1.tiff". Any chance we could opt to have that become a PNG instead of a TIFF? It took me a minute or two of staring at this one to find it, but now that I have, seems to work just fine. I like it. A nice option to add for this yet would be for the text on the "other side" to be rotated back to the correct orientation. The current option is good too, but it might be nice to have the text on both sides be right-side-up sometimes but still follow the curve?

Interesting... Yes, w/2 works as does w*.5 - I wonder what I messed up earlier when I tried an expression like that there... Thank you!

I don't believe this is currently possible.

2010 Mac Pro, quad-core 2.8 GHz 20 GB RAM Radeon HD 7950 - 3GB MacOS 10.13.6 I will try to remember to run on my (newer) MacBook Pro later and post those results as well...

It does that already. Currently it does select from hidden groups, locked groups and hidden locked groups. This doesn't seem to be available at present. Select Same -> Fill Color does work on gradients, including those with different angles but otherwise matching. If you "Reverse" one of the gradients (using the Reverse button on the gradient editor) it won't find it, but rotating it all the way around still allows it to be matched. Select Same -> Shape effectively does this.

Right-click the master page layer itself on the page and choose Edit Detached to make changes to master page items such that those changes only apply to the current page.

A workaround is to create a text style from the text in question then apply that style to the places you want to match the original. This has been mentioned on the various past threads making this same request...

They may have difficulty getting this to work well because of trying to keep the app versions relatively in sync in terms of feature set while needing to fight with the limitations of the sandboxing requirements from the various app stores.

Hi @sonyfreak, welcome to the forums! This has been discussed previously on numerous other threads. This is unlikely to ever find its way into Affinity Photo as it is the wrong model for this type of application. There has been previous discussion on the possibility of Serif developing a DAM or RAW development type of application which would be the appropriate place for this, but there are conflicting reports on whether or not they are currently working on one or what the plans are in this area. At different times Serif team members were either saying that they were not working on one, while at others they were. In any case, if you have an immediate need for such an application I would suggest looking at one of the other existing solutions for now (Capture One you already mentioned, there are also DXO Photo Lab, On1 Photo RAW, darktable and numerous others floating around).

You can already resize by percentage by entering the "%" into the size fields - ex. "50%" to scale to half size. That much makes sense given that percentage is not really a unit. The problem in your case is that the calculation is performed immediately and the actual number substituted, which makes it not work very well if trying to code something for a batch operation which may need to deal with varied image sizes. I think the real requirement if you need to do this is not to add it to the menu, but to retain the expressions when they are entered and store those instead of the numeric values as part of the macro used for batch processing. Curiously, the feature on the New Batch Job window does allow you to enter percentages and expressions, but they don't actually work. When I try to enter a percentage this way it doesn't complain but it silently ignores the request and simply exports as full size: Clearly there is a bug in that somewhere, but it is not clear if the bug is that it doesn't complain about the % character or other expression format when it is not supported, or if the bug is that it should be working and doesn't...

In any case, this should probably be on the bug report forum instead of the one for feature requests?

The Serif team does not normally respond to feature requests. They do sometimes, but not usually. They do read them and determine their priorities internally, not on a voting system or by popular request.

I am seeing the same issue with some text editors but not all. Apple's Xcode and TextEdit both seem to accept the text and display it correctly, but Atom for example does not. Agreed that this should be fixed.

Interesting... it wasn't always like that so they must have fixed it somewhere down the line and I missed that.

Bit of a tight squeeze?