Friksel

@kwebble you wrote you started a file with sRGB color space, but that's not what the 'titlebar' says in your screenshot. There it says 'ROMM RGB', which is a much wider color space than sRGB.

I just posted a bug issue about this, because it's not right that the color preview changes when opacity changes. There's no way the color preview could ever know how the final result of a color mix with everything underneath it would look. So using opacity (transparancy here) into account with the calculation of the preview-color doesn't make any sense and is confusing and unexpected behaviour. We should see the actual result mix of the color sliders instead without influence of the opacity value.

When we set our colors to, like, full red in the color panel, the color preview displays full red as expected. But when we than change the opacity, the color in the preview-circle gets lighter. That's not what we might expect and it's actually wrong, because this color preview doesn't (and can't!!) take in account what lies underneath this color (and in what blend mode an object using this color uses is in), which would affect the mix of colors. The color-preview circle should always display the color as a direct result of the sliders. The opacity slider should never affect this preview! In fact, nothing else apart from the color sliders/wheel/boxes should ever change this preview, because this preview should show the result of the COLOR channels we picked! No opacity: With opacity;

I see in your screenshot something is off indeed. But if I do what you did in Photo here, as you described in the quote above, I just see a perfectly red color on 100% red and 0% blue and 0% green. So no orange here. Sorry if I can't help you, but maybe it helps you to know it's not orange everywhere when doing what you described. Could it be something is off in your file? Like did you use transparancies or something like that in your color? (when changing the opacity slider in your color panel to something less than 100% the color also changes in the color panel color preview-circle. [edit] I see in your screenshot for some reason your opacity slider is disabled. Not sure why and when this might happen. Maybe that's related to this problem? no transparancy: with transparancy:

Without reading your post I would say, YES you need Publisher. But after reading your post I fully agree with @MikeW on this. If you just use designer to create labels to be placed inside guitars, just stick with designer. It's great software that does the job perfectly. As @MikeW wrote, if you need to write documentation, need to work on different pages or have to do some advanced text-styling with paragraphs and floating photos inside your text, only than you might benefit Publisher.

This one just as a shoutout to @Ash. Watched the presentation again yesterday and it was just a flawless and nice enthousiastic presentation, well spoken and well prepared, but still looks spontanious! Very nice to watch something going so well and fluent! Just saying

I'm using masterpages for general layout for letters with address and stuff like that pre-printed on it. Than I have some masterpages using the first masterpage as described above and put preformatted labels on top of that default letter layout. With this I created a new masterpage for startPage, middlePage and endPage of a letter to a client. I pre-created some pages using these startPage, middlePage and endPage masterpages with content printed on top it for the letter-body and values after the pre-printed labels, like subject of the letter and to-address. ... But now I'd like to put a new type of letter-layout, also based on the same letter-layout, in the same file. This time not a general letter-layout, but an invoice layout. So I will create some additional masterpages also using the bass masterpage, but this time with a toplayer with different pre-printed labels on it, like prices and tables or whatever. And for this invoice layout I now also need to add a dummy layout page to be ready to override when I use this layout to create an invoice. ... Now I'd also like to add some other specific letter layouts to the file. Also based on the first masterpage. So again I need to create some pages with the right layout already filled in with dummy text as a placeholder for when it gets used. ... If I like to use this file in practise it's full of all kind of pages I will only need 1, 2 or 3 off. So I would copy my main afPub-file with all layouts in it to a new file. Than I have to delete all pages I don't need for this letter, write the contents over the dummy content and export it to a pdf to send it. But if I'd like to use some page-templates later they are gone from this file (because I'd deleted them), so I need to copy them over from the main-file again somehow. That's not very practical and efficient and quick. While this is doable, I wonder if there isn't a better and more efficient and convenient workflow to do this. For this it would be nice to have a way to create page-templates. So to store the pre-created dummy template-pages inside a page-templates-list. That way we could keep our pages list empty and pick the page-template we would like to use from the templates when we need it. I'd like to paste this to the feature request forum, but I'm not sure if something like this doesn't already exist in Publisher. Does anybody here knows if something like this is build into Publisher already? Thanks in advance!

Looks like I can't reproduce this in 1.7.1.404, so it seems like this it solved! Hooray!

Yeah, the help could definitely use some love. There are some important things missing and it's not always written in an easy to understand (and nice to read) way. Also some hyperlinks to other pages in the help would definitely help to dive deeper into the matter. Now it's all based on the search. That said, it's great Serif got some help in their programs and it's nice to have a manual inside the app. With a little extra love this could be a very important source to get information.

I don't mind having a setting that let users switch the 'save with document' per default to on. But this setting should at least be per default set to off. For users that want it to always be on they can switch it on, but new users not knowing about it, or advanced users didn't think about it, don't forget to turn it off. Leaving it on is not only resulting in big file sizes, but just like the Affinity message state: a lot of designers might send the Affinity file to collegues or maybe even an external party, and don't want them to view the whole history to know how everything was build. I would not want them to go all the way back to see how everything was build, because that's not for them to see.

I thought so too, but there happens to be no trial of publisher available at the moment. Still even buying it just to try for 40 euros now it's not that bad I'd say.

Although this is an older post; underlines under anchor tags ('hyper'links) in html are also called text-decorations in css stylesheets. So it's not only called like that in graphic design software obviously, so in that way it makes kind of sense.

Sorry, I didn't read this whole thread, but I'd like the idea of having scripting in Affinity and would use it for sure to solve some repitive tasks. I would definitely go for Javascript. It's the fastest growing language a lot of people already are familiar with. Not only for websites, but also for use with NodeJs and even Windows programs itself. All editors can work with it, it's easy to learn, not too strict, there an enourmous amount of information about it online, we could use parts of the scripts directly in web applications if needed (and visa versa) and it's super multiplatform. There's also a lot of support for IDE's and text-editors for Javascript and there's active development on the language which is growing a lot last years. Also people coming from Adobe and did scripting in Photoshop or for example After Effects are used to the Javascript inside Adobe, so they don't need to switch a language either. Not the best reason maybe, but still a plus. If I would be Serif I wouldn't look any further and use Javascript. Also there are a lot of libraries they could probably easily implement in the software to have Ecmascript (javascript's 'base') working. My preference would also be to be able to at least import a javascript script directly from file or even better: live reload (like a watcher), so we could create the javascript script with an external editor like VS Code and Affinity would update/reload the script automatically when saving the file in VS Code. That way we could use all features from the IDE of our own preference and Serif doesn't need to build a full javascript-editor to do that. My guess is that scripting would be done by more advanced users anyway and I don't believe they would mind it if there would be no editor onboard in Affinity products and could easily find and use an external editor. By the risk of repeating what everybody here already said or discussed (and I didn't read)... My 2 cts

I don't think that's currently possible. That said; as a workaround you could just temporarily drag the masklayer out of its pixel-layer, scale the pixel-layer and drop the masklayer back on the pixel layer. That way your masklayer-shape is still the same while your pixel-layer is streched.

Looks nice. Also nice work on your behance portfolio! Nice stylish maps there!

Please no. I don't want to sync through some 'external' cloud-party. I'm glad Affinity didn't follow that Adobe path. Just a way to copy files, like json, xml or an official Affinity extension to move brushes around to other systems would fit my needs perfectly. Or a sync-button would be fine too. And that wouldn't be even nececary, at least on the Windows instatllations, because all three Affinity applications already have a generic place to store generic files: the 'Affinity/Common' folder. That way all three programs could reach all generic files already and there's not even a need to copy files over, neither have duplicates files installed on the same system.

The lock-button in the color panel says 'Lock colorSPACE'. But that's not at all what it does. It's only locking the selected view-layout of the color-panel. I call this a bug, because this text is not at all right and looks like a typo or some quickly set text that's never really got checked before a release. Lock has nothing to do with color-spaces, not even with the color-model the document is in. Calling it Colorspace is not only wrong, but very confusing here and leads to mis-understanding and even fear about what this lock does. Color models and color spaces are already confusing and complicated enough, so please change this tooltip to something not connected to that and easier to understand. I would also advise to avoid terms like 'color mode' (like seen in the help-file), because than it still feels like there's some connection with color models and color spaces. Why not something more descriptive and understandable for designers, like 'Lock color panel view', 'Lock color panel mode' or something like that, in my opinion that's way better to understand for users and prevents confusing with (and fear for) color models, spaces and profiles. or misconceptions. Than we understand directly what it does without having to fear it's technically affecting our color space or model of the document. I think than more people might start using the lock button too, because then there's no fear of technically changing some color thing in the back causing unexpected color problems. (This also counts for Photo and Publisher)

Thanks for finding this. I must have overlooked this. I had to re-read this piece of help-text some times, but now I understand it. I was confused because of the (wrong) tooltiptext in the interface, saying 'lock colorspace'... Actually what it does according to the helptext and what I see happening now, is that, when locked, the color panel is somewhat behaving like we would expect: after switching to a different view-mode to select colors it stays that way while working with all elements inside the document until we end the session (so close the file or quit the software). But if we unlock it, suddenly every object has its color-panel-view-mode remembered from how it was during creation of the element. So if we create an element when the color-panel was in the RGB view mode (so we saw 3 r, g, b sliders) it remembers RGB-view-mode. So when switching between object-selections it also switches the color panel to the 'state'/color-panel-mode, it was in when creating. So if we were selecting object B which was once colored using the 'HSL'-viewing-mode, it switches the panel from whatever viewing mode we were in to HSL. To be honoust, I don't know when I would find this feature useful, but maybe it could help somebody that likes to work that way. What I don't think is okay, is the name in the tooltip; that's confusing and misleading. It's saying 'Lock colorSPACE' and if I get the help-text right and based on what I now see what's happening, is that that's not at all what it is doing (and should not do!) now. The document has a colorSPACE, like sRGB, defined and I'm pretty sure we could not set elements inside that document to a different colorSPACE (like AdobeRGB or Wide Gamut RGB), because if that would be possible that would be madness all over the place, leads to a lot of confusing, unwanting conversions and would be very errorprone and lead to unwanted or unexpected results while exporting. So this has nothing to do with colorSPACES, not even colorMODELS the document is in.

In all three desktop apps there's this lock-icon that says in its tooltip 'Lock colorspace'. When it's 'locked' we can still change the dropdown to other 'color models' and so probably to their connected color spaces in the settings (?). I know about color spaces and models, but I'm not sure what this lock does. Couldn't find it in the help of Designer and nothing on this forum either. What does this lock do?

I understand. I personally hope Serif will start fixing some long standing breaking bugs first (like outline stroke and svg import export problems), than long awaiting feature requests like warps and image trace and UI improvements (weird opacity slider, renaming swatches, stuff like that, although great programs, a lot of improvements still could be done there). And hopefully only than, and if their team is big enough to maintain all applications, thinks about creating a new application. In other words: please stability and all the must-have features completed first before starting a new project.

Yes, maybe now Publisher is here Serif will catch up fixing these things!

I don't want 'resources'-software. Nor those cloud-based things. I just want to save a preset to a file or load it from a file. And who talks about a Windows-only feature? Like it's impossible to create a common-folder on Mac...

Not sure, but it looks like the 'svg masking'-bug:

Actually it would be nice if all apps could use the already exising 'Common'-folder to store these export presets instead of storing in their own seperate app entries! Like this: C:\ProgramData\Affinity\Common\1.0\exportPresets That way we could at least have the same presets available on all three Affinity products on the same machine/account! And when we adjust a preset it's synchronised throughout the other Affinity products on the machine. An export-to-file option would still be needed to export our settings by file to other machines and to backup these settings. But if all Affinity products would use this common-folder (they already have and use for other things, like clipboard and dictionaries) we would only have to paste these preset-files to just one folder on each machine!