Can anyone recommend an acrobat pro alternative?

[iPeter]

I think i have another good solution for view color separation. The solution ist nearer than you think and you need no another software (only with affinity apps): 

1. Reimport the exported PDF in Affintiy Photo (direct open or place as passthru PDF).

2. Reduce it to only one Layer (as pixel image).

3. You can see and switch (on/off with eye icon) now the certain color separation plates in the color channel palette. In the Palette you can see the color profile too. 

4. When click with the pipette tool on a certain area, you can see the color value in the color palette. 

The another important prepress review can you make in the free Acrobat Reader (optic, resolution, color profile, PDF-Standard, format, bleed, marks and embedded fonts). 

I tested it first only on my iPad and with normal CMYK colors (not now with special solid colors, i must test it with desktop apps and special solid colors later). But the colors in the document, PDF and in Affinity Photo (separations) has the same values. 

It would be a good idea when the Affinity developers integrate it direct as a kind of export review persona (for the certain page), so the user can use this function much easier (with no manual conversation and several palettes on several locations) . 

 

[Lorox]

1 hour ago, iPeter said:

I think i have another good solution for view color separation. The solution ist nearer than you think and you need no another software (only with affinity apps): 

1. Reimport the exported PDF in Affintiy Photo (direct open or place as passthru PDF).

...

Thank you, this is actually a very interesting (and in its simplicity somewhat surprising) take on the issue of preflighting colour separations in Publisher generated PDFs. As it is so easy to drag/import rich black text into Publisher without really wanting to, checking the blacks (for all black text elements) is – at least for me  – of primary importance when viewing the colour separations. And your method seems to make this possible without resorting to any third party apps.

So far I've only checked (on desktop AP) with strict CMYK PDFs (which I almost solely need these days), but back in the day I've done quite a lot of spot colour jobs, so it would be worthwhile to know how solid colours from PDFs are handled in AP and if the method works with them as well.

[Optische Ausrichtung]

18 hours ago, iPeter said:

I think i have another good solution for view color separation.

Yes, but unfortunately, I did not manage to display the overprint elements correctly this way.

 

On 10/15/2021 at 12:40 AM, Kal said:

It uses Ghostscript

The fearless among us can still check their print separations "in a post-Adobe world" with ghostscript in a terminal windows. On a Mac it should be something like this: 

gs \
  -sDEVICE=tiffsep \
  -dNOPAUSE \
  -dBATCH \
  -dSAFER \
  -r300x300 \
  -sColorConversionStrategy=CMYK \
  -dOverrideICC=true \
  -dRenderIntent=3 \
  -sDefaultCMYKProfile="/Users/[username]/Library/Application Support/Affinity Publisher/profiles/[profile].icc" \
  -sOutputICCProfile="/Users/[username]/Library/Application Support/Affinity Publisher/profiles/[profile].icc" \
  -sOutputFile="output"%08d.tif \
  [input].pdf

Of course, the parameters have to be adjusted individually, especially the paths to the ICC profiles and the filenames in square brackets. If it works, the code is fine in a shell script. Maybe someone with more knowledge can also make the code a bit more elegant.

I don't know if this method has been mentioned in the thread yet.

 

[Lorox]

1 hour ago, Optische Ausrichtung said:

20 hours ago, iPeter said:

I think i have another good solution for view color separation.

Yes, but unfortunately, I did not manage to display the overprint elements correctly this way.

You're right – if overprinting is part of your design, it will not work. Obviously Affinity Photo does not translate the "overprint property" from the PDF into its rendering of the design. I checked with a simple file using overprinting versions of CMY and they block out completely what's below them.

In this regard I have to add to my post above: whereas you can actually check whether your blacks are 100% K blacks or all-component "rich" blacks, you – due to this method’s failure at handling overprinting correctly – unfortunately CANNOT check whether your 100 K black is overprinting (as it usually should with type elements). Too bad!

[v_kyr]

1 hour ago, Optische Ausrichtung said:

Of course, the parameters have to be adjusted individually, especially the paths to the ICC profiles and the filenames in square brackets. If it works, the code is fine in a shell script.

You can reuse/enhance/customize the below shown script code further (Note: ...didn't tested it via GS, since I don't have gs installed here on the computer) ...

#!/bin/bash

username=$USER

Help()
{
   # Display Help
   echo "$0 -- Calls Ghostscript for color separation"
   echo
   echo "Syntax: $0 [-p|i|o|h]"
   echo "options:"
   echo "p     A profile name, excluding the .icc extension."
   echo "i     The input file name (sample.pdf)."
   echo "i     The output file name (sample.tif)."
   echo "h     Print this Help."
   echo
}

while getopts :p:i:o:h flag
do
    case "${flag}" in
        p) profile=${OPTARG};;
        i) inputfile=${OPTARG};;
        o) outputfile=${OPTARG};;
        h) Help 
           exit;;
    esac
done

if ! command -v gs &> /dev/null
then
    echo "Ghostscript could not be found"
    exit
else
  gs \
    -sDEVICE=tiffsep \
    -dNOPAUSE \
    -dBATCH \
    -dSAFER \
    -r300x300 \
    -sColorConversionStrategy=CMYK \
    -dOverrideICC=true \
    -dRenderIntent=3 \
    -sDefaultCMYKProfile="/Users/$username/Library/Application Support/Affinity Publisher/profiles/$profile.icc" \
    -sOutputICCProfile="/Users/$username/Library/Application Support/Affinity Publisher/profiles/$profile.icc" \
    -sOutputFile=$outputfile \
    $inputfile.pdf
fi

[Optische Ausrichtung]

1 hour ago, v_kyr said:

didn't tested it via GS

Thank you, I added my Username in line 3:

username=optischeausrichtung

and changed

  -sOutputFile=$outputfile \

to

-sOutputFile="%08d"$outputfile \

tested with

test.sh -p ISOcoated_v2_300_eci -i input -o out.tif

Has worked! (Input filename was "input.pdf", the script writes 5 TIF files per PDF page: Cyan, Magenta, Yellow, Black, Combined)

 

Edited April 11, 2022 by Optische Ausrichtung
\ added and improved to "%08d"$outputfile

[v_kyr]

1 hour ago, Optische Ausrichtung said:

Thank you, I added my Username in line 3:

username=optischeausrichtung

That usually shouldn't be needed, since in shell scripts a command of  "$USER" will allready return the active username. You can test this inside a terminal/shell with ...

echo $USER

... if it returns your systems active login username.

[Optische Ausrichtung]

3 minutes ago, v_kyr said:

You can test this inside a terminal

thx … tested, you are right.

 

[iPeter]

7 hours ago, Optische Ausrichtung said:

Yes, but unfortunately, I did not manage to display the overprint elements correctly this way.

 

The fearless among us can still check their print separations "in a post-Adobe world" with ghostscript in a terminal windows. On a Mac it should be something like this: 

gs \
  -sDEVICE=tiffsep \
  -dNOPAUSE \
  -dBATCH \
  -dSAFER \
  -r300x300 \
  -sColorConversionStrategy=CMYK \
  -dOverrideICC=true \
  -dRenderIntent=3 \
  -sDefaultCMYKProfile="/Users/[username]/Library/Application Support/Affinity Publisher/profiles/[profile].icc" \
  -sOutputICCProfile="/Users/[username]/Library/Application Support/Affinity Publisher/profiles/[profile].icc" \
  -sOutputFile="output"%08d.tif \
  [input].pdf

Of course, the parameters have to be adjusted individually, especially the paths to the ICC profiles and the filenames in square brackets. If it works, the code is fine in a shell script. Maybe someone with more knowledge can also make the code a bit more elegant.

I don't know if this method has been mentioned in the thread yet. 

 

I had yesterday tested it after my post detailed on my mac. That's right. Overprinted and solid colors unfortunately are not viewing correctly with this method. Sorry! 

I experimented yesterday with a virtual postscript printer in acrobat too. You can see and switch the various color layer in the printer preferences dialog (even the solid color), but the overprinted color was incorrectly too (how for example in Affinity Photo). This information is store in the PDF in a very special way. 

But the Ghostscript solution is a good possibility to do this.  

[Optische Ausrichtung]

Here is a new modified version of the script. In most cases, you will not need to specify the color profiles. But you will need control over the resolution of the output files.

This version is probably a little easier and safer to use:

#!/bin/bash

username=$USER

Help()
{
   # Display Help
   echo "$0 -- Calls Ghostscript for color separation"
   echo
   echo "Syntax: $0 [-d|i|o|h]"
   echo "options:"
   echo "d     dpi, output resolution (600)"
   echo "i     The input file name (sample.pdf)."
   echo "o     The output file name (sample.tif)."
   echo "h     Print this Help."
   echo
   echo "Example: $0 -d 600 -i sample.pdf -o sample.tif"
   echo
}

while getopts :d:i:o:h flag
do
    case "${flag}" in
        d) dpi=${OPTARG};;
        i) inputfile=${OPTARG};;
        o) outputfile=${OPTARG};;
        h) Help 
           exit;;
    esac
done

if ! command -v gs &> /dev/null
then
    echo "Ghostscript could not be found"
    exit
else
  gs \
    -sDEVICE=tiffsep \
    -dNOPAUSE \
    -dBATCH \
    -dSAFER \
    -r$dpix$dpi \
    -sColorConversionStrategy=CMYK \
    -dOverrideICC=true \
    -dRenderIntent=3 \
    -sOutputFile="%08d"$outputfile \
    $inputfile
fi

 

The PDF/X-4 "sample.pdf" exported from an afpub-document (cmyk) with 2 pages, 2 Pantone colors and overprinting elements results in these 12 TIF files:

(The file names of page 3 would accordingly start with 00000003.)

Thanks again, especially to @v_kyr ! The script works very reliably and is for the task a good alternative to expensive products. 

 

[Johannes]

On 2/20/2019 at 10:23 PM, Tonda said:

Take a look on https://www.qoppa.com/pdfstudio - I own the older Pro version and coming from Acrobat Pro X I am quite happy with it, although I am not sure if it does really everything you mentioned. You can try yourself the free trial here: https://www.qoppa.com/pdfstudio/download and at the moment they have promos 25 % Valentine discount + next version for free with purchase. Just note that it requires Java (at least the older version I own).

 

On 3/7/2019 at 8:02 AM, Pariah73 said:

After trying LOTS of PDF programs, I can say I haven't found a single one that does color seps. Tried PDF Exchange, PDFSam, PDF Architect, Bullzip, Sumatra, PDF Creator, PDFill (which had the best value -$20- for pro if you can deal with the hideous interface) Foxit Reader (trial of Phantom PDF) Nitro..there's some more that I can't remember. Only program I've discovered is Callas PDF uh..something..anyhow it's just as expensive as AA. Horribly neglected field of software IMO. I ended up creating a PDF in AD, then handing that off to Scribus for color separations. Not perfect but it works.

2022 pro version should get color separation 

maybe I try it out then

[RM f/g]

On 5/30/2022 at 8:47 PM, Johannes said:

2022 pro version should get color separation

Yes, Pdf Studio 2022 Pro has colour separations, but it doesn't work well. If at all.

 

[Lorox]

2 hours ago, RM f/g said:

Yes, Pdf Studio 2022 Pro has colour separations, but it doesn't work well. If at all.

 

I tried to verify this via their website but I honestly could not find actual proof for this. As you can obviously check overprinting by activating the proper kind of view mode one would have thought that being able to inspect colour separations would have been a point worth mentioning in the features list...

[AffinityAppMan]

I like this PDF app

PDF elements

 

[prophet]

46 minutes ago, AffinityAppMan said:

I like this PDF app

PDF elements

I'm not seeing color seps here. Did I miss something?

[DebraS]

I too have struggled with Acrobat Pro X. At first I didn't know what the issue was, but threads like this have shown me that it is not compatible with Windows 10. There is a version of Acrobat Pro 2020 that you can purchase, but it is at a pretty steep price and I don't know how long that will work - especially with Windows 11 in the future. My solution (that works every time) - pop the CS6 install CD in and reinstall only Acrobat Pro. I don't uninstall the program first, just reinstall and it works fine. It seems like it works for about a month and a half and then I have to repeat this process. A bit of an inconvenience, but it's a fact of life for the moment. Just thought I'd share this in case it may help someone. I will continue to follow this and search in my spare time to see if a solution becomes apparent. I do not mind spending money for a program, but I don't want to spend $500+ and have it not work next year. 🙄

[lacerto]

9 hours ago, DebraS said:

I too have struggled with Acrobat Pro X. At first I didn't know what the issue was, but threads like this have shown me that it is not compatible with Windows 10. There is a version of Acrobat Pro 2020 that you can purchase, but it is at a pretty steep price and I don't know how long that will work - especially with Windows 11 in the future.

This is odd -- I have Adobe Acrobat Pro X as part of CS6 Master Suite and it works perfectly fine on Windows 11, without any tricks (repeated reinstallations), permanently, no need for reactivations, etc., along with Adobe Acrobat 2020 installed on the same computer. I also have CC apps and Adobe Express apps installed on the same computer:

I have pretty much the same configuration on a Windows 10 Pro computer, so Adobe Acrobat Pro X is definitely not incompatible with Windows 10, and I do not think that this has been issue in this long thread: it is rather the fact that 32-bit Adobe apps cannot be run on macOS, not since Catalina. But on Windows there should be no issues in running any CS6-based apps -- Adobe will reset your installation count so that proper activation is possible, but you need to be in touch with their support to have that (I did it a few months ago and it is a matter of couple of minutes with chat connection).

In light of that, I do not expect Adobe Acrobat 2020 (as a 64-bit app) becoming incompatible on Windows in any foreseeable future (if ever). On macOS this is a valid worry, since who knows how long Intel-based apps can be run on Silicon macs.

[lacerto]

PDF Studio 2022 Pro was mentioned above so I had a quick look on it. It seems to have a bunch of nice features that aim at replacing Adobe Acrobat, but its prepress features are very basic. The Output Preview does show overprint preview but seems to be missing a color picker for examining color values (in Edit mode there is CMYK mode but it displays incorrect color values). Spot colors do not seem to be supported, at all, and I could not find any kind of TAC coloring, page box handling, transparency or font flattening, color conversion tool, or proper preflight (basically just conversion to PDF/X-1 to PDF/X-3 (and PDF/A) and verification of the mentioned methods). The preflight information is minimal. The app itself does not seem to be color managed (at least on Windows).

[loukash]

On 4/11/2022 at 10:48 AM, Optische Ausrichtung said:

The fearless among us can still check their print separations "in a post-Adobe world" with ghostscript in a terminal windows. On a Mac it should be something like this: 

Why so complex?
I'm using a much simpler shell script as a part of a custom Automator workflow. The workflow is still a bit rough because it can only process one PDF at a time (haven't figured out a loop yet) but it works excellently:

More on that earlier in this very thread: 

 

[lacerto]

For information to anyone using Ghostscript to check separations and distribution of colors, it was recently found out in another thread that this process is similarly ICC dependent as Adobe Acrobat Pro, and would typically show wrong color values for any job that is ICC based (instead of DeviceCMYK) and has color profiles embedded. There might be a way to choose the matching preview profile to get correct object color values, but a complex job might have multiple color profiles embedded so the values should be read using a referred ICC profile for each object, and I do not think there is a way that Ghostscript can handle this (Adobe Acrobat cannot, either, but has a tool that lets the user check the ICC and true color values one by one).

What is more important is that it seems that having an embedded CMYK profile might actually cause unnecessary translation of color values, even if the existing color values were already calculated for this color space (similarly as happens with Ghostscript), just because of the embedded profile the file would be considered ICC-based. This e.g. would result in all K100 values becoming four-color-blacks. When using Packzview, the embedded CMYK profiles are not considered and native CMYK values are passed, but it is not clear whether this is something that requires experienced and careful print personnel to take care of when ripping the file, without which these kinds of production PDFs [= kinds that Affinity apps create by default whenever choosing "PDF (Press ready)" based exports] might end up being recalculated when ripped.

[iPeter]

Hello Affinity community! 

I developed a AppleScript-droplet-collection and a Safari/Publisher-Preview too. I wrote the Safari-Preview with HTML, CSS and JavaScript (only Safari can open TIFF-files). Furthermore i make a Affinity Publisher 1 & 2 preview. But this is on the first time only experimental (only for A4-papersize, portrait-format and with 3 mm cut frame). When you like, you can change the document for your needs. 

You can download the Version 1.00 from the software here: Download CMYK Separation Extractor & Preview 1.00

Sorry for the not very well english in the english user manual. I translate it with a web service quick and dirty for the first time. 

I hope you enjoy my little software. 

Best regards 

[loukash]

@iPeter, thanks! Looking forward to check it out!  

[loukash]

@iPeter, ich würde sogar sagen, das ist auf den ersten Versuch mit v1 im El Capitan ziemlich genial!  Genau sowas wie dein Affinity-Vorschau-Skript schwebte mir mit meinem vorhin erwähnten Automator-Plugin auch vor, ich war aber bisher zu faul, mir als "Hobby-Skripter" all die notwendigen Schritte im Teh Internetz zusammenzusuchen…

Summed up in English:
Safari preview works even on El Capitan with Safari 11! Yay!

[loukash]

@iPeter: Why opening Terminal? Why not "do shell script"?

[iPeter]

German: 

Keine Ahnung, ob das auch anders nur im Hintergrund gehen würde (ich habe das schon vor längerer Zeit angefangen). Du kannst es ja gerne mal anders probieren. Aber ich glaube, dass damit nicht so viele Sachen funktionieren (habe glauben ich damit schon mal Probleme gehabt). Es handelt sich ja eigentlich auch nicht nur um einen Befehl, sondern immer mindestens zwei die nacheinander (in einen Prozesse) abgearbeitet werden müssen. Im ersten Befehl wird in den Programmordner gewechselt, wo sich die Skripte und der Export-Ordner sich befinden (das braucht man für den genauen Export-Pfad der Dateien) und im zweiten wird der der eigentliche Ghostscript-Befehl ausgeführt. Das war schon eine ziemliche Arbeit, die Pfade zwischen AppleScript (Finder) und Unix (Terminal) untereinander kompatibel zu bekommen, ohne dass es irgendwo wegen Syntax-Fehlern hängen bleibt. Ich finde das eigentlich auch gar nicht so schlimm, da man so immerhin eine Art Statusmitteilung (Fortschritt- und Fehleranzeige) hat, ohne eine Art Fortschrittbalken dafür programmieren zu müssen (das wüsste ich auch nicht, wie man das in AppleScript realisieren könnte).

English: 

I don't know if this would work in the background (I started doing this a long time ago). You can try it with pleasure times differently. But I think that not so many things work with it (I think I have had problems with it before). It is actually not only one command, but always at least two that must be processed one after the other (in a process). The first command changes to the program folder where the scripts and the export folder are located (this is needed for the exact export path of the files) and the second one executes the actual Ghostscript command. It was quite a job to get the paths between AppleScript (Finder) and Unix (Terminal) compatible without getting stuck somewhere because of syntax errors. I don't think that's too bad, because it gives you some kind of status (progress and error) without having to program some kind of progress bar (I wouldn't know how to do that in AppleScript either).