BofG
-
Posts
1,431 -
Joined
Everything posted by BofG
-
I think it's just a misunderstanding, technically it is rasterising the element - you cannot export it as a vector. Behind the scenes it's keeping the original copy which is then re-used for any changes, making it "live".
-
Well that's another joy of this UI element - some actions apply it like you mention, others cancel it. If you forget to hit apply and group the elements with the keyboard shortcut it all goes wrong (unless they newer versions fixed this, I'm on 1.7).
-
Try align to first selected. You can't choose that until you have aligned everything to selected bounds. Aka, you have to visually see everything go to where you don't want before setting them to where you do want.
-
Before the change, you could choose what to align to and then hit the appropriate button and you got what you wanted. Now you have to hit the align button first, see everything on screen jump to where you don't want them to, and then choose the align to option you want and have things jump to the appropriate positions. It's just visually disconcerting to see it all "go wrong" before having the option to put it right. I see no benefit to enforcing this way, and as has been shown it confuses users to the point where they come here asking for help.
-
Exactly. I guess they had finished all the all the other features and fixed all the bugs and needed something to fill their time. Oh, wait.
-
At some point will Serif realise this change was nonsensical and reverse it? I'm guessing no
-
https://www.w3.org/TR/SVG11/coords.html#ViewBoxAttribute Having a viewbox for anything cnc related doesn't make logical sense - you need absolute sizes, not a flexible container to stretch to fit a viewport.
-
Your terminology is a bit off - it's not down to rasterising, what is happening is that Affintiy converts your colour space to RGB prior to sending to the print driver (and no one knows which RGB profile it uses). I doubt they will address the issue, to send CMYK data apparently requires PostScript, which would mean them writing code for this - at the moment the apps just hand off to the OS level print drivers. It's as basic as it gets. The fact you can select a CMYK printer profile is nonsense (and I hold my hand up and say it was me complaining about them not being listed that got them added in). Export to pdf, print from Adobe Reader.
-
Yes I'm sure, if you dig around on here you'll find the devs have confirmed it. You will probably come across a few of my posts complaining about it too
-
It cannot be done. Affinity is RGB only for printing. What you are seeing is k at less than 100%, maybe there's something in the driver you can tweak, but I'd think you are just better off outputting to pdf.
-
It's been this way for ages, no one will acknowledge it.
-
I believe the example is to show that implementation specifics don't really matter (Affinity/svg/whichever), it all comes down to Vector math and matrices. No one is reinventing the basis for these manipulations, they are all well established mathematical principles. Regardless of the data/code a 'skew' matrix is always a skew matrix and so on. Serif know the formulas, they don't change just because they have a new file format.
-
Good to know the newer cards have improved in their noise output. I'm probably odd in how much those little noises get to me.
- 52 replies
-
- 1
-
-
- graphics cards
- multi-monitors
- (and 5 more)
-
One thing to bear in mind, fast graphics cards mean more heat, which means more fan noise. If you value pace and quiet there are fanless options available, Palit do some good options with older generation Nvidia cards.
- 52 replies
-
- 1
-
-
- graphics cards
- multi-monitors
- (and 5 more)
-
I guess the OP should have opted for the book after all
-
That may be "behind the scenes" but the displayed colour is converted, and if you export to a format that supports mixed colour models (e.g. pdf) you won't get a mixed output. To all intents and purposes, the colour model of the document is what you get. I understand what you are saying, technically the object's data isn't converted, my point was the result won't be an RGB "colour" in the display, or in any export. If the document pasted from and the target document are both in the profiles as the defaults then I believe the shown values will be correct, unless I'm missing something? You can place an image of a different colour model, and that is maintained on output to pdf if set that way, however as Affinity cannot display mixed colour modes it won't show correctly in the app.
-
Nearly got it As your destination document was CMYK, your pasted elements would have already been converted. All you need to do is "save as.." to get a copy, then go to the document setup, colour tab as show earlier in this thread, and select the cmyk profile you want and the colours are all converted for you.
-
RGB document profile = rgb colours CMYK document profile = cmyk colours Anything shown in the colour picker that is not the same colour mode as the document (e.g. cmyk sliders in an RGB document) are conversions based on the default profile that is set in your preferences. Setting a colour using the cmyk sliders in an RGB document does not give you a cmyk colour. To go from one to another you have to convert the document colour space as mentioned before. The other thing to bear in mind (which confuses a lot of people) is there's no such thing as an RGB colour or a cmyk colour - you need a profile for the values to mean anything. "Highway Green" will be different values in SWOP, ISO coated etc etc.
-
In the main window menu, choose Layer > fill mode and change to the one that isn't currently set. Affinity is known for being sketchy at best with Boolean operations. Try: move the "t" layer up or down in the layer stack. If that doesn't help, hold the "alt" key when clicking add - this will create a compound object and might work.
-
If your RGB image falls completely (or mostly) within the gamut of the printer (which might exceed some CMYK gamuts if the printer has additional inks) then it's going to be reproduced well. That is a completely different thing to expecting RGB (0,0,255) to be reproduced in a CMYK gamut (which cannot be done). Create an RGB image of a single 255 blue block, send that to your printer - it's not going to come out like it does on screen, because it's physically impossible.
-
It's not. Why are you certain that there is a 257th grey?
-
Can you post the list of the 257 distinct values? I suspect it's a perception issue as opposed to a data one. If you can post a jpeg (8 bit) of your gradient and/or the aphoto file it would be helpful.
-
Just to another mind bending element - 8 bit images use a non-linear tone reproduction curve to allocate more data to storing the dark end of the spectrum (where we are better at noticing these things), so your linear gradient is actually non linear (but our useless human brains don't notice).
-
Converting of colour spaces isn't a straight forward process and it isn't "reversible" like you are expecting - it is done to maintain the appearance of the colours in whichever colour space, and as in your example the colours look the same, the values are irrelevant. Just handle the file in the way the print shop recommends, maybe ask for a hard proof if possible.
-
Interested to know how you have done this if you have time to expand on this.