jwst

Well, I did it. The steps that caused the problem in the live version do not cause the problem in the Beta. I did discover that font favourites are persistent: (With Publisher closed) I tested uninstalling the static fonts after making them favourite. Start Publisher, of course there is no reference to Source Sans 3. Close Publisher. Install the static fonts. Start Publisher: Source Sans 3 is still a favourite! Now for the test what caused the problem in the live version: Close Publisher, Uninstall the static fonts, install the two variable fonts, start Publisher. It starts fine, and Source Sans 3 is still a favourite, even though it is actually different font files. So the beta looks like it has fixed the problem. Thank you!

kenmcd has understood the behaviour I reported - that it is *uninstalling* that causes the problem now. Others of you haven't got it. This is the problem: Affinity crashes at "Loading Fonts" when one of the four fonts I identified is *not* installed. At the moment I have all 14 fonts installed and everything is working fine. I recorded the steps that led to the problem, some of which might be relevant, or not, so that the developers have as much information as possible. So, I had Source Sans 3 as a favourite in the font selection dropdown and everything was fine. Then Affinity 2.5 came along with variable font support, so I installed the two variable fonts and uninstalled the static ones. That's when the problem occurred. So maybe if I had not originally had them as favourites the problem might not have occurred. Or if I had not installed the variable fonts but just uninstalled the static ones, then the problem might not have occurred. Or perhaps it was doing the font install and uninstall while they were still favourites that made it happen... Now I have *no* favourite fonts and the variable fonts remain uninstalled and I can reproduce the problem by *uninstalling* any one of the four identified fonts. For the record I don't have any duplicate fonts. Uninstalling an identified font leaves emptiness for that font. Since some of your are interested, all these fonts are version 3.052. I believe I got them from the github repository. The foundry is identified as Adobe. The fonts identify themselves as "Source Sans 3" *without* "VF" so static, not variable. they are "OpenType Layout, Digitally Signed, TrueType Outlines". But remember - they are working fine. It's only when one of the four identified fonts is *not* installed that the problem is reproduced. The problem does not occur if any of the other ten fonts is not installed. Thank you all for your interest!

Thank you for your reply. In this case the bug seems to be just related to any of four specific fonts not being installed, so I'm OK leaving them installed so I can use the Affinity apps, and wait for the 2.5.2 update. If the bug escalates and I have no workround, then I'll go to the trouble of installing the beta.

All Affinity apps 2.5.0 (Testing done mainly on Publisher.) Windows 11 Hardware acceleration ON I see other reports of crashes of 2.5.0 but it's hard to understand if any of them match this one. I successfully used 2.5.0 after upgrading. Source Sans was one of my "favourite" fonts in the font selector I had the static version of Source Sans installed - 14 variants I decided to replace them with the variable version of Source Sans. I uninstalled all the 14 variants, and installed the two variable fonts, regular and italic. Now for the crash - when I started Publisher, the splash screen got to "Loading Fonts ..." and then it crashed - silently disappeared. I've included the Event Viewer event below. (I use High-Logic MainType to install and uninstall fonts) I tried a number of things - uninstalling the variable fonts, stopping High-Logic MainType's Windows Service, rebooting, and starting Publisher holding Control and deleting my preferences, but to no avail. Then I thought perhaps it's looking for the static version of Source Sans, so I installed the 14 variants and RESULT! Publisher and the other apps now start correctly. Of course Source Sans and my other favourite fonts are no longer shown as favourite, presumably because they are part of the preferences that I removed when I started Publisher holding down the Control key. I reproduced the sequence - close Publisher, uninstall the 14 Source Sans variants, start Publisher: It crashes at "Loading Fonts..."; install the 14 fonts, start Publisher: it starts correctly. I noticed that uninstalling the fonts while Publisher is running caused Publisher to crash, with no entry on the Windows Event Log. Now I uninstalled the fonts one by one, while Publisher is running, starting with the heaviest. Publisher didn't crash until I uninstalled Source Sans 3 Medium. These are the other ones that made it crash: ExtraLight Italic, Light Italic, Italic. Publisher (and Designer) are happy with the other variants uninstalled. So it's just those four fonts that have to be installed for the apps to start. Otherwise they fail at "Loading Fonts..." To be honest I can't think of any time I've actually used ExtraLight Italic for anything, or included it in anything that might have gone into a "PropertyCollection" (what's mentioned in the Event message). Heres the Windows Event: Log Name: Application Source: .NET Runtime Date: 27/05/2024 10:29:45 Event ID: 1026 Task Category: None Level: Error Keywords: Classic User: N/A Computer: JWS-HP2 Description: Application: Publisher.exe Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: System.Runtime.InteropServices.SEHException at <Module>.PersonaController.LoadFontsAndPropertyCollections(PersonaController*) at Serif.Interop.Persona.Services.InteropService.LoadFontsAndPropertyCollections() at Serif.Affinity.Application+<>c__DisplayClass100_0.<OnServicesInitialised>b__1() at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object) at System.Threading.ThreadHelper.ThreadStart() Event Xml: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name=".NET Runtime" /> <EventID Qualifiers="0">1026</EventID> <Version>0</Version> <Level>2</Level> <Task>0</Task> <Opcode>0</Opcode> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2024-05-27T09:29:45.9487898Z" /> <EventRecordID>48947</EventRecordID> <Correlation /> <Execution ProcessID="26984" ThreadID="0" /> <Channel>Application</Channel> <Computer>JWS-HP2</Computer> <Security /> </System> <EventData> <Data>Application: Publisher.exe Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: System.Runtime.InteropServices.SEHException at &lt;Module&gt;.PersonaController.LoadFontsAndPropertyCollections(PersonaController*) at Serif.Interop.Persona.Services.InteropService.LoadFontsAndPropertyCollections() at Serif.Affinity.Application+&lt;&gt;c__DisplayClass100_0.&lt;OnServicesInitialised&gt;b__1() at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object) at System.Threading.ThreadHelper.ThreadStart() </Data> </EventData> </Event>

I don't have a problem using a separate vectorizer, such as the one in Inkscape. It's a one-off conversion process, so it is not disruptive for me to do the vectorization and then import it into Affinity. In these days of rapidly developing AI, and also the specialist nature of vectorizing I can see a valid reason for leaving that process to an external application. However ... when I saw the Vector Flood Fill tool announced for AD2.1 I did have hopes it would work like Inkscape's - in other words Vector Flood Fill even in bitmaps. For certain cases the Inkscape vector fill is much better for achieving a good vector result than using the actual vectorizing function. So I am disappointed that the new Vector Flood Fill tool in AD2.1 doesn't fill bitmaps.

Publisher 2 on Windows 10 1. Place a PDF in the document so it is embedded 2. Save the document. 3. Check that File -> Save is greyed out in the menu 4. Double click the embedded PDF and make a change to the PDF, and then close the PDF edit window 5. The document shows the changed PDF 6. The File -> Save is still greyed out in the menu 7. Export or print the document to show that the changed PDF is changed in the export or print. 8. Close the document. Publisher does not prompt to save it. 9. Re-open the Publisher document to verify that the change to the PDF was lost, and not saved.

I did it. I uploaded one from today and two previous ones, from 11 and 12 Nov.

Wow! I have access to an old iPhone and I opened "PDF Export.pdf" from my post above in the iPhone and YES it has the transparency effect. On my Android phone, opening with MS Office - no transparency effect, just the rectangular image. So Apple Yes. Windows, Android No. If I have time, I'll try it on Linux later today.

Well, yes, your pictures all have the transparency effect. When I open the file attachment from my post "PDF Export.pdf" it doesn't have the transparency effect - it's simply the rectangular image. I don't normally use the standard Adobe Acrobat Reader, but it is the same in all my PDF readers, including Adobe Acrobat Reader Version 2022.003.20282. I've attached a screen clip. I'm amazed and flabbergasted that you say that the PDF I included is "in the lower left" (on my screen it's upper left, but no worries). It does have the same text problems as my exported PDF, but it shows the transparency!!! And you say that's the actual "PDF Export.pdf" 567.23 kB that is attached to my post, which I can open from the post and it looks like the image below. I opened it in my usual PDF reader, in Adobe Acrobat Reader, and in Affinity Publisher 1 and 2 (using Open with..), and placed it in Affinity Publisher 2 (using place) and they all look the same - no transparency. Just to check my sanity I re-exported the original Publisher file from Publisher-2, and the result was the same. For the sake of interest I opened the Publisher file with Designer 2 (open with...) and exported PDF with the same result. But what is so amazing is that when you open the attached "PDF Export.pdf" file from the post in MacOS that it shows the transparency effect, but it does not show it from any of my PDF readers, or Affinity Publisher versions on Windows. I hope this kind-of helps! (some different PDF library for Windows and Mac with some incompatibility with Publisher/Designer output?)

I did some more checking. System Memory usage after Photo 2 crashed was the same as the memory at the start of the tests (5GB) Checking GPU: Photo 2 defaulted to the integrated (Intel) GPU, but running the test again, GPU memory use was insignificant as Photo 2 consumed more system memory. I changed the setting to use the dedicated (NVIDIA) GPU and likewise GPU memory usage was insignificant in the test, with zero Virtual Memory. Photo 2 crash came after its memory usage reached 9 GB and I tried to open the next RAW image. I set zero pagefile some time ago to improve a particular aspect of performance since 16GB physical memory was plenty. As far as I can see, allocating a pagefile would only defer the crash until the pagefile is full, as I understand it - though my understanding is probably not perfect. So I think zero pagefile means Commit Charge is all allocated into physical memory, until it runs out, which is what looks like is happening. I have some screen dumps from Task Manager if you want them.

Windows 10 64 bit, Photo 2.0.0 16GB RAM My process, recording the Memory from Task Manager after each action. This is system memory (not GPU VRAM mentioned in another topic) I did this simplified process after getting memory warnings and a crash doing real work. (1) Drag a RAW image file onto Photo and wait for it to open (2) Develop (3) Export as a JPEG (4) Close the document by clicking the MDI window close-X and choose "don't save" Repeat until crash The result: Starting memory after opening Photo = 478MB Seq (1) Dragged (2) Developed (3) Exported (4) Closed 1 2.4GB 2.14 2.25 2.13 2 3.56 3.33 3.49 3.37 3 4.43 4.27 4.46 4.34 4 5.67 5.46 5.64 5.36 5 6.68 Photo window crashed when "Develop" clicked - but Photo was still 'running' - icon in taskbar and showing in Task Manager. and errors with other open apps with error messages shown and apps became unresponsive/frozen Task Manager showed 15.8/15.9 GB committed memory, showed Affinity Photo with 6.768 GB memory, 0 cpu, 0 disk After ending Photo on Task Manager it showed 9.1 /15.9 GB committed memory. This seemed high compared with the memory listed for running processes. Pity Task Manager doesn't let you save its display - and my screen capture app was frozen Memory usage is not something I watch in my normal daily life, so I can't be certain that it is abnormally high, but it feels like it. I will check further tomorrow after rebooting, to see if memory might be leaking.

This is one of two reports for this file, so ignore the image for this report, please. Just look at the text. Windows 10, Publisher 2.0.0, Microsoft Print to PDF, Lexmark printer with PCL and Postscript drivers. "Stroke Centre" means stroke aligned to centre "Stroke outside" means stroke aligned to outside I also showed that the Layer FX "Outline Centre" prints correctly All the text is Artistic Text I've attached these files: PNG Export.png: This is correct - what it should look like PDF Export.pdf: Shows some "stroke outside" errors Print to PDF.pdf: using Microsoft Print to PDF. Shows print output, showing the stroke rendering errors in the two script fonts. This is a correct representation of printing - I also printed from Publisher to my Lexmark printer using its PCL driver and its Postscript driver, and both prints are the same as the "Print to PDF" Arial also shows a problem too if you magnify it. It's barely noticeable on my paper prints but under bright light it is there too with Arial. But I think this issue also shows in the PNG Export, so it might be a different issue. Print to PDF.png: To confirm what printing looks like without having to use an app to display it. Fonts I've demonstrated with two script fonts, also included. AdineKirnberg.ttf was used for my daughter's wedding invitations (not by me) so I chose it for their Wedding Anniversary Card - where I discovered the problem. Gabriola.ttf is a Microsoft font. I tested with Gabriola from a high quality source just in case the AdineKirnberg font was in some way substandard and that caused the problem. I used basic Arial for comparison. It shows a different problem under magnification, but that also shows in the PNG export, so might be a different issue. Same faint pale line also shows in the "Outline" FX on the PNG Export I've included the Publisher file and a screen dump of the PDF Export settings. PDF Export.pdf Gabriola.ttf adinekir.ttf Print to PDF.pdf Print and PDF Export bugs.afpub

This is one of two reports for this file, so ignore the text for this report, please. Just look at the image. It's an Image layer (not pixel) Attached files, exported from Affinity Publisher PDF Export.pdf shows the image with the transparency tool ignored PNG Export.png shows what it should look like Print and PDF Export bugs.afpub is the Publisher File If also included a screen dump of the PDF Export settings PDF Export.pdf Print and PDF Export bugs.afpub

Sorry this is way after the sell-by date of this topic, but from my point of view I won't argue whether it's a bug or not, but it is accepted that scaledness is a property of the scaled text frame. Therefore it should be accessible as a text frame property in the text frame studio so it can be set/reset numerically. That's where I looked when I had the same problem, and actually deduced the reason, but the scaled property of the text frame is not included in the Text Frame Studio. Apologies if this same issue is in a more recent topic, or if I ought to have created a new topic. I hope someone sees this post and understands my point.

YES: Convert the shape to curves, then select the node tool. Everything you do with the node tool selected keeps the fill static.