fde101

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.

Data merge is for stuff that changes throughout the document. Global colors are for colors that are the same throughout the document. Completely different concept and purpose - though a color variable which could be impacted by merge is not a particularly bad idea, it would be a distinct concept from a global color, and questions such as how to map the use of the color to a particular merge record and what to display for the color when no merge record is present would then come into play...

This is a duplicate thread and should probably be closed?

Maybe as an option, but certainly not as a required feature, and ideally not as a default. Those who are taking color seriously will generally want to avoid as much color influence as possible from the area surrounding the image. Spectrally neutral pigment-free neutral gray paint which is designed for environments such as color grading studios can run $120/gallon (and needs to be paired with appropriate lighting to be fully effective). In environments like that, colored tabs like this would be a major problem, as they are even closer to the image being worked than is the paint on the walls. Serif already provides the option to make all the icons grayscale, which is likely an important factor for those environments also.

Rest assured there are many who find it bad, not necessarily all in the same ways, most of whom are not wearing themselves out writing online books to describe it in such exhaustive detail that the developers at Serif will probably never take the time to study it... ...though I am reminded of an old web site that is no longer maintained but is still around in a sort of "archival" status - not sure but I may have posted a link to this before: http://hallofshame.gp.co.at/shame.htm

If you were using physical media and tried to rest your hand on a wet painting you would paint your hand and smear the artwork. Resting your hand on a touch screen in particular is just flat out bad. Even without a user interface control there, if you are zoomed in enough artwork might be there instead and you could be changing it. That is not to say that the interface design of v2 on the iPad is actually good... it does have a number of relatively serious design flaws (the whole on-screen modifier key swivel thing in particular is just stupid for a touchscreen design)... but the crux of some of your complaints boil down to problems which are ultimately being caused by your own bad habits, possibly combined with Apple removing too much of the inactive rest/grip area surrounding the screen.

Try turning on the alignment handles in the Move tool (this can be found on the context toolbar). Make sure snapping is turned on. Then you will get additional handles surrounding selected objects which you can drag to align them to other objects: for this example, select the square and drag the center horizontal alignment handle (double-arrows left and right which display near the center of the square) until it snaps to a guideline at the center of the circle.

Why stop there? Layer FX properties too... Corner radius... Stroke thickness... How about reverse duplicates? If we are rotating four copies forward, add another four copies rotating/translating in the opposite direction?

You can select them in the Layers panel, but I agree, an option to select a locked object by holding a modifier while clicking on it (or perhaps by double-clicking on it) would be useful at times.

Wondering if there is a difference in how rendering intent is being handled? In the Affinity apps it is configurable in Preferences/Settings but in Pages I don't see an option for it so not sure what is being used there.

The original Mac operating system was single-tasking. The 128 KB of RAM in the original Macintosh simply wasn't enough to juggle a bunch of GUI-oriented applications at the same time. One application at a time. This resulted in user interfaces where the tools were right on the screen without any kind of window frame, such as in the original MacPaint: https://en.wikipedia.org/wiki/MacPaint#/media/File:MacpaintWP.png Notice that the entire screen is the application frame.

I think these are both bad ideas. There are plenty of "design for dummies" apps out there already, no point in Serif wasting their time on another. A separate "easy mode" is bad for the reasons @MikeTO outlined, along with others. Personally I think the Layer menu could be split into two: one with the actual "layer" properties such as group/ungroup, hide, arrange/align, etc., and one with the more "graphical object" properties, such as Convert to Curves, Expand Stroke and the like, but I'm at a loss as to what to name the split-off menu - calling it "Graphical Object" or even just "Object" doesn't quite feel right.

The Table Formats panel works quite well for quickly formatting an entire table. The problem here is that the OP has a specific use case in which formatting needs to be applied differently to specific cells of the table which do not match the calculable patterns which can be used in defining those table formats. I agree that there is not currently a good solution for applying styles selectively to arbitrary cells.

If whoever wrote the posts you are searching for did not know the correct terms (or the same incorrect terms as you do for that matter) you will wind up with a similar problem.

Yes, that is how that software works, and yes, that is a limitation of such programs. A benefit, on the other hand, is that most such applications provide ways to repeat the adjustments/edits against other photos, so if you have a bunch of photos that were taken at the same time in the same place, you can make your adjustments to one of them, then apply those adjustments in bulk to the others as appropriate, and the adjustments are still just slider values and the like so you can still tweak them per photo if needed. The solution to the proprietary nature of the tracked edits is obviously to export the photos in their completed formats once you are happy with them and need to use them outside of the application in which you performed those adjustments/edits.

There are numerous options out there for this already; just a few examples: Capture One DxO PhotoLab On1 Photo RAW DarkTable RAW Therapee Luminar Neo