User_783649

Agree, Aaron. To beat the others in UI/UX field, Serif needs to implement three key things: 
A really fast, low latency multi-player editing mode with state-of-the-art built-in conflict resolving so file damage will never happen whatever everyone does. Existing incremental file saving model may be super beneficial here in order to reduce network overhead. Symbols should be taken to the next level. They should evolve into powerful interactive components with multiple states support and proper encapsulation (nesting). There’s also a need for powerful prototyping tools with optional, customizable animations/micro-interactions. All the rest and truly great stuff is already here (think about existing StudioLink, very powerful text editing and image editing abilities and other useful stuff).

Same issue happened to me recently. Decided to purchase another three licenses for Designer, Photo and Publisher.
Unfortunately, I got the same error message right after I correctly entered all the card details and successfully entered 3D Secure verification code.
"Your payment has been declined by your payment provider. Please change your payment method and try again."
But, the thing is: my payment provider didn't declined the payment. It was declined by Serif or their processing gate.
I was on a call with my bank assistant and they confirmed, that transaction looks fine to them and no errors were logged on their side.
In fact, the money are still currently reserved (holded) by Serif or their payment gate for 3 days. Hopefully, I'll get this amount back on my card at some point.
What's going on here, Serif? You can't even properly receive payments.
There's definitely an error or misconfiguration on Affinity store or their payment gate website which incorrectly process some orders.
Already have a couple of emails back and forth with Serif support. They simply said that transaction failed (no idea why) and money should return to me at some point.
Btw, using the same debit card, I successfully purchased a bunch of different software licenses on this week as well as arranged payments for hosting and domain services.
Very disappointing.

Fully agree. Wonderful app. A perfect blend of pleasant user experience, nice features and great performance. The man behind this app is a very passionate developer and type lover. Thank you very much, @Floor, for your truly incredible work on Typeface.

Fully agree. Wonderful app. A perfect blend of pleasant user experience, nice features and great performance. The man behind this app is a very passionate developer and type lover. Thank you very much, @Floor, for your truly incredible work on Typeface.

The wing mirror...

Auto Activation is included and works natively for the Affinity apps. Not sure about v2 of course, I don't have access to the super secret internal beta unfortunately... eagerly waiting for the 9th like all of us!

I'm the developer of Typeface app for Mac — would love to integrate with the Affinity suite to get better support for font collections. Currently it's possible to drag and drop from Typeface to Affinity, but it would be nice to have your custom tags/sets in the font picker as well. Fingers crossed for a plugin system in v2, that would be amazing 

Fully agree. Wonderful app. A perfect blend of pleasant user experience, nice features and great performance. The man behind this app is a very passionate developer and type lover. Thank you very much, @Floor, for your truly incredible work on Typeface.

The level of details is truly remarkable! I mean, even those subtle dust particles... Metal texture, lighting...You are the true God of Vectors, @VectorVonDoom. Thank you very much for sharing with us. Can't wait for seeing more teasers from this. Wishing you the very best with current and all your future projects!

The Alfa P3 was a single-seater Grand Prix race car designed by Vittorio Jano. It was the first genuine single-seat Grand Prix race car.
I'm only doing a section of the car. I started a while back but didn't do much. As it's not the whole thing I was going for extra detail.
I thought I'd try and post some bits full size as I complete them for a change as the finished images are always shrunk so much. For some reason I'm working at 34400x22934, don't ask me why because I'm not sure. So apart from it being jpg and some compression to keep the file sizes reasonable they'll look as I've done them. 
The first detail is the front filler cap on the bonnet (hood).

By looking at the recents ads and moves from Adobe, and reading about the near-turmoil about Affinity v2 in the web, I believe that many things will change in design and communication in the next few years.
Affinity v2 might be just a step more that what it is now, but it will be a solid, viable replacement to the Adobe design suite for whomever is not forced into that ecosystem (by slow decisions, installed software, compatibility with the archives and other tools, cost of retraining). Many passionate amateurs, part-time professionals, and even independent professionals will finally switch.
To the usual objection about how irreplaceable Adobe is, I could oppose a list of affirmed professionals and publishing houses using different tools. Sometimes real classics, like CorelDRAW or Quark XPress. A minority, maybe, but a consistent one, and not even a niche. In any case, professionals for which the tool is not the focus, as much as this is their work. For which any viable and comfortable tool can do the work.
Adobe is clearly targeting to a younger audience, less likely to be moved to use deep and complex tools. They are pushing toward artificial intelligence, pre-made actions, and a much simplified graphic style. InDesign has entered maintenance mode since years, and is in any case, with page layout and print slowly becoming nearly-residual, reserved to a limited number of users. The more complex tools are going to become something reserved to a narrow circle of old-style creatives, a bit like engraving and calligraphy.
Not having expected competition, Adobe looks like having been caught with their defense lowered. They are again mad at trying to destroy any competition, even spending immense fortunes to purchase them (as they did with Macromedia and Aldus). On the other side, Serif has gone through the hell of being purchased by bigger companies, and have been lucky enough to be able to buy themselves back. They will grow considerably during the next years, but they will probably do all they can to avoid being purchased again.
So, we will have an incumbent (Adobe) that will still profit of the current position in big institutions and less-informed professionals. They will change their business model again, by trying to have their subscription subsidized by schools and public institutions. They will get the younger "new professionals", at least with Photoshop and maybe a simplified Premiere. They will continue to profit from the digital document protection system (assuming Amazon will not definitely eat their market share).
And we will have Serif, that will continue to appeal to independent professionals and shops, and continue to develop and perfect the traditional arts. Maybe they will also slowly slip into the schools and universities (something that seems to be already happening). Adobe and Serif will progressively move toward the opposite sides of the design and communication worlds.
Paolo
 
 

@dcr  I concur completely.  Typeface is a joy to work with.

Love Typeface, such a clean easy to use app. Font switching works with Affinity apps and selected text too, drag a font from Typeface to Affinity and the font changes.

I'm just wondering what the reason can be for not paying for the product directly to the developers who develop and maintain the app (and therefore deserve to be rewarded for a job well done), but rather give the money to someone who is not involved in the development and maintenance at all, only benefiting from its dominant position and does it mediate sales?

Something Big is Coming https://affinity.serif.com/
spoilers

This is basically an "illusory" problem, caused by making color references ICC-dependent. The ideal (IMO) is to create a device specific (and accordingly ICC independent) PDFs where all CMYK values are fully resolved and will simply be passed through without further interpretation. This basically happens if you use any of the PDF/X-based export methods or if you choose the default "PDF (press-ready)" preset without inclusion of ICC profile. I am not sure why Serif has chosen to include the ICC profile as a default since it just confuses everyone, and leaving it unchecked does not seem to have any negative effect (e.g., RGB objects still include references to their source profiles so e.g. AdobeRGB and sRGB objects are differentiated).
So to explain the reason for confused display values in Acrobat Pro, here is a situation where the document CMYK profile (here ISO Coated v2) is different from the simulation profile used in Acrobat (Adobe used to have Coated Fogra 39 as the default CMYK profile in whole Adobe suite and this is still true for many users using Adobe apps; the default used by Acrobat Pro can be defined separately in the preferences of the app):

...so the K100 values are shown using ad-hoc conversion of color values based on chosen simulation profile, and appear to be four-color CMYK.
But when the preview is switched to Object inspector, you can show object-wise the actual ICC profiles the objects use, and true internal color values for the object:

If you use PACKZVIEW, it shows true color values so this conflict does not show there. If you change the Simulation Profile in Acrobat Pro to ISO Coated, the illusory conflict is resolved and true color values are shown for CMYK objects:

If "Embed ICC Profile" is unchecked, you would get all color definitions of native objects (including RGB definitions) converted to ICC-independent CMYK, and Adobe Acrobat Pro would show true CMYK values no matter which simulation profile is selected, as all CMYK objects are now "DeviceCMYK":

If you additionally force conversion of image color spaces to the defined color space, you would get pure device CMYK color space (spot colors excluded), and basically a similar plain vanilla PDF export that you get in InDesign when choosing the Press Quality export (at least in ID CS6): the PDF version is by default 1.4 in InDesign (not 1.7), but using PDF 1.7 is wise to get maximum "compatibility" to avoid PDF conflicts within Affinity apps. As the PDF version is always 1.4 or later in Affinity apps, you would still retain transparencies (the only way to flatten them in Affinity apps is to use PDF/X-1 or PDF/X-3):


Using PDF/X-based methods would basically be problem-free because then the output intent is included, which would cause simulation profile to be chosen automatically in Acrobat Pro Output Preview, while image color spaces would by default stay in RGB :

But in Affinity apps using PDF/X based export methods has some serious limitations so they cannot be used without precaution.
BTW, what you mentioned about PDF Output Preview (POP) -- interesting, I had not noticed this! So it seems that embedding ICC does fool Ghostscript, since I am just using the default functionality in Ghostscript to get the separations. Ghostscript does support in some degree color profiles but I have thought that it would by default ignore all ICC based stuff and just read the "native" color values (similarly as PACKZVIEW, or Adobe Acrobat Pro when using the object inspector).
This is good information, as it could then be possible that this "illusory" problem would actually cause the RIP to produce incorrect color values, or would require a skillful enough prepress personnel at print shop to get the job separated "as intended". Basically this is of course something where the blame is on the guy who created the PDF, or software that was used to create it
Here are the test files I used:
press_ready_default_iccdependent.pdf
press_ready_default_devicecmyk.pdf
press_ready_default_devicecmyk_all.pdf
pdfx3_default.pdf

Are we talking about these little guys? I've heard they're on the road!

Are we talking about these little guys? I've heard they're on the road!

I had another (and proper) look on the issue, and this is actually another thing, and something I really do not get.
PANTONE+ CMYK is basically a library that specifies CMYK values for coated and uncoated stock to get output that matches PANTONE defined CMYK printouts.
The values that one gets when exporting colors defined by using this color library match exactly what is defined by PANTONE e.g. in PANTONE Color Manager for sRGB values, and exactly the same that InDesign shows as CMYK values of these library swatches. So Affinity apps and Adobe apps seem to give identical CMYK output when using this PANTONE color library (the color definitions of the U library are intended to be used with uncoated stock using profiles like U.S. Web Uncoated V2 or Uncoated Fogra 29). 
But what is interesting is that the official sRGB values that PANTONE Color Manager specifies, and which Affinity apps use, differ significantly from the CMYK output, exactly as noted by @Dreatern, as if the sRGB gamut could not produce the defined CMYK colors for uncoated stock, which is simply just absurd! It is true that there are colors in the region of cyan that cannot be reproduced in sRGB, but the ones shown in the blue region in this library are not such, and interestingly InDesign completely discards the PANTONE guide values when it produces an sRGB output of these colors and uses standard profile conversion between any given CMYK to RGB color space, and gets a much closer match.
a) Same PANTONE CMYK Uncoated definitions in sRGB (left) and CMYK US Web Uncoated V2 color modes (right). The document color palette shows the RGB guide values of the PANTONE library that will be used in sRGB export, and the actual CMYK values used for CMYK output. The actual sRGB conversion values for the CMYK colors do not match the guide values, which give oddly desatured RGB output: 

b) The same PANTONE library used in InDesign, and the Swatches palette showing first the library defined CMYK swatch (with identical CMYK values produced by Affinity Publisher), and then smaller swatches with RGB values used by InDesign, and guide values given by PANTONE. 

Here are CMYK and sRGB PDFs produced by both apps for comparison. It can be seen that InDesign, which discards the PANTONE defined sRGB values, produces more accurate RGB output from this library.
 PMS_CMYK_Uncoated_cmyk_apub.pdf
PMS_CMYK_Uncoated_srgb_apub.pdf
PMS_CMYK_Uncoated_cmyk_id.pdf
PMS_CMYK_Uncoated_srgb_id.pdf
I must have misunderstood something here, but feel kind of relieved not to be dependent on anything like PANTONE libraries to be able to produce CMYK colors reliably and getting closely matching sRGB output for digital versions of the publication!

It seems that Affinity apps basically define PANTONE colors in terms of sRGB (rather than in Lab color space). This means that their visual appearance is limited to sRGB even when the document color space allows a larger gamut, like e.g. when using ROMM RGB, as below (note that the forum narrows the color space of any screenshot to sRGB, but the difference shows relatively):

Note that InDesign, on the right, shows the PANTONE colors in Lab color space no matter what. Above the InDesign document has sRGB and ISO Newspaper assigned as RGB and CMYK color profiles but the PANTONE colors are shown purely, in terms of Lab color space, and realistically as long as the display color gamut allows it.
However, within Affinity apps, when the document is in CMYK color mode, the sRGB based PANTONE colors are shown simulated (as a kind of a proof print) using the active document CMYK profile, below ISO Coated V2:

This is of course inaccurate and highly misleading, but basically expected whenever a color definition is made in terms of (s)RGB, not considering the spot colors as specific inks but rather as part of the process color space.
 

@NotMyFault Thank you for your efforts! Indeed, it may just be a limitation of the PDF format itself. But, strangely, the images included in the PDF files exported from Affinity Designer are apparently formatted as 16 bit (although their internal data seem to be compressed to 8 bit).
@Alex M I use Affinity Design to make scientific figures, so it would be nice to be able to make a PDF with 16 bit color depth so the quantitative data of the images remain uncompromised.

Hi @cgidesign, hardware acceleration is used for all raster operations within Photo—that includes basic layer transforms through to filter/live filter and adjustment layer compositing. In cases where a GPU with strong compute performance is present, the performance difference can be huge. Take M1 Max for example: the CPU is no slouch, and scores very highly on our vector benchmark, but raster performance is only around 1000 points. In comparison, raster performance on the GPU is 30,000. That's a linear scale, so to say it's 30x faster than CPU is no exaggeration.
The fact that all major raster operations are accelerated is a huge undertaking, and means it's not really appropriate to compare our hardware acceleration implementation with what other software has. I understand there's a lot of frustration around the choice to disable support for AMD's Navi cards, but Photo compiles new kernels every time you add an adjustment, filter, use a tool etc for the first time during the session. It was simply unusable on Navi because the kernel loading is unacceptably slow, to the point where it could take up to a minute for a RAW file to be initially processed and displayed in the Develop Persona (multiple kernels are loaded simultaneously in this scenario).
If you start to introduce vector operations to your workflow, such as text, vector shapes, poly curves and so on, this is where the GPU must copy memory back to the CPU, and this is where most bottlenecks occur—unified memory architecture (e.g. Apple Silicon) manages to reduce this penalty somewhat, but as of this current time it's still not as fast as compositing purely on the GPU.
The Benchmark (Help>Benchmark) will give you quite a clear idea of the performance improvement you can expect. In particular, focus on the Raster (Multi CPU), Raster (Single GPU) and Combined (Single GPU) scores. They will indicate CPU compositing performance, GPU compositing performance and shared performance (copying memory between them when using a mix of raster/vector operations) respectively.
Hope that helps!

For your interest - an image with the same resolution (i.e. 1920 x 1021 px), but saved as a JPEG, i.e. with a smaller file size (7x) and therefore with a significantly faster download.

Your original:

Compressed JPEG:

By optimizing the parameters (degree of compression vs image quality vs file size) plus possible sharpening, you can get the desired result, i.e. a small file without a noticeable reduction in quality.
P.S. In your case, reducing the image size only halved the file size, from 767904 Byte to 361511 Byte (compress JPEG is 111069 Byte).

https://en.wikipedia.org/wiki/Image_resolution

I need this because I use Publisher as turbo charged Designer. so the Export Persona is necessary.
Many others do the same.