Illustrator scripting bug list.

[Silly-V]

Hello dear friends, the time has come... to assemble a list of bugs we want to have eliminated.

I've come into contact with an engineer on LinkedIn and he has this to say in a private email exchange:

Me: "I have a variety of issues I can provide you with, including cases provided by other scripters around the world. Would you want to focus on any specific issue at first, or do you wish to get the entire catalog of reports?"

Him: "Entire catalog in a prioritized list will be great. I can then get into a conversation with developers with this doc. Also, anything you can do to help me explain why fixing something “non obvious” is important will also help me."

Okay, so let's put some list together to send him and hopefully it can start some ball rolling.
I think we should come up with a format to document each "situation" , as these bugs are not typical user bugs and are sometimes more elusive.

[Silly-V]

Don't everybody just jump in all at once now!

[CarlosCanto]

yeah, please one at the time, we don't want to crash the site.

[Silly-V]

MMkay let me start off. These issues are prevalent on Mac OS, but also may be present on Windows too.

1. PARM/MRAP errors relating to reading of spot color swatches in batch processes.
   • Work scenario:
     • A script which processes a folder of documents and reads each document's spot colors in the process.
   • The Error:
     • Some of the spot color objects are read in with "Invalid Object" and script cannot continue unless document is closed and re-opened. As more documents are processed, the chance of this occurring increases until the script cannot function at all.
   • Workaround:
     • Closing & re-opening a document using a try-catch statement. Inconvenient and slow, also not viable during large document sets.
2. PARM/MRAP errors relating to reading of pageItems in a document in a batch process or any singular script process.
   • Work scenario:
     • A script which processes a folder of documents and manipulates various pageItems in the document, or a script which does so on a single document.
   • The Error:
     • Some of the pageItems are read in with "Invalid Object" and cause the script to be aborted. User williamdowling reports that "nudging" the pageItems by changing their coordinates sometimes fixes this.
   • Workaround:
     • Closing & re-opening a document using a try-catch statement. Inconvenient and slow, also not viable during large document sets.
3. PARM/MRAP errors relating to reading of pathItems which have been created via createOutline from editable text.
   • Work scenario:
     • A batch or singular script which processes editable text to be converted into outlines and the resulting pathItems and compoundPathItems.
   • The Error:
     • Batch: Some of the pathItems are read in with "Invalid Object" and require document to be closed and re-opened. As more documents are processed, the chance of this occurring increases until the script cannot function at all.
     • Single: When a script is ran a single time, it will work, but the consequent time it crashes the application.
   • Workaround:
     • Adapt the script to duplicate every single pathItem created from editable text and remove original. Duplicated items now possess valid properties. Viable workaround, but should not have to use it.
4. Non-responsive application after a batch script.
   • Work scenario:
     • Any batch script which saves multiple documents or opens and saves multiple documents.
   • The Error:
     • Illustrator will remain unresponsive, sometimes showing spinning beachball for several minutes after a batch script is concluded. On my laptop this period is accompanied by an increase in the fan activity.
   • Workaround:
     • Wait or force-quit Illustrator if in a hurry. Very inconvenient.
5. ExportOptionsTIFF resolution bug.
   • Work scenario:
     • Any script which sets the resolution to export a TIFF.
   • The Error:
     • The resolution is always set by previous UI-entered resolution during a manual TIFF export. Script-set resolution seems to be ignored.
   • Workaround:
     • Saving the file 3 times previously with script-set resolution as it seems to use setting from 3rd previous save. Not confirmed to be reliable 100% and inconvenient.

Philosophical reasons to fix these although they are non-obvious to average users:

    Globalization has driven down the price of manufactured and decorated consumer goods, forcing those businesses to rely on automation to stay competitive and afford their costs. Often, a promotions/print/decoration business cannot stay in business due to low margins and high competition, if an extra employee is required. Rather than investing in extra employees to perform clerical graphic arts tasks, they are investing in automation to empower the existing experienced employees to output a high volume of files in a fast-paced environment. As these kinds of enterprises focus on promotional, print and apparel goods for licensed and corporate clients, using spot-color swatches and especially PANTONE color books is essential. When you have PARM errors which result during processes which deal with spot colors, their efficiency gains are negated and they are forced to spend more money in areas of low return until they are forced to go out of business. Therefore, it is very important to eliminate the errors which result from such basic processes such as manipulating art objects in documents or reading spot colors in documents.

Okay, that's what I got so far, please feel free to correct, enhance, append, etc.

[elDudereno]

Speed and Stability in batch processing of files. This is related to number 4 on your list somewhat. But I'm also experiencing a slowdown as it moves through files. Evidently Qwertyfly was not getting the same results I was on a PC, but on a Mac this is a serious issue.

• Work scenario:
  • Batch processing on a mac.
• The error:
  • Each file processes slower than the last (memory leak maybe?).
• Workaround
  • When possible using Illustrator 5.1.
  • When using executeMenuCommand or other scripting elements that aren't available in 5.1, limiting the number of files processed in one batch and restarting Illustrator between runs.

[Silly-V]

Oh duh, one more huge thing!

6. ESTK on Mac Yosemite

• Work scenario:
  • Simply using the ESTK on Mac Yosemite OS
• The error:
  • ESTK lags every few seconds, making typing code next to impossible.
• Workaround
  • Using another text editor to type up Extendscript, using ESTK only to launch or debug scripts.

[Disposition_Dev]

7. MRAP errors when creating/modifying layers. ESTK on Mac (i don't use PC so i don't know if it's an issue there as well)

• Work Scenario
  • Creating/renaming/modifying layers
• The error(s):
  • MRAP error when attempting to toggle visibility/locked status.
  • MRAP error when attempting to rename layer created by a script
  • Occasionally ESTK will return error "undefined is not an object" when attempting to rename a layer immediately after it was created
    • eg. var newLayer = layers.add();
    • newLayer.name = "The Layer";
    • //result is error "newLayer is undefined"
• The Workaround:
  • Retry running script several times.
    • This works ~20% of the time.
    • Result of retry can occasionally be changed by moving artwork on pasteboard, zooming in/out or deliberately moving quickly/slowly through prompt boxes..
      • WTF?!
  • Quit illustrator and re-open. Then retry.

[Qwertyfly___]

Most of my issues are with the stability of the engine. and the lack of meaningful error messages when errors occur.

(this one is hard as I can run the same script for days before it errors a hand full of times, then it might be good for a week before it happens again. with no consistency it makes it hard to know the what, why, how)

the next biggest issue for me is all the items that we Don't have access to via javascript.

ie.

Variable Width Strokes

Contents of Opacity masks

autofit area text toggle

But I think your trying to get existing bugs fixed, not so much what we want added, that sounds like a different thread.

I'll come back and post more as I come up against them so I can test and give the required detail

ScriptUI has some big ones that I can think of, but will need to play with them before I can provide useful information.

8. #target illustrator (does not point to latest version installed)

• Work Scenario
  • Use of "#target illustrator"
• The error(s):
  • opens old version of illustrator rather then the latest version, even if latest version is open and running
• The Workaround:
  • use #target illustrator-19 (targeting a particular version is great when required, but to have to do it means the script needs updating every time a new version is released)

[W_J_T]

This is a joke that this even has to be talked about, but given the total lack of effort by the developers over the years, not surprising. Most all of these "bugs" should have been dealt with years ago with direct involvement.

Qwertyfly... wrote: .... all the items that we Don't have access to via javascript.

Such a list could be extensive, given how lacking scripting support is in Illustrator, along with how few of features were added since scripting was implemented.

• Mouse Events: Down, Up, Move, Drag, Idle, Speed, Scroll, etc...
• Timers: ie: SetInterval, clearInterval, etc...
• Key Events: Press, Release, etc...
• Basic progress indicator when (non UI) scripts run, ability to abort scripts when running and proper garbage collection after
• Better support for Actions, shortcuts, inserted menu commands, etc.,
• Direct Access to load and use sub Libraries (Brushes, Swatches, etc., all)
• Complete access to Menu items and documentation of this feature (I think it would be nice if menus could be addressed via: (Menu/menuitem/subitem) or with corresponding documented numbers ie: 62)
• Create Pattern Swatch via script
• Improved performance with selections, currently the .selected property can be very slow
• HitTest
• Mesh Points
• Improved ScriptUI overall / GUI for making UI's?
  
• Better documentation overall and direct involvement with the community by the AI developers moving forward
• General optimization, better garbage collection during and after scripts execution, memory management and purging, etc.
• etc.,
• etc.,
• etc.,
• etc.,
• etc...
• Shall we go on?
  

So many glaring issues/omissions its hard to remember them all.

[W_J_T]

Speaking of BUGs, did I break this thread with my above post?

Regardless, I would be eager to hear of others ideas for things that are missing, need improved/expanded/fixed, various desired script related features, etc., all relating to AI scripting. Given the fact Silly-V is in contact with a mythical developer we might as well make a "wish"/hopes/dreams list, since the actual wishform (hilarious name) never works for much of anything.

Speak up folks, dream big people, heck you never know maybe someday the graph feature might even step out of 1993‌, or AI scripting support/features may actually improve.

[Silly-V]

Carlos talked to the same person a couple years ago, he mentioned, and nothing much came of it - but let's reach for the stars!

Oh and big edit, he's more like a manager who is in contact with developers, not even sure if they are in same building- but they for sure are in the same continent!   ..which is not western hemisphere.

[W_J_T]

Silly-V, You had me at "Hello" in your first post. But sadly I lost virtually all confidence in this ideal with your last post, that coupled with historical facts/truths regarding AI DOM scripting development, or more so the absence there of, version after version of AI. It seems less about actually making a concerted effort for change and more about saving face on social media. If they truly cared, they would have fixed bugs historically and came here directly for interaction on customer feedback and input and thusly would have had an actual dialog to make corrections/advances. Seemingly this thread is another subset of the all but famous Adobe "WISHFORM", where wishes, dreams and great ideas go to die. Sadly this information sounds destined to head up the same river without a paddle (unless you buy one via subscription), to never be seen or heard from again. I hope to be proven wrong, but history sure seems to prove otherwise.

[vasily_hall]

But, but.. he said they admittely dropped the ball on developer partner engagement and are keen on fixing it! Either way, it's good to have a single thread to serve as a quick reference for things which may give you problems
(as opposed to the rest of the forum where problems are inconveniently peppered with solutions)

[Qwertyfly___]

I say this list is a good idea.

even if it only serves as a reference for us.

[CarlosCanto]

+1

[W_J_T]

I never said it was a bad idea, I'm just not in any way optimistic it will yield anything by the developers (based upon previously stated).

CarlosCanto wrote:     +1

Start typing Carlos: all the things that you have seen, mentioned by yourself or others over the years that are missing regarding features and access via scripting. What is your list?

[Disposition_Dev]

I also wanted to add that just about ALL of the MRAP errors i get seem to be directly related to opening/closing a lot of files (or sometimes not even a lot..)

If i try to batch a folder using a script to open, manipulate, save, close, repeat... I will often get 2-3 files completed before an MRAP halts everything. However, as Silly-V‌ has pointed out in the past, simply opening a large number of files first, then looping through the open documents seems to run in a much more stable fashion, until of course, as silly has also pointed out, this then causes a period of unresponsiveness when the script is complete.

Many of the scripts that i used are not intended for batching a folder of files, but rather for making a lot of adjustments to one particular file based on input that I'm giving at the beginning of the script. So this requires me to open 2 files, copy artwork from one to another, run the script. save the destination file, close both files and repeat. I often only get through 4-5 files before MRAP's force me to quit and relaunch illustrator before i can continue.. but when I do the above method of opening many files at once, then batching the open files, i can get through many more before i get any errors.

I wasn't sure how to put that in the catalog format we've been using, but that's my experience thus far. Hope it's helpful.

[mickyhulse]

A few new things to add to the list, in regards to images in palette and dialog windows:

1. data URI support (i.e., embedded images)
2. Animated gif support

[Sturm359]

I don't know if this thread will actually have any impact, but I certainly hope it does, since I have a major scripting issue that I know for a fact is a bug. I'll post it below, but if there is a more "official" place in which to submit this bug, please let me know and I will do so immediately. Seeing as how the first two problems below are still problems after several months, I'm guessing that this thread is being ignored by the powers that be. Still, I'll give it a shot.

MRAP:

First, let me open by saying that I, too, have been having many MRAP errors in our scripts. We are on Macs running Yosemite currently, which fits with your theory, Silly-V. This has been an issue since Mavericks and maybe even Mountain Lion, I think, but it appears to be happening much more often now on Yosemite, and typically whenever the script is opening/processing a larger file or one with more complex artwork / many hundreds of paths. I have been attributing it to my relatively poor scripting skills--that "MRAP" meant some sort of memory leak in the scripts--but now I am not so sure.

ESTK Pause:

This is also happening to me, also running the Creative Cloud version (CC) on Yosemite. Very frustrating, indeed. If I were a less patient person, I would have gone through a dozen keyboards by now. Perhaps it is a very inefficient auto-backup feature?

NoColor fill reads as GrayColor 0:

Here's the one I'm currently having. I'll try to follow the same format that has been established earlier in this thread:

• Work Scenario:
  • Reading the fill color of a path that has no color (i.e., using "PathItem.fillColor").
• The Error:
  • The script returns "GrayColor".
  • Furthermore, when checking that "GrayColor"'s value (PathItem.fillColor.gray), it returns "0."
• Workaround:
  • No known workaround, to the best of my knowledge. Please feel free to suggest something.

The result of this is that whenever a path without a fill is being read, the script thinks that it has a fill of white. This can be easily replicated with the following steps:

1. Create a new document.
2. Using the pen tool, draw a closed polygon.
3. Make sure the polygon has no fill color. It should be empty. (Stroke color/existence does not matter.)
4. Write a small script in the ESTK as follows:

   1. var workDoc = app.activeDocument;
      $.writeln("Stroke Color: " + workDoc.pathItems[0].strokeColor.typename);
      $.writeln();
      $.writeln("Fill Color: " + workDoc.pathItems[0].fillColor.typename);
      if (workDoc.pathItems[0].fillColor.typename == "GrayColor") {
          $.writeln("Fill Color's Gray Value: " + workDoc.pathItems[0].fillColor.gray);
      }
      

5. Run it and observe the result.

And that's it. Thoughts/ideas/workarounds welcome.

[CarlosCanto]

for the Grey color issue, what would you take as acceptable workaround?

• The script returns "GrayColor".

what do you need instead of "GrayColor"?

[Sturm359]

CarlosCanto wrote:

for the Grey color issue, what would you take as acceptable workaround?

what do you need instead of "GrayColor"?

Since the polygon has absolutely no fill, I would prefer it return "NoColor."

If you try out the steps in my previous post to replicate the issue and remove any stroke (so it is also set to None), then you'll see that the PathItem.strokeColor.typename will return "NoColor."

A GrayColor of 0 is equivalent to White, which is not the same thing as having no fill color at all.

If this isn't a bug, then I don't know what is.

As for a workaround, I wish I could think of one. I need to be able to detect if a path that the script is looking at has no fill instead of telling me that it has a grayscale value of 0.

[Silly-V]

I think because of such things, you've got to use the .stroked and .filled properties too at that point.

[Sturm359]

Silly-V wrote:

I think because of such things, you've got to use the .stroked and .filled properties too at that point.

Much appreciated! I had completely forgotten about those two properties! Yes, I will adjust my scripts so that they will test for that first before the color and that creates a perfect workaround. Unfortunately, I cannot edit my earlier post now to put this in there as a workaround. Now if we can only get rid of these annoying "MRAP" and "ESTK Typing Pause" problems, then my scripting life would be whole again. ;~)

Thanks again!

[mickyhulse]

and "ESTK Typing Pause" problems

my workaround for that is to click the green link connection button. You'll be able to type faster but you will loose access to the apps documented api in the one palette (on phone, I forget name of this palette).

[Silly-V]

Man, actually this for me did not produce a marked improvement.. maybe it did for a little while, before things went back to molasses.