Can anyone recommend an acrobat pro alternative?

[lacerto]

(...)

[loukash]

For the record, Acrobat X installed on Mojave without a hitch. In fact, I have deleted the apps (Distiller comes with it) right away and only relinked to the existing apps on my El Capitan partition to save space, as my Mojave partition is only 64 GB and getting full. Mac apps, Adobe's included, usually don't care where they actually live as long as there's a symlink in the active /Applications folder and as long as they see their support files – or symlinks thereof – in the active /Library/… and ~/Library/… folders. So far so good.

[loukash]

On 2/16/2021 at 9:49 PM, loukash said:

just realized a much bigger issue: Affinity will rasterize any vector objects with transparencies on PDF/X-3 output.
Unlike e.g. AICS5 with exactly the same vector content.

Also for the record, I have posted a separate thread on that ^ topic here:

 

[lacerto]

(...)

 

[loukash]

1 hour ago, Lagarto said:

But it is a start...  

Nice!
Installed, opened and checked your test file on Catalina.

1 hour ago, Lagarto said:

I am technically a novice on macOS, and it certainly shows

Observations:

• Since you're distributing a simple and fully self-contained app, usually you wouldn't need a *.pkg.
  Preferred "Mac-like" method is a DMG with a symbolic link to /Applications, then simply drag & drop the compiled app from the DMG via symlink into the Applications folder to install.
  Zip is also OK; this app is for "advanced users" who should already know how and where to install an app manually. Sometimes you may also want to install an app into the optional ~/Applications folder, not for other users to see and use.
• Command-P is traditionally reserved for the Print command.
• In fact, "Process PDF File" should be command-O (Open PDF File) because you are opening the file.
• It's not immediately obvious what Open Separations is supposed to do. Choosing and opening a grayscale TIFF crashes the app. If the former command becomes cmd-O, then this one should then be e.g. cmd-shift-O
• Creating a folder at the top level of a user home folder without a warning and permission is a no-no.
  In fact, I, for one, strongly dislike any app that auto-creates folders anywhere in my home directory without asking, except ~/Library/Application Support/App Name.
  My Services plugin "Ghostscript PDF To TIFF Separations.workflow" (still the initial "alpha" version, but at least I just finally tested that it works on Catalina!) creates a folder next to the input file with the same name as the file and places all output in there.
  Another option would be the system temp folder. Not sure where exactly it is; somewhere in /private/var/folders I think? Then you could optionally offer to save the output files to user's directory of choice. That would be my favorite method because usually I'd just want to preview but not necessarily save.
• Loading a "real life", print-ready – actually printed a few months ago – CMYK PDF/X-3 created by ID CS5.5 crashes the app. (It contains some sensitive data, so send me a private message if you want to test it.) Also my test PDF/X-3 created by Affinity crash. The same PDFs process just fine via Ghostscript when using my Service plugin.
• Disabling all plates has caused some weird display issues but can't replicate it now.

Looking forward for more! cheers!

[v_kyr]

44 minutes ago, loukash said:

...Creating a folder at the top level of a user home folder without a warning and permission is a no-no.
In fact, I, for one, strongly dislike any app that auto-creates folders anywhere in my home directory without asking, except ~/Library/Application Support/App Name...

That's your opinion but is mostly common usage on Unix systems either way. None of these ever asked for permissions, some even do highly depend and strictly look after some ".xxx" file or folder (most CLI tools & apps) in your home path.

Quote

.ApacheDirectoryStudio                                                                                                                                                                                     
.rnd                                                                                             
.adobe                                            .spacemacs                                                                                       
.android                                          .ssh                                                                                             
.bash_history                                 .subversion                                                                                      
.bash_it                                          .tooling                                                                                         
.bash_profile                                 .viminfo                                                                                         
.bash_profile.bak                          .vscode                                                                                          
.bash_profile.pysave                   .bash_sessions                                                                  
.zsh_history                                  .zshrc                                                                                                                                      
.bashrc                                           ActivePresenter7.5.4                                                                             
... and so on ...                         

Further it's much easier to detect and remove possible stuff from there, instead as being crippled under other deeper nested system locations.

@Lagarto against which MacOS version compliance & SDK version did you compiled? - Also it might be time to make an own Resources section thread entry for your efforts here, since this thread here is not that much particularly clear for your project!

[lacerto]

(...)

[v_kyr]

21 minutes ago, Lagarto said:

I am not sure if I understood the question! I compiled and built with default settings for Xamarin.Mac, but when I created the project, I was asked the minimum macOS version that I want to support: ... ...and I chose macOS High Sierra ...

That was the question, so you compiled against High Sierra. - Ok then I don't need to download and test, since in this case it won't run at all on El Capitan.

[loukash]

52 minutes ago, v_kyr said:

is mostly common usage on Unix systems either way. None of these ever asked for permissions, some even do highly depend and strictly look after some ".xxx" file or folder (most CLI tools & apps) in your home path.

I'm not talking about hidden ~/.files and ~/.folders which are unnecessary in this scenario because Ghostscript doesn't need them. I'm talking about the ~/PDFOutputPreview folder.
A Mac app should not create such a specific visible folder in ~/ where only the main default user folders are supposed to live.
I can't find the corresponding guideline on developer.apple.com right now, but the fact is that no serious Mac app does that. I remember reading about it some time ago. Everything a user should see should go to one of the ~/Subfolders.

Also, those user ~/.files & ~/.folders are hidden from the user for a reason – much like the whole underlying Unix, in fact – and they are relatively rare. From the plethora of 3rd party apps that I use, e.g. Karabiner creates and uses hidden folders on top user level like .config and .local , likely because it does quite some low level Unix things to make its magic work. Also, .dropbox hides some stuff that is irrelevant to the user but likely needs to be at this level and not in App Support.

Also, as PDFOutputPreview contains temp files (~/PDFOutputPreview/Input/tempcomposite.tiff and ~/PDFOutputPreview/Input/temptac.tiff), it must not be a hidden folder unless the app or the OS cleans it up afterwards. Otherwise the user will quickly end up with GBs of wasted storage space without knowing where to look for it.

2 minutes ago, Lagarto said:

I was not sure if the package installer would e.g. check if there are some additional features that need to be enabled in the environment (or possibly fetched from the Internet) to get this running

Ah, I see. It could possibly check if Ghostscript is installed, and if not, alert the user to get it first from pages.uoregon.edu/koch

3 minutes ago, Lagarto said:

I am not sure about "opening" -- as this app does not open PDF files but just extends them for processing.

Fair enough. Still, I think that cmd-P as well as any other otherwise "standardized" shortcut should be avoided.
How about Import PDF File? cmd-I

7 minutes ago, Lagarto said:

cannot assume it to be "Documents" in localized OS versions

On MacOS it is always the /Users/username/Documents directory. The localization is virtual, depending on user's system language settings.
Most standard MacOS folders contain the hidden blank ".localized" file that tells the system to look up the respective localized folder name in its database and display it to the user.

Ineterstingly, I just noticed that Catalina hides those ".localized" files from the user even if you enable "defaults write com.apple.Finder AppleShowAllFiles -bool true".
Hm…

19 minutes ago, Lagarto said:

I have so far tested with non-PDF/X files only (or basically ones with content up to PDF/X1, so all device cmyk). It also seems to crash sometimes on a bigger file where one page is extracted, possibly because of poor processing of Ghostscript messages, or just because of not clearing properly the environment (e.g. trying to access null objects).

As I said, Ghostscript itself is not the problem.
My Automator command goes:

/usr/local/bin/gs -q -sDEVICE=tiffsep -r300 -dTextAlphaBits=4 -o "$2"/output%d.tif "$1"

… where $1 is the incoming PDF and $2 the output path calculated from $1.
I may also add an $3 for the resolution input variable via dialog window, if 300 ppi is not enough.

Generally, I'll likely try to rewrite the whole plugin almost entirely as an AppleScript, as the built-in Automator modules don't necessarily do what I want them to do.

[lacerto]

(...)

[loukash]

17 minutes ago, loukash said:

My Automator command

For what it's worth, I just tested a 10 MB 2-spread PDF/X-3 (a 6-page 2-fold brochure) that I created yesterday after finishing "remixing" an old duotone layout of mine from 2003, originally created with XPress 4, converted to *.indd (InDesign 2) in 2006, exported this week to *.idml with ID CS5.5, imported into Publisher and there recreated as duotone (which Affinity cannot read, so I had to convert the original duotone EPS images with PS back to grayscale) to appear exactly as the original was.
It was a very satisfying exercise – see also:

Anyway…

So, PDF Output Preview will crash right away.
My Ghostscript PDF To TIFF Separations.workflow will take its time, eventually ending up with almost 50 MB worth of TIFFs, correctly separated into CMYK – CMY being blank apart from registration marks – and Pantone 300.

So if your gs command is correct, perhaps your app tries to proceed too quickly and thus fails?

[v_kyr]

8 minutes ago, loukash said:

'm not talking about hidden ~/.files and ~/.folders which are unnecessary in this scenario because Ghostscript doesn't need them. I'm talking about the ~/PDFOutputPreview folder.
A Mac app should not create such a specific visible folder in ~/ where only the main default user folders are supposed to live.

Also most developer tools (IDEs) do that too, they create "IdeaProjects" or "NetBeansProjects" etc. folders under your home directory. Even DropBox creates a "Public" map folder there. Other apps like image apps create their folders then one level deeper under "<userhome>/Pictures/xxx" (for example Adobe, Monosnap, Nikon Transfer, Canon tools, ... etc.).

[lacerto]

(...)

[loukash]

6 minutes ago, v_kyr said:

Even DropBox

Yep.
And the first thing I do when installing Dropbox is go to its Preferences > Sync > Dropbox Folder Location and change it to Documents.

All my ~/ are belong to me!

10 minutes ago, v_kyr said:

Other apps like image apps create their folders then one level deeper under "<userhome>/Pictures/xxx" (for example Adobe, Monosnap, Nikon Transfer, Canon tools, ... etc.).

~/Pictures/PDF Output Preview would be a good location. Actually I wanted to propose it in my earlier post but then forgot to type it…

[lacerto]

(...)

[v_kyr]

13 minutes ago, Lagarto said:

Ok, the implication of choosing the target was not clear to me, because it obviously made a difference in application design but not as regards the supported features. This is so simple app that I later probably re-create it so that is supports also older systems, but wanted to make it as easy for me to port the app.

No big deal now. You can try later to lower the MacOS compliance and dependencies then, as far as you don't use functionality (API functions) which isn't supported on earlier MacOS versions.

I recently had a to fight with some MacOS "autotrace" build in that regard, the people who created the Mac port told they compiled against OSX Yosemite compliance on a Travis server, but their SDK usage was High Sierra and thus their binary always gave an "Illegal instruction: 4" error response when trying to execute on MacOS systems "<High Sierra". So their binary wasn't really downwards compatible build due to their SDK usage and I had to recompile the whole darn stuff with it's xx foreign library dependencies on my own in order to build some really running binary version of that tool.

[loukash]

20 minutes ago, v_kyr said:

Even DropBox creates a "Public" map folder there.

^ Actually on a second look: are you talking about ~/Public/Drop Box?
That has nothing to do with the Dropbox.app. That's a standard MacOS folder since OS X 10.0.0 Public Beta some 20 years ago.

[loukash]

1 hour ago, Lagarto said:

But both open and print are of course somewhat obscure and metaforic in this context so perhaps could use different shortcuts altogether.

Thinking of it, you might even go for cmd-N because by processing a PDF you are creating a new separation.

[v_kyr]

14 minutes ago, Lagarto said:

Yes, that's what I assume (it does not wait the process to end but just processes the messages and when there are no more messages rushes to open the files which are still probably under preparation and not saved on disk, so that's probably the reason). I assumed this because some larger PDFs crash on first time but not on second. But as said, it could equally well be just a matter of clearing the environment poorly after successive PDFs opened for processing...

You can check for initiated subprocesses and threads if they are still running or if they have exited, the MacOS Process and Thread classes offer appropriate methods for checking this.

[v_kyr]

11 minutes ago, loukash said:

^ Actually on a second look: are you talking about ~/Public/Drop Box?
That has nothing to do with the Dropbox.app. That's a standard MacOS folder since OS X 10.0.0 Public Beta some 20 years ago.

Yes it's a pretty old one which contains an empty "Drop Box" folder, seems to be left or take over from good old Snow Leopard times. - It's a good candidate for puting exchange data in.

[v_kyr]

21 minutes ago, loukash said:

All my ~/ are belong to me!

Well since you are probably Admin (Gott) on that system pretty much all belongs to you!

[loukash]

4 minutes ago, v_kyr said:

Yes it's a pretty old one which contains an empty "Drop Box" folder, seems to be left or take over from good old Snow Leopard times.

No, this has always been MacOS default for file sharing with other users. System Preferences > Sharing > File Sharing > Shared folders. (Unless something changed on Bug Sur which I have no idea about.)
Unlike the other ~/Subfolders which are drwx------ ~/Public is drwxr-xr-x (read access for others), whereas ~/Public/Drop Box is drwx-wx-wx which means they may put (write) files inside but they can't see what's inside. Hence "Drop Box".

7 minutes ago, v_kyr said:

Admin (Gott)

Ich bin Root. Every now and then I use the root account for messing up with things mere mortals shouldn't ever mess with. Well, unless they painstakingly maintain multiple bootable backups like I do.

[lacerto]

(...)

[v_kyr]

1 hour ago, Lagarto said:

(I would personally prefer a subfolder under Documents folder but need to examine this a bit more to get that path in a proper way, it is strange that system environment path only returns the top folder as that is not as easily available as anything under Documents).

In ObjC/Swift you would get that one like this ...

Quote

ObjC

NSArray *paths = NSSearchPathForDirectoriesInDomains (NSDocumentDirectory, NSUserDomainMask, YES);
NSString *documentPath = [paths objectAtIndex:0];

Swift

func getDocumentsDirectory() -> URL {
    let paths = FileManager.default.urls(for: .documentDirectory, in: .userDomainMask)
    let documentsDirectory = paths[0]
    return documentsDirectory
}

... or ...

Quote

ObjC --> [NSURL fileURLWithPath:[NSHomeDirectory() stringByAppendingPathComponent:@"Documents"]];

 

[loukash]

1 hour ago, Lagarto said:

The input and ouput folders are now by default created under user's Pictures path (I would personally prefer a subfolder under Documents folder

I've been thinking about it this morning in bed while slowly waking up – the best time of day to form new ideas.
Perhaps the best and most transparent solution would be to prompt user to choose the folder location on the very first PDF import.