nwhit

Having done this kind of work for decades, I don't agree at all with that. As pointed out, most graphics people use large libraries of inserted materials/content placed into a wide range of final publications, and they do NOT want things "messed up" in every document that contains changed/updated graphics/content. 

Having done this kind of work for decades, I don't agree at all with that. As pointed out, most graphics people use large libraries of inserted materials/content placed into a wide range of final publications, and they do NOT want things "messed up" in every document that contains changed/updated graphics/content. 

Having done this kind of work for decades, I don't agree at all with that. As pointed out, most graphics people use large libraries of inserted materials/content placed into a wide range of final publications, and they do NOT want things "messed up" in every document that contains changed/updated graphics/content. 

I'm working on the assumption that if using a particular image in multiple documents you may not want an edited version of the file to be updated in all documents so the option is off by default allowing the user to decide whether or not they want the edited image to be automatically updated when opening or editing a particular file...
It could be quite dangerous to have the option enabled by default, i.e., suddenly updating files you don't want to be updated...

Not for me. I turned this option off, because I want to control what happens in my documents.

No, it's actually one program with three different scopes of prioritized features. And this is the foundation of the StudioLink feature.
Probably because Publisher and Designer are made for, wait for it… graphic designers, not photographers?
Like vice versa: I'm a designer, not a photographer. Even though I use Photo a lot for specific tasks, I don't use, let alone understand every advanced feature that there is. And that's OK. 
Like in Photo, there are some really silly years old bugs in Designer and Publisher that need to be fixed, finally. 
Other than that, I ditched the Adobe CS apps five years ago (I never subscribed to CC), after using them professionally since 2003, and I have never looked back.
Your mileage may vary… 
Hear hear!
^ How time flies…  

I've been very pleased with Typeface also. 

Aha! Just saw that now, Walt! Old age and going blind I guess! 😆

Okay, after a whole bunch of searches and reading, finally found an answer in a beta thread. 
1. In Preflight panel, need to click the Edit Profile in the little Actions menu (top right of pane).
2. Go down to PDF Passthrough, then select the minimum type of PDF you're wanting to Place.
3. Will need to Create a Preset for that setting since the Default seems to be a minimum of X-1a:2003. Otherwise you will always see the error message if you are Placing regular v1.7 PDFs. 
Overall, doesn't seem like a very intuitive or smooth way to do this preflighting. Would think there would be a better way, but who knows. Maybe in upcoming versions.
Just wish that this would be explained on the need and how to do this in the online Help for the app! The Help says there is a Preflight for PDF Passthrough, but doesn't explain how it works and the need to set it to what you want in the Edit mode. 

Poztcode? or Sip Code?

I thought you wrote the manual...

I have no expertise in QR codes, but have clients who can use them from time to time. The ones we have "outsourced" have all had the client's logo embedded into the center.  While a post in this thread suggested just dropping a logo somewhere on top of a code generated with these apps, I would like to vote for a mechanism to place a logo there that is compliant with whatever rules need to be followed (obviously, not blocking key parts of the code!). Really would be preferable to having to learn a bunch of QR rules when we only do these on a limited basis. If it were easier to accomplish (a benefit of this new feature), we certainly could be doing more. 

This is one of the benefits of having the tool add the logo for you.
Back toward the beginning of this thread, I showed screenshots from iQR, an app I have from the Mac App Store to generate QR codes.
That app has a built-in validator, that given the resolution of the QR code, actually "scans" the generated code internally to make sure it will read cleanly with the specified settings.  Because it adds the logo itself, it can account for that when validating - the final result with the logo on top is validated by the program and it gives you an indicator (the green checkmark along the bottom) telling you that it will scan well - or warns you with a different indicator when it is marginal or when it will not.
It can also adjust the error correction automatically based on this result, increasing it when possible with the resolution specified, where doing so will make the code read cleanly when otherwise it might not.
The Affinity apps could take a similar approach to validate the resulting QR code that is being generated, but if the logo is not accounted for by the app, then the validation would not take it into account.
I would suggest that as this is a shape, the logo could be specified simply by making it a child layer of the QR code itself.  The child layers would draw on top of it just like any other child layers, and if they are included in a render of the QR code which is run through a validator, it could be performing that test on behalf of the user.

I have no expertise in QR codes, but have clients who can use them from time to time. The ones we have "outsourced" have all had the client's logo embedded into the center.  While a post in this thread suggested just dropping a logo somewhere on top of a code generated with these apps, I would like to vote for a mechanism to place a logo there that is compliant with whatever rules need to be followed (obviously, not blocking key parts of the code!). Really would be preferable to having to learn a bunch of QR rules when we only do these on a limited basis. If it were easier to accomplish (a benefit of this new feature), we certainly could be doing more. 

I have no expertise in QR codes, but have clients who can use them from time to time. The ones we have "outsourced" have all had the client's logo embedded into the center.  While a post in this thread suggested just dropping a logo somewhere on top of a code generated with these apps, I would like to vote for a mechanism to place a logo there that is compliant with whatever rules need to be followed (obviously, not blocking key parts of the code!). Really would be preferable to having to learn a bunch of QR rules when we only do these on a limited basis. If it were easier to accomplish (a benefit of this new feature), we certainly could be doing more. 

Dude..........  WTH ARE YOU TALKING ABOUT? 🙄 
There are no "submissive pleas delicately and nervously wrapped in declarations of affection..." To put it kindly, that's an imaginatively distorted, mischaracterized projection, if I’ve ever seen one..
"You have now reached a point where you stand in an even more uncertain situation under Canva - like beggars with even more at stake." Ummm, NO! I'm actually quite optimistic about the Canva acquisition, as the influx of resources will help development...
"How long will you emphasize a word before you doubt the effect of yet another emphasis?" As long as I feel like it...
Are you some kind of paid troll sent by Adobe PR? Are you here to sow doubt and division? It certainly smells that way...

Feedback/Usability wise,
it would be nice to have an option to easily create a border with some text around the QR-Code.
Here is an example of such a result;
Of course the user could create such things manually but it is time consuming.

Hi @nwhit,
I've replicated and logged this with the developers, thanks for your report. 

Been tied up with other business so have not been staying super close on the newest changes. But using the last 2.4.2 beta and release, I can no longer stretch the hyperlinks window in order to actually see and edit the url. Same in the beta and the release. 
Is this a known regression? Makes it very difficult to add/use hyperlinks. (macOS)

@Patrick Connor @Ash
So after 22 years, you are still so unprofessional that you don't know that you don't chat about the topic 'our customers' loosely with other customers like this - while at least one of them is listening. This is a forum. Not a bar or bus stop.
As a company, I can see from your communication and products that you can learn a lot from larger companies and players. 
You seem to have lulled yourselves to sleep in the provincial and gotten used to the dangerous distance to customers that has arisen with computers and the internet. This is clearly reflected in product quality and communication.
It's shameful and strange that feedback from bit arts here is not taken seriously and answered in a mature and professional manner, not with smilies and hobby forum chatter like here. Let professionals handle customer communication.
My sympathies, @Bit Arts and other affected customers.
Serif Software, it's course time : https://delighted.com/blog/customer-engagement-101
(And no, I have nothing to say about the predictable comments of the forum's entrenched members that follow. I'm just stopping by to give this feedback directly to Serif. Unfortunately, I see that nothing has changed, so our decision was correct. Bye.)

Thanks. Yes, happens every time, and I was replacing a PNG with another PNG.

Aha! Found one that causes it to crash. Fairly simple doc (Errol editorial), but may be related to the prior issues with freezes/crashes with linked APh and ADes files. Can package and upload with a link if desired.
And with that same one, once again crash. Interesting because it contains nearly the same assets/items as the other docs I'm working on, just rearranged for a different use. 
UPDATE: Yup, it is that one doc that CTD every time. As I said, can upload a package if desired. Odd since it has nearly identical content to a couple of the other ones open. And also  of interest, it wasn't a layer/item in that problem doc that I had selected when I got the crashes. I was in another doc when I got the crashes, whether I had an item selected or not. The "catch" was that the now identified doc was also open in another tab.
Affinity Publisher 2 Beta-2023-07-07-153420.ips
Affinity Publisher 2 Beta-2023-07-07-153904.ips

Initial test in v2.2 beta seems to indicate that this is fixed. Oddly, when opening all previous docs in 2.2 beta, it requires updating virtually all the linked resources in RM. 

@nwhit - thanks for the files I've recreated and logged that issue

@Pauls All 4 zipped packages uploaded. 
Test Page: always open, never an issue (was back a few versions when linked eps caused issues) A4 Advert: Can work, open, close, quit with this one no problem, and works fine even with Editorial and Test Page open. Editorial: Same as the A4 Advert doc. Vital: This is the one that is most suspect. When it is open with the others, will eventually freeze at closing or quit. Happens every time. That said, it can be closed if done within seconds of opening. But if a little time passes, will freeze the app every time.