fde101

Each object in an Affinity document is a separate layer - each shape, pixel layer, text frame, etc. shows up as a separate entity. The contents of a picture frame are separate from the frame itself, so that does nest an additional layer inside. There are a few other types of layers that could show up under various conditions. Currently, the only layers that are shared across pages are the ones representing the master pages that are applied to them. This is expected to change at some unknown point in the future - try searching for "global layers" on the forum to see the discussion that has already happened regarding this. The Designer layers tutorial should be relevant: https://affinity.serif.com/en-us/tutorials/designer/desktop/video/301623317

Yes, obviously.

That appears to be the profile selected for printing, which is separate from the one set for the document. If the document has one color profile and you are trying to print in another then Publisher needs to convert them which might account for this difference.

yep There are plans to address this with a new layer type in the future.

With a plugin model, presumably the Affinity applications themselves would expose a common document model to the plugins, so the existing Serif code would handle those details and the plugins wouldn't care. I agree that supporting file import/export plugins would be a nice plus, and should be quite feasible.

@JerytheKID, welcome to the forums! No, Serif does not generally provide timelines for when specific features will be implemented.

In this case it simply won't be possible for some people to meet their requirements. I've never seen ANY evidence supporting this common theory. No scripting solution that can integrate multiple applications across an environment can be at this point due to security restrictions within the OS. To fully meet the requirements of production workflows on both platforms, this will almost certainly be necessary. Yes, it is. Unfortunately not possible to do in isolation. As I explained previously in the thread, there are two major use cases here with different and currently conflicting requirements: The ability to script within the application. This can be done with a cross-platform scripting language which could be selected by the Affinity team and integrated into the product; I proposed Lua due to the fact that it is engineered for this purpose and is likely to have the fewest security hazards and be the easiest code base for the Serif team to maintain - others seem to prefer ECMAScript (JavaScript) which has interesting semantics in a few places (but the syntax stinks) while others clearly prefer that snake thing for some incomprehensible reason. Using a common language across platforms for this has the benefit of allowing scripts to be written once and shared by users on multiple platforms. The ability to combine multiple applications. This cannot be done with a language integrated into the product and must use a solution provided by the host operating system. In this case, to support the needs of users integrating applications within their workflows, there is no choice. For the Mac, it must be OSA (AppleScript); for Windoze, it must be WSA (VBscript I think?) Note that much of the work required to provide this support, if carefully designed, can be done in such a way that all of the requirements could use a common base within the application code, minimizing the amount of effort to support multiple scripting languages (and a plugin interface). If a system is set up internally which exposes a "document model" that is common to plugins and to the various scripting languages, then the general scripting support could be implemented internally once, and the various languages and the plugin interface could hook into that common model. In this way, most of the "application" side of the scripting interface could be coded and maintained separately from the specifics of the individual scripting languages (OSA, WSA, Lua/Perl/Snake/CrypticThingUsedOnTheWeb/etc.) and from the native plugin interface. Then people who wanted to use the internal scripting language could do so, those building workflows across applications could use OSA/Applescript on the Mac or WSA on Windoze, and native plugin writers could hook off of the same document model. As the applications expand and add new capabilities, Serif would only need to update the document model once and plugins and the scripting languages would all fall in line.

Make sure the color profile set for the document is correct (in Document Setup -> Color). That would be my first guess.

I don't believe this is related to the export format. Affinity Photo does this internally without even exporting - I made a video to demonstrate this which is on another thread:

Thanks, I hadn't noticed that bug post until now. I didn't add one because I don't recognize this as a bug. It seems to be an intentional design choice in the engine, and not related to the export format, as it happens without an export. I was responding as part of an explanation of a post already on this thread, which is why it is here. Nevertheless, I will link back to this from that bug post as it does appear to be related.

Actually, the brush is a bad example - shapes are more telling. Here I created three rectangles filled with one shade of blue, and three with a sort of greenish shade that still has some blue in it. I gave all of them white strokes so that the strokes would stand out when looking at all of the channels. opacityZero.mov Note that in the end, looking at the blue channel only, the rectangles with 100% opacity and the ones with 1% opacity look exactly the same, but the ones with 0% opacity disappear (except for the white strokes). You can see from this that the channel in general is not pre-multiplied - it is not reflecting the 1% vs. 100% opacity - but there is something about the implementation that is causing the 0% opacity to drop off. You can also see that the two different colors are reflected as different shades in the channel, so it is not showing the channel as a black/white mask or similar: it is reflecting the actual channel values. This is NOT a PNG vs. TGA issue - it is something in the implementation of the alpha channel within Affinity Photo itself.

The PNG and TGA file formats are both defined as NOT pre-multiplying the alpha channel. As both are also lossless formats, if PNG is being exported without the added transparency data, there is no reason to expect it would be any different for TGA. This is a software implementation issue, not a characteristic of the file formats. Try this: in Affinity Photo, create a new document with a transparent background. Switch to the brush tool, choose a blue color, with opacity at 100%, draw a quick vertical stroke somewhere on the canvas. Then keep the same blue color selected but reduce the opacity to 0%, and draw a second stroke right next to it. Go to the channels panel and turn off the visibility (eye icon) of all channels except the blue one. You will only see *one* brush stroke. When opacity is at 0%, the color data is not even being recorded by Affinity Photo, so there is nothing there to export. It is not just brushes either: the same thing happens with shapes. Affinity Photo is "optimizing away" anything with 0% opacity internally, so it doesn't matter what format you export in - you will see this same behavior.

It is only subscription on the app store - if you purchase off their web site there is a perpetual license available: https://www.coreldraw.com/en/pages/ppc/coreldraw/mac I wish Apple would go back to forbidding subscriptions on the app store; they are resulting in lots of issues like this. Right now CorelDraw on the app store has a two star rating out of 60 ratings and most of it (if you read the comments) is from might-have-been-users complaining about the subscription model.

I would suggest adding an "insert" icon to the context toolbar somewhere that could be dragged into the table where you want a row or column inserted. Much as there is a hint line in the layers panel as to where a layer is being moved, as you drag that icon into the table, it could draw a horizontal or vertical line to show you where the new row or column will be added.

Betas downloaded from the forum will activate if you have the MAS versions of the released apps.