Mac or Windows?
1 person found this helpful
Ok. First thing to understand is thatwhile the AI license allows you to run it on a server, it only allows users inside your organization to use it, and only as many as already have desktop AI licenses. If you want your customers to be able to run jobs through it, you're going to have to speak to Adobe and see if you can negotiate it.
Second, unlike IDS, Illustrator isn't designed for headless server-based use. It can be done, but it's more work. You'll have to write your own web service (not terribly hard) as a SOAP server isn't included. You'll also need to duct-tape workarounds for its annoying habits like throwing up dialogs even after you've told it not to , or crashing after a certain number of files have been open and saved.
My own expertise is the Apple events API, which is the standard interprocess communication system for GUI apps. That generally means using AppleScript, which is a pig of a language to master, but is the de facto standard for macOS desktop automation. You could, for example, write a simple SOAP server in PHP that runs in a standard user account alongside AI, and calls `shell_exec()` to run an AppleScript via macOS's command line `osascript` tool. Using AppleScript for the IPC's certainly the safest way to go (unless you're going to go full C++, in which case you can do anything you like): while competent AppleScripters who know their way around Adobe apps are only slightly less scarce than hens' teeth, it's still the best documented, supported, and understood language for Mac automation. You can in principle mix and match: using AS just to call into AI, and then use Actions or JSX to do all the actual work, though be aware of that damned PARM bug, as when I tried going this route myself I ran into that wall in almost no time at all
Beyond that, you're getting pretty ambitious. At my previous job I built a job server web app that ran on a Linux VM and farmed out jobs over several Mac minis running in the server rack (think a bit like Twist, but built specificially for AI-based automation, and without the fancy graphical configuration interface). Worked pretty well: it could monitor the Macs for lockups and crashes and restart jobs automatically, send email notifications to admins and users, record full logs in a Postgres database and even take automatic screenshots to aid later troubleshooting, and to some extent reroute jobs from one Mac to another, though I never did get as far as fully distributed load balancing before I finished there). All done in Python3; around 20KLOC in total (including the templating engine, which was half of that). After I left IT would occasionally turn it off and on again when there was a problem, otherwise it pretty much looked after itself.
If you absolutely can't abide AppleScript, or you need to write code of significant complexity, the old Python 3 appscript bridge (which I wrote) still works, and is at least 99.9% as capable and reliable as AppleScript for application automation. I stopped doing [free] development or support for it a few years back, but I still use it to drive all my own high-end AI automation, and it's an absolute trooper. Or there's the new SwiftAutomation bridge I'm now working on, which I would _really_ like Apple to adopt for inclusion in 10.13 (feel free to file your own feature request with Apple for this). It's not fully finished (the docs are rough as hell and there's probably still some bugs) and not yet production tested, but it design descends from appscript so I'm pretty confident there won't be more than the odd running-in glitch to sort out.
Lastly, don't underestimate the value of sticking a second Mac on an artworker's desk and just having her run the AI automation on that. (Or, if it's in a datacenter, letting her remote in on TeamViewer or whatever from her main machine.) That way you get the productivity benefits of automation without the overhead costs of building a headless, autonomous server-based system. *Especially* if you're not yet doing AI automation on the desktop, because learning out how to write AI automation scripts that produce the results users actually need on time and budget is by far the most important part. The best workflow server in the world isn't worth squat if it can't do anything more useful than the company's business cards. (I do packaging automation where the whole industry's been trying to automate the artworking step for 20 years, and they still fall into that trap.) So always get that bit working right in production first, delivering real results, and you can then look at moving it to server-based hosting later on, when you've a much stronger case for the budget and a much clearer understanding of what the work entails.
 e.g. 3rd-party font manager plugins are a real pain for this ("can't find font" dialogs when opening files are a plague); swatch conflicts when merging artworks is another, and there's probably one or two more I've forgotten about. You'll want to look at things like your artworks' font requirements, and whether you can just have all fonts permanently installed on that machine, or whether you can script your font manager to install them on an as-needed basis before opening each file (font info can be obtained from an AI file's XML metadata without the need to open it, IIRC). And you'll probably want to write a watchdog app that uses macOS's GUI Scripting APIs to monitor for dialogs and dismiss them automatically; or at worst kill and restart AI if it appears to have locked up for more than a certain amount of time. Plus another that automatically restarts AI after every 50 or 100 jobs.
I aspire to one day have the proficiency of hhas01. So far, I had only made a very basic test of a .php page executing a desktop script which ran an application, as an experiment. Yet the legal question has always interested me because on the forums as soon as someone mentioned autonomous application installs, there would be people who would come out and complain that it's illegal.
Since I knew this would be a very valuable technique to know and use potentially, I decided to call Adobe myself earlier this year to ask the question: how much is the server license for Illustrator? When I got passed around to the right person on the phone, he said that there is no such product offered for sale, so there can't be a price for it - however, if I was able to rig my own server install of Illustrator to suit my needs using a single-user default product, then it's not illegal and as far as he knows, completely allowed. I specifically mentioned "web to print" in my conversation, the implication being of customer orders coming in via internet at all times to be processed autonomously. I wish I had this statement in writing, or even got the guy's name - but all I asked at the time was how long he's worked there, and his answer was "one year".
The horribly worded clause 2.1.7 of the Illustrator CC license (which on macOS is in /Applications/Adobe Illustrator CC 2015/Legal), which I repost here verbatim with reckless regard to all copyright (because, seriously):
2.1.7 Server Use.
220.127.116.11 Except as otherwise permitted in the Documentation and subject to license restrictions stated in this agreement, Customer shall not install the Software on a Server. If permitted in such Documentation, then Customer may install the Software on a Server for the purpose of allowing an individual from a Computer within the same Internal Network (“Network User”) to access and use the Software. If expressly permitted by Adobe, “Internal Network” may include web hosting services with dedicated physical server space and restricted access to only Customer. The Network User who has access to or may use such Software on the Server is referred to as “Server Software User”. Neither the total number of Server Software Users (not the concurrent number of users) nor the total number of Computers capable of accessing the Software installed on the Server may exceed the Permitted Number. By way of example, if Customer has purchased 10 Software licenses (Permitted Number is 10) and Customer elects to install the Software on a Server, then Customer can only allow up to 10 Server Software Users access to the Software (even though Customer may have more than 10 Network Users or fewer than 10 concurrent users of the Software).
18.104.22.168 For clarification and without limitation, the foregoing does not permit Customer to install or access (either directly or through commands, data, or instructions) the Software: (a) from or to a Computer not part of Customer’s Internal Network; (b) for enabling web hosted workgroups or web hosted services available to the public; (c) by any individual or entity to use, download, copy, or otherwise benefit from the functionality of the Software unless licensed to do so by Adobe; (d) as a component of a system, workflow or service accessible by more than the Permitted Number of users; or (e) for operations not initiated by an individual user (e.g., automated server processing).
IOW, don't publish a customer-facing web interface for triggering Illustrator/Photoshop automation unless you've got Adobe's written legal permission to do so first. (For InDesign you install InDesign Server, but IDS is not appropriate for a lot of jobs.) Not sure why Adobe wouldn't want free money when it's being waved at them, but their toys, their pram. Though if you're just auto-printing files do you really need Illustrator? Speak to some repro folks to get advice.
(Also, aspire higher; I'm the laziest, slowest automator ever.;)
Yes, I did come across this some time ago - does this really mean that my php page running a .jsx script test would be a violation? It appears to be so - and it appears to contradict the Adobe sales rep I spoke to on the phone. Perhaps he didn't understand my mentioning the web-to-print points.
Or, is it? If the application is actually sitting on a user's workstation and is accessible by a local web application that in turn interacts with a customer-facing one, is that a loophole? I think that's what they guy was maybe saying to me. I probably should call them again.
So, I'd expect a 'polling' method which queries another application to be allowed - and probably possible via CEP extensions as well as local web applications just like my test (if it listened to changes somewhere to spur Illustrator to action).
For Web-to-print stuff, people use plugins like XMPie and software like PageFlex - stuff that first messes with files or creates files and then outputs them. I asked around and XMPie does have a special relationship with Adobe.
This topic makes me think of the religious people of Israel and their tenacity in abiding by the Sabbath - they probably would have this figured out.
Spoken advice from a sales rep doesn't change the EULA. If they will give it to you in writing that might form part of a defence but check what the EULA says about that.
I know of companies who have found themselves billed for each distinct web user (IP address) for single user software running a web site. Very expensive indeed. Above all, make it SOMEONE ELSE'S DECISION in your company so you aren't personally liable.
@TSN: Yep, plan for your liabilities, not your successes. Anything outwith the standard EULA needs your directors to write their directors stating exactly what you want to do, and don't move until you've a response that your lawyers confirm is legally sound.
@SillyV: Can your users supply their .ai files with PDF compatibility enabled (or as .pdf, of course), allowing you to handle them in a pure PDF workflow? Once you start editing their files, you're accepting responsibility for any errors you introduce. Again, get advice from repro experts before going forward; web-to-print is not a new or novel requirement, so you may be missing standard off-the-shelf solutions that already do everything that's actually required, and better protect your own butt too in the process.
hhas01: my curiosity regarding web-to-print is mostly rooted in the interest of my own interest in crafting my own solutions to cater to those market areas where off-the-shelf solutions are susceptible to competition. Among such would be very small businesses, etc.
The scenarios wouldn't be handling people's files but creating those files based off web input. There are many organizations right now which handle orders by email and passed-around instructions among employees, and few of them would have a need for the expensive giants such as Esko or Pageflex, or even the moderately-priced XMPie. What they would afford for their size would be custom solutions tailored just for them, using their Adobe applications along with some web services. How rewarding would it be for me to create an entire career from this demand! Doing regular task automation is already a fulfilling area of freelance work for myself, as I find interacting with the many workflows and personalities a fascinating experience.
But I digress; the point is that in my scope of interest, the term "web-to-print" would more accurately be defined as accepting internet data to be processed by Adobe apps, including automatic processing at all hours. An example is creation of files from customer orders entered at any time during the day, to populate a daily queue folder with PDFs of customer names to be output later with an engraving machine on some keychains. Pretty much the exact same usage as at one of my previous jobs using PageFlex, but minus the many other extraneous capabilities and the 80K price tag.
So I think I'm gonna try to call them up again and re-report back here with my findings.
The End User License does not allow for server-based use of Illustrator (or any Adobe Desktop application) unless you have specific approval from Adobe via an Enterprise Term License Agreement. InDesign Server is an application that is licensed separately and specifically for server-based use cases.
So, to answer the original question, you need to first secure permission from your Adobe Enterprise sales team. Once you have that permission, then you can build your front end using the advice above in this thread.
So if we set up a specific PC or Mac and install AI on this machine, that would be no server. If then we set up a script which will run over all .ai files in a specific folder, that would be no server either. If this script would be able to recognize for itself that there is at least one file in that folder, then runs itself and deletes (or moves) the finished .ai files out of that folder, we still don't have a server. If we share this (stil local) folder over the network, should this be called a "server"? Or is it just a hotfolder with a script attached to it?
How good are your lawyers? That’s doing the work of a server, and I think Adobe would argue that It breaches. Did you check the EULA wording?
Look especially but not only at the prohibitions on doing work for others. Server software has two big differences from end user software:
- technically made to keep running without a user interface, popping up messages on errors etc; typically command line or API.
- different licensing model to reflect that it is doing the work of other people who MIGHT OTHERWISE HAVE PAID: maybe per user or per use fees, or just 100 times the single user cost; whatever.
Working outside software EULA has led to retrospective bills, such as the standard cost for each human‘s Work processed, even if there were millions of them who used it only once...
Adobe are old hands at this. 20 years ago it occurred to people that instead of spending $500 for each user of Acrobat, you could have one machine that makes PDF for everyone. Today Adobe offer server PDF creation at per client negotiated pricing, probably 5-7 figures.
What I learned is basically that there must be a human activation. This would allow best-case scenarios of the following kind:
- A secretary cannot press a button and get a file generate back by some graphic designer's apps on another computer.
A secretary can press a button to send instruction to the graphic designer who can press a button that generates a file and sends it back to the secretary's computer.
- A graphic designer's Illustrator can't run all hours of the night and process web orders.
A graphic designer can come in the morning and press a button to process all web orders which were accumulated overnight.
- A secretary cannot press a button and get a file generate back by some graphic designer's apps on another computer.
Illustrator, and all Creative Cloud desktop products (with the exception of InDesign Server), are licensed to a specific user for their exclusive use. All actions in the program must be initiated by the licensed user sitting at the computer on which the software is installed. Scripts are fine, so long as the licensed user starts the script through a menu pick, keyboard input, mouse click, or indirectly through an action via keyboard or mouse click somewhere in the application user interface.
The license to use the software is to one person, a specific person. q3player your use case is outside of the EULA, as Test Screen Name indicates.
Sounds like the correct answer to me - at this time.
As for myself, to obtain this answer I had to make numerous calls and have numerous conversations, which got me exactly nowhere. One person would say to talk to b2b-sales phone line, and when I call it, they tell me they have no clue what I'm talking about and pass me around to some random number like tech support. They pass me back to another sales line.
Only by attending Adobe conferences and really pushing myself into this field, investigating and researching all the avenues, asking uncomfortable questions, have I gotten to where I pretty much abide by the 2 rules in my post above.
Of course the reason I'm always on this topic is because I have clients who want to do these things, I personally don't have any use for Ai server in my personal life. However, as people keep asking me about these things, I'm interested in showing them the best, legal options available to accomplish their tasks. Even if its too expensive, at least it would give them a figure to shoot for and to measure against their business growth so as to have a real plan for when my semi-auto processing won't cut it and they will need to invest in the proper tools.