Luca Huelle
-
Posts
13 -
Joined
-
Last visited
-
Luca Huelle reacted to a post in a topic:
Publisher, Photo and Designer all crash on trying to save my document (without saving)
-
Luca Huelle reacted to a post in a topic:
Publisher, Photo and Designer all crash on trying to save my document (without saving)
-
@Hangman I think I originally created it in V1 in 2022 but I have heavily edited the same document since then. First in V1 and then later in V2 without issue. I also edited it on a mac in V2 in between. This issue started happening when I moved back to my windows machine. So the file would have passed through something like this (exact version numbers might not be correct but relative high/lower version is correct): v1 (windows) -> v2.0 (windows) -> v2.2(?) (windows) -> v2.2 (macos) -> v2.5 (macos) -> v2.2 (windows) [crashes start happening here] -> v2.5 (windows) [and continue here]
-
Hangman reacted to a post in a topic:
Publisher, Photo and Designer all crash on trying to save my document (without saving)
-
Right okay I'll try that in future if it ever happens again then. Thanks again for your help!
-
@Hangman that seems to have done the trick! Thank you so much. Anything I need to avoid doing so it doesn't happen again? Did you just strip the history from the file or was there something else wrong?
-
I was able to package it without any crashes so that's good I guess! I've attached the file. Investigating Affinity file save crash.zip
-
I've made a recording of the crash process - it really is very simple to achieve for me which makes me think this is a localised issue on my end. (I accidentally clicked New from last Preset when I want to open the file the second time to show that it hasn't saved through the crash: this is not part of the bug.) Screen Recording 2024-09-13 164544.mp4
-
Currently I open my document, make any edits as small as just replacing a + with an & character, try to save in any way and the application crashes. I suspect my file is in some way corrupted but would anyone be able to inspect the dmp file to confirm this? I can share the document itself if necessary. Note that when the applications crash during saving like this, they do not delete the ###.afpub~lock~ file so this has to be manually deleted in order to open the document again in another application that is not the original (e.g. to open in Designer after it save crashed in Publisher). Save and save as are both affected. Manually via the file menu as well as using Ctrl+S and Ctrl+Shift+S. Both saving history with the document and without it. I have tried disabled hardware acceleration. All three Affinity suite applications behave identically. All are up to date to 2.5.5. I am on Windows 11 Pro (version 10.022631 Build 22631). I have attached the most recent log and dmp files from Publisher (where I first encountered the issue before testing the other applications). attachment_Log.txt 9d543613-e331-4042-a020-d2e42545c128.dmp
-
kenmcd reacted to a post in a topic:
Korean (non-latin) font cannot be extracted from exported PDF if Embed subsets is checked
-
They both worked thank you so much! Could I be a real pain and ask you to convert Medium and Light (attached) as well? I can't seem to find any tools online that actually convert them properly NOTOSANSKR-LIGHT.OTF NOTOSANSKR-MEDIUM.OTF
-
Thank you for your explanation - clearly there's a lot to unpack here and it's all very complicated 😅! But still thank you for your explanations 🥰 If you could provide the TTF fonts that'd be great since that seems to be a suitable workaround for now - assuming it converted the Korean characters suitably as well (which I guess it might not have done given that might have been the whole reason the newer otf type was used in the first place... but it's worth a shot regardless).
-
Luca Huelle reacted to a post in a topic:
Korean (non-latin) font cannot be extracted from exported PDF if Embed subsets is checked
-
Thank you so much for the in-depth investigation, LibreTraining! Hopefully this gets a step closer to the root cause. So am I right in saying that it does seem to be something to do with sub-setting and embedding an OTF font? Does this happen with other OTF fonts or just Noto KR/other international fonts since it has a larger number of glyphs than perhaps expected maybe (because it includes non-latin glyphs)?
-
Hi, thank you for having a look at the issue! None of the issues I looked through in those search results are really related to my bug I think. They were using the wrong fonts, resulted in garbled output, had issues using the Adobe Fonts platform or eventually discovered it was actually a bug with InDesign and not the PDF reader. Could you give some examples of "elsewhere"? I've tried to view the PDF in Microsoft Edge, Firefox, Sejda & PDF Chef (online) - none displayed the font correctly although some had a crack at some of the individual letters at least but never all of them.
-
Further potential note of interest, NotoSans KR are OpenType font (.otf) files whereas NotoSans are TrueType font (.ttf) files when downloaded from Google Fonts (links in original post).
-
I have a document (Font Embed Example.afpub) using Noto Sans Korean [KR] Bold (Google Fonts) and Noto Sans (Google Fonts) but still only using Latin characters. Both fonts are listed as 'Installable' in Windows font settings: However, when exporting the document as a PDF from Publisher with the Subset fonts option checked, the exported PDF (Font Embed Example (subset).pdf) is missing all styles (i.e bold and regular) of only the KR font: The regular Noto Sans font however embeds perfectly well: Unchecking Embed subsets fixes the issue, at the expense of increasing file size from 1MB to almost 8MB (since the Korean font is quite large) (Font Embed Example (non-subset).pdf) which is too large for some file upload limits. I think this may be a bug in the PDF exporter. I haven't conducted any testing with other non-latin fonts but this may yield similar results. I'm running the latest Publisher version on Windows 11. The same issue also occurred on my laptop running Windows 10.
