thetasig

I was able to restart AFPUB and load the main document after all of this happened - amazingly, it was saved perfectly as expected. Other times this has happened, the files were all AOK. It seems then to be a benign type of error that does not corrupt the document. I have experienced this with other, smaller documents. The trigger seems to be having two different documents open, editing one, then the other - back and forth. Then saving one and using Command-W to close that one. This brings up the remaining document to view. You can then edit it a bit - but when you save it the save is usually almost instant when there are few edits. You can see that the progress bar immediately goes all the way to the right - then the access message pops up. I had suspected that the save process (into a document database file?) might re-read something from the document/database file (validating the changes made?) and that might be when it stops responding and gives that message. Or, it could be something like the Split view problem where the software suddenly switches to another document other than the one you are working on. (I was using the normal view, not split.) I read that 1.8.4 fixes that problem but have not yet upgraded. It is, unfortunately, a bit random - I tried to reproduce it several times and could not. But it does still happen occasionally with 1.8.3. I don't think the files I have would be of much use. I have moved ahead 3-4 days of changes. I do "feel" that the Command-W to close one document (after switching back and forth between them and saving along the way) may be setting the remaining document up for some sort of failure as described. Since it is not catastrophic, it's just an unexpected occurrence. If you like, you can close or park this issue. After I upgrade to 1.8.4, I will let you know if it happens again. Thank you.

MacBook Pro16 10.15.3, AFPUB 1.8.3. Document Resource folder and Documents are all on the local laptop System Drive (SSD). I have to believe that it is a real bug. It happens randomly and I cannot replicate it reliably. Scenario: Have two documents open (cover, and main document for a book). I modify the cover a bit and save it to the local system disk on the mac. I modify the main document with changed text in an existing text frame. I save that with Command/S. Then I go back to the cover and export the two pages to PDF. Then I close only the Cover document with Command/W. I think that might be the trigger for the next event - a sort of crash. So just the main document is open and I add some indexing to the changed text and press command/S to save. The progress bar appears and then, a second or so later, a critical message pops up (attached). The message does not make sense - "access to the document file was lost while performing initial loading." Why would an open document that was just saved 2 minutes ago lose access from the local system disk and why would it be performing "initial loading"? After I click "OK" to close the message, the document disappears, the progress bar is locked at max, not progressing, and AFPUB has to be Forced Quit since it stops responding. The very unusual thing is that it appears that the document was actually saved properly (short save since it was only a small edit), then AFPUB threw a fit.

When you export a document to a PDF and then upload it to a printer site, it can be seen that there are "Annotations" in the PDF and some printer sites have to remove those annotations. It only happens in the Table of Contents pages, and the Index pages. It would seem that the annotations might be something that AFPUB needs to know about and use, but I'm not sure if a PDF can benefit from using them. I explored one of the PDFs I generated and Adobe Acrobat did not find any Annotations in the PDF, but a printer site did. If you don't need to generate them into the PDF, it might be a good idea to remove them as the PDF is exported.

Mac 10.115.3, AFPUB 1.8.3 On the Mac, the user can set Notifications to pop up on the desktop. I've noticed that when this happens and you are using some tool while editing an AFPUB document, the cursor can change. For example, if I am editing text in a frame, you have a vertical bar as a cursor. When a notification pops up, the cursor instantly changes to an arrow. And it stays an arrow until you click somewhere else on the document (say, outside the bleed area). Happens reliably. It's a small nit to pick, but it is annoying and it can make for a confusing situation - you don't know where you are in the text since the cursor has changed and the vertical bar is no longer visible.

AFPUB 1.8.3, Mac 10.15.3 I have been working with a large document with hundreds of photos. Loading this document from start to quiescence of the CPU takes some 8-10 minutes or so. I sometimes forget this as it is possible to edit the document while the document is still loading (measured by the activity of the Mac Activity Monitor). When I press Ctrl-S to save the document before the document is fully loaded, the "save" window pops up. Of course AFPUB cannot save the file immediately since it hasn't yet finished loading, so the "save" dialogue just sits there doing nothing. In some (thankfully) rare cases, the "save" dialogue never saves (measured by its progress bar) - yet sometimes a save is actually completed - and sometimes this request to save causes AFPUB to crash. The software is a bit unstable during the document load. Suggestion: do not accept the command to "save" while the document is still being loaded - pop up a "warning" instead to wait and do the save later. Yes, I know about the recent release of AFPUB 1.8.4. I do plan to test the new release soon, but cannot risk it now as I am just about to publish the document I've been working on.

I've run into this error many times. Finally caught a screenshot to show. Scenario. Photo book, photo source is Lightroom. Resource Collection folder. In Lightroom I edit the photo and export it to the Collection folder. AFPUB notifies the user that the file has been modified outside the application. The second notice is "Failed to Open File, File Type is not Supported." The photo is not updated in AFPUB document (not replaced with the edited version). However, all you have to do is to "Replace Image" with the very same image (.JPG) and all is fine. So the problem is that the file type is, indeed, supported when you replace the image. The earlier versions of AFPUB would automatically notice the change and apply the newly edited photo into the AFPUB document. No user intervention when the image is Linked, and the preferences are set to "Automatically update linked resources when modified externally" This is no longer working as expected. Something about the File Type.

AFPUB 1.8.3, Mac 10.15.3. I have a number of ordinals in my document that are indexed. An example is "18th Birthday", where the "th" is a superscript. In this case, the quoted words are also indexed. I don't know if this is by design, but the index text drops the superscript down to the default baseline (as seen here in this topic). I would have expected the index to respect the superscript and have that properly shown. I'd appreciate some clarification. Thanks.

Thank you all for your words of wisdom. I'm new at this whole publishing thing. Since it is not "really" changed in the final product, I can live with the perception issue, and even get used to it! Regards,

See screen shot. I have a background image on the spread. The printer advised to expand the image into the full Bleed so as not to risk some "white" unprinted edges when the bleed is trimmed off. Printer indicated a risk factor of about 1/16th of an inch. In this case, the image Opacity is set to 30%, but it comes out 100% in the bleed. I think this needs to be repaired - if the printer is off in the trimming, you would see the 30% image in the center of a page, but at the edge the risk is that you would see the image at 100%. This becomes even more important for the cover since there may be a wraparound and you wouldn't want the image to suddenly change opacity as it wraps around the cover edge. If opacity is not used, then the entire full bleed image is fine at 100%. Fortunately, if you export to a PDF, this appears to be only a visual, cosmetic problem. That is, what you see in AFPUB is not what you get when you export. The exported spread does not show a 100% opacity in the bleed area - in my case it is the specified 30%. I do not know if the export to other formats would follow suit. So, maybe not so critical, but it could cause confusion for users to see the difference in opacity in the bleed. Second screen shot is a PDF export.

Thanks, Gabe. It is difficult for me to understand why a programmer/designer would handle the incoming duplicate style by creating a new style and renaming it as it is copied to another document that already has that exact same-named style. Is there some rationale or useful purpose that I'm missing here? Thank you.

Thank you for that clarification. Much appreciated.

Thank you for that shortcut - it will save time and aggravation.

I've noted, and been quite annoyed by, this feature. If you wish to copy an object on the Mac, you can Option Key/left-click drag OR left-click drag/Option Key with the mouse button. If you wish to adjust the position of the object and use just the left-mouse to drag it around, it will snap to nearby objects easily making fine-tuned adjustments difficult or impossible. By pressing the Option key while dragging, it is possible to bypass the snap-to and accurately position the object. This carries the risk of inadvertently copying the object - occasionally, an exact overlay. It cannot always easily be seen that this has happened. So the question is, is it possible to bypass the snap-to on a Mac with some other key that will not also possibly duplicate the object you wish to move the object with a left-click drag? (I do understand that selecting the object and using the arrow keys permits moving the object with a different method.)

They are identical. Styles are created anew with a sequence number suffix when an identical object, say a specific text box in one document is copied to another document. In this case, the two documents are "identical" sharing the same picture frames, pictures, text boxes, pages, having been copied from one to another page by page. For example, Style "Box Blue" in the original and set for "Text box Intro" ends up in the other document as "Text box Intro" with Style "Box Blue 1", etc. Note that most of my copying is by "group" - all objects on the same page are highlighted, copied, then pasted into the second document onto an empty page, and so on. See the following issue link too - it seems other users are experiencing the same issue. https://forum.affinity.serif.com/index.php?/topic/116990-duplicate-styles-when-copying/

My document has hundreds of new styles automatically created in sequential numeric order when copying from one document to another that has the same styles (by Name). Instead of using the same-named Style, a new one is created for each object using it. I am trying to find where those "new" styles are located so I can change them back to the "base" style that was originally used. Using "Find and Replace", I changed the search to Paragraph Style, and a drop-down allowed me to choose one of the styles that needed to be replaced. Then I clicked the "Find" button - nothing. So I went through the drop-down list trying one after another of the choices. Many of them return no response. Some do. So the first problem seems to be that a bunch (about 120+) of Paragraph Styles were automatically created during the copy/paste, but now they are no longer to be found in use in the document. I'm estimating some 200 or more are not found, only a few tens are found. I have not edited any of them, and since they were automatically created, I am concerned that they SHOULD be in use somewhere. It's possible that the styles are there, somewhere, but not able to be searched for. Second problem is that the Find and Replace/Paragraph Style drop-down list is very long and the list does not scroll automatically (downward) and does not respond to the mouse wheel. I've check the Text Styles list and there are many, many more below that I cannot get to to search for - some 250+. Third problem is more of a feature request - instead of just a drop-down list, it would be handy to be able to search for a pattern such as "Body*" using standard wild-card characters. Fourth issue is cosmetic/consistency. In the Style Panel, the list of styles is titled "Text Styles" - these are the same list of styles shown in the Find and Replace/[GEAR]/Paragraph Style list - and suggesting that both lists have the same titling, i.e., "Text Styles" Attaching a screen shot of the long list that can't be accessed below the last item seen...