fde101

There is technically a way to get this working now, but it is a tedious process made more tedious by a few seemingly arbitrary limitations (some of which are probably bugs). Make sure the Links panel is open. Within the group that you want to use as the mask, select each object (not the group itself, sadly) and choose Duplicate Linked from the Layer menu. Select one of the objects (the original or the clone) and drag the other one from the Layers panel onto the Transform box in the Links panel to link the transform (as the transform is not linked by default when using Duplicate Linked - everything else is). Drag the duplicate layers out of the original group and group them separately. Select one of the groups (either the original or the one containing the clones) and drag the other group from the Layers panel onto the Group box of the Links panel (yes, you can link groups separately, so why can't you just use Duplicate Linked in the first place? Silly arbitrary limitation or a bug?) Drag the duplicate group's icon on the Layers panel onto the thumbnail of the Layer you want to use it as a mask for. Now for both the grouped objects and the groups themselves the clones used as masks will follow the originals due to the links - the one major catch is that if you add an object to the group, you will need to separately duplicate it, link it, and add the linked copy into the other group. One obvious bug that I discovered is that if you have two layers selected and choose Duplicate Linked, both of them are duplicated, but only one of them is linked instead of both. It seems that in order to make this practical, two hopefully simple changes would largely cover it: Allow Duplicate Linked to be used on groups, and duplicate the group along with its content, linking ALL of their properties for both the group and its content (including Transform). This can be done manually now using the process I described above but it is annoying, time-consuming and tedious. When using Insert Inside and creating or pasting an object inside of a linked group, paste a linked copy of the same object (including its transform if the transform is linked for the group) inside the group(s) that are linked to it as well.

I don't think anyone is going to argue that this is a sorely missing feature, but you might want to take a look at the new Layer States feature that was added to version 2.4 in the meantime. When combined with use of master pages this may give a reasonably usable work-around to this missing feature for some use cases. By no means is it ideal for all cases, but it should at least make some of them reasonable to deal with, and may even be better for a few. That said, I too look forward to an eventual implementation of the real thing.

It would also be nice to have the option to apply them to global colors directly without breaking the link between the global colors and the objects they are applied to. Obviously this would mean that all objects using those global colors would be impacted - but that is kind of the whole point of them, so that makes sense.

Most probably could, but that is not what I am getting at here. @Pšenda had suggested that this request be redirected to the libraw team, and I am suggesting that this particular format is unlikely to be supported by libraw and that the request would likely be better handled by Serif incorporating the BMD BRAW SDK to be used in place of libraw when handling this particular format.

Perhaps not from a user perspective, but from a technical perspective they are rather different. For one thing, consider how BRAW is described by BMD themselves as a "partially debayered" lossy compressed format. The libraw library is designed for "true" lossless RAW images, which BRAW is not. A BRAW file is already partially developed by the time the library would gain access to it, and has already had some data thrown away due to compression, so it is really a unique format which would require specialized development for the library to support - it would need to handle it in a way that no other format is handled - so given that BMD already offers a free SDK of their own there is probably little incentive for the libraw team to reinvent the wheel on this one. Serif could incorporate the BRAW SDK to support this format and still present the same basic user interface that they do for "true" RAW formats to the user, but use the BRAW code from BMD to perform the processing instead of using libraw, so this is not necessarily a user-facing issue - rather a technical one in how it would be implemented behind the scenes.

The cameras sold by BMD are sold purely as cinema cameras, with a focus on video, and still capture as something of an afterthought meant to help support video capture. They do not really have any kind of investment in the still photo world, so given that stills shot with these cameras are generally thought to be in support of some video project, converting them within a video editor does not seem all that unreasonable as you would normally be opening it to ingest the video footage anyway. If you happen to be on a Mac, and want an alternative application to perform the conversion, GraphicConverter can do it. BMD has a free SDK of their own available which is likely a better choice for this format. I doubt there is much incentive for libraw to implement support for this one. https://www.blackmagicdesign.com/products/blackmagicraw

Barcode fonts have been around for ages and there are a number of them floating around if you do a search. One example: https://graphicore.github.io/librebarcode/

For 1D barcodes, yes, and barcode fonts are the traditional solution for this. For 2D barcodes (QR codes and the like), no.

Even more specifically, this was only ever present in the non-App-Store version of the Affinity apps. If you bought them from the App Store, updates are controlled by the App Store, not by the Affinity apps directly, so this does not apply in that case.

Yes, in the form of every thread in this section of the forum which actually belongs here and follows the guidelines. Just "like" the post to vote for it, but note that votes don't really mean anything. Serif decides themselves based on their own internal criteria how to prioritize things.

Problem is, they are developing it as a web app. That has never been a good thing for something intended to be a professional creative tool with an extensive feature set, so I for one am not really giving them the time of day, much less would I consider investing in them. Even if they did manage to pull off a decent feature set, would my documents still be saved locally on my computer, instead of in some cloud solution where I would have less trust in maintaining control over access to them? Ideally I would be looking for something designed natively to run under macOS, with a native macOS interface, and designed to take advantage of its unique technologies. Failing that, a second choice would be a cross-platform app that at least makes a reasonable attempt to fit in well in the macOS environment, still running natively on the hardware in front of me (not on some server under someone else's control). Web apps have some utility as add-on products in various situations, but they are never really optimal for primary creative / productivity apps.

Not sure why this would block access to GPUs as even a number of Intel-compiled games for Windows run smoothly with accelerated 3D under ARM builds of Windows 11. For moderate project sizes I would not think the translation layer would be a major performance barrier - slower than native, sure, but it's not THAT bad, unless you are pushing the limits of what the system can handle with a relatively large/complex project. Note that the x64 emulation is only provided by Windows 11 on ARM, not by Windows 10, so the Affinity apps would not work under Windows 10 on ARM - only on 11 - but I'm not sure why GPU support would be a limitation. The CPU type should be completely irrelevant to that.

And here is yet another thread on this...

I would rather pay $100 a year to upgrade a software product than a penny a decade for a subscription. Ick. No thanks.

I believe the intended workflow is that you select a vector shape (such as a rectangle or a cat) then use the color picker to pick a color from somewhere else in the document to apply it to that shape. It is fairly obvious when paying attention that the tool was engineered around a vector workflow, not a raster one.

This is not at all clear. There are plenty of companies which own other companies but have different business models from the companies they own. Image-Line (makers of the DAW FL Studio) own several highly recognizable plugin vendors (ex. UVI) which have very different business models from I-L itself; they have owned several of those companies for several years now and have not made any attempts to change their business models. I am taking a wait-and-see approach on this. There is no point speculating, only time will tell. No, in other words, you will need to pay for version 3 just like you had to pay for version 2 when it came out. Free updates to v2 for those who own v2, then pay for v3.

When "Apply to Selection" is not checked, the color which is picked up is placed in the circle used by the color picker which is embedded in the Color panel, which you can click on to set it as the fill or stroke color (depending on which of the circles is selected there). It is not directly selected as a stroke or fill color, possibly because doing so might have the side-effect of setting the fill or stroke color for whatever is selected? Alternatively, you do not need to have a layer selected if the "Source" is set to "Global" in the context toolbar. If you keep all layers deselected, then you can leave "Apply to Selection" checked and the color will be set by the tool without impacting the colors of the existing layers.

One problem you are going to face is that as soon as you export it to some vector format it will *always* be an approximation of some sort. Sine and cosine waves are interchangeable with each other, but neither can be perfectly represented as a Bézier curve, and they cannot be coded into most vector graphics formats. There is some discussion around this here: https://math.stackexchange.com/questions/4235124/getting-the-most-accurate-bezier-curve-that-plots-a-sine-wave PostScript does have a few trig functions, including sine and cosine, so PDF might as well (I can't seem to figure out the right search terms to identify this), so it *might* be possible to code this into a PDF, but other vector formats (such as SVG) would only be able to contain approximations.

One thing to remember is that Photo *never* actually opens a JPEG. It always works with its own custom document format. When you "open" / import a JPEG image, it is being placed on a layer in an Affinity document. When you "save" / "export" the document, you are exporting the Affinity document, not just the JPEG image. Even if the image itself was not touched, you are not exporting the original JPEG, but the Affinity document which just happens to match its appearance. Consequently, you are not "recompressing" the JPEG, but newly compressing the Affinity document which did not previously exist.

It does that. All of the Affinity products do; this does not mean there is a leak. If you had evidence that there was a leak, then it should be filed as a bug report. This part of the forum is meant for feature requests. Bug reports go here: https://forum.affinity.serif.com/index.php?/forum/71-bug-reporting/

The problem here is that the export persona is decidedly biased toward artboard-based documents, while Publisher is intended primarily toward page-based documents, with rather different requirements for export and publication. The Photo persona in Publisher makes sense to allow manipulation of photos embedded within publications, and the Designer persona similarly to enhance the ability to work with vector artwork within publications, but while it is possible to work with artboard-based documents (as well as standalone photos) within these personas within Publisher, that does not seem to be the intended function of their inclusion. Including the Photo and Designer personas within Publisher does not strike me as an inconsistency in these statements as their inclusion does well to support Publisher's primary function of supporting page-oriented print-focused document preparation, but the additional personas (Export, Tone Mapping, Liquify) do not really contribute toward this purpose, and so would be much more out of place within the product.

It probably will as Serif has consistently indicated over the years that they have no intention of merging the apps; examples:

This section of the forum is for feature requests. Bug reports belong in a different part of the forum.

Referring to this:

Publisher does offer limited access to the Develop persona, but it is slightly hidden. If you insert a RAW image, the context toolbar shows a "Develop Image" button that switches to the Develop persona for that image. While Photo does allow access to the Develop persona for non-RAW images, it doesn't really make that much of a difference since just about everything that can be done in the Develop persona with a non-RAW image could be done just as well in the Photo persona. What is really "missing" in Publisher mostly amounts to the Liquify, Tone Mapping and Export personas. Personally I think that is fine - I would rather they add a Prepress persona to Publisher and a Tracing persona to Designer.