thetasig

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

I've uploaded the document - what I do is to wait for it to load (takes about 3-4 minutes) and then I go into text mode and inside a text frame I just type a character. A few seconds after that, AFPUB crashes. If you immediately type something while it starts loading, it crashes after the load has completed.

Is it not possible to respect the naming of a style when copying between two documents? I currently am making an e-book format from a larger format document. It is a process of duplicating the original to a smaller format. It has to be done page by page. When copying a single text frame with text, the target document already has and uses the same Style (name). However, the process of copying creates a new, sequentially numbered version of the same Style. This seems to be more with the created Styles than with the built-in default Styles. An example is a "Box" style that has been created with blue text and a grey background: "Box Blue". The source document has a single "Box Blue" and the target document has a single, identical, "Box Blue." When I copy then paste another frame with that Style, a new Style is created: "Box Blue 1." This happens repeatedly and, as one example, I have 75 sequentially numbered new Styles all with the same settings and same name except for the sequential numbering. This plays havoc with the built-in concept of using a single Style to control many objects using that Style.

I am trying to finish creating an e-book format document from a 12" x 12" coffee table book by copying from the larger format to the smaller e-book format. As far as I know, I cannot replicate this on a new document. It is most likely, as I mentioned, an esoteric error that occurs when working with two large documents simultaneously and copying between them. I was able to get about two-thirds of the way through the process before I ran into the crashes with the e-book document. The "target" document and "source" document, when both open, give me the opportunity to copy from "source" to "target" and this, I believe, is the underlying reason the "target" document eventually becomes corrupted. It is difficult for me to pinpoint the specific cause(s). I have been able to replicate the problem starting with a "good" target (I use versioning to advantage) and then ending up with a corrupted "target" document - I've attempted about 4-5 times now and failed each time. One approach that I'm now attempting is to use the source only as a reference and NOT copying any objects directly from that. Instead, I will try to re-build the remaining parts of the target manually. That will be a slower process, but might likely work in this case. For example, I've copied some text from the source to an external Text editor, then transferred that from the editor to the target - and manually creating picture frames and images, from the Resource Manager Collection folder. With the two documents I've been working with, I can work on the "source" document alone successfully. In that situation, I am not copying from another document. I can upload the currently corrupted document - but I'd appreciate using your secure Dropbox location to do that.

See also this related link "Document has changed:" https://forum.affinity.serif.com/index.php?/topic/116724-document-has-changed/

Regarding the document in question, it is stored in a local folder. The folder is local and part of the Mac system-created folders: "Documents." It is only managed by the Mac operating system and no other. I do not use cloud-storage services for the Documents folder (specifically, not using iCloud Drive or any other). However, the Resource Manager Collection contains all of the linked images used in the document - and that is located on my own local (LAN Ethernet) NAS that is on a Volume mounted under the Mac O/S. None of the images there were changed in the past 5 months (more importantly, not changed during this reported incident). I have been using the Resource Manager Collection configuration since January 2020 and have not had any problems. I may have alluded to the following in the related topic above. Each time I have had trouble, I have two documents loaded and copying from one to the other. I have a weak suspicion that AFPUB may occasionally mix up which document is "active" and which is "inactive" - that is, on top of the AFPUB desktop or not. I noted that possibility during a time when I used the Separated Mode and AFPUB kept switching documents when I was editing the other document (this is a known issue). I stopped using the Separated Mode after I learned about that problem. During this incident, I did make a change to the Source document and I did save it with no problems. Later on, maybe shortly thereafter, while editing the Target document is when I got the unusual messages above and, eventually, a crash. I am just guessing here - not really sure what is causing the problems.

Follow-up - the same document in question (vers. 7) is now corrupt and cannot be worked with. First edit you try to make and AFPUB crashes. I'm going to go back one version to see if it is OK, however, upon examination, AFPUB 1.8.3, believes that the earlier version (6) is open by another application and AFPUB cannot load it. I have checked all the running applications and none of them have the capability of opening an AFPUB file. It is possible that the version I'm trying to open may have a "lock file" somewhere that AFPUB placed. I do not know where those reside, if they exist. The document is not locked by the System.

I now believe that this unusual series of errors was part of the problems I have been having - mostly AFPUB crashing when trying to make any change to a document that has been just opened, and quiescent (see below link). Right after I got the unusual message above (and had saved a new version of the document), I made a few more edits (copying text from another AFPUB document to this one), setting style and then performing a File/Save command using the mouse cursor (no key strokes). The document in question is located on the main disk of the computer (same disk that is used to boot the system). The document was NOT being loaded when the following message popped up. I cannot think of any good reason that the access to the document file was lost with the exception of probable bugs. See this link of a crash:

This may not be a bug, per se, but it seems very odd to have seen the warning message (attached). AFPUB 1.8.3; Mac OS X 10.15.3 I was editing and saving a document as I went. I had also saved sequential versions as I edited (to see if any problems arose). I keyed Command + S to "save" the file, did some more edits and keyed Command + S again and got this warning message. I should not have gotten that type of message as there is no other instance of AFPUB or any other process (including Design and Photo) that would access the document in question. That is to say there could be no reason (except bugs IMHO) that the message should have popped up. I did perform a "save as" as the message suggested.

Fortunately, I have versioning in my blood, so I do have some "good" document versions of the project I'm working on. I started with a good one yesterday. 1st document - older - stable-ish, also versioned. This is a completed 12" x 12" document. 2nd document - the newer one that is crashing after being edited awhile. This is an 8" x 10" format. I am copying page-by-page from the 1st to the 2nd document. In order to do that I do the following things to the 2nd document. a. add pages a spread at a time, usually, or maybe 6 pages. b. Copy (always copying from the 1st document) the background image in a picture frame (full page or full spread) then paste to the 2nd document. Arrange it "Send to Back". I noted that even though the source picture frame is arranged "to back" the copy is NOT arranged to back - so that must be done manually just after pasting it. c. Copy all elements on a page (text boxes, picture frames, usually) then paste to the 2nd document. d. rearrange the elements just pasted (as a group) grab lower right inner drag handle while holding the Shift key down. Drag the group to fit (smaller) into the page. Then center the group on the page. Then click outside page to remove selections. e. work with each item. Text boxes shrink, font sizes do not. So text boxes need to be resized and re-centered as captions for images. In some cases, I select all the text in each or a group of text boxes and make the font smaller. Also checking the Paragraph Leading to be sure it's value matches the font size. Adjust the text boxes to fit the text and place as a picture caption. f. Work with each image. Some are not set to "Max fit" in the 1st document so they tend to slide away from the picture frame and are not made smaller by the group of elements that are shrunk down. Center the picture frame where it needs to be, align to other frames if called for. This means clicking some other frames just so you can get a line-guide to show up with the picture frame I'm moving. May have to use "frame fit to picture" and followed by "Max Fit" and then grab corner with Shift key and shrink/fit the picture frame to the area it needs to go into. In some cases I have to double-click the image handle (center of image) so that it will fit into the frame properly. g. Select all elements on that page - center them vertically (guide lines) and horizontally. h. Move on to next page and repeat process. Here are some other possibilities. I noted that the text styles that are brought over from the 1st document (while copying them) are added to the Styles list with new, sequential numbers. I missed this little detail when I started the project. I have hundreds of duplicate styles because of this. An example is a "box" based on the default box that comes with the styles. I made one new one in the 1st document - Box Blue 1. Now there are maybe 40 of those (duplicated) with sequential numbers. This is also happening with other text styles. One of the "clean-up" efforts I was doing is to select a group of text/box and change them from the sequential box styles to Box Blue 1 or another standard Style I was using. This changes the text size (my new Box Blue 1 in the 2nd document has a smaller font and Leading size). It may be coincidence, but it was after these changes that the "good" document started acting up and crashing. But it could have been any number of steps listed above where I'm copy/pasting and re-editing a lot. Another difference between the documents is - just around the same area where the document is "good" and then it goes "bad" again. I have been changing how text flows between text boxes. The 1st document does not use this feature - just two to four boxes with fixed text representing one transcription of a written letter. In the 2nd document, I have been linking the text boxes and then copy/paste the actual text into the new boxes - where it all flows. This is a new difference that I have been using. I have about 12 letters that are transcribed. The good document (2nd one that does not crash) has just the two text boxes on one page. What I've been doing is to continue to add pages and text boxes (with links to flow the text) and saving test versions as I go. I use the Text Frame panel to set the background colors (12 different colors for the 12 letters) and use a Style "Letters Home" and make sure that is applied to the text. There are also the text frames that are styled as "boxes" and making that Style change to the standard (non-sequential) box Style I now use. I got to about the 10th letter home when the document started acting up and it would just crash when I tried to continue the process. That's about 10-12 spreads added to the "good" version. Do keep in mind the earlier "fix" you did for me - apparently something to do with the Indexing/Index marks, and "See Also" types of references. Those index marks are also coming into the 2nd document from the 1st document as I paste the text in. One probability is that an earlier index mark (in the sequence of pages) that has a "see also" reference, references an index mark that HAS NOT yet been added to the document. I do have lots of memory in the "very fast" machine 64 GB 2667 MHz DDR4; 2.4 GHz 8-core Intel Core i9; available disk storage 2.81 TB; Catalina 10.15.3 and using AFPUB 1.8.3 currently. Thanks for helping out - hope what I've written might help to narrow down what is going on.

I've uploaded the document. I tried to open with 1.8.3 twice. The Resource Collection is on an external Volume and it is mounted, so AFPUB did not ask to locate the linked pictures. I used Activity Monitor as it took a good 5-8 minutes for the CPU to settle down as the document was loaded. First time I just edited some text and changed the paragraph Leading. Crash. Second time I waited until the system was quiescent and tried a Save As - it thought a few seconds and then crashed with no output file.

Thanks - I'll upload the file in a short while. Do you want a crash report too? It was this post - @Pauls had requested the file be uploaded and then Gabe contacted me later to have me download the "fixed" file. As you can see Gabe sent me notification of the fixed file via a PM - weird that I can't seem to find that PM. Is there an archive of the PMs?

A while ago, your team "fixed" one of my documents that had some "index" problems. I thought your 1.8.3 Publisher had fixed that problem. I don't know if it is the same problem, but I would appreciate it if I might ask that you (Serif) look at the document to see if it can be repaired. It was created with earlier published versions, and then transferred to 1.8.3. However, in the end, this document somehow became corrupted while in 1.8.3 - now if you do anything after it has opened (edit text, save as, move a frame, etc.), it crashes within seconds. I can easily include a Mac crash report too if needed. Would it be possible to upload the document to your secure DropBox site so you can have a look? Thank you - and Santé -=mark=- OSX 10.15.3, AFPUB 1.8.3

Apologies, but I'm going go decline the offer to attach. I'm having terrible trouble with 1.8.3 and some 1.8.4.beta documents I was creating/testing. For now, I'm going to chalk this shadowy behaviour up to corrupt documents. I'll keep you posted after 1.8.4 is released and I start working on the documents again. Any hint on an ETA for 1.8.4 on Mac?

Using AFPUB 1.8.3, OS X 10.15.3. Cosmetic? Please see screenshot. The 4 text frames are linked for text flow. The images within all have wrap settings of "jump" with 3mm spacing. If you select all of the text in frame 1 with CTRL-A, the selected text is ghosted in the wrong places. You can see, for example, the bottom 2 text frames have "shadow" highlights that precisely match the actual text in shape, but are somehow shifted down below the actual text. This seems to be related to the size (spacing) of wrapped images and perhaps the flow link to a new spread/page as I have just started using the "wrap" feature and have never seen the problem before. It's a cosmetic thing, I suspect, but the highlighted "shadow" boxes should be exactly overlaying the actual text.

MacBook Pro 16 OS X 10.15.3 I've stopped testing the Beta versions for the interim. I am not having trouble with AFPUB 1.8.3. Thanks for the information on the location of the recovery file - the recovery feature is very, very helpful. My documents are stored locally on the same drive as the application. I move sequential versions to an external archive (NAS) when they are no longer needed locally. I think my crash experiences were caused by the extended loading time it takes for my large documents - about 7 minutes while the CPU (16 cores) goes crazy. If I try to save during that time it often fails and crashes. I have to use the Activity Monitor as a measure and wait until the CPU settles down.

My problem is slightly different but the results are the same - zero bytes saved, AFPUB may crash or just hang there with the pop-up "Save File" progress bar and no progress after several minutes. Using a beta file saved under 1.8.4.648, OS X 10.15.3. Using 1.8.4.651 to open and run. I just loaded that file, observed it, and then performed a Save As - just crashed after about 5 minutes. Left a zero byte file (see screen shot). Note: no actual progress reported on the progress bar during the wait. After crash, started AFPUB 1.8.4.651 and it automatically restored that file. Again, just observed - could not "Save" (greyed out) so I did a Save As with an incremental name. Again, just the non-moving progress bar (attached). Eventually, it crashes again, and left a zero byte file. I'm guessing the file is corrupted from using the Beta (several successive versions) so will probably have to go back to 1.8.3 versions of the file and then use the final of 1.8.4 to continue the development work.

In this case, I was using Lightroom to edit and "export" the photo. The export is quick and LR releases the file as soon as the export is complete. As I mentioned, AFPUB recognizes the file has been changed (Resource Manager has it marked as "Modified") - but the automatic update in the document and attendant pop-up message is not happening. So far I have had to use the Resource Manager to identify and manually "update" each modified photo. Fortunately it's only a few. This used to work on earlier versions of AFPUB - not sure where it changed.

I performed a search for "nested layers" in the Affinity help web site and could not locate instructions. Then I found something else on another site, but it was for AFPhoto instead. Is there somewhere I can get a "tutorial" for how to use nested layers in Publisher? For the immediate needs, I am just using Shift-Drag-Inner handle on a mixed group of text and picture frames/images. This keeps the text the same size but shrinks/expands the picture frames, etc. Fixing the image positioning and size is fairly quick. I did read up on Constraints - very useful. Thanks again for your help

Using AFPUB 1.8.3.627 OSX 10.15.3 Noted with this beta version that there are red rectangles that sometimes show up "attached" to actual objects but they are "ghosts" and not always outlining some object. This is very noticeable when you have many objects on the page. The red rectangles show up even after clicking outside (left or right) the spread. But sometimes disappear if you click above or below the spread. In the attached, sample screenshot, there is an image shown with a red rectangle. The image is not selected, but the picture frame is selected. Nevertheless, the image has this red rectangle around it (actual size of the image). The image on the right, a copy, also has this red rectangle. Normally, these won't go away until you go to another spread. Also, there is a background image across the spread and it also has a red rectangle - but this rectangle is much larger (taller) than the actual image, which is anchored to the inner bleed edge. You can see how that rectangle extends far below the spread (and above as well). That image is not selected. Finally, there is a red rectangle outlining the spread itself - you can see the bottom edge in red. Just curious if this is a feature or some type of weirdness. Thanks for any information.

Thanks very much. Do you by chance know a way to preserve the font size when dragging a group of image and text frames using the outer handle? The handle preserves the image aspect as you drag it smaller/larger - but it would be nice to exclude the text so that it stays at it's original size. It may be a binary situation and, in that case, I'd have to decide whether it's easier to fix the image aspect/sizing or change the text size and corresponding text frame sizing after dragging the group. Originally, I was dragging / shift the inner handle which preserved the text sizing but images shifted around a bit.