lynzrand

Thanks for the reply! Looking forward to the next version!

Just double-checked that 1.9.0.876 does not have this issue.

Environment: Windows 10 Insiders Build 21286 The application crashes as soon as I select anything inside two specific artboards. Possible hightlights from the crash report backtrace: "classifier": "AccessViolationException", "attributes": {}, "message": "尝试读取或写入受保护的内存。这通常指示其他内存已损坏。" // ^ Trying to read or write in protected memory. This usually indicates other corrupted memory // ... "backtrace": [ { "funcName": "DocumentInspectorNode.GetVisibleIndex", "line": 0, "il": -1, "metadata_token": 100688723, "column": 0, "address": -1, "sourceCode": "9ab8f0b9-24f5-4932-a948-ee3a0335aaf4", "library": "unknown" }, { "funcName": "Serif.Affinity.UI.Controls.LayerView.OnUnrealizeItemCommand(Object parameter)", "line": 0, "il": 7, "metadata_token": 100669798, "column": 0, "address": 7, "sourceCode": "a2cfc014-dce4-43cd-aeda-de0521ff0126", "library": "Serif.Affinity" }, { "funcName": "Serif.Windows.Data.CommandHelper.ExecuteCommand(ICommand command, IInputElement element, Object parameter)", "line": 0, "il": 49, "metadata_token": 100665517, "column": 0, "address": 49, "sourceCode": "3d88be7c-c40c-4d8c-ab40-2e542f7edc08", "library": "Serif.Windows" }, { "funcName": "Serif.Affinity.UI.Controls.VirtualizingTreeView.ClearContainerForItemOverride(DependencyObject element, Object item)", "line": 0, "il": 14, "metadata_token": 100672854, "column": 0, "address": 14, "sourceCode": "6e459fa5-96ee-4b4b-80b7-2c3815fbef02", "library": "Serif.Affinity" }, { "funcName": "System.Windows.Controls.ItemsControl.MS.Internal.Controls.IGeneratorHost.ClearContainerForItem(DependencyObject container, Object item)", "line": 0, "il": 18, "metadata_token": 100683926, "column": 0, "address": 18, "sourceCode": "5d4b9e49-2f3c-4d93-acf7-9ef5545e2c5c", "library": "PresentationFramework" }, // ... ] The crash report is in the attachment. I will upload the related file if it's needed to resolved the issue. CrashReports-lynzrand-2021-01-09.zip

BTW, Is the forum censoring the word 'local-host' (without the dash)? I am constantly receiving 403 Forbidden, possibly because of this word.

Here's the config. I'm once again being 403'd, possibly by some word detector I guess? address: (...);127.*;10.*;172.16.*;172.17.*;172.18.*;172.19.*;172.20.*;172.21.*;172.22.*;172.23.*;172.24.*;172.25.*;172.26.*;172.27.*;172.28.*;172.29.*;172.30.*;172.31.*;192.168.*

CrashReports-lynzrand-128560.zip

For some reason I kept getting 403 forbidden when posting this. Please see this paste for bug detail -> https://paste.ubuntu.com/p/zZKpf3STF2/

Well, this post survived... Here's a mirror of the content I tried to post in Designer Windows Beta forum: https://paste.ubuntu.com/p/zZKpf3STF2/

This is not a issue on Beta versions alone, but I think it fits here. Affinity Designer has a very handy feature of generating a bitmap version of the selection when copying. But when copying large items, like something larger than 10000x10000 px, this could lead to the program freezing for many seconds (to generate the rasterized version), and even crashing (when the expected image size is larger than system memory size). Expected solution: one of following Add a configuration to avoid rasterization when item size is larger than a user-entered value Warn user about large items when copying, and add an option in the warning to copy without rasterizing it Move rasterization feature to a separate shortcut and menu option, like "Copy PNG (Ctrl+Shift+C)"

Maybe these documents from W3C can help Affinity's developers know what they need to implement: Requirements for Chinese Text Layout https://w3c.github.io/clreq/ Requirements for Japanese Text Layout https://w3c.github.io/jlreq/ Not all features are that eagerly needed, but at least the key and most demanding features for Eastern Asian typesetting like positioning of punctuation marks (JP, CN) and vertical text (JP, CN) should be implemented with high priority. They are the core of typesetting, and with even only the first feature (punctuation mark positioning) we can build designs with much more ease. Copied from my thread:

Maybe these documents from W3C can help Affinity's developers know what they need to implement: Requirements for Chinese Text Layout https://w3c.github.io/clreq/ Requirements for Japanese Text Layout https://w3c.github.io/jlreq/ Not all features are that eagerly needed, but at least the key and most demanding features for Eastern Asian typesetting like positioning of punctuation marks (JP, CN) and vertical text (JP, CN) should be implemented with high priority. They are the core of typesetting, and with even only the first feature (punctuation mark positioning) we can build designs with much more ease. --- Also copied to Loykufai's thread

Try changing the position of the second artboard. You can see from this picture that the grid does not move with the second artboard. But when I change the position of the artboard, the snapping grid moves with it. It might be a mistake in the codebase where the origin of the "displayed" grid is related to the global origin instead of the artboard origin.

Version: Noticed in 1.7, but also reproduced in 1.8.0.486 (latest beta) Bug: Points are snapped to a different grid than what is displayed when using multiple artboards Steps to reproduce: Create a new document Create two Artboards In View > Grid and Axis Manager, create a two-axis custom grid in the second artboard with angles other than 0 and 90 degrees Notice that points aren't snapped to the grid displayed

The Affinity team have noticed this issue, but currently they have no plan on this. They might need more pressure =u= Some related posts: