Jump to content
You must now use your email address to sign in [click for more info] ×

jhonan

Members
  • Posts

    13
  • Joined

  • Last visited

Everything posted by jhonan

  1. If you sign out of the desktop versions, will the devices be removed from the registered list, or is it the case that when you log in on a new device it gets added to the list forever? - I have a mac in a different location I need to use Publisher on temporarily, but I don't want it stuck in my 'registered devices' list forever.
  2. Ah, that's excellent - I hadn't gone into that tab before, but it's very useful - especially for removing fringing etc.
  3. The image size for the D40 is advertised as 3008x2000px, so it looks like it is indeed including the areas outside the sensor. Thanks for the clarification Walt.
  4. This is from a Nikon D40, so I'm not sure if it's an older version of the NEF format causing this. DSC_5940.NEF
  5. I got about half-way through that document before I realised I'm going down another rabbit hole! The level of complexity behind the 4-colour process is crazy. Even the section on half tone dots was new to me. It just never occurred to me that CMYK percentages eventually end up as half tone dots like that.
  6. That's a pretty impressive reply, thanks for taking the time to explain all that. There are some attempts at pre-press functionality in Publisher (like the pre-flight section) which are fine for basic checks before sending to pre-press, but not powerful enough to provide all the checking and processing that a dedicated pre-press application provides. I took a look at the Packzview videos and it's insane! - So that seems like a grey area; where does the responsibility of the graphic designer end, and the pre-press person begin? The graphic designer should at least send a 'printable' document to pre-press, but they might not necessarily have checked every single aspect of it. But on the other hand, you don't want the document going backwards and forwards between pre-press and the designer ad nauseum. Affinity offers simplicity and guides you in a way that prevents errors (which I prefer, personally). But any errors that do creep in are then left to pre-press to discover and sort out.
  7. Yeah, I thought I'd take advantage and try to learn a few things. Unfortunately I have very little experience in this area, as you can probably tell. But feel free to ask me any questions about Data Analytics, I've got about 30 years experience in that! 🤣
  8. Who is the colour profile benefiting, as in, who uses it? - My understanding is that you set it during document production to make sure that your ink coverage % is within the correct limits for the selected stock, and that your on-screen colors match the final output as closely as possible (i.e. you're working in the same gamut range as the final printed output) - The reason we select CMYK profiles is because professional printers use a 4-colour process. A PDF can be a mixture of CMYK and RGB elements for example (I don't even think the selected profile is stored in the PDF file) - Does the printing company read the profile or even care about it, or do they just take the PDF file as-is and work with it from there, creating the separations etc? Theoretically, if I'm happy with a RGB colourspace document, I could output to PDF, send it to the printers and say 'print this' - The colour matching might be all over the place and out of gamut, and I might end up with holes in the page, but me telling the printing company what RGB profile I used won't stop that from happening! (Please correct me if I'm wrong about this)
  9. Even a 'Retain K100 text' checkbox in the assign/convert dialog would be a big help. Basically convert all the colours except any Frame Text or Artistic Text objects set to K100
  10. Yes, I think that's what I need to do. I must admit to not fully understanding how Colour Profiles are used by the printers and why they're important during document creation. But that's the subject of another investigation!
  11. Thanks for all the replies, they're very helpful. I'd like to narrow this down to one simple issue; If I'm sending body text to a commercial printer, I want it to appear as 100%K 0/0/0/100 even if I switch profiles. When I create a CMYK document from scratch, everything works as it should. "File / New / Press Ready / A5" Gives me a CMYK/8 US Web Coated SWOP v2 document. If I create a Frame Text Tool or Artistic Text Tool it defaults to 100%K, great! But, I realise I've selected the wrong colour profile so I click on 'Document Setup' and pick Color Profile 'Coated FOGRA27 with 'Convert' selected, and click OK Oh no! - My nice 100%K text has now been converted over to some 71/71/65/77 'Rich Black' value! I'm fine with illustrations or blocks of black converting over, since black in that context might appear better as a rich black. But I certainly don't want my text going to the printers as anything other than 100%K - I want my printers to use the K plate only. And now, I can't revert that change! - If I change back to the US Web Coated SWOP v2 profile, what was originally 100%K text now becomes 67/68/66/75 Which means that if I pick a CMYK profile when I create a document, I need to remember not to change the profile at any point or I'll lose my 100%K text. I'm not sure what I'd do if the printer comes back to me and asks for a different profile? - Do I click 'assign' instead of 'convert' in that case?
  12. Thanks for the reply, and for welcoming me to the forums. Even if this behaviour isn't a bug, it's certainly an inconsistency in the interface of the Colour Chooser. I tried a few more combinations using Colour Chooser, basically selecting a value using the sliders in the RGB screen, and then checking to see what corresponding CMYK values I'm getting. Here I've created an RGB/8 (sRGB) document Let's start with the colours that give CMYK its name; RGB 0/255/255 (Cyan) -> CMYK 52/0/13/0 - should be 100/0/0/0 RGB 255/0/255 (Magenta) -> CMYK 27/82/0/0 - should be 0/100/0/0 RGB 255/255/0 (Yellow) -> CMYK 6/0/96/0 - SO CLOSE! RGB 0/0/0 (Black) -> CMYK 72/68/67/88 - should be 0/0/0/100 Now onto the other basic colours; RGB 255/255/255 (White) -> CMYK 0/0/0/0 - CORRECT! RGB 255/0/0 (Red) -> CMYK 0/100/100/0 - CORRECT! RGB 0/255/0 (Green) -> CMYK 62/0/100/0 - should be 100/0/100/0 RGB 0/0/255 (Blue) -> CMYK 88/77/0/0 - should be 100/100/0/0 Why is this issue important? - Because for commercial printing you're using some combination of four plates; Cyan, Magenta, Yellow and Black. If I'm in a CMYK colour space document, and I want to pick 'Yellow' for a block of text. I open up Colour Chooser but I'm on the RGB slider panel so I select 255/255/0 (That's yellow, right?) - My text changes to yellow, I produce my PDF and send it to the printers. But the colour separation isn't giving me a 100% yellow plate for my text, it'll give me 96% Yellow, with a 6% Cyan plate - how'd that get in there? On the other hand, I want to change some text to Red - I quickly select 255/0/0 on the RGB slider, it maps to 0/100/100/0, and at the printers I've got a 100% Magenta and a 100% Yellow plate. Everybody's happy! And here's the worst part. I have a load of text I want to print in Black. It's important that it only uses the Black plate at the printers, since I don't want to get blurred text by 4 plates not aligning. I know that pure Black will use only the K plate. I select my text, open up the Colour Chooser and pick RGB 0/0/0, that's black, right????.... Wrong.... It gets to the printers, my 'Black' is actually CMYK 72/68/67/88, resulting in 4 plates being used to print my text. And a blurry mess. I wouldn't want to be creating a 300 page book in Publisher and accidentally select RGB Black. Arguably I should stay away from the RGB sliders when working in the CMYK colour space, and I can understand why this conversion between colour spaces has to happen Also, the other colours I tested aren't as important as Black. But Black is the important one; Does RGB Black really map to different CMYK values depending on the profile? How about a preferences checkbox that says something like 'Do direct RGB -> CMYK mapping in colour chooser' to at least map the 8 basic RGB colours directly to the CMYK equivalent?
  13. According to conversion charts like this; https://www.rapidtables.com/convert/color/cmyk-to-rgb.html CMYK black should convert to RGB black, and CMYK white converts to RGB white. For example; CMYK 0/0/0/100 = RGB 0/0/0 (Black) However, if you open the Publisher colour chooser and play around with the sliders, you'll see it doesn't do the conversions like this. Here's what Publisher does; Selecting CMYK 0/0/0/100 on the CMYK sliders gives you RGB 35/31/32 (Some sort of dark grey??) Selecting RGB 0/0/0 on the RGB sliders gives you CMYK 72/68/67/88 (Some variation of rich black??) And here's the funny thing. If you select CMYK 0/0/0/100 on the CMYK sliders, switch over to the RGB sliders (which read 35/31/32) and just *touch* one of the values without even changing it, the CMYK values suddenly flip over to CMYK 68/67/65/74 ! Where'd that number come from? This seems a bit buggy to me. Is there any way to tell Publisher to use the normal RGB->CMYK conversions, i.e. RGB 0/0/0 -> CMYK 0/0/0/100; This would make life much easier when switching colorspace from RGB to CMYK for sending to a commercial printers, for example. As it is, I have to manually go through the document, select all the black text, and change the colour to CMYK 0/0/0/100
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.