MmmMaarten

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.

+1 for a real perspective grid!

@walt.farrell @Wosven @carl123 Guys, I know what's happening here. That's why I posted this issue. Telling what I already know doesn't solve this issue. That's up to Serif. To clear things up further: 1) I saved the afdesign-file right before exporting, so I'm sure nothing has changed. 2) I didn't change any export settings. 3) Export settings and export path aren't saved in the afdesign file, but globally instead at app space. To verify this just open file a.afdesign, export it to a jpg and save a.afdesign again. Open file b.afdesign and export it to a svg. Than open a.afdesign again and see it's not on jpg, but on svg. That proves the settings aren't saved into the afdesign file. Also the export path is clearly not saved into the file, but stored globally too. 4) I test things several times and don't post an issue if I'm not sure

After exporting to a file (to svg or jpg for example) of an already up-to-date-saved afdesign-file, Affinity thinks something has changed to the file (even though nothing has changed), and asks us to save the file when closing the tab. Even if we didn't change the export settings. This makes this confirmation box unreliable and therefore error prone, as we can't tell by this message if something really has changed, or it's this issue again just saying something has changed, but is not.

Looks like you posted this accidentally into the wrong forum. If you post this into one of the 'Report a bug'-forums chances are the developers see your post and can fix it.

This has been requested a lot of times already. Do a search on 'animation' and these are the results: https://forum.affinity.serif.com/index.php?/search/&q=animation

Yes, these are the most important ones as these would solve a lot of confusion, complexity and errors. Next to this my suggestion nr 2 in the initial post is: make 'join curve' usable for both connecting at front as well as connecting the nodes on the other side, so both joining AND closing. So we don't need to think about when to use 'join curve' and when to use 'close curve' anymore either when connecting two curves head AND bottom all the way around. A lot more user friendly if we could just select two lose ends and press 'join curve'. And do the exact same action with the other open end-nodes. 'Close curve' would still be needed, but mainly to use when trying to close open single curves that were single in the first place.

No, that's not what I'm trying to do. I refer back to my initial post.

Yes, I understand when this feature starts working and I've seen it working several times now as you can see in the videos above. But in some cases it's obviously not working without turning off alignment of handles.