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

Bobbob

Members
  • Posts

    22
  • Joined

  • Last visited

  1. Thanks! Will have a look at this. There certainly seems to be a gap in the market for such a tool. None of the many available PDF viewers seems to be geared towards prepress. Free would be ideal, but cheaper than £20/month would be a start.
  2. tiffsep and tiff32nc seem to produce the same 32bit CMYK tiff file, but tiffsep also produces a separate greyscale file for each separation.
  3. How much time do they want? I've been using Publisher for three or four years now. I've stupidly paid for the underwhelming v2 update. I won't be sticking around much longer if they can't sort out "pre-basics". I love designing in Publisher, but sending a job to print you're basically flying blind.
  4. I didn't read it anywhere. I meant they've made it clear through their actions (or lack of them). Looking through the forums people have been asking for basic print-related features like this for years and years with absolute silence and from Serif.
  5. Perfect!* I hadn't thought of using Ghostscript (only ever used gs to convert from PS to PDF, didn't realise it worked the other way around too). Just checked and gs -sDEVICE=tiff32nc does the trick, and confirms it's just 100%K that overprints automatically. You've just saved me an Acrobat subscription 😄 *well, more perfect would be having basic vital functionality like this implemented within Affinity but I think Serif have made it pretty clear they have no intention of catering for even the occasional prepress user.
  6. Hi, what counts as "black" for automatic overprinting of black in Publisher? Is it just 0%C 0%M 0%Y 100%K, or will any colour with 100%K automatically overprint? And is there any way to check that overprint is set correctly in the output PDF without Acrobat Pro? thanks Currently using 2.2.0 on Win 10
  7. OK, thanks @Dan C, but in that case why doesn't the "Ungrouped" text get rasterised?
  8. It would be very useful to have an (optional) preflight check to flag vector layers which will be rasterised on export. There are times when you want vector layers to be rasterised (e.g. using some blend modes, pixel-based masks/effects etc.) and other times when you really don't. Background: I recently found a bug that was causing some vector layers to be rasterised on export, but this could just as easily happen through user error. Now I have to go through several very large documents and manually check layer by layer to make sure it's not happening anywhere else. Which is going to take a while... On the other hand, I can quite see that such a check would very often throw up lots of results for layers that you're quite happy to be rasterised, so you would need to be able to turn it off.
  9. @thomaso yes, with export at 300dpi you can only just about tell at maximum zoom on my PDF reader, but it can make a big difference to the final print job.
  10. Thanks Dan, something that would really have helped me to pick this up would be if there was some way to check for vector layers being rasterised - an optional warning in preflight maybe?
  11. Hi @Dan C thanks for getting back to me. Here's a minimal demonstration: The text "UNGROUPED" on p1 is not rasterised on export but the text "GROUPED1" on p2 is (I set 36DPI in the export dialogue to make it clear). The two text objects seem to have the same relationship to the adjustment layers below them, but only the one that is in a group is rasterised on export. The text "GROUPED2" is not rasterised, which is as I would expect as in this case the adjustment layer is attached to the image. I used soft proof layers to demonstrate because that's how I initially found this behaviour and also I thought they weren't supposed to do anything on export. If this is how things are supposed to work that's fine, but it seems a bit weird and I wish I'd noticed before I sent an expensive job to print... Steve goup_text_test.pdf goup_text_test.afpub
  12. I have a group which contains a number of vector layers and a pixel layer as the lowest for the background. If I add an adjustment layer to the pixel layer it only affects the pixel layer and the other layers render as expected. However, if I (accidentally) move the adjustment layer to be immediately above the pixel layer, it only adjusts the pixel layer but it causes all the vector layers above it to be rasterised on export. Is this the expected behaviour? It's kind of a pain. Publisher 1.8.4.693 on Win 10
  13. Do I also need to un-check the "overprint black" checkbox? Will checking it force 0,0,0 RGB black to 100%K?
×
×
  • 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.