Saving non-Anti-Aliased PNGs from Illustrator

[nanui10361275]

We have many EPS files which we want to process into very precise bitmap formats.

I have a square artboard (and man, was generating that automatically a scripting exercise far in advance of how complex it should be...) that I would like to export with no anti-aliasing.

Doing this via File-->Export-->Save For Web (Legacy) generates a correctly non-anti aliased bitmap provided that you set the anti-aliasing dropdown to "none".

Doing the same thing by seting pngExportOptions.antiAliasing to false, then calling doc.exportFile demonstrably produces an anti-aliased image.

You can waste more time by messing around with ExportOptionsTIFF in the misguided belief that it's "AntiAliasingMethod.None" might do the trick. It doesn't appear to do anything either.

There is, of course, an unanswered, 2 year old question about this as the top hit on google.

Side note, we have experimented for some time over the past years with using the "professional" tools photoshop and illustrator to handle our scripted bitmap and vector image processing, instead of using ghostscript, pyimage, imagemagick, etc, and I have to conclude that their scripting support is just a complete joke.

What am I missing, aside from the fact that I'm wasting my time trying to use a "professional" solution?

[nanui10361275]

I see you can also waste your time playing with doc.imageCapture() and ImageCaptureOptions, which will get you a non-antialiased PNG, but if you want to output, say, a 16384-sq PNG from a relatively small image, you'll exceed the supported resolutions. I'm sure I could rescale the image, but really, this has been an extended experiment in using an adobe-based pipeline for our images that I consider a failure.

[nanui10361275]

I tried using Photoshop instead, just for shits and giggles and because I thought shouting into a manhole was fun, and realized that since you can't explicitly specify final image dimensions on the PDFOpenOptions, you get some incorrectly sized images. E.g. attempting to open an image into a 16384-sq image resulted in 16381-sq image being generated in photoshop, eventhough I'm pretty sure I've calculated the resolution correctly based on the document's width (I open the document once up front to check that.)

I don't think using Adobe tools in an engineering workflow is a very good idea.

[Silly-V]

Okay we feel your pain, yes this seems to be quite an issue. The SFW dialog seems to not really persist with its options either, between AI sessions.

Anyway, but not all hope is lost! Using writing of dynamic actions, you can keep writing actions for Illustrator to use in its Actions panel, so that your SFW format that works for you may work!

Check this thread out for the description of the cumbersome-yet-necessary dynamic Actions workaround:

Creating a dynamic action to use with app.doScript() method.

[nanui10361275]

Hey, thanks for your reply. I actually found your dynamic actions work through further googling later in the day. It really is super cool and I congratulate you on a great bit of reverse engineering.

We could therefore do it in from within illustrator one of a couple of ways - either script resizing the art to a known size artboard then using a dynamic acton to export at known DPIs, or a single dynamic action modified with with a computed and inserted hex DPI based on the drawing's artboard.

But sadly, given that we don't use photoshop/illustrator in house, it's just not sane to use. We're all engineers, and we're going to use a pipeline based on tools that are engineering friendly. I'm too nervous that if we build further infrastructure on top of adobe's house of cards, they might change things (like the action export format) underneath us at any time. Plus, it'll only be a matter of time before we want to do some other algorithmic / mathematical transform to an image and discover that that doesn't work correctly either.

I am very impressed that Adobe have managed to make a data model and scripting architecture that makes Maya seem robust though.