Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by Truthseeker10

  1. Thank you, Dan! 👍 It's good to know this is the right place to send in bug reports. I've got another one lurking re tabs with custom leader characters but want to do a bit more checking before I report it.
  2. I'm sad to see that this bug hasn't been addressed in the newly released Affinity Publisher 1.10.5 I thought this was the proper, official way of reporting bugs to Affinity? (I know it's worked before, but no-one from there has even acknowledged it here so far.) Is there a better way to report bugs as I'd like to get this one corrected to save my sanity! Cheers, Mike B-)
  3. Thanks, PixelEngineer! Thank you for the tip about Shaft-Clicking the border of an image to restore its aspect ratio; I hadn't found that. I might well do that, although it's a bit of a pain as there are 93 images scattered through the 248 page book. But once it's done it's done. I did think about some form of technology to help the ageing relative read from a PDF, or even trying to copy the content into something that will generate an ebook. Sadly, she's at an age where technology totally defeats her and we need a physical print book. Thankfully I can scale-up the book from Affinity Publisher and use that to prepare an A4-sized book at the print-on-demand company we use; it's fine to order even just a single copy!
  4. Hi, Wosven! Thanks ever so for confirming the results/problems exist on Windows as well; that's reassured me I've described it in sufficiently painful detail for the Affinity Team to reproduce the problem too! 😂 I try not to use Acrobat Reader as in the past it's annoyingly tried to take over handling various documents and viewer processes. But using the Mac's own Preview application to do the enlargement was going to be my fallback position if I'd not found a workaround. (Although the enlargement would have been approximately 100 x 297/210 = 141% rather than 200% to go from A5 to A4 — it's double the area, not double both linear dimensions.) However, Preview has its own way of being annoying: sometimes putting extra margin space around the thing you're printing. I think it's trying to be helpful and avoid non-printing margins. I also need to have an exact amount of bleed around the edges of the standard A4 content size, otherwise the printing company's validator software will get cross when I upload it. 🙄 As APub has already downsampled the images I've embedded in the book, I'd also prefer not to then upscale them and lose quality, but instead re-export the PDF direct from APub so they're downsampled correctly for the A4 job. (Yes, I know: I'm too much of a perfectionist, perhaps! 😄) To work around the border scaling problem I can do the enlargement and ignore the massive borders, but then select the heading paragraphs on the Master Pages and replace the wildly wrong border thickness with a correctly scaled value — 0.8pt x 297mm/210mm = 1.13pt. This fixes the problem, but sometimes doesn't cause the other pages to refresh in APub and show properly until you save and re-open the document. Hmm… Maybe I should have mentioned that refresh/redraw being omitted as a possible bug too! 🤔
  5. Hello! I'm using Affinity Publisher 1.10.4 on a Mac running macOS 12.2 (Monterey). AP's hardware acceleration is turned on. I've been creating a book with pages sized to A5 (which AP believes to measure 148mm x 210mm) and which I now need to resize up to A4 pages so I can generate a different PDF for a larger print copy for an ageing relative. I use two sets of Master Pages, each set being for facing pages. One Master Page or the other is applied to every page in the book. In particular, Master Page A is applied to every page after the introductory pages, to provide running titles and page numbers throughout the book. To do this I have two text frames on Master Page A: one for the odd (right) pages and one for the even (left). The text in these two frames has a Decorative paragraph attribute applied to it to add a horizontal rule the width of the page's column, of thickness 0.8pt. After I resize the Master Pages from A5 up to A4 with scaling applied, the thickness of the horizontal rule goes insane! I was expecting the thickness either to be left at 0.8pt (if left unscaled), or increased to 0.8 x 297/210 = 1.13pt (if scaled in line with the overall document). Instead it increases in thickness to 3009451852967572480pt! 😳 (Yes really: that number is copied from the border thickness in the Paragraph attributes' Decorative settings.) This results in huge black boxes being applied over the content of pages throughout the book. I've tried replicating this in a new document and it also occurs there. However, in my first tests the border thickness does not increase so drastically, but still increases more than it should. Instead how bad it is appears to relate to the number of pages in the document — my test document has only 10 pages, whilst the book has 248. See below to confirm this… Sample Document and Steps to Reproduce the Bug I'm attaching my newly created test document: Test Sample 1.afpub. In it you will find one set of Master Pages with some text for the odd and even pages, each with a 0.8pt border applied below its paragraph. There are ten regular pages in the document, each with the Master Page applied. The first page has some dummy content: some text, along with a picture to illustrate a different issue that occurs. To reproduce the problem: Open the test document in Affinity Publisher. Select the Move Tool and go to the Master Page by double clicking it in the list of pages on the left. Click outside the master pages so you see the Document Setup and Spread Setup buttons at the top. Click the Spread Setup button. In the dialog box that appears, select the Dimensions tab. Select the All Spreads radio button at the top of the dialog box to apply what follows to all Master Pages (probably not necessary here, but is in my book document). Change the Page Preset size from A5 to A4. Click the Scaling tab. Choose the Rescale option. Click OK and, when prompted whether to also apply the rescaling to the target pages, choose Yes. I would expect the thickness of the border below the paragraph in the header area of the Master Pages to either email at 0.8pt (if left unscaled), or to be adjusted to approximately 1.1 (if their thickness is scaled in line with the adjustment in page size). Instead the thickness of the border is increased to 9.2pt — you can check this by selecting one of the header paragraphs on the Master Page, going to the Paragraphs panel and looking at the Decorations section. The stroke thickness for the border below the paragraph has been set to 9.2pt. Now Blow Your Mind… Revert to my original test document. Add 100 pages after its final page, applying the Master Page to them as you do so. Repeat the above test. This time the border thickness is set to 334341210.3pt instead of 9.2pt! 😳 I'm also attaching a screenshot of the result of this test, showing the border thickness that's been calculated and set for this 110 page version of the test document in the Paragraphs panel on the right. So the thickness of the border you get is related to the number of pages in the document you are rescaling(!). In passing… Non-Proportional Scaling Problems After you have done either test, go to the Preflight check panel. There'll you'll now find a warning that non-proportional scaling has been applied to the image — you'll probably see something like 19.0% x 18.9% which isn't really visible to the human eye, but is to the Preflight Checker. (Sigh! 🙄) I think this may be because A4 is exactly 210mm x 297mm, and A5 is 148.5mm x 210mm. However AP, like printing companies, uses 148mm x 210mm as the dimensions of A5 — a very slightly different aspect ratio. This means that when scaling from one to the other you end up with AP applying non-proportional scaling, and thus triggering the wrath of the Preflight checker. I wish this could be fixed too, but don't see how it can without causing problems for people preparing work to go to printing companies, who want A5 dimensions of 148mm x 210mm. Sadly, that deviation from A5's actual measurements means you can't apply proportional scaling without risks, I guess? But maybe the wonderful AP team can figure out a way to Magically Make Image Scaling Work Properly too, to pacify the Preflight checker?! 😇 Cheers, Mike B-) Test Case 1.afpub
  6. I've been creating a book in Affinity Publisher 1.10.4 on a Mac for a friend with its pages set to A5, laid out in spreads of facing pages with Master pages applied. They then asked me if I could do a larger print version with the pages sized to A4 and content scaled up to help their ageing relative read it. Like this thread, I learned that if you do the instinctive thing and resize the actual spreads of the book the content of the body pages is resized but that of the masters isn't. I also discovered the trick of resizing the Master pages instead and then saying yes to apply the resizing to their child pages. However… As well as a bug I found to do with paragraph rules (which I'll start a separate thread for), I found that resizing from A5 up to A4 is not great: it leaves placed images very, very slightly distorted, which then annoys the preflight checker: warning me that non-proportional scaling has been applied to the images. For example, 113.8% x 113.4% I assume this is because Affinity Publisher believes the size of A5 to be 148mm x 210mm, which technically is not correct (but is as far as printing companies are concerned!) — it should be 148.5mm x 210mm. So instead of upscaling from 148.5mm x 210mm to 210mm x 297mm Affinity Publisher upscales non-proportionally from 148mm x 210mm to 210mm x 297. This leaves your images distorted by a tiny fraction unnoticeable to the eye, but incurring the wrath of the pre-flight checker. If this could be looked into too when improving resizing as discussed above it would be great. (Although I'm not too sure what the correct procedure would be. As I say, A5 is technically 148.5mm x 210mm, but if you're preparing A5 material to go to a printing company they want 148mm x 210mm. Sigh.)
  7. I have been seeing display (and image data) corruption similar to what Ozzoo describes, and which I reported here in another thread (link included below). A workaround is to go into Affinity Photo's Preferences, then the Performance panel, and turn off the Metal acceleration: untick a checkbox at the bottom of the panel. For me and others this makes 1.10.3 usable, albeit without the performance improvements from hardware acceleration. (These instructions are for Mac users, but I think are similar for Windows users where I think it also works around the problem.) Another alternative is to revert to version 1.10.1: either from a Time Machine backup (just restore the application in your /Applications folder) or, if you bought the software direct from Serif, by downloading the older installer from the Affinity website.
  8. I’ve been seeing this, too, but on the Mac version. (In Affinity Photo version 1.10.1) it’s a pain.
  9. I'm attaching a screen recording as requested. (Sorry it's a huge 285MB!) It demonstrates the corruption I see, which looks to be a bit different from that seen by fatfreemedia. In my recording I: Open my test image from the Finder. Wait for ages for Affinity Photo to launch and the image to open. (Affinity Photo 1.10.3 feels slower to launch and to open documents than 1.10.1 was, but let's not get side-tracked!) Open the Preferences panel to show that Metal acceleration is ON. Add a Clarity Live Filter (after getting sidetracked into the wrong menu first!). Adjust its control slider several times. After a handful of such alterations the corruption starts. (For me it has so far been contained solely within the image view in the editing window.) Close the image, NOT saving the changes. Re-open the test image. Corruption is shown immediately: the loaded image is missing a part. Add a Clarity Live Filter. The corruption happens immediately on changing the slider. (After launching Affinity Photo it seems to take several adjustments before it starts. However, re-opening the image within an already running Affinity Photo causes the corruption to continue happening right from the first alteration to the Clarity settings slider.) This is on a MacBook Pro (15-inch, 2018) now running macOS 12.0.1 Monterey. (When I wrote my initial report I was still on macOS 11.6 Big Sur.) MacBook Pro (15-inch, 2018) Processor 2.6 GHz 6-Core Intel Core i7 Memory 32 GB 2400 MHz DDR4 Graphics Intel UHD Graphics 630 1536 MB No external hardware connected; just using the MacBook Pro and its native keyboard and trackpad. 1138871048_ScreenRecording2021-10-26at16_52_29.mov
  10. In case it helps… Whilst browsing posts for Affinity Photo in Windows I learned its Preferences > Performance settings. I've been into these on my MacBook Pro in 1.10.3 and turned off (unticked) the "Hardware Acceleration: Enable Metal compute acceleration". Repeating the test using my test images no longer causes the corruption as long (as long as this is turned off). I'm bemused why this should affect more than just the displayed image: why the saved image also got corrupted. But perhaps the acceleration is used not just for the display but also applying filters and edits to the actual image data itself? It seems to be a workaround for this particular problem, but I'm going to hang fire on using the 1.10.3 applications in general for now. PS. I've now upgraded from macOS 11.6 Big Sur to 12.0.1 Monterey and the problem with Affinity Photo 1.10.3 with Metal acceleration remains (and the workaround works).
  11. The Problem I'm using Affinity Photo on an Apple MacBook Pro running macOS 11.6 (Big Sur). Today I updated from Affinity Photo 1.10.1 to 1.10.3 and promptly hit a problem with one of the images I'm editing. The problem manifests when I add a Clarity live filter to the image then adjust the filter's slider several times. After a few (6 to 10) alterations to the slider the image displayed on screen starts getting corrupted. This is NOT just a display problem. If work is saved, the resulting file contains a corrupted image too, although in a different way to that shown on the editing screen. This suggests the actual memory copy of the image data is being corrupted, and so if saved can lead to data loss. The problem does not appear to affect all images so I'm attaching two test files, named "1 - Test 1.jpeg" and "2 - Test 2.jpeg". These are two distinct copies of the image downloaded from different sources at different times, and indeed are slight different (eg, aspect ratio, content). Steps to Reproduce the Problem Open one of the two test files above in Affinity Photo 1.10.3 (I'm using it on an Apple Mac). Add a new Live Filter > Sharpen > Clarity layer. In the filter's adjustment panel, adjust the slider up and down several times. (Eg, move it between a positive and negative value in quick succession.) Within a small number (typically 10 or so) "jiggles" of the slide control the image being edited starts showing corruption, appearing as large square blocks containing either a different part of the image, or random coloured "static". You might need to let go of the mouse/trackpad after each alteration; keeping it pressed and simply sliding the control doesn't seem to cause the problem (as quickly?). Sometimes the corruption effects are transitory and shown only when the control is being slid. Other times they remaining in situ. See the attached screenshot "3 - Screenshot of Corrupted Test Image 2 in Affinity Photo.png" to see an example. Here, the corruption has replicated part of the cottage at the lower right into the top centre of the image. Other parts of the image are misplaced below it and elsewhere. The problem does NOT happen when the test is performed in Affinity Photo 1.10.1 (see below). Observations Closing the image without quitting Affinity Photo then opening the test image again and repeating the test seems to make the issue occur immediately rather than after several wiggles of the Clarity Live Filter's settings slider. This might indicate memory corruption happening within Affinity Photo that is not reset until the entire application is quit and re-run: that closing and re-opening the image file is not sufficient. See the attached screenshot "4 - Screenshot of Corrupted Test Image 2 in Affinity Photo.png" to see the result of closing (without saving) then re-opening the image file without quitting Affinity Photo then re-opening the image file; adding the Clarity filter and adjusting it immediately caused this spectacular corruption. Exporting this corrupted image as a PNG gives rise to a corrupted image saved to disk. See the attached file "5 - Corrupted Test Image Saved.png". Likewise, saving as a native Affinity Photo file also stores a corrupted image. This can cause data loss when editing such a file, causing the corruption, then hitting Save before realising: it overwrites the original file with the corrupted image. I have not had this problem before, so restored Affinity Photo 1.10.1 from a backup and repeated the tests. Version 1.10.1 had not problems with my repeatedly altering the Clarity Live Filter's setting; no corruption occurred. (I see in other posts people mentioning crashes caused by memory allocation issues, and this corruption gives me the feeling it is the same sort of issue.) Trying the Test Images in Other Formats In case there was an issue with the JPEG data in the two test files I used Affinity Photo 1.10.1 to open "2 - Test 2.jpeg" then export fresh copies as JPEG and PNG. I then repeated the tests using these exported images in Affinity Photo 1.10.3. The problem continues to affect both images, suggesting it is not related to an issue with the original JPEG file's data. The fault in 1.10.3 does not affect all images. I repeated the tests with some other image files and could repeatedly alter the Clarity Live Filter's settings without problem. In Conclusion For now, I have both 1.10.1 and 1.10.3 installed on my Mac so I can do any testing Serif might need, but plan to only use Affinity Photo 1.10.1 to work with for now. I don't trust 1.10.3! Cheers, Mike B-)
  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.