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.

+1 is all I can say

Thanks for the effort and the help. I really would like to confirm some good news, but I cannot. It still crashes. I did as you said: Uninstalled all those fonts (all Dax variants, I do not even use in this document). I made sure in Windows Fonts folder is nothing in. I deleted the old versions, replaced them with the new fonts you sent me (all 5). I installed the fonts with MainType. The double entries are gone now in AP. Filenames do not show "(1)" anymore. So everything looked good. Tried it (on 2 PCs, one with HWA on, other off), crashed (on both). I deinstalled the fonts and copied the font files directly to the Windows Fonts folder without MainType (hoping to circumvent the font cache). Tried it (2 PCs), crashed (on both). In addition I can report: Earlier I did what I always have to do in the end. I copied the whole content from the problematic file in a new AP document (even merged multiple documents with the same layout and fonts), i.e. Dax was still used. I did this actually with my old versions before you sent the replacements. I worked with this new document without issues so far. So, IMHO it is not the font directly, although it may be involved in the issue. I do not want to play the wise guy, but this is what I think: According to what I saw so far, I really have issues with almost every document after some time (at least with the larger and more complex ones). Sometimes it is misplaced/distorted images, sometimes layout issues, crashes when opening, or some seconds after that, etc. All of them I could fix by copying the content to a new document. And issues started slowly in most cases. It is hard to explain and I do not remember exactly what happened. However, to me it feels as for some reason something gets scrambled in the save file, as the issues persist after restarting and reloading the document. As soon as the issue is there it won't go away and gets worse the more I try to fix it, as if the data structure is damaged and depending on where and what the issues are always different. So, maybe the problem lies in the document data structure... Also, isn't is strange that the crash does not happen if you do this slowly enough? How should a broken font be involved in that? What happens in these few seconds to avoid the crash?

Well, I am not sure if it is related to the Dax font, but it seems to be related to Fonts in general. I completely replaced Dax with Arial and did not have any crashes by doing the reported thing and by doing random things for some time now. With Dax it would have crashed several times. But I also created a new file and used Dax and could not produce any crashes no matter what I did.

Yes, the answer to why the Dax fonts are doubled is 42! 😄 I tried to get rid of this, tried to delete the Windows font cache (some files I could not delete). I use MainType for font installation. If I uninstall the fonts they do not appear in the Windows Font Manager and also MainType does not show them in the Windows Font Folder. If I install them then MainType shows them once in Windows Fonts, but with "(1)" (an unused font even with "(2)") at the end (e.g. "C:\WINDOWS\Fonts\Dax-Medium(1).otf"). AP reports them twice. However, I replaced the restricted font with an unrestricted. Strangely enough the Dax Medium is not shown twice anymore. I attached a new package with this. Unfortunately, it didn't help and it crashes in the same way. 1) crashes for me too (select "attacks" then pressing cursor down), 2 to 4 does not crash for me. And it crashes if I select "attacks" make it non bold (apply "No Style for Chars"), then do the same (place cursor before "or", ...). I also should note that I used the (restricted) Dax font in other AP projects and it did not cause issues (well, I had issues, but related to images and no crashes like here). Package.zip

As I am over 50 I assume this was even faster than me 😉. Very strange indeed. Did you install the fonts? I confirmed it is also happening when working locally (normally I always work with the files on the NAS, but I copied the package folder to the desktop and it happens too).

For me it happens on two computers in the same way (latest release 1.10.1.1142; and yes HWA does not make a difference as it is on one PC and off on the other). You may have waited too long. If you do this slowly than it does not happen (roughly a key stroke per second). If you do this in normal work speed (roughly 300-500 ms per key stroke) than it happens. Uploaded several crash reports in a ZIP reports.zip

I really love Affinity, really I do. But AP drives me crazy. With each and every document I create, I end up with crashing issues, sometimes when opening the file, sometimes when doing certain things. So I keep several versions of the file to be sure to have a recent backup for recovery. And in most cases the only fix is to copy the whole content into a new file (well, it is a lot more work than it sounds). This time it is really annoying. Just by moving the cursor (sometimes beginning/end of line, or line up/down, etc.) AP crashes. The problem started today out of nothing. This happens every 1 or 2 minutes while working with the document. Now I save after every word. But this is just too annoying. The crash can be reproduced. For example by doing this: At the end of the document in section "Explanations" go the the second line of the paragraph "Immune", i.e. place the cursor before the "or". Then type ", " (comma space). Then go back 2 characters (press cursor left 2 times). Then press Backspace (to delete the space after "attacks" (see image). Then press cursor down to go to the next line... well, got you, this will not happen as AP crashes in this very moment... every time. Ah, wait, I found something out while taking the screenshot. Wait 5 seconds before pressing Cursor down. Then AP does not crash. So, this is even more strange... Package.zip

Released 1.10.1.1142 still has this issue

Ad 2) Mmmmh, for me Affinity was always a shining example for well thought-through and intuitive functions. But this is quite the contrary. This is the M$ way, trying to be smarter than the user. First, if I set a setting other than default, I do this for a purpose, and I would wish the software acknowledges this. Why would I set it to "Outside Left" if I "want" the SW to change this to something else? Second, even if intended, it is not consistent. In the one case I mentioned, the alignment does not change, but for example, if you do the same, increasing the image, but by using drag&drop (instead of dialog) then it does change! This is really expected??? Very strange indeed.

I already wanted to post a bug report, as for me clearly this is a bug. If I select multiple objects and then select to transform them separately then I do this to transform each of them "separately", just in a single step to save me some work. And if I then enter an exact dimension, then I cannot expect anything else as that all those separately(!) transformed objects will get exactly this entered dimension. Right now they do get scaled relative to each other. But if I wanted that, I could enter a percentage, which is possible already. So the current behavior could be achieved by entering a percentage (would be perfect if I could enter the math directly, e.g. "30/25%", but anyways), but the intended behavior cannot be done at all. What else should be needed to say? (I am just referring to the resize behavior, as I do not agree with the OP regarding the "bounding box issue". Although I would not mind a setting where you can define that "transform separately" is the default.)