nwhit

I think he's referring to saving a new doc where the save dialogue's name box has "untitled.apub" showing for saving a new doc. In most all apps, and I think earlier Affinity apps, the word "untitled" is normally highlighted so that you can simply type the new file name without having to manually select the word "untitled". May be the same for doing a save as. The current file name (but not the appendage) should be highlighted so as to allow easily changing the file name if desired. Normal Mac interface SOP.

Not sure if you have done this. Make sure you go to MacOS Prefs>Security & Privacy>Privacy>Full Disk Access, then be sure to add the app. May have to click the lock at lower left to be able to add an app. If the app is already there, then may take something else, but this is a possible reason.

That would be great to get this fixed!!! I spent a few days trying to fight this issue on a doc that I routinely use as a base, then update content. For the life of me, I couldn't figure out what the heck was going wrong every time I flowed to a 2nd page! Ended up deleting all the text frames involved (and content) and had to reset everything from scratch, which was a PITA. Yes, if there were an indicator like the overflow "eye" to warn someone, that would be a huge help. Also like the Transform scale panel idea.

Yes, it is.

As per my post above, all the resource files are stored in a wide variety of locations (on local drives) based on the related product, project, use, period/date, etc., and cannot under any normal circumstances be moved to a single directory/folder for use in an APub doc. These resources are routinely used for a wide variety of projects, and in many cases, are often revised/updated, so need to be stored in their appropriate locations and only linked, not embedded. The resources are used in or linked to numerous other docs, pubs, etc. So if I follow what you are saying, I would need to in the Resource Manager click the Replace button, but select the same resource for each graphic item? That alone will resolve the problem? PITA, but if that's the only option, guess I'll have to remember that for any further IDML imports. Doesn't seem like it should be that way, so hopefully it's something that can be resolved in a future update. When IDML import was first added, I trialed it during the various betas. I opened numerous IDMLs with lots of linked resources but never had this issue, so it appears to be something related to the newer versions. Thanks.

@Gabe, looks like you found the problem. I've been playing with the packaged version and it doesn't seem to show the problem. Interesting! I'll keep playing with the file today as time allows, but looks okay right now. That does raise the question. For other files that are IDML imports that might have this same issue, is there a quick way to relink all the linked files? In a few threads I have seen the advice to rename the directory with the resources in it, then re-find and relink the resources. However, our production group has never kept various resources in a single folder. They are distributed all over the place and are filed based on project, product, use, etc. Thus no possible way to simply move or rename a folder. Nor would it be possible to Package, then rename/relink since those assets have to stay where they are. Thus is the correct way to accomplish this to simply click on the Replace button in Resource Manager and select the same file? Thanks. Happy that I can still Place and link to APhoto, etc. files!

Thanks.

@Jon P Any update on this serious issue for possible fix in 1.10.2? Thanks.

UPDATE: Okay, I went through and replaced all graphic items (linked as before) that were eps, psd or APhoto items with pdf or TIFFs. I don't seem to have the freezing up issue anymore. Seems that the bug/problem is related to placing those type of files/objects within a Publisher file. I'm thinking that it shouldn't be that way. In many cases, I would think it would be preferable to place a APhoto file, especially where there are transparencies, drop shadows and other issues that may not do as well as an exported and placed file in another format. But at least I can proceed with this revision for this project! That's the good news! That's assuming my PDF/X-4 output file will now work okay once I'm done!! 😉

Thanks. Interestingly, when I replace the linked APhoto files with TIFFs, they show OK right away. But all of the items that are replaced with a PDF show missing until I Save, Close, then reopen.

Related to this same file, I have done another Save As and am attempting to replace items that are either APhoto or PSD files with jpg, TIFF or PDF versions. However, having tried to replace 3 of them, each time in Resource Manager when I replace one, it shows up listed as Missing in Resource Manager and Preflight. But if I save and close the doc, then reopen, it now shows as OK. And what I see on screen at 100% looks correct. Am I doing something wrong or is this perhaps a bug? (Still using the beta.)

Done. Just uploaded. Thanks.

Also just did a Save As and used a new name. Reduced file size slightly. Then moved a small text item and Saved. Took about 3 minutes for it to save.

Thanks. No. Produce a bunch of far more complex docs daily and no issues. With this iMac, never had a problem with Metal. Likely something related to the document since much larger (MB-wise), more complex files have not caused any issues. First time this has happened with APub. I do seem to recall someone once reporting issues with placed APhoto/ADes files within a Publisher doc. Plus I have a couple of the original PS files linked as well from when this was an ID file. That's my best guess but will wait for someone who knows or has resolved a similar issue.

UPDATE: Just moved a small linked APhoto graphic element and did a save. The Save froze the app for about 4 minutes. I also do have 5 items placed in the doc (linked) that are APhoto files. Could that be the culprit? Do they need to be TIFF/JPEG/PNG etc.?

I am working on a trade show display (panels) doc in 1.10.1, then in the newest beta .2.1167. As I work on the doc, placing images, moving things, adjusting sizes, setting type, etc., within a few minutes (5-10), the app essentially starts to freeze up and won't proceed or recognize new clicks/input. Doesn't actually freeze/lock up the entire program since I can switch to other apps, and I can eventually close the project after letting it sit for several minutes, although it takes a few minutes (with the beachball) for it to actually close. It appears that it is simply overloaded and can't handle any more input. The doc saves and reopens fine. Changes made just before the slowdown/freeze-up are there (eventually). Just gets to a point where I can't go any further and need to close the doc (waiting until it eventually closes) and reopen in order to proceed. I had thought it might have been an issue with 1.10.1, so tried the current beta for 1.10.2, but it does pretty much the same thing. The doc file size is only 7.4 MB with linked graphics. I have 72 GB RAM, so not short on that, as well as a new iMac. The doc's single spread is 3748mm x 2280mm in 300dpi, cmyk (actual size trade show panel). I opened it for the first time in Publisher today for revision work from a newly done IDML export from the original ID CS5 file. Never had this issue working on several of the same files in ID CS5 many, many times. (This is the first time working on them since Publisher came out). Files are on a local drive (RAID5 Thunderbolt 3). I think I have the APub performance settings at about a max setting (see attached). Don't have Save with History turned on. Overall, the doc is not highly complex with only about 9 images/pics. Just physically large, but as I said, never once caused any slowdown in ID CS5 for the many, many revisions and working sessions in the past. Can upload (with link) a package if needed. Just very difficult to work on this project in Publisher and hard to understand why.

Just tried and I get the same thing. Does it with several tools that I tried. A bug for sure.

Speaking of lots of fonts that most Mac users would not be aware of, Big Sur (and even Catalina) automatically installs a few hundred fonts, so the Affinity font menu will show a lot of fonts. But those are all located in approved font locations. Just a PITA because many cannot be deactivated at all and even the Supplemental fonts require TypeFace font manger to deactivate. May not resolve this person’s issue, but will clarify where a whole load of “mysterious” fonts come from!

Thanks @Dan C. I normally participate fairly deeply in the betas as these new features are added, but when PDF Passthrough happened, I was too busy to get more than superficially involved. Thus I missed the discussion on the ramifications for Preflight. Also seems odd that something so critical (the Preflight errors show virtually all the time due to the default being for an X-PDF) wasn't covered in the new video tutorial for the new PDF Passthrough/Placement. It would seem that most all users would get a preflight error after placing a PDF for passthrough since using PDF-x output isn't all that common except for users working with prepress requirements. I'm guessing most users simply ignore the errors (or don't use Preflight) because trying to find out the actual meaning of the preflight error is very difficult to ascertain. Perhaps it should be added to a Publisher FAQ section until it is better described in the Help. I watched the progress of PDF passthrough with great interest during the beta process since I used to have a background in print shops, newspapers, publications, etc. where it is a critical feature for modern publishing. I realize that it is still a work in progress with some rough edges still, so can understand how this might have been overlooked. Hoping at least the presence of this thread will help others who, like me, are initially baffled by the preflight error messages and can't find much of any info on the errors. Pretty simple to fix, assuming you know where to look!! 😉 Overall, Affinity apps just keep getting better and better. A few bumps along the way, but so refreshing as compared to the old standard apps. I was an Aldus PageMaker v1 user and trainer, so it's been a long journey to get to this point. While Publisher still has some glaring missing things, it is today highly competitive with far greater customer support. Thanks again.

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.

Just watched the Affinity video on placing content including PDFs, but like the online Help, it does not explain what kind of PDFs will actually passthrough instead of rasterizing. Rasterizing a placed PDF is not acceptable under most situations, so one would think that if there is a limitation on the kind of PDFs that will work, that info should be readily available in the Help. It's just hard to imagine that PDFs created in Designer won't work. I thought that might be a bug, but apparently it isn't. Sure could use some help on this since I have a publication that needs to be finalised.

Not sure how this got moved from Bugs to Questions. I've looked in the online Help for Publisher regarding the recent feature to Place PDFs as Passthrough, but I cannot see anything in the entire online Help that says what kind/type of PDF will actually passthrough without rasterizing on export (thus, not really passthrough). As per my original post, a PDF created in v1.10 of Designer apparently cannot be used for Passthrough in Publisher v1.10? That doesn't seem to make any sense, thus the question if this is a bug. Placing a Designer PDF shouldn't end up getting rasterized when exporting a PDF of the Publisher document, at least I wouldn't think so since that would be of little use. Right now, I cannot seem to locate any information of what is allowed to be Placed as a Passthrough PDF if I want to avoid the Preflight error message that it will be rasterized. If Passthrough doesn't work with Designer-created PDFs, then how do I create a PDF that can be Placed for Passthrough in Pub?

Working on a doc in 1.10.0 and have a couple PDF's exported from ADesigner. Have them marked as PDF Passthrough. Yet Preflight is warning "Placed PDF version (PDF-1.7) is not compatible with the PDF export version. The PDF will be rasterized on export." I haven't tried exporting yet, but the warning concerns me. I've tried exporting from Designer in both For Print and For Export, but get the same warning. If I place the Designer doc instead of the exported PDF, I don't get a warning. Obviously, I don't want the placed PDFs to rasterize. Is this a bug or is this newer feature just a bit more complicated than simply placing a PDF and having marked as Passthrough? Haven't tried exporting from Designer in PDF-x formats, but would think a "normal" PDF for Print or Export would be "compatible" in Publisher. But obviously I'm doing something wrong.

I can see that problem happening. Of course, the issue in this thread isn't the same since the font menu corruption occurs on each and every new, blank document in all 3 apps. No carryover. For some reason, Affinity cannot use the Font Book collections without subsequently corrupting the All Fonts menu. And as per the various posts and pics, it's not just with a single font. The duplicate font styles happen to numerous fonts. As said before, the All Fonts menu is correct initially (in a blank, new document in any of the 3 apps), but if you then select one of the custom collections you've created in Font Book, there are then numerous duplicate styles showing for many fonts in the various collections. Following that, the main All Fonts menu now shows an increased number of duplicate styles for many fonts. That makes it pretty tough to pick a font and style, not knowing if it's "real" or not! Note: This issue is new as of v1.9.x since I used to use these same Font Book collections constantly in previous versions without any issues. Never had a problem previously.

FWIW, while I'm on a different machine (Intel, etc.), I just tried opening several large PS files in v1.10.0 and had no issues. You might need to upload a sample file or two for people to check to see if it's file related.