thetasig

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...

I also cannot replicate the issue with a new document.

Yes I do have lots of disk space - see below. My AFPUB did not stop responding - I waited until the load was finished (using Activity Monitor CPU measure). Here's the numbers for two files I have - usually both are open simultaneously (copying one to another page by page). For many weeks there were no problems doing this. Then, suddenly, the target file seems corrupted - if any action is taken it crashes. I still suspect some problems during the copy/paste process. See my notes earlier. Source file (never crashed yet): FIle Size: 77.2 MB; Memory: 19.09 GB, Disk: 16.02 GB Target file (crashes at any edit/action): File Size: 78.3 MB; Memory 16.52 GB; Disk: 31.97 GB System: Memory: 64 GB; Disk Space: 2.74 TB available of 4TB (SSD) - it's a MacBook Pro 16 circa 2019 Perhaps one thing to note, but it could be from the issues (my notes in "suggestions forum" on duplicate Styles after copying). The source file is, page-wise and object-wise, much larger than the target - the copy process is not yet finished. Yet the target file size is larger than the source file size. Also attached, system info. Thanks for looking into this - cheers!

Do you believe that is the reason this file crashes? I'm not sure how to interpret your findings.

I've uploaded the resources in a folder. This folder sits on my local network NAS (Ethernet) and its Volume is mounted on the Mac when I need to work with AFPUB. When you are finished testing, please delete the resources from your system and Dropbox. These are photos and are not yet copyrighted and I'm concerned about losing control over them prior to finishing up the copyright process. Thank you. p.s. Is it not possible for you to receive private messages ? I tried but the system says you can't