Vozka

If it helps, Inkscape supports saving into dxf as far as I know. As it is with many open-source tools it has a specific GUI, but it's not terrible, just something to get used to and imo less intuitive than Designer. But it has more functions than Designer in general.

I'm an optimist so I'm going to say that Affinity is holding this function back for Designer 2.0, and that they're currently crunching to release it (or a public beta) this year since there haven't been any beta versions since march. Now I dont actually have expectations of 2.0 being released any time soon since there has been no official information about it yet, but if it doesn't have this fundamental feature, it's going to be really embarrassing in my eyes.

Once again, the reason why I'd like to have this fixed is because a) it is not reasonable to expect a common user to know this b) it took me hours of my life to diagnose the issue and find out how to fix it and I think others should not be forced to do the same. Perhaps you notice in my original post that I do actually know to use the github fonts instead because I stated that this is a workaround. This post is about preventing other people from having to also spend significant amount of time (and potentially failing) because of an issue that is not going away (Google fonts are popular) and at this moment seems to be on Serif's side. Your advice does not help me in any way and muddies the thread. Please do not waste your time any more unless you have ideas about the technical side of the problem.

My eyes tell me that the rendering is broken and (in a glyph outline editor) they also tell me that the glyph itself does indeed seem to be correct (and that other applications do render it correctly). I am unable to toss it out for the current project for various reasons. The main issue is that this seems to be a feature of one of the biggest providers of free fonts. Therefore there are going to be more people experiencing this problem with other fonts too and potentially spending hours needlessly, trying to investigate it and find a workaround. If there was some information saying "we don't support fonts made of multiple components, please download single-component static font at xxxxx", I'd be okay with that. But there isn't and it takes a layman a ton of time to get it.

This is about a professionally made font that Google claims is made entirely correctly, and viewing the glyphs in an editor also doesn't immediately show issues (except being made from several components, but the components seem to be perfectly aligned). But several (not all!) applications do show issues when rendering it, Affinity suite being one of the worse ones. Since this is a feature of the Google Fonts system, it is probable that this is not the only font affected, but I don't have the time to go through all of them. Yes, I was just downloading FontForge and looking at the glyph as well to check that the components are not misaligned, but they don't seem to be. What I found funny was that the preview rendering system in FontForge also has the rendering issue, just as bad as Photo or stable version of Gimp.

When exporting to pdf the rendering issue gets delegated to the pdf rendering application. I don't use Adobe Reader, but I assume they would not have this issue. When exporting to say .png it is slightly less visible than in application (and dependent on DPI), but still present. Another thing, don't know if it helps: Rendering issues with this font seem to be really common, so I tested various applications to find any differences. I found two applications that seem to handle it with zero issues: Firefox (or at least its pdf viewer) and the development (2.99.x) version of Gimp. From joe_l's message above I suspect Adobe suite might also handle it fine. Chromium or SumatraPDF also render it incorrectly, but less so than Affinity suite. The issue is about 50% less visible and only manifests on "h". In Affinity suite, especially Photo, and also in the stable 2.10.x version of Gimp for example the issue is clearly visible, and with different weights also manifests on other glyphs.

Sure! This is the project file. It uses Comfortaa regular and semi-bold. EDIT: I'm sure you did that, but just in case, it's important to use the static fonts downloaded from here by clicking on the "download family" button. comfortaa publisher.afpub The magnitude of the error depends on the zoom, or dpi of the rasterized file when exporting. Just to be sure, I'm adding another screenshot of how the document looks with 100% zoom on my machine, because I cannot say for sure that the screenshot in my previous post was taken with 100% zoom: Also here's a screenshot from Photo, where it's easier to produce the issue since the Text tool is immediately rasterized. The fonts are Comfortaa regular (top left), medium (bottom left) and bold (right), size is 9 pts. There are smaller issues visible on the other glyphs too in certain weights. comfortaa publisher.afpub

OS: Windows 10 21H2 19044.1766 Application: All latest Affinity suite applications afaik. I first noticed it in Publisher, so I'm putting it here. Problem: Some fonts contain glyphs made of several components that overlap. Affinity applications seem to not handle this correctly, which sometimes creates subpixel errors (see image below). The font I'm using as an example is Comfortaa, but unfortunately this seems to happen in (static versions of) various Google fonts. I first thought this was a bug in Google fonts, but they assured me that this is deliberate, it's how they will continue to generate their static fonts and any applications are supposed to render it correctly. I don't know if their decision is reasonable, but it means that this is not going away. Current workaround: Individual font repositories in the Google fonts github seem to contain static versions of the fonts different than the Google fonts website, and at least with Comfortaa it does not have this issue. However it took me several hours of work spread over several days (due to communication with the font author and a Google github person) to diagnose the issue and find this workaround and I don't think it's reasonable to expect users to do this. Here's an image from Publisher showing a problem with "h". With various font sizes and weights it happens with other glyphs as well, although usually not as obviously: Here's a screenshot from a completely different application, Blender, in which this font is even more broken. I'm adding it because it shows the components that the glyph is made from (I don't have a specialized application for that) - the rendering issue in Publisher clearly happens in a place where several components overlap. Blender has trouble identifying which side of a component boundary is inside and which is outside (that is why parts of the glyphs are hollow). I wonder if that has something to do with the rendering issues in Affinity suite.

Well why didn't I think of that. Yeah, disabling the second card in Device Manager works, Photo no longer crashes with OpenCl enabled and the Performance menu only shows 1 GPU instead of 4. It's quick to do as well, pretty decent workaround. Thanks!

A good Idea! Unfortunately neither setting a preferred card through Windows setting nor doing so through NVidia Control Panel helped, the behavior is still the same.

Sorry, forgot to mention. They are independent of each other, GTX 1060 does not have SLI support.

My operating system: Windows 10 21H2 19044.1706 GPU: Previously MSI Nvidia GTX 970, now MSI GTX 1060 + EVGA GTX 1060 Driver version: 512.59 DCH Problem: After switching from one GTX970 to 2x GTX1060 and updating the drivers (everything else stayed the same), photo crashes either right after loading an image or after I try to add any adjustment layer/live filter. Previously, with the GTX970, Photo worked with OpenCL without issues. Other applications that use both cards with CUDA or OpenCL (Blender, Darktable) currently work without issues, only Photo crashes. After turning off OpenCL in Photo, it works without issues, no crashes. Crash dump: Doesn't get created. All the subfolders in the CrashReports folder are empty. Either there's some setting to turn on logging that I missed or the crash shoots down the crash handling as well. Screenshot of the Performance section of Preferences included. One thing that seems wrong is that it lists 4 GPUs, where in reality there are only 2. It doesn't seem to matter which GPU I select as Renderer. Device manager in Windows, NVidia control panel, Blender etc. only see 2 GPUs as they should.

Pinging @Callum again since this has not been resolved. Like I said in both my previous posts, this behavior happens with 100% zoom. Adding a screenshot to more clearly show what happens when I export the image with 3 px radius median zoom. This usually does not happen immediately after opening the project file, but consistently starts happening after I change up the median radius a couple times.

Thanks for the reply @Callum, but as I wrote above: The screenshot is taken with 100% zoom. I realize that the exported image is correct - the fact that exported image changes with every adjust of the live filter (while the viewport doesn't) is a good clue as well. When I first open the project, the image shows correctly, as in your screenshot. It is when I start adjusting the filter that it breaks, after a couple adjustments.

When editing a night sky stack I discovered that when applying a live median filter layer to a photo, the result looks completely different in the application compared to the exported result. To be more specific, the exported picture seemed to use a larger radius size than the live filter in application. My first thought was that maybe it's an aliasing/blurring issue related to viewport zoom, but I verified that this happens when picture is 100% zoomed in and regardless whether I use nearest neighbor or bilinear filtering. It also happens both when using GPU renderer and WARP renderer. When changing the radius size, the live filter seems to only run at certain sizes, as if there was some radius size quantification. What usually happens is that from 0 to 1 px it does nothing, then at 111 px it starts to work and keeps producing the same result up to 2 px, changing again at 2.1 px. If I export the picture with radius set to 1.1 px or 2.1 px, it looks the same in the application and exported. This behavior does not manifest immediately after opening the file. The filter seems to work correctly at first, or at least the radius "quantification points" are not at _.1 pixels. It breaks for me when I start to change the radius size using my mouse - the slider jumps around, not following my cursor precisely. Even after that though the filter does not always change at 1.1, 2.1, 3.1 etc. pixels as usual, I wasn't able to find out why. Added to this post are example pictures and the project file, which is a simple jpeg with one live median filter. I tested it both on my desktop and my old laptop, both running Windows 10 without any unusual hardware. I use the current version 1.8.5.703 and it seems to hapen to the latest beta (downloaded today) as well. stack.afphoto