MmmMaarten

Windows shows some thumbnails of Designer files razor sharp and others, with exact same dimensions and dpi, and even exact same files but re-saved, blurry. Looking at the thumbnails below, the left one is the thumbnail of an exising afdesign file. The right one is the exact same file, but opened in Affinity Designer 1.8.5.703 and saved to another name. So for some reason newly saved afdesign-files get a very blurry icon while older files have perfectly sharp icons. I include the original afdesign-file as an attachment. buffer.afdesign

After closing files that were opened in Designer they are still locked by Designer in Windows making it impossible to remove or rename them. Only after closing Affinity itself the files are unlocked. I'm pretty sure this wasn't an issue in previous versions of the program.

Thanks!

Thanks a lot! I really appreciate it! 😙

Yes! Part 5 just went live. The era of Pixar, the beginning of mayor software packages, moving forward towards interactives and animations on the internet! 😎 Now that the second wave of the pandemic had arrived, we better have something interesting and full of content to read as well! Enjoy it everybody, hope you have as much fun reading as I had researching, writing and illustrating it! After this part there will be only one more part (part 6) to complete this series I've been working on since 2017 with preperation, research, organising, reading, illustrating, writing etc.! Collect them all 😉 Thanks a lot everybody for liking and (positively) commenting on previous parts! It motivates me to keep on writing quality blogs! English: The History of Interactive Computer Graphics - Part 5 Dutch: De Geschiedenis van Interactieve Computergraphics - Deel 5 @Alfred @Madame @Roger C @Wosven @GarryP @A_B_C @WatcherMagic @John Rostron @Renzatic @dutchshader @CLC @SrPx @haakoo @telemax

This is exactly what I wrote in my post. But the problem here is: why does it needs to be reversed in the first place if the shapes are created by 'convert to curves' in the first place. IMHO This whole thing wouldn't be a problem if Affinity would always convert to Alternate Fill Mode. But for some reason I don't get Affinity converts texts to Winding Fill Mode, making this an issue with boolean operators as we see above, and in other issues here on the forum. @Sean P Is there a good reason why Affinity doesn't always convert curves to Alternate Fill Mode? As it seems like that would solve a lot of issues with the boolean operators.

This bug still isn't solved in 1.8.5. As written above Expand Stroke only works when stroke alignment is set to the center. It's not working when alignment is set to in- or outside. Could this get some attention by Affinity to fix this?

[edit] please read the last line of this post, which I think could be the solution to the issue I just did some more testing and found out how to make it work without tricks in the file I'm working on. In this file there are a few paths that work with subtract and others that don't (see previous post). So I tried reversing the paths of the 'non-subtracting' paths, and after that the subtract is working as expected. So it looks like the issue of boolean subtract not (always) working has to do with the direction of the paths not being the same as the path to subtract from. (But ofcoarse this shouldn't be an issue and should always work, so this is more of a workaround than a solution) Second video below (workaround 1): first paths without correction resulting in wrong subtract, then first reverse path directions of 'non-subtracting' paths before subtracting resulting in expected subtract. (btw, it would be nice if this forum would let us move videos around in a post) Hope this helps the developers to fix the issue. [edit] workaround 2: changing fill mode of all paths to alternate I just found out that when changing ALL paths needed for the subtraction to 'Alternate (even-odd)' fill mode, subtraction works as expected, no matter the direction of the paths, but when switching to 'Winding (non-zero)' we get the subtraction issues back again. In the video below all paths are in fill-mode 'Winding (non-zero)' first. And you see this is causing issues when subtracting. After that I change the mode to 'Alternate' and subtraction works fine. Changing it back to 'Winding' again and subtraction fails again. So to me it seems like 'Winding (non-zero)' is throwing these issues with the boolean subtract operators. And now I also understand why @anon2 's workaround works: convert to curves ALWAYS puts the created path/curve into 'Alternate (Even-Odd)' fill mode. And with that fill-mode there are no subtract issues. So the workaround in there is basically not the non-destructive subtract, neither the 'convert to curves', but the switch to 'Alternate' fill mode. So my guess is that the issue would be fixed if subtract would automatically switch all selected paths to alternate mode first before subtracting. subtract-works-when-all-paths-are-in-alternate.m4v workaround 1 (when in 'winding' mode): reversing direction of 'non-subtracting' paths before subtract: boolean-subtract-works-when-same-direction.m4v

After checking all nodes again and again in a graphic today I came to the exact same conclusion that subtract is sadly not working anymore. I'm pretty sure this was working before on the exact same file in an earlier version of Designer. Just to give another example of it not working anymore see video below. All shapes are closed and there are no overlapping nodes or weird things. Everything is checked. Also all windings are the same, so subtract should just work without issues, but it does not. I found out though when changing the fill mode of the lowest layer to Alternate (even-odd) and subtract after that the result is okay. But I don't want that fill mode and when changing it back to Winding (Non-zero) after subtraction it destroys the result again. @anon2 Thanks for this workaround. When applied to the vectors as below example it works! Hopefully this info helps the developers to fix it so we can use destructive subtract soon again in the next version (BTW Using Designer 1.8.5.703 here) boolean-subtract-not-working-anymore.mp4

As title says; see video below. Example in the video is a new document. resizing-doesn't work.mp4

Very busy writing part 5 inbetween other (commercial) projects. Trying to fit the last mayor developments in the history of interactive computer graphics into the last two blog-articles now! As a small flash back in the mean time on the previous part with an item about inverse kinematics, as I just recorded new demo-videos of some interactives on touch screens: There really is no better way in experiencing the difference between Forward Kinematics and Inverse Kinematics than with an interactive on a touch screen! 😀 Stay tuned and watch this space. Part 5 will be pretty interesting too and things were more and more moving towards and centralizing on the web during that period of time! 😎 kinematics-comparison-1920x1080-24fps.mp4

I agree. It's frustrating. As a professional I bought a Surface to do graphical work with a graphical pen as it is made for that, but it's just impossible to use Affinity products without a keyboard. I even needed to buy a seperate bluetooth keyboard just because when using a Surface in tablet-mode the keyboard cannot be used and Affinity can't without. Like you I have the strong feeling for a long time Affinity is not taking professionals working on Windows seriously neither, even though last 20 to longer years it's no longer only Mac that's ruling the graphical/web industry and a lot of companies use Windows for a long time now. The time that everything was only Mac for graphical work was in the 80s and 90s. We're in 2020 now.

I think so too

I just by accident found out about this pdf title on a document that I created about a year ago and was on a website for all those months for customers to download without me knowing about this title. Thank god it wasn't a weird title, but it wasn't right for the document either. After not finding a title-inputfield in the document settings to change this I searched on this forums and found this thread. I now understand the title is set to the first given filename and is never updated, but can be changed in a panel. But to me this is so hidden that I'm pretty sure 99,9% of Affinity users don't know about this title field like me. Even if you find out about this thing the first place I'd look is in document settings. Having a wrong title without even knowing about it could be 'dangerous' as who knows what the first filename was when first saving. It could have been some weird working title not intended for the final document. Example of when this is critical: I create a letter/invoice/whatever for customer A and save it to customer_A as a filename. Then later I use the same file as base for a letter/invoice/whatever for customer B by copying the file and saving it to customer_B as a filename. Then, without even knowing about this title field (or forgetting about it), I would have a title with customer_A in the letter/invoice/whatever of customer B without even knowing it. As a user I would never expect the first ever filename to still be even in the file. Now pretend there is even more critical information inside the first ever filename wich is not meant for (other) customers... and it's in all document titles that used this file as base... I don't think it's a great idea to ever save the filename as a title. My suggestion to Affinity on this is: please give this title field a higher priority, move in into view: move the inputfield for it to the document settings. To me that's the place to look for such a thing. And please make sure the title is shown somewhere during the export process when exporting a PDF so people can find out this title field exists and what it is set to. Then, if not satisfied, we can find the right way to change the field, but at least we then know it's there and might be set to the wrong title and needs to be changed. But better: never save a filename in the title field. Make sure a user entered a custom title for the document or else leave the title blank in the export or ask the user to use the filename as a title when exporting to PDF. Thanks in advance! Edit: (BTW I also now understand why I have never seen this wrong title; I always check PDFs in Adobe Acrobat Reader DC, and it is not showing the title in the header and tab, but the filename instead)

That sounds way better then 'because the usage is too low we don't implement it' (so little people will start adapting it as graphics software just don't supply the tools for these modern formats, so usage stay low)! Thanks for this turn! 😀 Looking forward to webP support in Affinity!

Hi @SeeJaneB Sorry for the late response. I just see this comment for the first time. Thanks for the nice compliments and very nice and glad to hear that it helped you getting a better understanding of color models and color spaces! Yes, this subject can be pretty confusing at first (and second ;) ), but after a while you get the hang of it!

Love this!

Thanks @A_B_C and yeah, the Wigglepixel guy is everywhere and sometimes hidden very well 😉

@Pauls @carl123 You are right, my bad. After opening the file again I saw a master page had been selected during save causing the master page to open up with a hashtag. When selecting a Page (no master page), saving and opening that file again, there is indeed a number, as it now opens a Page in the editor and not a Master Page. I can't edit the initial post, so can't add things like [Solved] to the title of this thread. I think it's too much to hide this post. So that's a little unfortunate. But anyway, thanks guys!

I found this thread which is a little older. I am reading this in 2020, because I want to serve raster graphics for an upcoming website in more web-performant formats than jpg. Also as @Burndog was written before for SEO-benefits. As Google advises modern file-formats for quite a while now to use on websites. Like JPG2000, JPEG XR and WebP, but none of them seem to be available in the Affinity exporter. This surprises me a lot, as these formats are around quite some time now and the usage and demand for them will definitely be there and rise by webdevelopers and -designers all over the world. Strangely enough Google's own browser doesn't support all the formats they advise themselves (no support in Chrome for JPG2000, JPEG XR), but WebP has very wide supported on all modern browsers except Safari, which does support JPEG 2000. So WebP looks like the way to go with a JPEG2000 fallback for Safari and jpeg fallback for older browsers. But Affinity to my surprise can't write these files. I'd rather not add extra steps like exporters in the workflow and like to do everything with the great Designers Export persona. As that's the whole idea of the export persona automation and it would be very time consuming and unneeded steps to use all kind of exporters after exporting every time. So I herby kindly ask Serif to add at WebP as a format to the exporter of both Photo and Designer (and Publisher too?). And preferably JPEG 2000 too (for Safari). Thanks in advance

Yes! Part 4 just went live, and it has some pretty interesting stuff and things you might not expect... but really happened! 😎 Enjoy it everybody, hope you have as much fun reading as I had researching, writing, illustrating and programming it! After this part there will be two more parts (up to six in total). Collect them all 😉 English: The History of Interactive Computer Graphics - Part 4 Dutch: De Geschiedenis van Interactieve Computergraphics - Deel 4 @Alfred @Madame @Roger C @GarryP @Wosven @A_B_C @WatcherMagic @John Rostron @Renzatic @dutchshader @CLC @SrPx @haakoo @telemax

Busy finishing the writing for pt4 now to publish tomorrow.... But wow... the story of Atari vs Amiga vs Commodore is quite something... pretty interesting stuff and impossible to keep it as short as some other items, just because it's such a story! Love it 😎

Working hard to finish my blog post on time! It's starting to look like I'm writing a book about interactives, computergraphics and animations! Part four will go live this week and it's pretty interesting stuff! 😀 correcting-blog-4-1920x1080-24fps.mp4

Thanks @Sean P. That's very much appreciated!

Not sure what your motivation is for these kind of responses, but it's not coming across as helpful to me.