fde101

If you prefer to work that way, there are ways to do so. One example: Make sure you don't have any layers selected, then hit the Mask Layer button along the bottom of the Layers panel. Use a black brush (or other relevant tools) to paint onto that layer the area you want to effect (if at 100% opacity you are asking for full effect and the area will turn transparent). After you have the desired area targeted, invert the mask layer (Command+I by default on the Mac - Layer->Invert) and only the targeted area will be visible. Deselect the mask layer, add the desired adjustment layer, drag it below the mask layer, and group the mask and adjustment layers together - you can then edit the adjustment layer and it will have an effect on the intended area. If you select the mask layer, you can continue to refine the area. If you add an additional adjustment layer to the group (keeping it below the mask layer) it will apply its effect to the same area as the existing one.

It is not wrong depending on the purpose of the brush stroke usage. Consider that the brushes can be used for painting on a mask and that allowing accumulation when you are trying to set an area of coverage can produce uneven results making the usage of the brushes much more difficult for that purpose - and I have no doubt that other examples exist. Photo is meant for photo manipulation first and foremost, and the current behavior impresses me as the most likely for that function, and is almost certainly the best default behavior for the application's primary function. What is being requested here (allowing the opacity to build without "lifting the brush") is more in line with painting software, which is a secondary function of Photo rather than its primary use case. While I agree that this would be a good option to have, it is not an ideal default behavior for this particular application, and should either be a property of the specific brush, or an option to toggle on and off (likely from the context toolbar) depending on the intended usage of the tool at that time. The reverse would be true for an application such as Painter or Krita whose primary function is painting.

Agreed there should be an option to allow opacity to build within a single stroke, at least for raster brushes. The current behavior is perfect for many use cases, but having this additional option would be a relatively simple way to expand on the application's potential. It would only need a checkbox for the UI behind it...

Try it. If your selected layer is an empty pixel layer, then you can adjust the selection and only the empty pixel layer is impacted. If you then copy merged, it copies the combined data of the layers that are visible within the selection - as the empty pixel layer is empty (and 100% transparent) it has no effect on what you wind up copying. The method @Return pointed out also seems to work (assuming default shortcut keys):

Interesting... I was just playing with this a bit more and those handles only show up if there is a pixel layer selected. The selected layer does not need to intersect with the selection - you could have an arbitrary pixel layer completely off to the side and having nothing to do with the selection and it will otherwise behave as I described it - so I'm not sure why that would be a requirement. I can get it that they might hide those if a non-pixel layer is selected, but with no layers selected, wouldn't it be better to display those handles and let the user manipulate the raster selection without impacting the underlying layers? A workaround for now is to create an empty pixel layer and select it. I don't think that should be necessary, though.

yes

If you have a raster selection, it puts handles on the selection that can be used to resize, rotate and shear it. If there are intersecting pixel layers selected their content is also affected, but you can prevent that by deselecting the layers and having only the raster selection when using the move tool to manipulate it. If true that is likely a bug and should be reported in the bug report section rather than here in the feature request section - but are you sure that you are accounting for the marquee itself possibly sitting on top of that pixel?

To adjust the marquee using handles after creating it, switch to the Move tool. Also. try Copy Merged (Command+Shift+C on the Mac) instead of just Copy.

Not quite exactly - this converts the end points to "sharp" ones, effectively deleting the control points, rather than adjusting the control points without removing them. It's a little thing, but it is a thing. It also doesn't provide for other functionality such as the bisection feature I listed.

Try Copy Merged (Command+Shift+C on the Mac) rather than just Copy (Command+C on the Mac). Remember that in the Affinity products there are two selections going on at the same time: the layer selection (which is more vector-oriented and is managed by the Layers panel, move tool, etc.) and the raster selection (managed by the marquee and freehand selection tools, flood select tool, selection brush, etc.). In spite of its name and focus, Affinity Photo is primarily a vector-based application which happens to have a focus on tools for manipulating the raster content of its layers. The normal "Copy" command follows that of the other Affinity products and considers the layer selection rather than the raster selection. Copy Merged pays attention to the raster selection.

Given the intended parity between scripting and plugin capabilities, a few things that are important to remember if you want to be complete about this: File import/export filters Custom user interface components (studio panels, menus, menu items, context menu items, etc.) Custom tools to be added to the toolbar (with custom context toolbar configurations associated with them) - this one meaning the toolbar with the Move Tool, Hand Tool, etc. Custom color pickers which can be defined and added to the Color panel and other related areas of the interface Custom brush engines (previously referenced in this thread) Custom items to be added to the main toolbar (at the top of the window - this one the toolbar with ) Custom color spaces (ex. RYB, RGBW, etc.) Custom personas (by specifying a name, icon, set of standard and/or custom studio panels, standard and/or custom toolbar items for each toolbar, callback when entering/exiting persona/closing document, etc.) Custom smart shapes Custom snapping candidate identifiers Custom data sources for merge feature (Publisher) Custom search criteria plugins for Find and Replace (Publisher)

One request per thread please, as per the guidelines.

There is already a zero-key solution for this if you have the right input devices: a Wacom tablet with touch sensitivity lets you do this using gestures without holding any keys and without losing your position in the text; I haven't verified but I suspect a trackpad on a laptop might do the same? I also plugged in a mouse for a moment and verified that the scroll wheel on the mouse allows for vertical panning while editing text and holding down the middle mouse button (the scroll wheel) allows bidirectional panning (at least for my 3rd-party mouse on my Mac), so a mouse with a scroll ball or a Magic Mouse would probably allow bidirectional panning as well. For my own part I would normally arrange for the entire text area I need to work with to be visible before I start typing rather than mess with this, but depending on the project I can understand that might not always be practical, so while this isn't really something that I need or am bothered by, it is not an unreasonable request, but as most modern mice have a scroll wheel and that seems to provide a solution for this, I'm not so sure it isn't already there...

Thanks, reviewing your clip again reminds me that my "another would be" option is actually available in that panel so that would in fact be a possibility (I rarely use that panel so had lost track of that option being there). For the more "normal" use of the distribute option the key object would be irrelevant, but when turning that off and using manual spacing, I agree that would be relevant and useful.

https://alessandrofrancesconi.it/projects/bimp/

Those commands space things evenly between the two ends of their shared bounding box. How would that work with a key object? It would make no difference at all in how the objects would be positioned - it is irrelevant to that operation. In order to make it work, you would need to redefine the operation in some way: One option would be to have the current behavior of distributing within the bounds, but then adjust the position to match the new position of the key object to its old pre-distribution position. Another would be to manually specify the amount of spacing you want to have between objects before performing the operation, rather than having it calculated for you. Either way this is a different function from what is currently offered.

How is that any different from what @Old Bruce demonstrated? Different fonts have different proportions of width to height and it can vary by character. In order for the text to have the same bounding box it will frequently need to be stretched in one direction or the other. This opens up an entire range of possible interpretations of what you are asking for: Should the height be fit, the width, or both? If both, then the text needs to be stretched; if one or the other, then this is not a simple checkbox on/off state but you would need an interface to select which way the fit should occur. Should the fit consider ascenders and descenders so that it is a simple match of the bounding box, or should it simply fit the x-height above a matched baseline and allow the ascenders and descenders to ride around that? Should the match be for the entire string, or should each character be matched individually in order to maintain the spacing of the characters of the text (as there can be differences in how characters compare to each other and this could throw off alignment of the characters to other visual elements of the document)? Differences in available ligatures and stylistic alternatives could also come into play... If Serif ever gets around to supporting variable fonts, should the settings for each font axis be adjusted to try to obtain an optimal match between them? ... ...

Only to a point... All code is ultimately interpreted at some level. When it is interpreted by hardware we call it "native" and when it is interpreted by software we call it "interpreted" or "emulated" but in the end it is being interpreted at some level. There have been hardware implementations of the JVM byte code format (https://en.wikipedia.org/wiki/Java_processor) and a hardware implementation of the smalltalk byte code format has at least been considered if not implemented so at some point an equivalence with capabilities is reached and the differences become a matter of performance due to levels of abstraction and implementation characteristics. Many of these scripting languages are actually being compiled into some byte code or internal data structure format or another by their "interpreters" which then interpret the byte code rather than trying to execute the scripting language directly. In a sense, they are compiling the code and then executing the compiled code, no differently from a native code workflow, except for the specific architecture of the compiled format and the fact that they are interpreting the results in software instead of in hardware. There are examples of implementations of fully native compiled languages that can accept the source code in the same way that a scripting language interpreter would, compile the code and execute it with the same immediacy of a "scripting" language, further blurring the distinction between them (the GNU Haskell compiler offers a "runhaskell" command which does this for Haskell code, for one example). At the same time, it is possible (and sometimes quite easy) to write scripting language code for many scripting languages that is specific to a particular operating system. In Perl for example I would just need to write a "system" command to run some outside utility that is only available on some specific operating system, and that code becomes non-portable.

Command+A already does that if you turn off Edit All Layers in the Layers panel; sadly I don't see an option for assigning a keyboard shortcut to that.

A number of open source apps such as LibreOffice and Inkscape currently support named instances of variable fonts (the preset configurations stored as part of the font itself) but do not currently allow you to adjust the individual axis values. Seems it will be coming at some point, though.

All of these flip/rotate tricks break if the objects are different sizes and you want to maintain the center positions. The command as originally requested impresses me as something that should be relatively simple to write a script for once that functionality is available then assign it a keyboard shortcut of your own. If Serif does not provide this before then it would not be the end of the world.

Agreed, and that would be the way to offer this for those who might find it useful. Yes, and the point size of the text is one of those constraints, which is why what you are requesting would not be a good default behavior for a tool like Publisher in particular, since the same point size could be set for the same text in multiple places but they could wind up at different sizes, which would usually be a bad thing, as the size of the text should ideally derive from a style which promotes consistency wherever it is used, and an alteration in text characteristics in the manner you are describing runs contrary to that purpose. While I can agree that your requested behavior would also sometimes have merit, it would not be a good default behavior, so offering it as a property of the specific artistic text item would be the best way to incorporate this if Serif does decide to add this feature to the products.

You can get 1200 gold stars here for US $6: https://www.amazon.com/Holographic-Stickers-Adhesive-Behavior-Supplies/dp/B0BDDTQDRS I'd imagine it will cost a lot more to pay the developers, testers and documentation team to make this change so I'm not sure that this provides much motivation. Note that you can also adjust the brush size by dragging on the stroke panel icon in the upper-right corner, which is in a consistent location, as is the "Width" slider within it, which also adjusts the same thing.

Interesting! Thanks for pointing this out. The context toolbar says to use the option key to "ignore snapping" - seems that the help text needs to be updated?

Out of curiosity, how would you expect it to work for these commands? These work on the space between objects at the two extremes (ex. the leftmost and rightmost if spacing horizontally) so there isn't really any way to use a "key" object for these as far as I can tell... This is exactly what "last selected" does: shift+click on one of the objects to de-select it then again to re-select it and it becomes the "last selected" and thus the "key" object. As an alternative, consider turning on the "Show Alignment Handles" button on the context toolbar when using the move tool. You can then drag the bottom alignment handle (for example) to align the bottoms of the objects, and it snaps to the top, center or bottom of any of the snapping candidates (or just place it arbitrarily even without snapping), allowing you to visually select where you want the objects to be aligned, potentially even to something that is not part of the selection.