expressoaddict

Small glitch — I could be wrong but: Seems like if "change straight quotes to typographic quotes" is checked, Publisher will always correct them to the English/US standard even if I choose Swedish in the Replacement menu. (My system language is already Swedish). In other apps, quotes are converted to the correct Swedish method: I got the last one in Publisher by actually entering the correct quote manually (alt+shift+2 on a Swedish keyboard) so it CAN be done. But would obviously be better for Swedish (and Finnish) users if the correct conversion took place automatically. Thanks!

My bad, Incorrectly posted in Designer Beta, should have been Publisher Beta. Might a moderator help move this there or should I post anew?

Perhaps by design, but to me this is an oddity/quirk: Add a couple of photos. Say you want to mimic a classic photo, so you put a white stroke on one, and a drop shadow. Some of the photos you crop, some not. You then copy the layer effects from the first photo to the rest. Result: All parts of the stroke that goes outside of the photo bounding box will be cut on cropped photos. You CAN work around this by only using "stroke inside" — but it is a bit counterproductive since the drop shadow, while no doubt outside the cropped bounding box (correctly) stays visible. So I would suggest the paradigm should be "stroke is added to photo after crop", not "before crop and thus affected of the crop itself". Hope you see what I mean. Thanks, /Fredrik.

Small glitch — I could be wrong but: Seems like if "change straight quotes to typographic quotes" is checked, Publisher will always correct them to the English/US standard even if I choose Swedish in the Replacement menu. (My system language is already Swedish). In other apps, quotes are converted to the correct Swedish method: I got the last one in Publisher by actually entering the correct quote manually (alt+shift+2 on a Swedish keyboard) so it CAN be done. But would obviously be better for Swedish (and Finnish) users if the correct conversion took place automatically. Thanks!

Thank you Mike for your response/followup — and sorry for not answering sooner. I guess I'm starting to understand what's going on, and I will use this post to elaborate, but let me start with saying I think Affinity Designer has a fundamental flaw in its CMYK color handling, probably due to the fact that Affinity has its roots in bitmap graphics and thus implicitly in the RGB color model. First, to answer the questions above: I am choosing 100% black (known as K in the CMYK world) by choosing CMYK for color model and 100% black from the CMYK slider window. After that, whether I print directly or export to PDF (and thus also if exporting to PDF, then printing said PDF) the black surface will appear not solid black but rasterized (probably at about 85%K) This is not correct behavior. I attach two photos below — a 100%K square as printed to the same printers directly from Affinity Designer and directly from Adobe Illustrator. As can be seen, when printed from Affinity a 100%K comes out as a rasterized grey. The same from Illustrator becomes solid black. The problem, I believe, is this: Sure: Everybody knows 100%K isn't perfectly, deeply pitch black. BLACK ink/toner lacks the depth to create a rich, full-bodied black. This introduces problems when interpreting an RGB photo for printing with the CMYK model, since RGB(0,0,0) means perfectly black and 100%K optically really doesn't. To compensate, RGB(0,0,0) is normally printed by complementing the 100%K with some extra C, M and Y to thicken it. As a result of this, going in the other direction — i.e. converting a CMYK artwork to RGB — 100%K is often rendered only as a dark grey, since it would take 100%K + some extra CMY to make it fully RGB(0,0,0) pitch black. This is all fine and dandy. BUT. For some reason, Affinity Designer seems to be INTERPRETING a CMYK artwork when printing to a CMYK printer — and this should not be done. CMYK values should just be passed on as-is to a CMYK printer, meaning 100%K should be printed with 100% coverage from the BLACK cartridge/toner/ink. As can be seen on the print from Illustrator, that is also exactly what happens there. However, Affinity seems to be thinking "hey, 100%K isn't really black, so let's interpret it as 85% black" which is like paying tax twice: When printing just 85% coverage with the black cartridge, which you may argue already isn't optically black in itself, the blackness is reduced even further — in direct conflict with rules, logic and most importantly: the values I have chosen. So, in summary, it seems as if Affinity applies some kind of "interpretation" for CMYK values even when printing to a CMYK printer, which is incorrect behavior for a vector graphics program. Photos below. Please also note that this becomes even more visible when printing to a black-and-white laser printer — I apologize for the quality issues (stripes) due to low toner levels, but even so the square (and supposedly solid black text) come out as grey and rasterized. Whereas again, from Illustrator they don't.

I did ask this before, and found myself somewhat trashed for not getting CMYK/RGB conversion. I left the forum (and finished my work in inkscape because I had to get it done) but would like to ask once again, hopefully this time someone can help me with a solution. The short question is: When working in CMYK space, assigning 100%K to an object, why is it not printed as 100%K? To reproduce: Start a new document. For settings, I choose PRINT and color format CMYK/8. For color space I'm quite sure I've been through them all, from US WebCoated SWOP vs (which I think was the default) ending with Generic CMYK. Add an object, set color to 100% K. Print. Whatever I choose, a 100%K object will be printed as rasterized (on a black and white laser printer) or grey in a PDF etc etc. What do I need to do to make Affinity treat 100%K in CYMK mode as something to print with 100%K black?

Let me just close this topic by stating that if I have purchased a vector design package that does not print the same CMYK values to a CMYK printer that I have set the artwork to be, then I am the fool for thinking an app for forty bucks could do a professional job. I don't want to be rude — I have just read your bio and realize that you are not a graphics professional — but the information in your post above makes no sense at all from a professional standpoint, nor are your deductions about color handling correct. I could go back to the early days of manual color separation, when we printed four sheets of black-and-white film at the very expensive typesetter service, then exposed them onto plates, which in turn were used for offset printing onto paper. Those four sheets were the respective originals for the C M Y and K printing colors, which meant that if I gave an object a certain mix of these components, each film would represent that mix in a literal, one-to-one ratio. If my color was 20C, 30M, 40Y, 10K, then the cyan film would be 20% grey, the magenta 30% etc. This, quite simply, is how CMYK printing works. So. Designing in CMYK and printing to CMYK, I don't want any conversion to take place. If I want my blacks to be 100%K, I design my artwork accordingly. If I want something else, then that's the value I'll set. But I alone decide how black my blacks will be. In case your answer is to be considered an official contribution to this forum, I guess I'll have to go back to using apps like InkScape which, while crazily inferior in features and UI, has never once let me down in terms of printing and designing in CMYK.

Perhaps at the risk of becoming crazy here... If I add an object, set the color picker to CMYK, make the object 100%K — then right there in the document what I get is an almost-black object. If I then change the color picker to RGB, it will change not to (0, 0, 0) but to (35, 31, 32). So quite obviously, Affinity Designer has decided that 100%K is a greyish color — which is also the way the object prints. I don't think I can explain it any clearer — all I do is wonder why something I set to a CMYK value won't print with those values.

Both, in fact. Printing a 100%K object, either direct or from a PDF, gives me a weak, weak raster — I guess corresponding quite well to the 94% I see if exporting to RGB. So one could also say that the only way for me to print full black is to set RGB(0,0,0) and not 100% K. I'm on MacOS Sierra, printing to two different Laser printers, one Samsung and one HP. So I think you're understanding my question perfectly — I would so dearly like my CMYK objects to print at the CMYK values I set... :) So — you can choose a conversion? Is there a way to just turn it off? Or what am I not doing the way you are?

I am sorry, but are you responding to my question or to one that you would like me to have asked instead? I am designing things in CMYK. When ripping such graphics to a CMYK printer no conversion shall take place. That's the beauty of vector graphics — and the difference to bitmap/raster — if working in CMYK I set the values to be printed and that's it. Color conversion may take place for display onscreen (which is RGB) but that is totally different from the ripping process. If I have a number of CMYK objects, as in Affinity Designer, they shall be ripped/printed/separated as per my settings, period. If I also add an RGB photo to my design then by all means, it — and only it — need be converted at the time of rip/printing. But not the rest. It is true that no color conversion can be exact. That is why none should take place, when I design a CYMK object and print it as such. My question, to clarify, is: Why does it? And: When conversion does take place, why is it off, so that 100%K — the blackest — isn't rendered as RGB(0,0,0) ?

Thank you for understanding my initial question. Yes, this is what's odd — even printing a 100%K surface (to printer or to PDF) gives me a not-quite-black surface where it should. I can't really see why RGB conversion should be involved in the process at all here — especially of the color "completely black" which should be at the absolute end of any color model anyway. And the answer is yes — my color model is CMYK8. Which makes it even less understandable. So how does everyone else do? I surely can't be the only one using CMYK colors in Affinity Designer...?

Not sure about how this answers my question yet — but here goes: The document is set to "print", and the color to CMYK/8 About color space, it doesn't matter what format I export to — 100%K turns into some lighter off-black, which I can't see why it should. I'll try to explain what I mean: 100%K should turn into #000000 regardless of colorspace — from a (line art) designer standpoint, K is as black as can be and should be treated as such. Again, designing line art using some "enhanced black" say, CMYK 222X, isn't a good idea due to the potential bleeding and misalignment that may follow. It seems to me Designer lives in a photo world, forgetting that vector graphics, designed in CMYK for print, need no color space. They are what they are. Is there any way to have Designer not handle colors at all?

Hi, having worked with vector packages from the early days of Corel Draw for Windows, I consider myself having quite a grasp of coloring, CMYK values, separation for print and whatnot. But with Affinity Designer a problem is introduced that I have never encountered in any other vector app: The CMYK values seemingly being transformed using RGB color profiles and turning out something completely different from what I intended. While in other packages exporting a 100% K renders just that: complete blackness, a 100% K surface from Affinity seems to result in a greyish almost-black (and if exporting to a bitmap format, 100%K transforms into 94%.) This seems to be the case regardless of export format. Is there any documentation for how to use color values in Affinity, and how (or why) conversion takes place? Can it be turned off? Or is the CMYK color model in Affinity Designer only there as a coarse guideline, translated internally to and from RGB even if my intended use is printing? Any help and explanation greatly appreciated. (Case in point: Yes, you could argue that 100%K on paper isn't as rich and totally black as K with some percentage of CMY — but being a vector app, I want to be able to design a logo with a BLACK element — to be printed with K only — then print it as vector in complete blackness while also exporting it to, say, a web page header, with the black element still being completely black. This seems, confusingly, impossible with Affinity Designer today. Am I right?)

Not to barge in uninvited, but I need to say I don't think this should be considered a bug, and "fixing" it would open up a can of worms the size of... well, something big. I would argue resizing an object is an entirely different animal than editing an object's contents, and the two should be treated differently. Cases in point: Resizing a shape with "scale with object" set to on naturally should preserve the ratio between the object and its shadow/stroke/other effect, as it is now the same kind of artwork, only smaller/bigger. BUT. Changing the shape on a curve level — moving a control point or converting a line to a curve or adding more nodes to a star — should, when exiting editing mode, leave me with the exact same values for shadow and stroke, because even if the total size of the shape may have grown or shrunk in the process it's still basically the same object and should be treated identically to how it was before. (This is also exactly how AD handles it, so nothing wrong there.) Applying this to text, then: Scaling a text object — yes, preserve the scale of the effect. But changing the text contents of the text object — even if it means making the font bigger or smaller — must be considered the same kind of "internal" editing as changing a curve or adding a node. Digging deeper into the ramifications of having effects scale with changing font size, it's easy to see how things would be extremely unpredictable from a user standpoint. What if I misspelled a word? If I add a letter, remove one, make three lines into two or vice versa? That would change the relative size of the text object — but would I really want shadows and strokes to change because of it? And what if I choose another font, italicize a word, make it bold? Or even change the point size for ONE word in a multi-word text object? Should that change the effect? What happens when the axis are affected differently, as in breaking one line into two thus making the text object narrower, but taller? Bottomline: I'm deeply in love by the way AD handles effects. So please don't change. My two cents, anyway. :) /F.

Well, actually no — good point, this can be recreated without SizeUp too. Steps to recreate: 1. On your laptop, create a new AD document. 2. Click the green button (either with or without pressing ALT) thus either maximizing or going into full screen 3. Add a few shapes. 4. Connect a monitor with a different resolution that your laptop's native one. 5. (Perhaps optional) Close the lid to make sure AD opens on the monitor, not the laptop. 6. Watch the black workspace with invisible artwork. And/or: 1. With your laptop connected to an external monitor (one with a different pixel resolution than your laptop's built-in screen) create a new document 2. Click the green button, with or without using ALT 3. Add a few shapes. 4. Disconnect the monitor and open the lid on the laptop. 5. Black workspace again. If this doesn't work for you, could we be having different graphic cards? According to the system info, my MBA 2014 is equipped with an Intel HD Graphics 5000 1536 MB. Anyways, my apologies for dragging SizeUp into it — this seems to be an issue somewhere between AD, Sierra and/or possibly the graphics card. Thanks again!