Peter Werner

There are several different brush types in Affinity, and unlike I am missing something obvious, it appears to me that the raster brushes used in Affinity Photo can only be used with brush tools. It would be fantastic to be able to apply these non-destructively to vector paths. Essentially like a non-destructive version of Photoshops "Stroke Path" feature. This is something that for instance Macromedia Fireworks and Discreet Combustion were always able to do, but for some reason it was never added to Photoshop. Possibly, the applications could also support adding multiple brushes (or strokes in vector terms) to the same path, opening up even more possibilities. In addition to the obvious benefits, having raster brushes on vector paths would also allow the brush engine to be used more like a particle system, another long-standing omission in Photoshop's feature set that would be great to see in Affinity. NOTE: There is a "Texture Line Style" setting in Affinity Photo's path stroke options, but this doesn't seem to work with the raster brushes, counter-intuitively not even with those in the "Textured" category in Photo's brushes panel. I assume that this requires Designer brushes (as these work when applied in Designer in the same place), but those are not available inside Photo as far as I can tell. As such, I find this a bit confusing, and it seems that I'm not alone. Some kind of note in the Stroke popup under the "Texture Line Style" that lets the user know that they need to use Designer to apply Texture stroke brushes would be useful.

Agreed, Python is very powerful, has a clean and object oriented syntax, is easy to learn and has a lot of extensions available, allowing even things like OpenCV to be used, and native code can easily be integrated via boost::python. If the VFX and games industry is a target, Python would be a no-brainer anyway. Ideally, the version of Python and all associated libraries would then conform to the VFX Reference Platform for each year to make pipeline integration even easier. I'm hoping for a much better UI integration than Adobe has with their horrible JavaScript stuff. Having a basic command line/script console and a basic script editor in the actual application, possibly as an optional Persona, and a way to add scripts to buttons (like with the Maya Shelf) into the main UI would make it really useful as power user could then quickly do stuff that way with no need to fire up a script editor, save to a special folder, relaunch the application a hundred times and so on. As a next level, being able to create custom commands with undo support and even tools, menu integration and native UIs from within scripts would be killer for creating seamless extensions with great usability, avoiding the ugly Flash and recently HTML5 UIs of Adobe extensions that stick out like a sore thumb. Recently, it is apparently even necessary to use some custom version of the Eclipse IDE. I think developing scripts and scripted extensions should be simple and easy, while still offering great integration when needed, so that more complex tools developed this way are really seamless and end user friendly. InDesign already has very limited, buggy and kind of cumbersome support for menu commands via ExtendScript. It's a great idea, but it's a pain to write and there is no proper support for localization, and you have the issue of parallel persistent script engines running, and using code from other files is really annoying to do in ExtendScript. Compared to simply deriving from a MenuCommand class in a clean Python API, it's a joke. One thing that would be cool would be a way to package python scripts with all code files, resources like icons and localization strings and libraries into Apple-type bundle folders that would make them very easy to install and uninstall for the end user.

It would be useful to be able to preview which areas are affected, essentially as if the blend curves were a regular alpha mask. I'm talking about offering the standard mask display options, like as a BW image, quick mask overlay, marching ants and so on. Another useful display mode for displaying masks, which is currently not supported, would be the content being masked composited on 50% gray, like most video color grading programs offer.

Duplicating layers is really quick by pressing Cmd+J (Mac) / Ctrl+J (Windows), Merge Down / Merge Layers is Cmd+E (Mac) / Ctrl+E (Windows), same as in Photoshop. It's much faster to use the keyboard shortcuts than to move the mouse to the Layers panel, target a tiny button, then move the mouse back, so I guess that very few of the people who would be considered the target audience of such a workflow speed increase would actually ever click those buttons. Most professional graphics programs are really designed for two-handed operation with one hand on the keyboard and one on the tablet or mouse.

"Content Aware Crop" is Adobe's terminology for a filter that applies a patchmaching algorithm that attempts to fill in transparent areas (or selections in the case of "Content aware Fill") with pixels gathered from different areas in the rest of the image with an intelligent algorithm. What you are talking about is an entirely different feature, similar to the "Edit > Crop" and "Edit > Trim" command in Photoshop. While I agree that this would indeed be a useful enhancement, you may want to refer to the discussions about this type of feature that already exist elsewhere on the forum if you want to add your vote. I really like your idea of putting that into the crop tool (for example as a button in the tool options bar) instead of the main menu like Adobe did, as it not only makes a lot of sense there conceptually, it allows the user to then adjust the crop rectangle further if need be.

Completely agree, it's one of the few essential tools that are still missing. I recently submitted this feature request – I'm hoping for it to also be usable live and non-destructively with other adjustments as well as regular layers, and to generate selections like Photoshop's "Select Color Range" does.

I wholeheartedly agree with Patrick. Both Content Aware Crop and Content Aware Move in Photoshop are utterly useless because they don't work on separate layers. Even with Content Aware Fill, I always do a Stamp Visible, select the areas I want to fill, perform the fill, then Cmd+J the generated areas to a new layer and then delete the Stamp Visible layer. For extending images, I always do that manually, using a combination of different tools, from clone stamp to content aware fill to copying image regions to generating portions with their seam carving resize tool. The automated version almost always requires manual adjustment, and having the result baked into the image like Photoshop's Content Aware Crop does is counterproductive. It's pretty much just Adobe adding a useless new button in a different place for the Content Aware Fill feature that has already existed for ages.

I believe that GIMP supports PSD files, which Affinity Photo can both open and save.

Photoshop has traditionally had the Select > Color Range command. There is also HSL keying inside the Hue/Saturation adjustment toolset, which, annoyingly cannot be used to create selections for use with other commands without clumsy workarounds (that I know much better than I would care to admit). What I am hoping to see is a non-destructive way to do masking based on luminance, HSL tools, as well as possibly more sophisticated keying algorithms that are found in video software (Primatte, Keylight, etc.). Most video-focussed color correction software (DaVinci Resolve, Speedgrade, Lustre, Baselight, FilmMaster, Assimilate Scratch) allows for non-destructive HSL keying already. The most elegant way I can imagine this working inside Photo is that similar to regular layer masks, a new procedural mask layer type for non-destructive HSL/Select Color Range masks with adjustable parameters would be available. Like an adjustment layer, except that the result would be a mask instead of an RGBA image, to be used just like regular layer masks. That way, it would be easy to adjust the selection parameters interactively after the fact, and, if need be, rasterize destructively to a regular raster mask layer. In additions to the keying in Luma, RGB, HSL, YUV and LAB, parameters for blurring the result, expanding/contracting the mask would be useful. The exact same functionality could then double as a vastly improved "Select Color Range" command as well.

First off, hats off for a spectacular release, this is absolutely fantastic!!! Sorry for bringing in my feedback at this point in time and in this form, but unfortunately I haven't had the time to take part in the Beta this time around. The following is all based on looking at James' excellent video demos, not on trying the features in practice, so my apologies if I'm overlooking things that are already there. Here we go: Having to activate the clone tool before double clicking a source seems kind of redundant. It would be useful if double clicking a clone source would also activate the clone tool as well if it is not active yet. In the Equations filter (which looks amazing by the way!), it would be useful to have a flyout menu that just offers to add the supported functions until a full expression builder is available. A button that takes the user directly to the corresponding help page with all the documentation might also come in handy. It would be nice if the Equations filter allowed to save equations as presets. This would also allow you to ship a few examples to get everyone started/inspired. Same situation for Apply Image. Macros are of course a workaround, but they are not as convenient if you want to use existing presets as a starting point for your own equations. When creating a new macro category, I think popping up a dialog asking for a name would be useful since pretty much everyone would likely want to name their categories right away. Those who don't want to could always just press the return key. I think the Pixel Art resize filters could be built into the regular image resizing dialog with an option to switch between regular resampling and pixel art resampling, and then changing the other options based on the choice. As the number of features increases, there will be lots of menu items, so this would keep the main UI less cluttered. It's also quite likely that a new user looking for the pixel art resizing feature would look for it unter the "Resize" command, and not think as far as to search for a separate command. Integrating it into the pre-existing dialog would also allow for readouts of the dimensions that, say, "4x" would result in (just re-use the existing input fields). For 360° editing, I think it would be infinitely more intuitive to add a 360° navigation tool (similar to the pan hand or zoom tools). In the current form, it's really hard to discover how to get back into the tool for someone who hasn't seen the video tutorial. The options bar could include an additional checkbox option for "Enable equirectangular 360° projection" for quick access (would be possible even in the current form). Since 360° projection viewing seems to be a per-layer setting, it would be useful to display a corresponding indicator icon in the layers panel for each layer that has the setting enabled. Or a separate checkbox column that can be shown and hidden via the flyout menu, or shown only when 360 projection is enabled for at least one layer. For macros, you are using the eye icon to indicate visibility of settings, but for layers in the layers panel, you are using a checkmark, which is a bit inconsistent. Might be wrong, but it seems to me that it is not possible yet to do HDR and panorama merge in one step, which would be cool since it would eliminate the need to manually export out the HDR files to EXR and re-import them to merge them to a panorama. For Apply Image, a small thumbnail in the dialog box would be useful to see what the source is currently set to and/or if a drag and drop operation yielded the desired result. In Apply Image, just like in Curves and other parts of the software (Channel selection in Adjustment Layers etc.), the color space choice is a drop down field, which, compared to, say, an NSSegmentedControl, requires an additional unnecessary click from the user. Drop downs are better suited for long lists like blend mode, but if there are only very few options, direct access buttons are much faster to use. This is really annoying in Photoshop as well. Also in Apply Image, the S in the variable names seems a bit superfluous – as far as I can tell, recursive operations don't make sense there, so just using r, g, b for the input color values would suffice I believe and make things slightly more readable. And if destination values should really be accessible, they would be differentiated by the D already, eg. DR = R + 50; DG = DR; (i.e. copy the result of the calculation for the red channel) DB = B; In the video, EXR loading seems to occasionally take quite a bit of time – visual feedback in the form of some kind of progress bar would be useful, especially on slower computers. Seems to me that the histogram panel only shows values from 0..1 for now It would be cool if the Lighting Effect filter could access normals imported from EXR files for interactive relighting Tone Mapping: Need to play with this myself, but on first impression, it seems like an "Auto" button for Tone Compression would be useful. Simply look for the maximum value in the image and set the slider value so that all information is included in the result without any clipping. The first thing James does in every video is find this value manually, and then start from there. So if a button could do that work for us, that would save some time. I know it's too late for this release, and my apologies for just dumping all this in one solid block, but I hope it's still going to be helpful for future development. Again, congratulations on entering the RC phase and thank you all for your hard work!

Yes, that is the case. For instance, Adobe are lying about their 0 values. Their 0 doesn't actually mean 0 but zero difference from Adobe's default value (contrast is one example). For other settings, they just apply default values that you can then reduce if you want to (color noise reduction being one example). So you'll find that you'll have to use much higher values in Affinity for some of these settings or activate them manually compared to other software. The advantage is that you can have more flexibility beyond what is possible in other programs, including in this case using less noise reduction than Canon would want you to use, but also other things like disabling the built-in tone curve. You could always make your own presets with some noise reduction, sharpening etc. applied that you can turn to to quickly get you where you would normally be starting out in other software.

By default, all images are set to fit to the viewport when they are opened. For images that are smaller than the viewport, this leads to a zoom percentage greater than 100%. Personally, I usually prefer images not to be enlarged as it gives a wrong impression about the pixel-level quality. It prevents checking if the file is sharp, while not giving any real benefit since enlarging them does not provide any additional information, unlike in the case of larger-than-screen images. So fitting larger files by default is fine, but I find myself routinely pressing Cmd+1 every time I open a low-res file in Photo.

While we are at it, a command to split multi-column frames into individual text frames for each column would be fantastic.

In case you are not familiar with it, Procreate is basically the number one most popular digital raster painting application on iOS. It's a great and fast little program with a very well thought-out UI. It would be cool to be able to open their files up in Affinity Photo on the Desktop. There is currently no application on the Desktop that supports .procreate files natively, so they must currently be exported to PSD on the device, which loses some features like the embedded time-lapse video. PSDs also cannot be re-imported, hence PSD is not suitable for archiving files from Procreate. So being able to open the native files in a desktop app would be great, and it's something many Procreate users have been requesting for years. Thus I imagine you might be able to generate quite a few extra sales among Procreate users. And when the iOS version of Photo is released, Procreate support would of course be even more useful. Ideally, if the Affinity QuickLook plugin would also provide support for viewing .procreate files in Finder and QuickLook, as that would be the absolute icing on the cake. The file format is actually quite simple, it's basically a ZIP file with some plists that describe the structure, then there are the individual raster tiles as separate files, and the embedded time-lapse video. The only potentially difficult thing would be figuring out how to decode the image tiles as they seem to be compressed somehow in recent versions, but I'm sure the people at Procreate would be glad to help with that.

I see, fantastic, thank you! Great to be able to do this non-destructively as well. But to be honest, I think this feature would be much easier to discover and also much faster to use if the Curves layer was added in the correct nesting position automatically if a mask is selected in the layers panel. Thus the workflow would be as simple as Select layer mask and press Cmd+M. Ideally, the user would even be presented with the drop down in the Curves dialog set to "Alpha" already.

Does that mean that the fact that you couldn't apply adjustments like Curves to masks has finally been lifted? Or maybe it's just me and I just haven't been able to figure out how to do that so far.

There is also Anime Studio (used to be called Moho), which is actually a pretty cool program for 2D animation if you don't like the more traditional approach of the difficult to learn programs rooted in traditional cel animation like Toonz Harlekin (though The TAB might be of interest to you), ToonBoom Harmony, Animo, RETAS Pro and so on. Anime Studio also has some features borrowed from 3D programs, such as support for bones and basic 3D and is thus suited for a wide variety of animation styles. It's quite a bit easier to pick up than most other animation programs and is a bit more flexible. There are also lots of tutorial videos you can watch, but there is of course always some learning curve involved. This software also looks very much worth following. It takes a more traditional approach, but apparently it is not a reality yet after the crowd funding did not come together. The mockups look great, though. Blender, while not exactly pretty and despite a few major quirks, is actually currently one of the cleanest interfaces of a 3D program of this complexity out there. Modo could be considered another. But if you wanted to use a 3D animation package, you would always have a major learning curve ahead of you if you want good results. It's not something you can pick up just by experimenting with the software like you say you like to do, just due to the sheer complexity of the task, and the way of working is nothing like the process for 2D animation. SketchUp is the closest thing to a 3D program that you can pick up yourself as you go along, but it's no good for animation. As far as an Affinity-based animation program goes, that actually sounds like a great idea. Currently, there aren't many good tools out there for web animation (SVG etc.) and interactivity. There used to be Macromedia Director, which was great for animated UIs and interactivity (not so good for actual 2D animation, which most people used Macromedia Flash for, which also wasn't that great for traditional animation), but it seems like Director was discontinued and Flash is no longer very actively developed either. It's kind of a shame since Director's approach would have been perfect for instance for bringing static print publications into digital form (compare that approach to how cumbersome it is to even create basic animations in InDesign). Unfortunately Director never received standard-based output features for the web and went out of style alongside interactive multimedia CD-ROMs. I think the combination of real animation features (something you could make an animated film with, based on vector and raster tools already found in Affinity) and interactivity for web and screen would be a very appealing product. Sort of like a modern equivalent to Flash and Director, but without the bloat and quirks and with output based on SVG and/or HTML in addition to serious traditional production tools and output formats like rendered video.

MBd, as I suggested in the other thread, having the option key held down in Levels, Curves and other Adjustments act as a toggle would probably be a more elegant solution. Basically, holding down Option when dragging the slider would toggle the clipping warning on if it is globally set to off, and it would temporarily disable it if it the global setting is on. With that strategy, customizable thresholds (for instance, it might make sense to set 95% for print work to determine where details may not show up even though they are technically in the file) could also be implemented as part of the global setting without bloating the UI of the Adjustments with clipping warning options. I'd say a toggle button in the main toolbar with a popup with settings similar to the snapping options would be a great way to implement this. That way the feature would also be a lot more discoverable. Most new users would never be able to figure out on their own how to get clipping warnings in Levels in Photoshop. That button's popup settings could even be combined with features like highlighting saturation clipping, Gamut Warning, Broadcast Safe Colour, and Ink Limit Warnings (the latter being something that Photoshop is still sorely lacking). Depending on the user's settings in that popup, the Option-Key toggle in Levels could then also be toggling a gamut or ink limit warning instead of the default clipping warning.

Great to hear that the feature was added, as that was one of my major remaining issues with the software. However, I would really have loved to see it implemented as a global setting instead, as I suggested in this thread. I'm currently using the old Photoshop trick of using a color fill layer with very narrow blend-if settings to emulate clipping warnings when working on white background images, but I think building it into the software would be much easier to use, especially for beginners who may not be comfortable with messing with the advanced blending settings. Besides, the blend curves become difficult to control when it comes down to just a level or two of difference between points and they don't support multi-selecting points or nudging them with the keyboard, so it's a bit fiddly to set up.

My apologies for the lengthy post. The concept of a raw converter in the Adobe sense is really a bit strange and mostly exists for historic reasons. As far as I can tell, the reason for the existence of ACR was that back then Photoshop was not very good at dealing with floating point images that represent values below 100% black and above 100% white. As such, performing all the colour correction steps in a separate plugin that has a floating point processing pipeline internally allowed values clipped in one step to be brought back again in another. So for instance values clipped with the exposure correction could be brought back with the Recovery slider, whereas doing it in Levels inside of the main Photoshop would clip those values so that a Shadow/Highlight filter applied afterwards would have no chance at ever bringing those details back. With a scanned image or an already converted raw image, that's not such a big problem since dynamic range is more limited, but with raw images and HDRs and their extended latitude, it becomes a problem. So really mostly a hack on Adobe's part for not having to fix shortcomings in the main application. The downside is that ACR has a much inferior memory management system and thus cannot deal with large images and also breaks down when using lots of localized corrections. A raw conversion plugin could theoretically bring in the raw file as a floating point image (similar to an HDR image) and everything that can currently be done inside of ACR could be done completely inside the main application (possibly with the exception of the camera calibration profiles), again, provided that there is floating point support. The fact that ACR is a separate plugin has created other absurd situations, like tools being available inside of ACR that are not available inside of Photoshop (like Dehaze, Clarity, and so on) or filters that duplicate that functionality with their own UI (Lens Correction for example). Even Adobe got sick of that at some point and recently decided to offer ACR as a Filter inside of Photoshop as well – which has nothing to do with raw conversion any more, but just with making its regular image editing features accessible from within Photoshop. However, in the meantime, this all-in-one approach has become popular outside of just a raw import plugin since it has also proven useful for photo management applications like Lightroom, Aperture and Capture One. It allows quick non-destructive processing of images that don't require the extended complex toolset and workflow of a full raster editing package like Photoshop or Affinity Photo, and it is very useful for processing similar images in batches (like fixing white balance on all images shot under similar conditions). Ironically, then traditional raster techniques like masking with brushes have crept back in, showing us that this strict separation isn't really ideal. But far as I am concerned, tying all of these things to the process of raw conversion has mainly historical reasons and in context of a modern application is kind of limiting. Such an all-in-one environment could simply be an adjustment layer (whether it's tied to a Persona in terms of UI or not) that provides a floating-point processing environment. If the sliders internally were implemented as other nested adjustment layers, all tools from inside Develop would be available individually inside the main application without duplicated code and some features only being available in one place or the other. Inside of the all-in-one system, they would be able work together without clipping artifacts even for 8-bit images since the software would first internally convert from 8-bit to float and back at the very end. That's essentially what happens right now when we enter ACR as a filter or the Develop persona inside of Affinity from a layer. Also, implementing and limiting all the non-destructive masking tools like graduated filters inside a raw converter environment only is also severely limiting since these features would be equally useful inside of a regular raster editing toolset for masking layers. Why not have the main "raw converter" be an adjustment layer, and all corrections produced by non-destructive masking additional Develop adjustment layers? The editing UI could still be a persona instead of a dialogue box. Graduated filters, masking brushes and radial filters could then be made usable as regular masks, even for everyday pixel layers and vector shapes, and, hopefully in the future, we will be able to use vector shapes with variable feathering like most video colour grading applications offer them for masking our adjustment layers (we all spend way to much time filling in shapes with a brush). However, this would require floating point support in the main application if a localized correction should be able to bring back details that were previously clipped. Otherwise the masking would need to be done inside the Develop floating point pipeline. With such an approach, all adjustments done inside of a separate photo management application would then automatically be accessible and adjustable inside of the raster editing environment as adjustment layers, including masking. And the Develop Adjustment Layer could be expanded into individual adjustment layers with one click, opening the door to individual advanced blend options, masking, reordering, grouping, multiple copies and so on for individual steps of the processing pipeline if more control is desirable. I was really surprised to see that Affinity Photo had basically copied Photoshop's approach more or less as-is.

Provided that your path has a fill assigned, you can Cmd+Click it in the Layers panel to load it as a selection. Unlike clicking the "Selection" button in the Pen tool's options bar, this keeps the original path. However, it would of course be nice to have a modifier key in the future so that Option+Click on the "Selection" button would keep the original path (in true Mac fashion, it would be awesome if holding down the Option key would toggle the button label in real time, like menu items do).

Sorry for the confusion, that is just a suggestion for a very straightforward way to solve to the problem outlined in the original post: Going back in history and making any change irrevocably deletes any subsequent history, making it impossible to go "back to the future" if you make a change that might be as simple as accidentally clicking in your document view. It would work like this: Go back to a history step of your choice. Make a change. Instead of all your history from the point that you went back to onward disappearing for good, a new "Go back in history" entry would show up at the end of the list, followed by the change you made. It still wouldn't allow you to selectively modify things you did in the past and leave all subsequent history applied, but it would prevent you from accidentally erasing your history with no way to go back. It would essentially allow you to undo the "Go back in History" like any other action you take. In general, both Designer and Photo allow you to work pretty much non-destructively so that you can always edit things directly without having to rely on changing things in the past of the document. For instance, if you move something in your document, then do some work, you can usually just manually move that thing back instead of having to go through history. A convenient trick is also to use Copy & Paste: Since Edit > Copy will not affect your Undo stack, you can go back in history, copy something, then go back to the future and paste. Just keep in mind that making selections may trigger the aforementioned "erasing your history" issue, which I hope will be solved in the future. I usually save file revisions whenever I make major changes. So files would be named "client-project-publication-XXXX.extension" (such as "johnsbrewery-tradeshow2015-banner-0007.indd" for revision 7) and whenever I start work on making any significant changes, I do a "Save as…" to a new revision first. That's also a way to deal with a client saying "I know I said I want the logo bigger, but I actually liked it better before.". And you can always selectively copy & paste elements from multiple older revisions to the current one if you only want to restore a certain piece of your design. Affinity Photo also offers Snapshots through a dedicated panel which can be used for similar purposes, you might want to look into those as well.

A "selectively delete past history items" feature is usually extremely difficult to implement. Think about all the time travel movies you have seen and all the logical and philosophical questions that they raise and you will have an impression of what it would be like from a software engineering point of view. Even if somebody wrote some very complex logic to figure out which future steps depend on a certain history item and delete those as well (and those that depend on them and those that depend on those and so on), you would be creating lots of unpredictable situations. It would also likely be a source of a lot of stability issues since occasional bugs are unavoidable with complex problems like that. Though the developers would be more qualified to speak about their specific case of course. That being said, the "one wrong click, lose your whole history forever" issue is indeed a huge usability problem. It might be worth thinking about introducing some sort of branching feature inside the history instead of just maintaining a linear stack. Or, even simpler: Just make going back to a certain history step create a "rewind history" command on top of the history stack as soon as any other operation is taken. Without deleting what is below, simply making "go back in history" perform like any other command. Any subsequent actions would then be added on top of that and hence the linear structure of the history could easily be maintained without generating dependency issues, requiring any history to be deleted, or causing any confusion for the user.

You are most likely looking for the Perlin Noise filter, which is located under Filter > Noise > Perlin Noise. Instead of giving you a different result every time like in Photoshop, it actually gives you parameters, which is way better. Also unlike in Photoshop, you can change your foreground and background colours interactively using the Colour panel while the filter dialog box is open. No need to cancel, change your colours and go back into the filter like in Photoshop. You can even set one of the colours to transparent! However, you should be aware of the following bug: Changing the Opacity parameter will currently lead to the preview disappearing. It will still render fine and the preview will also re-appear when changing any RGB components. Setting noise in the colour panel (hidden feature when you click the preview circle to the left of the Opacity slider) will also trigger the preview bug, and any per-colour noise you set will be ignored when rendering (the latter is intended behaviour I think). But since we are in Feature Requests: One thing I would love to see is more types of noise in addition to the standard Perlin Noise, like the "Fibers" filter in Photoshop or the "Fractal Noise" filter in After Effects, which can generate all sorts of handy procedural stuff like Voronoi ("Cell") patterns and the like.

I mean literally all lowercase as a formatting option/text style attribute. In languages such as German, a lot more words in a sentence are capitalized than in English, such as all nouns, proper names and so on. This leads to much more mixed-case text than in English. As such, it has to actually be typed as mixed case in order to appear correctly when no special capitalization settings are applied. If due to aesthetic considerations or due to the way the font was designed, the decision is made to go for all uppercase or all lowercase (and possibly back again, we all know how it is), it is incredible useful to have this as a character attribute that can be set via text styles without having to re-type, say, all headlines in a publication. I have been in that situation even for English text a few times, and I can say from experience that it also leads to errors since you are inevitably going to miss the occasional word. Also if the content is to be reused and the publication is, say, exported to HTML or ePub, you wouldn't want this kind of styling to be baked into the text, be it because of search engines, because of font differences, or because you want it to use CSS text-transform. In general, I think it is a good idea to keep formatting and content separate as much as possible. This is especially critical for Publisher once it comes out, of course. In Designer and Photo, documents will generally be less complex, so re-typing a few lines of text is, while inconvenient, is a lot less of an issue of course since it is probably feasible to do it manually. I imagine you will also be factoring out Affinity Publisher's story editor persona into a separate application at some point in the future to offer something along the lines of Adobe's InCopy and Quark's CopyDesk. In such a workflow, you would then as a designer of a larger magazine or newspaper have to tell all your editors to type out all headlines in lowercase, which then means they will be fighting auto correct and spell check, and it will possibly get messed up or at least flagged again when somebody decides to proofread the copy in story view.