MattP

Hi doodleskull, I do intend to add this - but as Miguel says, I've been constantly distracted by other things that need to be done. I'll see if I can ind some time to add an option somewhere soon... Sorry about the delay :( Matt

Hi JDW, Thanks for the link - I'll take a look when we're looking into it. There are a number of very easy steps to reduce the file size dramatically - and at the moment we do none of them, so I can imagine certain files could exhibit huge savings. Thanks, Matt

Unfortunately, the colour RGB(50,177,65) specified in Adobe RGB (1998) looks the way it looks... I have created a PhotoShop document in the Adobe RGB (1998) colorspace, used the same RGB values and taken a screenshot - try picking the colours and you'll see that they are identical. I don't believe Affinity Designer is doing anything wrong at all when you do the assign process I described. (Affinity Designer on the left with your document changed to RGB8, then assigned to Adobe RGB (1998). PhotoShop with RGB8 document and Adobe RGB (1998) profile on right) By choosing to convert, you are telling the program to convert the colours to try to maintain their visual appearance as much as the mapping between source and destination profiles will allow - but that means the RGB values will change. Be sure of what you are trying to achieve... Do you know the profile the Pantone RGB approximate values was specified in? If so, then assign your document to be that profile and they will look the same. If you want the colours to look as close as possible but use a different profile then you need to convert to the other space but you have to accept that those RGB values have to be different to the ones you typed in, because the ones you typed in look different with different profiles.

Hi ottobyte, The back-end already has b-splines and can render them to the screen. Our curve classes already load and save b-spline data. We don't have a tool to create them yet, but I haven't overlooked them - they've been in the code for at least a few years now and a tool will exist at some future point - but there has been strangely little interest in them to this point, hence why I haven't made it a priority yet... Thanks, Matt

The fact that the Illustrator-produced SVG is only slightly smaller is frankly astounding, because no effort has been made to reduce the file size of the exported SVG yet. When we start looking at file size then it sounds like we can hope for a good reduction.

Can I just mention that adding bevel emboss effect does per-pixel lighting, shadows are generated per-pixel, glow is per-pixel, noise is per-pixel, etc - so you're doing many things for each pixel which require non-trivial algorithms. Most of these algorithms also involve a convolution stage that requires sampling input from a large number of surrounding pixels for each destination pixel so when you multiply all of this up to being how large your image is on the screen and how large the effects are on the object then that is the reason your cpu is busy - it simply takes time to work out the answers. There are shortcuts but these result in inferior results so we don't use them. Other programs choose to cache the results so you can use the program smoothly after an initial lumpy delay - we don't do this because: 1: it takes memory, 2: it is cached at a particular size, so when you zoom in you would start to notice the pixellation. This is the only real alternative to it using your cpu to generate the effect at the required resolution per-frame.

Exporting of SVG slices will soon be available, this will resolve your whitespace issues. File size will be optimised in future.

Fantastic work again, Lescot! :)

Hi Hokusai, No, this makes perfect sense - I will try to add it, thanks :) Matt

Hi Slettli, Thanks for that. Basically, your document's RGB profile is currently set to sRGB - this is the application default. You have a CMYK document and when you are going to the document setup dialog and choosing to change it to be RGB8, you are also choosing to change it to Adobe RGB (1998) at the same time and this is where the problem arises... It is doing a single command to convert your colours for the closest representation through the colour spaces you have chosen, so this is why your colour values are being changed to different RGB values. Instead, do this process: Open your document, go to Document Setup. Now choose RGB8 format and press OK. Your document is now in RGB with its default sRGB profile. Click one of your colours and you can verify that it is still showing the correct values in the RGB readout. Now go back into Document Setup and choose the Adobe RGB (1998) profile and choose the button to Assign the profile (i.e. without converting the colours to be perceptually similar) and press OK. Now your document will have assigned the profile and left your colour values alone. Check this by selecting one of your colours and the value will be as you'd expect. In future, you can avoid this by making your document with the correct RGB colour profile. If you know in advance that you will often use the Adobe RGB profile, why not choose this as your default in the Preferences option - this will hopefully save a few headaches over time :) We will hopefully be able to allow a per-format assignment of colour format in the future which will avoid you having to do this 2 step procedure. Hope that helps, Matt

Could you possibly provide me with some information about the colour you're using? i.e. RGB8 document set to Adobe RGB (1998). Input colour = RGB(255,0,0), Observed Colour = (x,x,x), Expected colour = (y,y,y) so that I can test it?

Hi Slettli, I'm a little bit confused of what you meant when you said "but printing will have a rgb 1998, 8bit"? The first thing I would definitely advise is to use the latest beta version as it has a lot of changes relating to RGB/CMYK colours and their correct proofing. If you could give us a little more explanation of what exactly you're doing and/or the .afdesign file (or part of it) then I'm sure we can offer some specific support and get you to the right answer :) Thanks, Matt

Hi Quarter, Is there any chance you could either share the .afdesign file with us, or even just post a screenshot? It's just so much easier to help if there's a concrete example :) Thanks, Matt

Nice video, Alex :)

The autosave file is a failsafe - if you happened to crash then we would know you didn't shut down cleanly and would offer to load from your autosave. If, however, you are given the option to save when shutting down normally and you chose not to save, then the file would be in its original, unmodified state and any autosaves would have been deleted on shutdown. So the behaviour is: If you say 'no, don't save' then your file will be the way it was when you last chose to save it. If you crashed the application then it would offer to let you recover your autosaved document state as you'd not been given the choice to save or not - because something had gone wrong. Thanks, Matt

A tooltip sounds like a fine idea to me :)

Hi newuser :) I just had a chat with some of the guys here and apparently there were a number of issues specific to OS X Lion that have been fixed but are not included in the current Trial version, or even in the current Mac App Store version. The changes are available in the beta version of Designer, but the beta will not run for you unless you have a purchased version, sadly. So at the moment there's no way for you to try it out :( I would like to take this opportunity to reiterate what was said above - that Designer is usually very stable and usable. I'm sorry that you're experiencing these problems, but they're unfortunately down to it being used on OS X 10.7 - which is something we have identified and resolved, but without purchasing the Mac App Store version and then downloading the beta there is no way at present for you to try these functions :( We will look in the future to enable the beta to run on machines with a valid Trial period. In fact, I will look at getting that to work before the end of this week and hopefully update the beta version so that it is possible for you to try it. Thanks, Matt

Thanks for that! :) I've got the files now - I must say it's not acting as I'd expect either, but I'm wondering if this is a problem with embedded documents? I'll ask Ben to look at this for me when he gets in and then try to report back. Sorry about this in the meantime... :(

Also, I'm guessing you're using the Mac App Store version that had a bug where it would only export at a set 72dpi at all times - the latest beta version correctly writes the document dpi into this field :)

Hi monk :) Have you possibly got a simple example that you could share with us and I could ask Ben (who wrote the snapping feature) to give you a run through what's going on? Thanks, Matt

Hi monk, 1 is definitely a good idea :) I agree with you on point 2. I think that for point 3 you might be best taking a quick look at the snapping tutorials on our site (here) - you should be able to snap to anything on any layer - but it's all a question of candidates - watch the video and you'll get the idea :) Thanks! :) Matt

Things are never as clear as they may seem to be from the outside... Why were we playing with our iPads? Well, one of the reasons is that when you play with the iPad version which is CPU-starved, you find bottlenecks very easily and I have now been able to improve the performance of certain layer effects in all versions (i.e. the desktop machine benefits from this) and have set myself some other targets to look at or do differently to speed up all versions of Affinity. There have been precisely zero extra features added to the desktop version and not one unnecessary line of code has changed. The iOS version is a separate target and builds using the shared back-end as-is without modification, so there are no harmful side-effects to stability or bloat. I'd personally like an iPad version - but that's because I can imagine where I'd use it, and also because I've actually been able to use it and I can see that it's actually quite a lot of fun! That said, we wouldn't let it have any negative effects on the desktop version - there's no need and no point :) Want to know what your UI design will look like on an iPad? Well, there's no need to export it or 'mirror' it onto the iPad's screen - just load the file/handoff straight to it and then tap a button to hide the editor UI! Make tweaks to your design on the device itself - it's really liberating! :)

Brilliant! I think you're going to have a lot of work on your hands - everybody is going to want to see your version of their favourite shows! :D

Utterly amazing!!! Please can you share the .afdesign file with us? :) If you send it to support@seriflabs.com then I'll upload it to share somewhere if you'd prefer? Thanks! Matt

These are good ideas - thanks, VideoMonkey :)