Jump to content

thetasig

Members
  • Content count

    107
  • Joined

  • Last visited

Everything posted by thetasig

  1. 1.7.1 AFPUB, Mac OS X 10.13.6. Long delays in actions/clicks. Activity Monitor also reports "not responding" for long stretches of time (minutes). Was just opening a previously created (large) file with many photos. Waited for file to load (about 2.5 minutes total). I clicked one picture frame with photo on the first page of a spread and waited 2.5 minutes for the frame to actually be selected. Finally got a response - then went to replace photo, and waited over a minute for the response to select the new photo in the Finder. Then photo went into frame enlarged so had to drag the size smaller and fit the frame to the photo. All is good, except slow. Then I clicked the next photo frame on that same page. Waited about 2 minutes for that frame to be selected. Then tried to create a picture frame on the next page of the spread - tried to size it, then a separate blue box was formed over top of the picture frame - somehow - by accident? Could not click that frame and could not click the new blue box. tried to select the created picture frame and could not select it. Could not delete either the picture frame or extra blue box. No photo added at this point. So I checked the Activity Monitor and again, "not responding". Eventually I hit Ctrl-W to close without saving (at least I could try to reload the large file again). Have seen this lag and v-e-r-y slow response also a week earlier after the final release. And - is there another forum for the final release to report more bugs or is the correct place? Thanks for help - not a good situation at present.
  2. As this is publishing software, it would be extremely helpful to have grammar checking built in. Without this feature, one would have to offload the text somehow, check it in some other piece of software, and then manually make the corrections. I'm not sure whether the grammar checking should be "on demand" and/or "as you type." Either way, it's going to be very handy to have built into Affinity Publisher.
  3. I'd like to raise this up strongly as a feature request. Having gone through a large document several times prior to exporting to PDF, I continue to see the dreaded warning that there are text overflows that need to be fixed. In my case, going through my document takes about 15 minutes - using Walt's suggestion to zoom out and look for red dots. But, as the document is a work in progress, the overflow pops up seemingly from nowhere. So there are two things to consider. The last time I saved the document after fixing all of the text overflows, one overflow appeared when I opened the document later on. What seems to be going on is that text frames with "tight" insets that look okay upon saving, shrink a tiny bit and then cause an overflow again as the text wraps around to another line. I think that needs to be addressed though I don't have an example at the moment; but I have seen this happen enough times to realize that some text frames are actually making minuscule size changes when the document is opened after saving. Example: I went through and found one overflow. Fixed that and saved and closed. Then opened the document again and voila! I have another overflow in a different frame. The second part of this feature request and apparent bug report is to make overflow text searchable (maybe through a "find" dialogue?) so that the time to fix can be minimized and make the experience more enjoyable.
  4. When you use a non-breaking hyphen between words, and then export to PDF, Adobe Acrobat sees that as a non-printing square. See screen shot. The solution is to use a "standard" hyphen - I found I had to open the Mac TextEdit application and just type a hyphen and transfer that into the AFPUB document. Then it comes out in the PDF as a hyphen. I think that the AFPUB "Soft Hyphen" is also broken in that regard.
  5. Large document with a standard 2-page spread. I decided to add a single page to the document just after a verso (left) page. This moves all the following pages down to different positions (recto becomes verso and vice versa, etc.). In the process, the following happened (again - reported in Beta too). The Master pages have a left-hand section name, a right-hand section name, and a left-hand and a right-hand page numbers (so the Master shows that data at the extreme left and right of the individual pages in the spreads, normally). This is standard practice for many book types - keeping that information away from the spine area. After adding that single page, most of the following pages switch the side of the page the Master A affected so instead of being on the left, the left-hand page had data near the middle of the spread at the spine. And vice versa for right-hand pages - all information at the center by the spine now. It's fairly easy to reapply the Masters and all is well again. It would be ideal if the s/w did that automatically. The next thing that happened after adding that single page is that some (not all) of the background images (all of them full page arranged at the Back) were sometimes pulled to the "Front" (Arrangement...) instead of being at the "Back." So the Master Page Section Names and Page Numbers became invisible (hidden behind the image). Again, fairly simple to click each and push them to the Back again but easy to miss that unexpected change. Finally, the last page in the sequence lost its Section name (just vanished from the Section editor so I had to manually enter it in again). The unintended moving of background images forward can also happen if 2 pages are inserted after a recto page in a 2-page spread. It seems random and not every following page exhibits the image problem. However, this is a consistent and repeatable problem that has always made these unwanted changes in the past. You can use my previously uploaded "large" document for the testing - it's what I'm working on.
  6. See the screen shot. This Box style is the built-in version with just a change in font color to black. The problem with this is several-fold. For one, the outline frame often does not match the actual "box" in size or alignment. This is especially difficult when first laying out the box. Then there is the distance from the frame versus the distance from the actual "box" - which are different. There is no way that I can see to select an accurate distance for the visible "box" - distance is only displayed for the misaligned frame. The last bit is just more of a question - is there a way to change the background color of the box itself. After spending lots of time going through the various Text Styles editors, I can find no way to change it from the light gray to another hue. Thanks!
  7. thetasig

    Box Style frame skewed

    Thanks, thomaso - very helpful. It seems to work fairly well and I can simulate using a "box" by using the Text Frame instead. There is one tiny nit to pick. The frame itself is the "box" edge, for all practical purposes (using a standard "Body" style). And the Insets work well for left and right edges of the frame - keeping the text 2.1mm away from the edge in this case. However, the top and bottom edges (also set to 2.1mm each) of the frame can be extended way beyond the beginning and end of the text (that is the top edge and bottom edge can be visually, for example, 8mm away from the text or 0.5mm close). So the Inset is not being respected and needs to be "eye-balled" for the distance. So one problem is solved - the distance to nearby objects is easy using the Text Frame. I've traded that ease for a not-fixed Inset for top and bottom edges. Overall, I think I prefer the box style as it enforces the 4-edge Indent settings. While I was testing this out, I discovered that (purposely or not) accents above or below characters are not kept at the Inset/Indent distance. I'm guessing that this is "normal" behaviour and not an accident.
  8. thetasig

    Box Style frame skewed

    sorry - forgot the image
  9. thetasig

    Box Style frame skewed

    Many thanks, Walt. Again, not intuitive in the interface. When I opened the Decorations on the default Box style earlier, it was NOT enabled. So I ignored it thinking that there was nothing there to change - nothing active. As I see it now, when Decorations is NOT enabled, the box has a default gray Fill (out-of-the-box AFPUB) and indent settings of -2.1, etc., (that are active on the object that uses the Box style). When enabled, then you can make changes. thomaso: Both Text Frames and the Box style have separate "fill" colors. And both have insets/indents to keep text away from the frame edges as needed. The Box Text Style has some interesting features that I may use in future - so I wanted to give it a whirl and see what it can do. One feature, for example, is that you can choose the "Indent" for the top edge to be relative to Cap Height; bottom edge relative to Descent, etc. This allows more freedom than the "inset" feature found in the Text Frame. My point is that each has useful but different features and implementation. Now, there is still the matter of deciding how to get the proper distance from the Box Text Style edges to nearby neighbor objects. The displayed distances as you move the text frame are not correct for the Box edges - ever. And I still have no clear/easy way to make that work the same way as other Text Styles work inside a Text Frame. What I would have expected from the programming, however, is that the displayed distance would show the "actual" distance of the box edge to the nearby object (regardless of the Indent values). Caveat - the Indent values can be set to positive numbers, moving the text outside the box. See the screenshot of the original text frame with Box style with example text frame with Body style. These two frames are exactly 7.mm on the left from the object on the left. But the gray box extends out closer to the left-hand object due to the negative Indent value. So to set the correct distance for the box, you have to add/subtract the Indent value of an edge to the displayed text frame distance as you move it. For a 7mm distance with a -2.1mm Indent, you have to manually set the distance to 9.1 to get the box edge 7mm from the nearby object. It seems like the software could do that for you. At least there is a workaround if you don't mind doing the math.
  10. thetasig

    Box Style frame skewed

    Actually, I did look at the Text Frame panel > fill and stroke - many times. For the box style (Text Style) I chose to use in the frame, the box background is gray and has its own, separate frame. In the Text Frame panel for that box, the Fill and Stroke are NULL. The Text Frame and the Box Style are two different objects as I can see when I fill the Text Frame with color and it fills but is behind the box style object. So, I am still looking to control the Text Style known as "Box". I have to assume that it is somewhere in the editing of Text styles, but I cannot locate the default gray color to make a change.
  11. I haven't tried this with Picture Frame Ellipse Tool. The scenario: 2-page spread with one 2-page background photo in a frame and several embedded photos inside Picture Frame Rectangles. I want some of the photos / frames to overlap so I move them into place and note that one frame (selected) is behind another. So I Arrange / Move Forward One. Nothing - the frame is still behind another. So I repeat Arrange / Move Forward One. Nothing. After several failed attempts to get the frame to move forward, I try to Arrange Move to Front. That works. The same happens when using Move Back One. Nothing appears to happen after several attempts and I must use Move to Back instead. The problem with that is that there is a framed background photo across the 2-page spread so the photo is moved behind that background and disappears. Then I have to go to great lengths to get things straight again since Move to Front is the only thing that will work visibly, I must, instead, deal with the second photo - Move to Front. My observation is that there are three layers of frames, then: the background, and two photos overlapped together. Basically you can move one photo to the back and it disappears, then you can move it forward ONE to become visible in front of the background. But moving forward one more time will not move the frame on top of the other smaller photo. It appears, then, that AFPUB thinks the two smaller photos are at the same layer since nothing happens. But Move to Front does work. My point in mentioning this is that the Move Forward One and Move Back one never seem to actually, reliably DO anything visible - I suspect that they are partially broken as I have see this problem over many months in beta and in the published version.
  12. Posted April 23 in mac bugs. Using AFPUB 1.7.1, OS X 10.13.6. I have noted that both text frames and index frames will wrap around entire words and will not split a word into two lines and will not put a dangling comma starting a next line (keeps the word and the comma together always) and will not allow a dangling space to start a next line. However, numbers are being split across two lines both in text frames and in index frames and a comma or a single space (such as found between index page numbers) may end up starting a next line both in text frames and index frames. I believe that these are bugs or broken features; that numbers (with commas and spaces) that wrap around to another line should be treated the same as alphabetic characters (and not split between lines ever) and commas and spaces should not be starting a line that has wrapped around. I have not found any way to control this from the UI. Here is one example that I have in an index (and confirmed that it has a similar problem when formatted separately in a text frame with the default "body" style). Example shows 1) the split page number "60" on the first line of page numbers, and 2) the dangling space starting the next to last line before "126" and 3) a dangling comma starting the last line of page numbers. Photo ii, 5, 18, 20, 21, 22, 29–31, 34, 40–42, 44, 45, 56, 6 0, 66, 67, 70, 71, 73, 78, 98, 99, 115–117, 119, 123, 126, 155, 173, 189, 190, 191, 193–195, 197, 200, 206 , 207, 212, 221 A quirk that is unusual to me: if the number of pages for an indexed item are few, then the Topic Name and the page numbers are all on the same line. If the number of pages is larger than will fit on the first line, then all of the page numbers start on the line after the indexed item (as shown above). I would think it more efficient and consistent-looking to always start the page numbers on the same line as the indexed item (as is possible if the indexed item itself is not too long) and then wrap around to the second and subsequent lines as needed. Is there a compelling reason for this inconsistency between a short page number list and a long page number list? Thanks for any information on how to control the formatting or confirm if these are bugs.
  13. A workaround is to (Show Special Characters) copy the enspace from one of the index entries and then perform a Find of that and Replace with a standard "space bar" space. Then the index entries do not split numbers or dangle commas and spaces. It's an extra step but fairly quick to do (Replace All - as long as you do not have enspaces anywhere else in the document. Otherwise just Replace one at a time through the index).
  14. I think maybe someone should look at my very large document. I have noticed, since the final version of AFPUB (and not before), that there is a huge delay in opening the document and getting it ready to actually edit. First there is just the loading percentage - that takes about 2-3 minutes or so. Then, if I try to open the Resource Manager right after the document is loaded, there is a 45 second delay while that populates with items. Then comes the silent delay. That goes through some 4-5 minutes or so of who knows? I can try to "do" something like show the text flow. That shows up about 2 minutes later, then I click a text box and nothing - it doesn't get selected. Waiting another 3-4 minutes, finally that text box gets highlighted. Similar delays happen when trying to select other objects to edit. All the while, I'm watching the "Force Quit" list and the Activity Monitor list and AFPUB goes into and out of "Not Responding" status about 2 times during the l-o-n-g wait and also showing %CPU upwards of 450 and back down to nominal 20-60%. It's AFPUB 1.7.1, OS X 10.13.6. computer memory 48GB, AFPUB using 23.74GB or so, plenty of local disk space 570GB available out of 1TB. This problem is repeatable, just have to close the document and open it again to see the delays. Eventually, some 5 or so minutes later - AFPUB finally gives me control. But the "not responding" status is worrisome and may indicate something that's not quite right. Let me know if I should upload the file - I think you may find some interesting "stuff" going on in the background. Thanks!
  15. thetasig

    Opening Long Silent Delay

    Here is the diagnostics file that was generated when Publisher became quiet at the end of the approximately 10 minutes Publisher was spiking the CPU. I hope it might be useful. Affinity Publisher_2019-07-12-070537_MacPro.cpu_resource.diag
  16. thetasig

    Opening Long Silent Delay

    Pauls, I am attaching a CPU History screenshot from the Mac Activity Monitor. Affinity Publisher is the only application running, except the Activity Monitor. The graph of the 12 cores shows affinity loading up the document. That is just the first spike in the screenshot. Then all became quiet for a short time. I just sat at the computer screen looking and did not click anything in Publisher or anywhere else. As I watched, you can see that, roughly, every minute or so, publisher goes through a very large CPU usage - a spike up to about 400-600 % and then gets quiet again. This goes on for some 8 minutes total time. At that point, Publisher actually becomes quiet and stops causing the CPU spikes. It is during that time of about 8 minutes, that anything you try to do in Publisher will be delayed or misinterpreted (as though "where" you click might be somehow offset to another object) or just causing the spinning "busy" wheel to appear. The "quiet" times in the CPU usage are actually times Publisher does not respond properly. I've learned from that to just go make coffee and come back after that long time frame. Then all seems well after that. I noted that 'Spindump' became active at the end of the Pulbisher activity and if you know where that dump was stored (or how to find its location) I could include that too. Spindump was automatically activated at just about the 8-10 minute mark just as Publisher quieted down. And, if there are other reporting aids of which you might make use, just let me know. Console/Mac Analytics Data/2019-07-12 07:05:37.264717 - com.apple.message.domain: com.apple.crashreporter.writereport.cpu_resource.diag com.apple.message.signature: Affinity Publisher com.apple.message.signature2: UNBUNDLED ||| 1.7.1 (1.7.1) ((null)) com.apple.message.signature3: cpu usage com.apple.message.result: noop com.apple.message.summarize: YES See screenshot for CPU history graph for the 12 cores. Keep in mind that the first spike in the graph is just the loading of the document. For all of the other spikes, nothing apparent is happening - but Publisher keeps spiking for about 10 minutes, then becomes quiescent.
  17. Note that this happens with numbers in a standard Text Frame (with "Body" style) - split numbers, dangling commas, and spaces. I tested that earlier by manually typing fake page numbers (not a copy/paste) into a "normal" text frame. I think it is not just the index field per se.
  18. Hi Pauls, Just the other day, I uploaded a large file for you to check out - it has problems of lagging and "Not Responding" for about 8-10 minutes after opening. That file shows the large index and all of the split numbers, dangling commas and spaces, etc. I still haven't found a way around the problem, except to manually make changes (too extensive to do). If you are not seeing the behaviour, then it may be some of my index settings, styles, etc.?
  19. I believe that I can safely say the non-printing character was a glitch that has been fixed between the beta and the final. But I did have to manually re-enter the keyboard hyphens in order to get rid of the non-printing character in the exported PDF. I'm guessing it was a database conversion issue in beta.
  20. Thanks for changing the indexing to include topic names that begin with numbers. Numbered items, then, are all under the Index Section Heading: "1". Changing the text style for all of the Index Section Heading items changes them all - except the "1" So all section headings A-Z can be changed to have a different font size. But the "1" (that is also marked as "Index Section Heading") stays the same size. Example: "A-Z" are 5 points, "1" is 12 points. See screenshots.
  21. Finally, I think, the original document in beta had all keyboard-typed hyphens. Nothing fancy. However, it seems that the latest document has changed all of those standard hyphens into non-printing characters when exported as a PDF into Acrobat. I will try a Find and Replace on all to see if that corrects them (it seems to do so when I manually type in the hyphen again).
  22. Sorry for the omission, the standard keyboard hyphen in AFPUB also works properly in a PDF.
  23. thetasig

    Opening Long Silent Delay

    Also, see this topic submitted earlier: "not responding" - shows a screen shot, computer and document info.
  24. I attempted to export to PDF and saw a message that some of the resource links were missing or out of date. Looking at the Resource Manager list, I found 5 or 6 photos with missing links. Now, this seems strange since the source files and names have not changed in several weeks. However, I continued on to Replace Photo for each one of those and, as I did, the Resource Manager marked them as linked again. So that might be a small bug in the Resource Manager - thinking something has changed but in reality has not changed. I also noted when updating an image in the source files, AFPUB dutifully notifies the user that an image was changed outside of the application. And that message has a button to open the Resource Manager. Instead of replacing the image automatically (as AFPUB used to do in beta) the image is kept without change until the user forcefully executes a Replace Image. It's a bit unexpected - to have to manually do that, but I suppose that it guarantees user intervention if the need arises. However, I noted that replacing the existing photo with the SAME photo caused the replaced image to stretch out of proportion. The reason is that the original photo was not marked as properties of "Scale to Max Fit" (NULL value in that dialogue). As soon as I scaled to max fit, the image was back to normal. It's a small bug with an easy workaround and may be "as intended' - just wanted to report that small issue.
  25. thetasig

    Opening Long Silent Delay

    Thanks Pauls - the file is uploading now - it will take a short while to finish up, maybe 15 minutes or so. Good luck checking out the document...
×