G-ELP

Lol not sure what point you are even trying to make here? Anyway the net result is I still haven't upgraded to Affinity 2, so.. their loss. And AI is eating their lunch now too.

I am a software developer myself, the software doesn't just magically become incompatible unless you are relying on brand new features of the OS (fair enough)... but these kinds of apps would barely have any OS specific code of that nature. It's just big corporations like Microsoft forcing people onto their latest OS by dropping support of the .NET framework on older versions and such. Awesome (/s) all those millions of perfectly good 6 or so year old computers, end up in trash because WIndows 10 runs like a dog and 11 worse doesn't support the CPU. Then on the other hand, they rave about being such an environmentally friendly corporation because they put a few solar panels on the roof of their HQ... ugh rant over, lol.

Yes obviously I've read the tech specs, that's why I stopped at the last second from purchasing it. Was wondering if the same requirement was stated on the v1 apps and those work.. Anyway my subsequent searches suggest that Win7 is no longer supported, with no reason given. Oh well, I'll save my money then, I wasn't upgrading out of 'need' of any v2 features, more just to support the company.

Have the Windows OS requirements changed between the Affinity v1 and v2 apps? Is there any chance v2 will work on Windows 7? I currently run Designer+Photo v1 latest on Win7 with no issues.

Yes the image will display correctly if you open it directly, because it is correctly setting the charset in the browser from the header of the svg. But if you open the text file with a hex viewer, you can see that what is output is not 2 bytes "f", "f", it's 3 completely different bytes as above. There is no reason for that not to be "ff". I am not intending to create a ligature, only changing font. And both fonts are English fonts! Imagine if this happened if you changed from Arial to Times New Roman. That is essentially all I am doing. So the issue arises when you paste the svg text into another document, that must be a different charset, so "ff" not being "ff" becomes evident. Because once you embed the svg into the html page, you are then at the mercy of the charset of the page. On that, I "need" to embed the file because I am adding hyperlinks which don't work if using as a regular img linked to the svg file. If you want a ligature. you should be going about creating one explicitly, just happening to type the word staff, or office, or off, or any of these thousands of words.. https://www.thefreedictionary.com/words-containing-ff ..and later changing the font. You wouldn't expect the text to be mangled and interpreted in another way. ie. full of ligatures and who knows what else and how many other 2 letter combinations are lying in wait. No doubt it's related to options set on this particular font, or the glyphs available - but missing an English "f" would be impossible. As a programmer, this just seems more buggy, than a feature. Some piece of the text processing pipeline is filtering and applying an unexpected conversion on the text. Also most apps let you choose the charset, I can't find any such option in AD. Anyway I've identified the issue and simply chosen another font - probably any other single font on my system would not have had this issue either, lol, what are the chances!!

I am not really sure what you are saying.. My point is, I can type in plain English, no special Alt key combinations, the word "Staff", 5 letters. (I only speak English so my computer keyboard, input languages, etc.. are as vanilla English as they come) Then change the font from default Arial to Open Sans. Then upon export I get something like "Staff". If I change the font back to Arial and export, I'll get "Staff" as expected. Changing the font, without editing the text, should not have this kind of affect. It's only by chance I've picked this up, eg. if it was a magazine column with lots of text, there could be all sorts of substitutions occurring. As it is, double f is reasonably common.

Also I tried exporting when I had removed the open sans font from the system. So the font was missing from the system but still selected in Affinity as "? Open Sans". And there was no problem with the exported file in that case either.

Possibly, although I see no different on my end, there are 2 separate characters I can individually edit. I didn't do anything crazy when typing that would trigger a ligature. And if all I do is change 2Staff to "Open Sans" the problem will appear there too. So Affinity is picking up a text encoding from the font and applying it. Inside affinity (and opening the exported file directly) I see the expected "ff", but on embedded webpages I will sometimes see a jumbled mess instead of the ff. Also if I set 1Staff back to Arial, the problem will go away. So it's definitely on setting the font, or exporting with the font set. btw: I have since tried installing the latest Open Sans font from the url above - and get the exact same behaviour and results. The answer in this article describes what I am seeing.. >In case 2, the character is written as UTF-8 encoded, bytes 0xEF 0xAC 0x80, but then these bytes get interpreted according to windows-1252, yielding “ff”. https://tex.stackexchange.com/questions/119374/why-ff-displays-strange-using-unicode-encoding-vs-iso-8859-1-in-html-output-f Also I am using WIndows 7 and Affinity Designer 1.8.5.703. (not the latest AD version, will update and test soon)

When I export a design to SVG, the character encoding is causing an issue at some part of the process.. To reproduce: 1. Create a document 2. Add a frame text box "Staff" without quotes. 3. Set font to "Open Sans" (I'm on Windows) 4. Export to SVG Examine the SVG file with a hex editor and you will find the "ff" has turned into 3 hex bytes.. &HF, &AC, &80 Instead of the expected 2 hex bytes.. &H66, &H66 This causes issues when I put the SVG text in 'some' html files - where the character encoding must default to something else. ie. some it works fine, some it doesn't (even with same UTF-8 charset definition) but it shouldn't be getting encoded like that to begin with. In putting this report together I've found it is the solely the font that causes the issue. If I export at step 2 when the default Arial font is set, then there is no problem. Also if I set the font back to Arial there is no problem. And if I have a mix of Arial and Open Sans, it is only the Open Sans text boxes that have the issue. So I guess Affinity is picking up character encoding from the font. Is this a default? Can it be overridden somewhere in the UI? Or is there just something about this font and I should choose another? In the attached file, the text boxes.. 1Staff (open sans) = issue as above 2Staff (set to open sans then back to Arial) = no problem 3Staff (Arial) = no problem The Open Sans was saved out of my Windows Font viewer. I believe this is from the Google web fonts collection. It is what is active on my machine if you need it for debugging, but probably not the latest release.. so even that could be part of the problem.. but I guess what I am asking is, in general is there somewhere to find this setting, or expectation from a particular font, so I don't get caught out by this gotcha in future. https://fonts.google.com/specimen/Open+Sans Bug-Character encoding ff export SVG problem-20211008.afdesign Bug-Character encoding ff export SVG problem-20211008.svg Open Sans.zip