DieterW

Maybe I overlooked something, but artboards are a completely different story in my understanding. You cannot set an object visible in one artboard and invisible in another. You would have to copy most objects to several artboards, but the idea is to avoid exactly that (for this no artboards are needed, could be done with layers). Besides artboards are not present in Photo for example.

+1 I think this should be a function of the export persona (for all apps). Where you can add slices for the whole document, which store the current visibility of the objects.

Same reasons, totally agree 😊

Thanks for the hint. But I usually use a character style, where I set the colors to empty, for the bullets. But this is not about finding a workaround, this is about what should be the default behavior. And in this case it feels ... wrong. I say "in this case", because the reason I changed to Affinity is that I again and again was puzzled how good they took an existing feature (e.g. we all know from Illustrator) and thought it bottom up and then it worked just wow (best example is the snapping for me, it is just so good). But in this case (and a few other cases) it feels actually worse.

Sorry, to warm this up. But it is hard for me to believe that anyone could argue that this is an intended behavior and makes sense. If I have a bullet list with several paragraphs and some words are highlighted by color or even background color, then some bullets are different than others just because I had to highlight the first word in some list item? So for example some bullets are black, then the next one is red with yellow background, then black again (see image)... Really? To avoid this by defining a character style for the bullets, where I disable the colors, is really 2 steps forward and 1 back. Isn't the solution easy enough? Just take the paragraph style for the bullet, not the character style (or local formatting) of the first letter. If there is a need to format the bullet differently, then you may define a character style for the bullets (still ensuring that all bullets are formatted the same). That is what IMHO is going 1 step ahead, and if you need to, go another 1. To be honest, this struggles me some time now and I was really hoping the new (beta 1.8.535) version would have fixed this. Nope :-(

I am impressed how far ahead of time your planning goes... I wanted to do an arc with arrow heads, but so I can easily change the angles later. It should look like the blue arc (I created with cutting a circle, so angles are fixed). I tried to use the pie tool and set the hole radius to 100%. Works in principle, but not in regard to arrow heads. When doing this both arrow heads overlap and only one is seen. This is how AD treads the start and end of the line, as can be seen with the red shape. By the way, the same is - of course - true for the line caps. You cannot get butt cap equivalents on the pie, as neither bevel nor miter join would achieve this. My suggestion is to tread the end of the line differently, when hole radius equals 100%. For this special case, I suggest to not draw the inner circle and the connecting lines, just the outer circle. Then the arrow heads should be shown correctly automatically... and the caps too. Maybe this can be implemented easier than the arc segment pen tool...

The whole color choosing solution is not as round as I would expect from you. I immediately was a fan of yours as your products are heavily soaked with deep conceptional intelligence.... First I do not understand why the hex color code field is only shown when I switch to the RGB Hex color sliders. It is extremely handy when coloring objects with a color from another object. There are other ways, I know, and all have their purpose, but sometimes the color code is the fastest way. So, why not showing it in all color modes (HSL, RGB, ...)? I know that it is not always possible to translate a color from one to another (many CMAK blacks translate to RGB black #000000). But for me this would not be a problem. Or, if this is a problem, then why not using color mode dependent code, i.e. the code is not always RGB hex, but depends on the current color mode and the notion is e.g. LAB#056-023+123 (or using unsigned hex LAB#3869FB), which would also allow to give a code for 16 bit colors. Then I do not understand why there are two different color chooser popups. When I click on the circle in the color studio a popup titled "Color Chooser" comes up, giving me less options than the other way, i.e. there is no RGB hex for example. When I select an object then I can click in the context menu, where it says "Fill" or "Stroke". This popup gives me different color modes as before, e.g. RGB hex is available here. I do not see a reason why to have two different color chooser popups with different features. When I want to choose a color then it should not make a difference which UI item I click. By the way I also would not treat RGB and RGB Hex as different colorspaces. It is just a different form of presenting the value. At least add the hex code field to the normal RGB colorspace, please...

Hello, Attached file is reduced to minimum content, where bug is still present and reproducible. The original file had clipped images and symbols. The strange thing is that the file is still 30 MB big, but there shouldn't be any elements in it, explaining this. However, to reproduce the crash (AD V1.7.1.404), select the rectangle "RESIZE THIS". Enable "lock children" and then try to resize it. As soon as you start moving the mouse AD crashes. When copying all the content to a new document, it works (and then the saved file has only 9KB). This is even true for my bigger original file with all the content in it, where I discovered the bug first. Therefore the bug is not experienced when starting with a new document. Something must have gone wrong with this certain file... Note by side: Originally I opened an Illustrator file to work in it. There I also experienced crashes (unfortunately cannot remember under which circumstances). Then I started a new AD document, copied just some elements over from the Illustrator document, and created most of the content from scratch in AD. So, even if there are some imported elements from Illustrator the file was created and mostly done in AD. br, Dieter Clip_Mask_Crash.afdesign

+1 PLEEEEEEEEEEEEEAAAAAAAAAAAAAAAAAAAAASE. So sick of Adobe. Paying EUR 10 per month like a professional but for private use, with very limited time, so paying most of the time for nothing; and Lr gets worse and worse... Just want to have a professional suite as my requirements and demands are still high. Would jump to Affinity within microseconds...

Then I am sorry for the redundancy. I could not find the issue as clearly addressed as I felt necessary, and was not aware that it is a known issue already. Thanks for the support. And just to balance out the negative tone of the thread a bit: Coming from Illustrator it happened several times now that when I saw how a function is solved in AD, I almost hugged the monitor out of exaltation. Just mentioning the snapping function... incredible good job!

Thanks for the explanation. Just still do not understand the error because after wake up the not loaded portion on the network is available again, so maybe the program should try several times or give a second option to "Retry" (so giving one the chance to fix the problem) instead of "OK" only. As the network file is definitely not corrupt, as I can open it again, the program should be able to recover the file. Performance should be a concern of the user. If it is too slow on the network I can still work locally, but with a very good network there are no performance issues. I know that for sure. All I can say is that other programs handle this better, so there must be a way to do so. And if there is no solution to it, why not copying the file to local file system automatically if I open a file on the network. The auto-save file is also stored locally. After closing, AD copies the file to the network and deletes it locally. Maybe this should be a feature to enable or not. Besides the whole recovery situation is cumbersome too. At least after you open the program again it gives to the chance to open a recovery version, so not all is lost, just the things since the last auto-save. But it opens it in read-only mode (I guess because original file is locked by Windows). You cannot save the file to its original location (read-only). So you have to save it under a different name. Delete the original file, which cannot be done as it is locked by Windows and you have to log-off and log-on again into Windows (or restart). Then save it again under its original file name and then delete the temporary file. I know that this is a very annoying "feature" of Windows and it makes me crazy sometimes, but again, other programs do not have such issues.

Thanks for the answer, but that thread is another topic (collaberative) and I am not happy with the usual solutions "then don't use it or do it". The point is, it shouldn't be the concern of the user to avoid such things. I work for more than a decade from network with all programs I use (including Adobe products, big files over 100 MB). Such a situation only occurred to me so far, if there was a real problem with the network (and with faulty network discovery of Win10). But I cannot see any apparent reason here. Network and file access to the network storage location are available. The only reason is that the PC went to sleep. Such a problem did not occur to me in all this time. So I have to assume other programs can handle this far better. However, the real point is: it does not matter why the file access was lost (being it network, detachable storage, etc) or why the file may have been corrupted, the program must not simply close the open file, but offer me the opportunity to save it elsewhere. So, the network part of the this topic is a minor one (that is why it is not mentioned in the title).

I am working directly on the network. When PC goes to sleep with a file opened, then after wake up, the file cannot be saved anymore. An error appears that the file access was lost and the document has to be closed now, resulting in loss of all work since last save before sleep. This is unacceptable and the only program I know of not handling this correctly. When the file path gets lost for any reason (network lost, USB drive disconnected, etc) the resolution cannot be to close the document with all changes unsaved! The normal and usual behavior is to provide the "Save as..." dialog to give the user the chance to save the current state elsewhere. This is the minimum requirement. Actually I would expect that Affinity can properly handle the particular situation I described above, ie not throwing up an error after wake up at all. Facts: Windows 10 (latest build), Affinity Designer (I do not have Photo; latest build)