Dan C
-
Posts
13,847 -
Joined
Posts posted by Dan C
-
-
Thanks for your report @Diego Lopez!
17 hours ago, Diego Lopez said:On the first screen shot you can see the strange white lines that appear at the bottom and right edges of the design. Upon zooming in, you can see on the second image that those lines are not part of the design, they just appear as artifacts when you are zooming out. I believe this behavior was not present in the last version.
As above, the white line you're seeing is a known consequence of the Affinity apps using mipmaps to render the canvas quickly when viewing at different zoom levels.
If you view the document at 100% zoom, or export the file, you will find these lines do not appear.
Affinity has been using mipmaps since the apps were first created - however you may have not experienced this previously as they may only appear with certain canvas content, or at specific canvas sizes/zoom level combinations.
I hope this clears things up
-
-
Thanks for providing that for me!
I'd recommend ensuring that your GPU drivers are fully up-to-date, directly from Nvidias website, as outdated drivers can cause issues in Affinity.
I'd also recommend ensuring that the 'RAM Usage Limit' slider is set sensibly for your system - either at the value of RAM you have available (most systems have 8GB or 16GB nowadays, but some can have more) or slightly below this. For example if your system has 24GB of RAM then this setting is currently fine, however if your system has only 16GB of RAM, I'd reduce this to 16384 MB or below.
If you're still having issues after updating your GPU drivers and restarting your system, I'd recommend unticking Hardware Acceleration at the bottom of this dialog and then restarting the Affinity app as prompted.
Please do let me know how you get on here
-
Thanks for confirming that for me
8 minutes ago, Barrie Hope said:This puzzles me greatly because all systems were working fine a few hours before. I presume there is a setup file, saved on each machine, and it was this that was corrupted, or maybe I'd hit the wrong keys accidentally? But why did it happen simultaneously on both mac minis? Do you keep my setup at your end, and was that corrupted?
I can verify that this information is stored locally to your system and is specific to each device - so I must admit that I too am perplexed as to how this could have occurred simultaneously across multiple systems that do not use an external/additional monitors.
I do not believe that you personally have done anything incorrect to trigger this, as there's no such shortcuts built into the Affinity apps that should cause this behaviour to occur.
I'll be sure to update our development log regarding this issue with the information you've provided above, and should we have any further questions to help assist our team in resolving this issue, I will ask them here!
-
Thanks for your report @srg!
As Walt mentions above, this is a known issue which I have recently created an FAQ regarding, you can find steps on how to resolve this issue here -
I hope this helps
-
Following the release of Affinity 2.2, our team have discovered an issue on macOS where when connecting or disconnecting an external monitor, the Affinity app window does not resize as expected.
This causes either the top 'toolbar' of the Affinity app to be hidden from view (ie the app does not fully fit on the screen), or not showing the applications UI at all, only displaying the 'New Document' dialog.
Our team are aware of this issue and we're working to resolve it as soon as possible. Unfortunately there's no way to stop this issue from triggering when connecting/disconnecting an external monitor, however simply navigating to Window > Zoom from the top menu should return the missing UI elements.
If you're still having trouble returning the Affinity app to default view, you can reset the app using the method described below -
If you aren't using an external monitor, please create a new thread describing the issue and your setup and our team will be happy to assist further.
-
Hi @Barrie Hope,
Welcome to the Affinity Forums
I'm glad to hear you've been able to resolve this issue, just for our developers information - are you connecting an external monitor to your MBP?
Many thanks in advance!
___________
Welcome to the Affinity Forums also @jim cuad!
As above, can you please confirm if you are using an external monitor in conjunction with Affinity?
You should find that selecting Window > Zoom from the top menu restores the Affinity app display without the need to reset to default settings, should you still be experiencing this issue.
I hope this helps
-
Thanks for letting us know @Diego Lopez & we're sorry to hear this!
This issue is still logged with our development team and I have 'bumped' this issue with them, to bring it to their attention once again - as we're seeing a steady increase of reports for this issue, we're hoping to resolve it as soon as possible.
Our apologies for any inconveniences caused due to this in the meantime.
-
Sorry to hear you're having trouble @LeighK!
Can you please email affinitysupport@serif.com so we can investigate this issue further for you, and better understand the examination Microsoft have made of your report?
The more information you can provide regarding this issue, your PC setup and the steps you've already taken via email will help us to asses and assist as quickly as possible.
Many thanks in advance
-
20 minutes ago, Evgenii said:
Perhaps you were talking about a different issue in the backlog?
The information I provided is an excerpt of a comment from our developers on the original bug report for the issue that has been logged against all 3 of your threads here on the forums - which can be seen in the 'Tags' section of each thread (AFD-1907).
Unfortunately I'm not personally familiar with font tables and therefore I can't provide much further clarification surrounding this - though my apologies if this does not align specifically with the issue you've reported above.
There are many similar reports of Hindi, Bengali, Thai & Myanmar diacritics failing to export to PDF from Affinity logged in the same development report as your report (AFD-1907) and it's possible the comment regarding Morx tables was specific to one of these reports, rather than a generic comment as to the cause of the issue across multiple fonts/languages.
The issue is still logged with our developers and is a known issue for the diacritics shown in your thread, as well as for multiple other fonts/languages - the exact reason for which may differ slightly between document/font/language, but essentially remains a known, unsupported feature of the apps when exporting to PDF at this time.
-
Thanks for providing these for me!
Your PSD from Designer has been exported to the CMYK colour space - whereas the Photo created PSD is using RGB/8.
Is it possible that Moho does not support CMYK PSD files and this is why you are seeing the difference when importing these documents?
(EDIT - If you need to change the Colour Space within Designer, you can do so through File > Document Setup > Colour)
-
Thanks for letting us know @Dlm71 - the behaviour you've described certainly aligns with our current understanding of this issue, in which it only occurs when installing fonts directly through the Affinity apps.
Equally, there is a separate issue logged regarding Adobe Cloud Fonts showing as 'red' when first used, as you've reported above.
I'll be sure to update both the development logs for these issues with your report now and we hope to have this resolved ASAP.
I hope this helps
-
No problem at all, thanks for the further information!
6 hours ago, CBNewham said:If you leave the slider open and click anywhere in the image that is to the right of the left hand side of the slider widget on the screen, then it works. If you click anywhere in the image to the left of the left hand side of the slider then it makes the value jump to 0 internally. It seems that the UI is detecting the click and assuming the user is inside the slider widget and has selected the lowest value on the slider, even though they have not clicked inside the slider widget. The value does not update immediately on-screen because the user didn't click inside the widget.
i.e.: there is an incorrect X/Y position bounds check for the click for that widget. 🙂
I agree, this certainly seems to be what's happening internally. I've updated the development report to include this information now, to assist our devs in resolving this issue
-
No problem at all, thanks for providing further clarification here!
On 10/19/2023 at 4:46 PM, FotobobJP said:Well now I have tried to replicate it (Publisher 2.2.0) just by making new folder on the Desktop, placing some random Publisher file in and giving the folder Read Only permissions. When I try open Publisher file, both double click in Finder or from Publisher itself, it pops up that message "Failed to open file" (path) "The file could not be opened" (OK).
I can confirm this is the issue I have replicated and has been logged as a bug with our development team
On 10/19/2023 at 4:46 PM, FotobobJP said:About "lost paths". They are not really lost to be exact. But the path to linked files in pCloud includes user name, something like /Users/his-her-acc-name/pCloud Drive/Next/next/picture.jpg, so once opened on other computer from same shared folder, the absolute path on that second computer is not same. If linked folders are in (or deeper in), the folder the document is placed (which we do), Publisher automatically detects that relative path and update the absolute one for itself, not issue here. If the afpub file is moved away from linked folders in finder, Publisher is not able to locate them anymore, because users has different absolute path to the linked files, unfortunately. I hope I did not mess up this explanation.
However the above is unfortunately expected behaviour currently, due to the way Publisher creates and stores paths to Linked files. As you've found Publisher will use 'relative' paths for linked content that is stored close to the Publisher file, as this favours speed in accessing these files - however when moving the Publisher file further from this location, the app then returns to using the 'absolute' paths, as this favours stability over 'further' folder distances.
This behaviour cannot be manually set at this time, though our devs are looking at ways to allow for user control here in the future, to avoid such issues with your pCloud resources.
I hope this clears things up!
-
Hi @PeterPeterPeter,
As Return mentions above, the Square Brackets [ ] should function as shortcuts to resize your Brush Tool within the Liquify Persona - though there is no option to manually change these shortcut keys in Liquify at this time, my apologies.
I hope this helps
-
Thanks for your report @Seneca!
I can confirm this issue is logged with our development team - many of the users experiencing the crashing are running macOS Ventura, though not all.
Users that don't experience the crash on macOS, and Windows users see the 'Connection Failed' error, which is also logged with our team.
I'll be 'bumping' these issues with your report now.
I hope this helps
- Seneca, Hangman and jmwellborn
-
3
-
Thanks for raising this @MikeTO!
On Windows, I see 'Outline Style' shown - which is much closer to the expected string from the Helpfile , but still not 100% aligned.
Therefore I'm getting the following logged with our UI team for Windows and macOS respectively;
- Windows needs consideration as to whether 'Outline Style' is correct and the Helpfile needs updating to match, or if this should be changed to 'Outline Stroke' as seen in the Help.
- macOS needs updating to match either the Helpfile or Windows, based on the above decision.
I hope this helps
-
Thanks for your report @NotMyFault!
I've replicated this behaviour here and I've logged it with our development team, as I'm not certain why the Pixel layer content is being shifted with this filter. This seems to change unpredictably based on the Quantisation value, which I have included in the above log.
I hope this helps
-
Apologies, my post was missing the clarification of within the same Affinity app of the parent file, as Carl mentioned above in this thread.
The 'Automatically update linked resource when modified externally' Setting option is functioning correctly for me when editing an .afpub in Designer - in that with the option enabled the Linked .afpub updates, and without the option disabled the linked .afpub does not update - therefore I'm not seeing any bug with this setting, at this time.
-
Thanks for your report @anto!
On 10/22/2023 at 12:50 PM, anto said:I have an linked afpub file. When I change something in it, everything changes in the file it's inserted to, regardless of whether this option is enabled or not. Although the assistant says that the resource was changed externally.
I can confirm that the 'Automatically update linked resource when modified externally' Setting option does not apply to Linked Affinity Documents (.aphoto, .afdesign & .afpub) - these will always automatically update within your parent file when edited.
I hope this clears things up!
-
Thanks for your report @Peter Panino!
I'm not entirely certain of the exact reasoning behind this currently, though I can see that Affinity macOS is able to create a New from Clipboard document using SVG data, so I would expect Affinity Windows to also support this.
I have therefore logged this as a bug with our development team for you now.
I hope this helps
-
No problem at all - thanks for providing this for me!
I can see the app is set to install on disk D :, however as Affinity still uses the temporary folders on your C : drive during installation, the install is unfortunately failing for the same reason as above.
Regardless of if you install the Affinity app on drive C or D, you will need to ensure there is enough space available on drive C during installation in order for this to complete correctly - as above this is around 1.6GB worth of free space on your C drive required.
I hope this clears things up
-
Thanks for your report @Old Bruce!
15 hours ago, MikeTO said:- Create a new document - it doesn't matter if it's facing pages or not
- Create 2 masters - you don't have to name them
- Draw a text frame on master A - you don't have to put any objects on B
- Apply master B to A
- On page 1, paste lots of text into the frame
- Shift+click the overflow icon and more pages will be created - those pages will have masters A and B applied instead of just A
Using the above steps from Mike, I'm able to replicate this on both Windows 10 and macOS and therefore will be logging this with our devs now - as I'd only expect Master A to be applied to the newly created pages.
I hope this helps
-
Welcome to the Affinity Forums @Katharella!
Your SetupUI.log file shows the following error:
Quote+Out of disk space: Out of disk space -- Volume: 'C:'; required space: 1.603.051 KB; available space: 474.884 KB. Free some disk space and retry.
You will need to create more free space on your disk, should you wish to install the app here.
In regards to installing the app on an external drive, can you please provide the SetupUI.log file generated after trying this on your external drive, so that I can investigate the cause of the secondary error for you?
Many thanks in advance
Designer 2.2.1, white borders appearing on edges at different zoom levels
in V2 Bugs found on macOS
Posted
I believe this is a difference shown when using Affinity Publisher (in any Persona) whereby the edge of the Page is always drawn over your document - you can see this by increasing the layer size to be larger than the page size:
As Affinity Photo / Designer uses a Canvas rather than a page, this line is not drawn:
Except for in Affinity Designer when disabling Clip to canvas, as the app then displays this line to indicate where the canvas ends and the pasteboard begins:
This is all expected behaviour for each Affinity app, as I understand it