DieterW

I know and I miss the object styles too. But I was aware of this and didn't suggest object styles. I think I did not express myself clearly. Pinning is closely related to text of course and therefore I think it would be more appropriate to have the possibility to set the pinning options for a text style (rather than object style). When I use pinning I use different pinning settings for different text styles, e.g. headings or normal text. Now it is more annoying than helpful that the last used settings are reapplied. It may be my way of work, but after creating the basic content I jump back and forth a lot and add new objects to the text in different places and so it seldom helps. In addition I end up a lot with inconsistent objects within my text, mostly because of copying them between locations with different settings... But if I could set the pinning options for a text style that would give me consistent and almost always correct settings for a newly inserted or copied object. This together with the inconsistent and faulty Pinning Offset implementation makes using Pinning not an enjoyable experience for me.

The 'Erase' blend mode in the appearance pane does not work on fill and stroke. When setting Erase in the Layers pane everything works as expected (the whole object including the stroke erases the objects behind). This is not true for Appearance. If setting the blend mode for stroke or fill to Erase it just makes the stroke or fill invisible. However, the other modes in Appearance seem to work. For me this would be very helpful if it worked correctly. For example when combining to cliparts, which technically overlap, but visually should not and one is cut out around the other with a distance. Now I have to set a stroke, expand it, subtract the expanded stroke from the object, etc...

My thoughts are... anything would be better than the current solution... I would go one step further than m.d.: Why not giving us the opportunity to apply multiple text styles as is, with all the issues there are (like wrong order, which cannot be changed in the first step). As an experimental feature, which must be activated in the settings. As m.d. mentioned, in most cases users would not apply multiple text styles with the same feature, I would say the vast majority of supporters here desperately are looking for a way to mix different features. I mean, really, this is soooo annoying... Regarding MikeTO comments: I do not fully understand the argument regarding the hidden control structure. There must be some form of data structure of applied styles and features. On top of the text style pane there is a box listing all applied styles and features. I assume there must be an order for this too within the data structure, or at least it should be possible to add it. At first it should be the order of application of the style/feature. I also assume that it should be possible to provide a way to change this order (instead of the current box at top, there could be a simple list of applied styles/features which can be reordered or entries deleted). That is more or less what would help greatly and satisfy most needs (with enough potential for fine-tuning later ). I am sure some issues remain, but we are looking at a 90% "there" and 10% "still not there" situation IMHO. Regarding the issue of missing a trailing space, etc I see no difference to the situation now. In addition, I think the majority of Affinity users is aware of this and could handle it.

When the Scale (inline pinning) is set to "No Scale" it is possible to have positive and negative offsets. When I change to a scale option then a negative offset remains (although it changes to a percentage for a reason I do not understand). However, it is not possible to set the offset to a negative value with a scale option otherwise. If it is positive or I change it from negative to positive it cannot be set to a negative value (again). This does not make sense as negative values would be needed in many cases. In addition, I do not understand why the offset influences the line height. If I offset an inline image then the next line moves downwards as the line height seems to increase. In all my cases this was not what I wanted or was helpful (quite the contrary). I think it should not influence the line height. If I need this to be (e.g. that the image and next line do not overlap), I can manually increase the line height (leading override) to prevent issues. But I cannot prevent the next line from shifting, as setting the leading override to a fixed value does not help.

Due to my experience a better option for controlling the pinning settings (for Publisher) would be necessary. I think the best option would be to add pinning to the text styles (character section). This should be sufficient to handle all cases, at least I came across. A separate style or preset option just for pinning would not be necessary I think.

No, that is not the case. I can continue to work on the document without issues. So it cannot be corrupted. It is just a saving issue.

I really, really, really appreciate that being added. Waiting soooooooooo long. Please also add some easy exchange possibility to provide the scripts to others, easily search for scripts, etc. I am also very sure that this will reduce the feature requests noticeable and then you can implement the most popular scripts into the core. Please prioritize that feature 🙂

This is an issue for all three products and it is extremely annoying. For me it is new with V2, as I did not experience with V1. I solely work form my NAS, i.e. all files (and linked resources) are stored on the NAS from where they are opened. When I send the PC to sleep and wake up again then this issue arises every single time. Very funny if you work with lot of files open you have to reopen manually after the application was closed without any choice. Good luck with recalling which files you had open so you do not lose the recovery state... After recovering you cannot save the file manually (Save as) over the original as this is still locked and write protected. So you have to save with a different file name, then deleting the old one (not with Windows as it tells you the file is still in use, so you have to directly on the NAS) and then renaming the new file back to the old name. So much joy!!! First, it should not happen at all. It worked with V1, so I do not see any reason why it cannot work in V2. Second, how on earth came someone up with the idea to deny me the option of saving the file manually before it is closed? I mean, honestly...

Pleeeeeeeeeeeeeeeeeeeeeeeeaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaseeeeeeeeeeeeeeeeeeeeeeeeeeeeeee! Any language, I do not care, I just want to have it. The reason for me is: As by no doubt there is considerable lack of programming resources at Serif, such a feature would take off quite some burden from Serif, i.e. many feature requests would vanish or never be asked for. So, I think, Serif themselves would profit the most from it. Just to add some specific points: Join scripting with macros, i.e. macros for all programs and make macros scripts (that can be edited, not like now, which drives me crazy). And I recommend to have a well designed user forum to share and exchange macros (OK, I am old school and hope this won't be NFT macros then... 😉)

Just can say such SW would make a dream come true. I wait desperately to uninstall Lr once and for all. I also would pledge on kickstarter.

What a fruitless discussion. There is clearly no common ground of agreed basic principles where you could base a discussion on. If someone, like wonderings, thinks that you have to take what is served or leave it, that's fine. We do not need a forum for that. If others think a forum is a place where you can request features you think you have a right to, that's fine too, everyone has the right to be frustrated. What I think is that: a) If you buy software for a certain purpose, like APub is for DTP (at least that is what is advertised for) then you can expect certain features, like well integrated functions for foot- and endnotes, TOC, sections, etc. Sure, there is a gray area as always, as a feature can be very basic (or unusable) to a dream comes true. Asking for such features, or suggestions to improve not so well working features is no affront I might say. b) A forum titled "feature requests" IMHO is for asking of new features, but maybe I am mistaken. And yes, I think sharing a dev roadmap without promising anything or publish dates would make sense, in principle, I have to add. Because both only makes sense if you have the resources to manage and communicate with the users. And here Serif is lacking a lot. They at least have some interaction on the support forums, but regarding feature requests I feel like hung out to dry. c) But what I am missing most is this: The reason I changed to Affinity was this incredible intelligent start-from-scratch-approach of AD (and AP). I was immediately convinced. While lacking a lot of features of AI, I found the already implemented features superior and more intuitive. It may sound silly, but it is Serif's own fault. This raised expectations of what were still to come. But APub was a disappointment already, not only feature-wise, but also bug-wise (cannot remember of another SW crashing and corrupting my files that often). And over time I became aware that it is not only the lack of introducing really needed and often asked for features, but also this fresh and intelligent redesign of known features was gone. Well to be fair, I mostly speak of APub. But you have to consider I am not a professional, I use all three programs for private projects only, although maybe on the more sophisticated side as the average, but still. So, I will leave you with that, as I have to add a new feature request... 😉

As it seems to me that devs are only reading bug forums for the time being and feature requests are more or less ignored entirely I do not hope for a solution soon. Therefore I am afraid workarounds are all we have ... The aforementioned method from ''' works, although the details took me a while. A short description to save others time: (In my case I wanted to divide an image in a grid with 10 columns and 7 rows) Open the image to cut Create a rectangle in the size of one cell of the grid in the upper, left corner (in my case with a width of 1/10 and height of 1/7 of the image size) Delete the image layer (it just served as an easy method to get a new document with the right size) With Duplicate and Transform it is quite easy to copy it many times so it covers the whole image as a grid (in my case 70 rectangles) Select all of them > Gradient tool > Type: Image > Choose the file of the image to cut Turn Snap on with options: Snap to spread and Include spread mid points Move the center of the Gradient tool handles to the center of the image, which should be easy with snapping Disable the "Maintain fill aspect ratio" option of the Gradient tool (strangely enough the image will be distorted when this is enabled; I assume this is due to the extreme scaling we will need to do) Move the horizontal handle of the Gradient tool to the right border of the image, while holding Shift (again will snap) Move the vertical handle to the top of the image in the same way Switch to Export persona and set your export options On the Layers tab select all rectangles and click "Create Slice" On the Slices tab click "Export Slices" (below the list of slices (took me a while to find it... 😉)

I had more or less the exact same issue, and unfortunately I have to say, quite some others. For example text wraps differently around image depending on linke or embedded, i.e. if I place an image it is embedded, although document is set to "link" (a known issue, which should be fixed soon), then if I change this to "linked" the text wraps differently (as like the text keeps a greater distance), if I replace the image with itself, then it works again, as the new image is of course embedded again. This can be played forever.

This is a small one but I fall to this every single time: When creating a new text style based on another the new style is always "Paragraph", not matter what the base style is. I strongly suggest that the new style should default to the same style type as the base style (so a character style creates as character style).

I must admit I share all those concerns. I am not a professional though and for me Affinity is still the best option. However, some years ago, to me Affinity was like a shining star by taking known functions, rethink them from scratch, and in many examples made them better, more intuitive, more consistent. It cannot be overlooked that this has changed. It somehow seems to me that product management changed some time ago as such things in the end depend on very few people with outstanding analytical and conceptual capabilities. However, to me it is also clear that Serif has an enormous lack of resources since quite some time now. Sometimes I think I can feel the principle willingness paired with the typical frustration due to being overloaded too long, and not seeing the light at the end of the tunnel. So, it might well be that the current situation is caused solely by this fact. If this is really the reason I can say for my part that I would accept a higher price for sure, if this would lead to more development resources.