m.vlad

you have a limited amount of votes, instead of spreading them throughout the suite let's keep the votes contained in the same app, the one that Redsandro linked. The issue is most likely the same across the board but it'll take us longer to get there if we spread out the votes

Guys, Affinity would be able to say its the only design app that works on Mars.

The shape tool has a limited look when it needs to be rounded off, the shape on the right is made with the built in shape tool, but the Inner Radius is limited to 71% here, and I can't make it more rounded off. With some manual tweaking I've made the one on the left (sharp corners, used the Corner rounding tool and manually added handles to the points to be able to taper at the edges in a curved way instead of having a rounded inside corner that goes to straight lines, which looks off) I've attached an .afdesign file star.afdesign

Tbh i didn't even see there's a vote thing there, also you need to register there as well, so we're now at 3-5 barriers of entry to gauge interest? We've got people who use the forums, who've seen this thread, and now who've been to the wineHQ page for affinity photo in particular, are registered and voted for the program?

Uhm, sure, but they need to get this app working with a multitude of apps. Wanting them to make the first contact is a bit presumptuous. They don't get anything from this, since wine is a free project, whereas you have everything to win. https://appdb.winehq.org/objectManager.php?sClass=version&iId=39311&sAllBugs

Guys you're going off-topic.

I know you're being very generous with the numbers, but only counting the number of people who a) use the affinity forums and b) have participated in this thread (most reddit users are lurkers, as a point of reference.) is a bit skewed. Not only that, but it's possible more people would consider linux as a switchable OS if it had this software on it. Also, people here aren't asking for new apps built from the ground up, they want the current apps to work, either via a native port or by working with Wine and getting the issues that make it not work ironed out. This is a way smaller endeavour than a re-write of 3 apps, especially since in the marketing materials I remember serif boasting about how all apps use the same *platformless* base. It's not word for word what I remember reading, but surely modifying that base is all that's needed, right? At worst you could switch the efficient calls that have no WINE parity to less efficient ones for the port, until they get added to WINE.

Adobe does however also have a much larger portfolio of apps and if they port one they would probably need to port their entire portfolios to make it more enticing. Considering adobe is already the market standard it's easy for me to see how they've grown content with their position and don't do anything too crazy except add features here and there that are up to date with the newest tech. Also the fact that adobe apps kind of work on linux means that, unless there's a real competitor on linux, adobe most likely feels like they win linux by default by having the apps kind of work on linux and there not being any strong competitor on there. If I was at serif I wouldn't totally ignore this potential future avenue now, because it'll create a lot of animosity later. And who knows, maybe they'll work on a port soon, maybe they won't, but completely ignoring an avenue like this when you need every user you can get would put them in a bad standing, PR speaking. As they've said before, this is not a democracy, serif is a company and they have to make decisions that make sense for them. For you and me it might make sense, like duh, its an empty market with a growing userbase due to the increase in mindfulness over privacy and data usage of Windows and the closed ecosystem of apple devices. Also making a linux compatible base would be better now than later, when they have a larger portfolio, but we don't know their financial standing, their developers' workloads, etc. There is a lot of stuff that goes behind the scenes at a company that can affect decisions like porting to a different platform, and Serif has shown that they're not ones to take risks. Unfortunately, I think when linux is big enough for them to consider it worth it adobe will throw a huge wad of cash at their developers and release a port of their suite before adobe, and then affinity will still be the alternative, instead of *the* primary choice for a lot of users, requiring them to convince adobe users to switch on the linux side as well, when they could release something now and have people think the opposite: "Do I want to try out adobe now when this is working perfectly for me and it's blazing fast?".

have you tried FontBase? It's supposed to help you manage large font libraries by only enabling fonts when you need them

+1 to revisit this. It's an important part of a potential adobe-affinity workflow and it would make mixing in affinity and adobe in teams easier (I for one have to use photoshop for a web design project at the moment, and i find myself hating the UI/UX, however if I could just use affinity and export a viable psd from that, I could just give that to the team and be done with it)

It already is. This suggestion is to add it to the new screen so the welcome screen stays relevant after the first month of usage and isn't just disabled outright (plus if it's disabled you have to go to the File tab and then under recents to open the recent files, and there's no thumbnails. Sounds like this would be a major improvement)

Such strong declarations indeed...

I think you mean "make a linux version". a "linux distro" refers to a linux distribution, and it's the ubuntu's and arch's of the world. they don't need to make a separate distro, just make the app compatible with ubuntu or something and people can repackage it then to work for different distros

depends on the definition of working, but the OP of this topic did get it to a state where they could create a new document and work on it. Doesn't mean it's in a fully working state, but it's still in a state where you might be able to test pressure sensitivity.

I agree with that. In my opinion the ideal affinity file structure would bet o open raw photos as .afphoto files and work on the photo in an embed document fashion, where you can open the photo to edit the develop settings and you can do stuff that you can normally do with that embedded document outside of it (similar to what you just said). That is perfectly fine imo. Because the settings are never rasterized you don't even need a sidecar file either, since they can all be contained into a single document. well, that's because of the way RAW processing is handled, via a plugin-like feature, instead of being handled in-app, like Affinity can, which raises the bar on what can be achieved. Considering the plugin-like experience of CameraRaw, it's not unexpected to have to apply the settings to the photo and can't be edited further, but because the develop persona is a persona, I'd expect the changes to be still there when i change between personas, instead of being forced to apply them. As it is now, it feels like an external application bundled into the app in a way that seems native but doesn't work like that. Yeah I can see why that's an issue, having a DAM built into affinity photo would just feel like bloat imo (it already feels like bloat in Lightroom tbh, i just want a powerful editor, i don't need nor desire to use a DAM, and even if I do, i want to be in control of the decision of using such a feature, instead of having it bundled into an app that has, to me, a different purpose. Ofc these are just my thoughts and opinions.

That is true nowadays, however Camera Raw used to be bundled in with Photoshop until around CS4 when the split, so for all intents and purposes it was part of photoshop but Adobe decided to split it away. It doesn't change the current state of things, and they must've had a good reason, but many people still use Camera Raw in Photoshop for when they don't need Lightroom. So a non-destructive improvement to a photo editing workflow would not be appropriate for an app that is literally called Photo? I disagree. The fact that the current Develop persona is so ingrained in the app as opposed to Camera Raw's plugin-like experience means it can be more developed to accommodate for true photo editing. The tools are already there, serif just needs to find a way to export/import those settings instead of forcing you to "Develop" the photo. The change would be minimal at best, since all the other stuff is already there. People keep bundling DAM software and RAW developing apps together. Rightfully so since all the current RAW developing apps provide both, but they don't have to both be developed, at least at this stage, considering RAW Developing is already mostly done whereas a DAM solution isn't even mentioned anywhere in the apps at this point and it's only in the planning phase, as far as we know. Naming them together makes the development of the non-destructive RAW editing a bigger hurdle than it is. Also, I'm personally more than fine with using my own folder structure and using Affinity Photo on a per-photo basis, a DAM isn't a priority right now, being able to save the photo adjustments in an app called Affinity Photo which already lets me edit them is a bigger priority imo.

That is also true. the browser render is the colour accurate one.

then i put that in the proper forum i guess. I've been mainly using the beta stuff because i got used to not getting any new features in stable while the beta builds were 90% stable, but since they've started pushing more updates to stable i'll consider switching over.

nice. i actually just ended up adding another shape between them and merging them via boolean ops.

Just selected the two red nodes on the left or right and pressed Join Curve. The vector is from a svg i exported from https://designs.ai/graphicmaker/illustration/243-public-transport-bicycle that i had to pass through inkscape for affinity to be able to open it (it gave a file type not compatible error before).

I have attached the .afdesign file. When merging the two left nodes (quick edit: it happens with the right most ones too, just lower on the leg): you get the leg in the "after" artboard that has been deformed and has nodes in areas outside the vector region. YqPk6dxHdL.mp4 weird join glitch.afdesign

I've got this svg file I saved from https://designs.ai/graphicmaker/illustration/243-public-transport-bicycle (I attached my saved file) that, when I try to open it in Affinity I'll get a "The file type not supported" error, even though it shows up fine when loaded in a browser. I've used the png option to export from said website instead but now having the svg option would really help in a larger scale usage. Can someone look into this? bike illustration.svg

Have you checked this?

No one would take a WINE app over a native app, but affinity won't make the app nor do they seem open to ironing out the wine incompatibilities, so the logical solution is to ask the other side, WINE, to do it. Also you're just reiterating the same points that have been raised in the past pages. Have a read through the thread before repeating points. For starters, Serif has said they are against kickstarters, so by extension they are against sponsorships.