fde101

only if the progress window is still visible after the crash, a limitation which a log file would address

Yes, snapping uses the baseline, but alignment uses the bounding box (as it generally should). The only benefit I can see from this is being able to quickly align more than two artistic text objects to each others' baselines. Snapping will accomplish the same thing, but if you have a large number of objects to snap, you would need to apply it to each one separately, while a feature like the one requested could be applied to all of them in one step (after selection).

Welcome to the forums! Can't speak for Serif, but consider that this would be one more thing on top of what they are doing already and probably would have a negative effect on their ability to continue to develop the products they already have on the market, so it probably can't be justified given that there is a lot more competition in that space and users are already complaining left and right about features that are missing in the products Serif has released already. Serif is a small company and their developers are already spread thin with the products they are currently maintaining.

In the interim, you can apply the one you want to happen first, then group the layer, and apply the next FX to the group.

These two sound like they should be in the bug report section.

Most English books I've seen have horizontally oriented text that has been rotated 90 degrees. If all you are trying to do is stack the letters on top of each other for effect that is a much simpler thing to achieve than general purpose vertical writing: just use an unrotated text frame, set the horizontal alignment to centered, and press return (enter on Windows) after each letter of the text you are trying to put there. For something like a book title on a spine that should not be a big deal? Note that I am not saying that the feature request is in any way unimportant or invalid, but simply that it is not essential for this particular effect on something like a book spline which is a one-off sort of activity in the grand scheme of putting a book together. Try writing entire stories that way and it would get old fast. This is highly unlikely. Supporting vertical or even right-to-left text is a massive amount of work - much more than even many developers are likely to realize - and Serif has given no indication that they are actively working on this. While I would not put it past them to add this feature eventually, I would be quite surprised to see it happen that quickly, and if it did, I would be even more surprised if it actually worked correctly.

It is on the context toolbar when you have a tool selected that can respond to pressure: For the brush tools, if you edit the brush properties, you can control what the pressure does:

If that happens automatically, you could pollute your brush list with random brushes from arbitrary sources when viewing others' documents. Many brushes can be obtained as part of sets that people charge for. If the application allowed you to import arbitrary brushes from existing documents, this would simplify the process of using copyrighted brushes from arbitrary sources that you may not have licensed - just pull in a document from someone who *did* license the brush and you can get a copy of that brush without paying for it. Not sure that would go over well?

Ok, that is a start. I am asking these questions not to discourage the feature, but to ask that it be better defined. Sometimes users post these requests which could be interpreted or implemented in numerous ways which may or may not be suitable for whatever the user intended, so being more precise about what is wanted may help to avoid those misunderstandings. What happens when the collection does not exist? When the collection exists when the brush does not? Are you treating it like a missing font and just showing the name in red? What if the brush does exist but is different from what is in the document? Select it but show an indicator that there is a mismatch, maybe giving the user the option to update the object on canvas to match the brush?

This thread is a duplicate - this was previously discussed at length in multiple threads shortly after v2 was released: For whatever it is worth, I am in the crowd that considers the icons at the top to be unsustainable. They would need to add a scrollbar as more export formats keep being requested by users - a better control for these would be a list box.

I don't believe this request would be practical to implement from a general perspective. Consider creating a rectangle and four or five steps later rounding one of its corners. If you then go back and use revisionist history to claim that what was created was a circle instead of a rectangle, what happens to the step where the corners were rounded? There would be no corners to round so that step of history would represent an action taken on something that never existed. As undo/redo functions on this history information, you would not be able to "undo" back to what it was because you basically traveled to a parallel universe in which the rectangle never existed in the first place. I understand what you are asking for, but this is not really the right tool for that job. This type of "revise the steps in the middle of the process" thinking is more suitable to a tool which has a node-based workflow, but not really suitable to the history panel.

How would you handle the situation in which that vector brush does not exist on the system you are accessing the document from? What if it does but it was modified and no longer matches the path that you are looking it up from? Do you really want it pointing you back to a brush that no longer matches the one on the canvas? What if the original brush was renamed and something else was renamed to replace it? You may wind up being pointed at a different brush than the one that is still there but with a different name or identifier?

I made the mistake of buying a license for Master Collection CS6 not long before they discontinued their product line (by going subscription-only). I had started learning to work with it but stopped all efforts to do so at that point since the suite clearly had no useful future. The behaviors you are showing are largely the same as the Affinity suite other than being able to collapse the panels into icons, which gives one additional bit of flexibility in that you can collapse them to save space, but otherwise removes flexibility in that you can't keep multiple collapsed-to-icon panels open at once from the same row of panels (since when you click one to expand it the others collapse) which reduces its utility. I am not opposed to adding the option of collapsing to icons (don't really care if that ever gets implemented or not, but certainly would not mind the option as long as it is an option), but the original request as stated was to have a design without panels, which is another matter entirely. If this boils down to just a request to add the feature to collapse to icons, then it is a duplicate of many requests which have been made over the past few years and should have been added to the existing ones rather than a new thread created.

Yes, and this gives you added flexibility. You can leave them attached (as I generally do) and still be able to place them where you need them within the constraints of attachment, which allows you to move the window of the application around to keep it out of the way of other applications, or you can spread everything out, placing different parts of the same program (or more commonly different documents) on different monitors as appropriate.

A number of users have requested the option of collapsing panels into icons like that, so that piece of this is essentially a duplicate request. As to the concept of the concept of eliminating the panels, that is inconsistent with a professional workflow. Studio panels are designed to stay accessible by default to provide immediate access to their content. I don't want to have to click icons on the sides of the screen every time I switch from a color to a text style - both should be in front of me and immediately available without the extra clicks, menu diving, switching tabs, etc. Granted that there are too many studio panels to keep ALL of them accessible at ALL times - but the idea is that we can set them up and switch them around to match them to the task at hand, laying out the screen to match a workflow in which we are actively involved. This is not possible with the iPad interface and is one of its limitations as compared to the desktop version at this time. With the desktop version we can use large, high-resolution displays to organize the panels for increased efficiency of the task we are performing. Note however that even now if you have several panels stacked on top of each other within a set, you can collapse a set of them by clicking on the tab to collapse them down to the tabs.