R C-R

That is in effect what using Symbols does, although it is not limited to items in the Assets panel, if that is what you mean by "embedded asset." Asset panel items are not stored in document files unless they are added to individual documents, at which point they become independent of the Asset panel. Among other things that means if you delete an Asset panel item it does not affect any document that includes an item that came from the Assets. A similar consideration applies for linking rather than embedding: if the linked file is deleted, altered, or not included if the document file is copied or moved to a different computer, it would affect every document that included the linked item. There are ways to deal with this but they add significant complexity to both the app & user management of their documents. Basically, embedding means each file is independent of all others while linking means they share dependencies.

Just as an aside, a few days ago one of the staff mentioned that the free content had been downloaded over 100,000 times, so not everyone is having problems with this.

You are wrong. You do not have to buy the Designer Workbook to order the free content. You do have to create an Affinity Store Account to place the order, which you can do if you read & follow the instructions in the first post MEB provided a link to in his November 2 reply that appears just above yours in this topic.

Which in turn means every app that can export to the various different image formats has to deal with this somehow as well, & in addition to any IPTC core or Plus data and/or XMP metadata the file might include. As I said, all this is certainly doable, but there is nothing simple about it. It requires a lot of complex coding & frequent updates to keep up with the changes & additions of camera makers, who are not necessarily keen on the idea of making this easy to do. So my point is if this is really something we want Affinity to divert some of its limited development resources to implement, which (obviously, I hope) means other needed features won't get the attention they deserve any time soon? Aside from that, adding any complex code can adversely affect performance, require still more changes to the native Affinity file format, create bugs that affect the existing code base, & have other undesirable side effects that end users rarely consider & could further delay the development of Publisher & the DAM, if & when that project ever gets any attention. I am just trying to be realistic about this. It is all well & good to think about how great it would be if all the features supported by other apps were added to the Affinity ones, but considering the downside as well as the upside has to be a part of it. That is not an excuse, it is a reality that can't be wished away or ignored.

What exactly do you mean by "the left and right hand panels disappeared"? If you mean the Left Studio & the Right Studio, go into the View > Studio submenu & make sure the "Show Left Studio" & "Show Right Studio" items are checked, & that "Hide Studio" is not checked. If that does not help, try the last item, "Reset Studio." Note that the Studio panel & Tools panel layouts in separated & regular window modes are independent of each other.

But in reality is there really such a thing as a "pure" copyright? With so many different laws in different parts of the world governing copyright provisions, what defines the difference between infringing derivative uses & non-infringing ones, various statutory frameworks for determining fair use, lax or nonexistent enforcement of existing laws in some countries, & all the rest of it, I do not believe there is.

@Moustachey It is not the same thing as what you want to do but you may find the discussion in topic Packaging/3D mockups about using the two apps together of interest, particularly this post by @paolo.limoncelli & the ones that follow it.

Little Snitch is Mac software that selectively blocks outgoing connections, typically used to prevent applications from "phoning home." It isn't that Little Snitch is blocked, it is that it might block the connection to the Serif/Affinity servers. If you have not installed it then it does not apply to you. The process works like this: 1. When the Welcome screen opens, the Affinity app sends a request to the servers asking that they send updated Welcome screen data back to your computer. 2. The servers respond, sending back that data. 3. The Affinity app then updates the Welcome screen with the new content, including the offer for the free content with the "Claim Now" button. Little Snitch could interfere with step 1. Firewalls could interfere with step 2. Anti-malware (also known as "A-V" or "antivirus") software could interfere with any of the steps. Other things can also cause problems with this process, including (obviously) no internet connection at all & (less obviously) things like an ISP (Internet service provider) that erroneously blocks or misdirects connections intended for the servers, or server overload or network congestion that slows down step 2 so much that it could take hours to complete.

Of course. But the problem is if users write their own content into tags that precede the makernote tag the makernote may need to be moved to make room for the user content. To make sure that doesn't break the makernote tag, the app can't rely on Exif standards because according to those standards the contents (including any encryption methods, offset pointers, & so on) are left to the manufacturer to determine. That is why reverse engineering to decode at least part of it may be required, why 1:1 moves can be problematic, & why the tools that permit writing to the various tags require frequent updates & complex error checking routines to make sure nothing gets written to a location that would corrupt pointers, allow writing info to tags that would conflict with the info in other tags or violate Exif standards for length or formatting. Obviously, this is doable but it is resource intensive, if for no other reason than the camera manufacturers are constantly adding tags & changing the info they store in them to support new features. It is considerably different from supporting the major image file formats, which are quite stable & rarely change.

If you search these forums on "Publisher" or related terms, you will see that a whole bunch of people have not just noticed this but many have also expressed their feelings about the delay rather emphatically!

The problem isn't solved unless writing to metadata tags does not break the Makernote tag or cause any other problem with tag offsets, etc.

There have been so many posts about this that if you search the forums on "free content" you will get about a zillion hits, but the first post in the pinned Free Content included with 1.6 ('Till 16th November) topic should tell you all you need to know.

Off topic but this problem could easily be avoided if software makers simply avoided using those four characters in product keys. Why none of them have done this is something I will never understand.

OK, for example dive into the whole big picture for Nikon at http://owl.phy.queensu.ca/~phil/exiftool/TagNames/Nikon.html. Search the page on "unknown," look for the question marks, or note what it has to say about Nikon LensID Values: Or consider what he has to say at http://owl.phy.queensu.ca/~phil/exiftool/writing.html about writing tags: That page also includes other info about the problems & pitfalls of writing metadata tags, even with tools based on an ExifTool backend. So it seems pretty obvious that if we do dive into the big picture it becomes very clear that there is nothing simple about this, & that the issue is in fact a very difficult one to solve.

I think a lot of different points have been mentioned here, not the least of which is that just adding some variant of "© copyright" to any tag is, by itself, just about useless. Minimally, the usage rights & who claims them need to be defined as well, ideally both in the IPTC "core" & "Plus" extensions.

I am not so sure that is true. Consider the table from the link. From what I can tell, it only covers jpeg files generated by the listed cameras, so the tags in the innumerable RAW format outputs might be different. The table also doesn't show anything decoded, just raw ASCII & hex values for the first 20 (of how many?) characters in the tag. Judging from your reading and writing those back link, 'automagically' fixing these "particularly insidious" write-back problems is iffy at best, so "operator intervention" is required, meaning some technical knowledge and/or experimentation will be needed. If not done correctly, "some" (how much?) of the MakerNote information may be lost permanently. So I suspect if the dev team posts any comments about it, they basically will say that the 'breakage' issue is a very difficult one to solve, regardless of the available third party libs/code the apps might use.

According to the links posted in this topic, doing that is what breaks the MakerNote tag.

Did you try editing or adding any of the tags that precede the MakerNote one in these apps?

Since cropping is non-destructive by default, I doubt this would make much of a difference unless the additional step of rasterizing each image instance was also done (since that removes the out-of-crop part of the raster image). But I still think using Symbols would be more effective ....

As I understand it, there are other ways for companies to buy multi-user licenses for the Mac versions, but it is not clear if the licenses for them would qualify for the free-for-now bonus content, or how the app updates for the Mac versions can be obtained.

I am reasonably sure they already know about this, but as the link @v_kyr provided explains, the real problem is camera makers are using the Makernote tag for many different kinds of metadata that should be in other metadata tags that are not encoded in some proprietary format that require reverse engineering to decode, and/or break if the Makernote tag must be moved because another tag is added or inserted before it in the file's embedded metadata. IOW, Serif/Affinity did not create the problem, but it they would have to devote significant time & resources to fix it. This almost certainly is part of the reason why apps that do all the necessary reverse engineering & are coded to prevent the tag from breaking when a preceding tag is edited cost more.

Nope. All apps bought through the Mac App Store include an anti-piracy & anti-malware feature that locally generates a receipt file encrypted with the Apple iD used when the app was bought. If the app has been altered, for example by someone injecting malevolent code into it & distributing that as 'free' version, or if the receipts file is missing or has been altered, the app will not run. This protects both Apple's & Serif's "piece of the pie" but it also protects end users from malware posing as legitimate MAS apps.

When you say "edit the file in AD from AP" do you mean via Affinity Photo's File > Edit in Designer like @Callum mentioned? If so, one of the staff (@MEB I think) mentioned some time back that this & Affinity Designer's File > Edit in Photo could cause problems in certain workflows. Unfortunately I can't find the post now or remember the details well enough to say if this was in reference to crashing/freezing or something else, but I do remember that it was suggested to save any changes to the file before using these File menu commands just in case something unexpected happened. This does not change the file extension -- regardless of which app you save the file with, it retains the original extension applied during the first save. Since saving one's work frequently is good practice anyway, maybe give this two step method a try & see if it eliminates the freezing.

Have you tried making one of the duplicates into a symbol & replacing the others with instances of that symbol?

That may have something to do with this from the Exif Wikipedia article: EDIT: The link @v_kyr provided explains this much better.