No offence taken. Just my normal brusque self.   (I am a little annoyed at myself for spending far too long posting—I could’ve just about written the script! Alas, shiny distractions are…SQUIRREL!) ... View more

My approach is not so dissimilar to sttk3’s, except mine doesn’t care about knocking out the gaps: it is purely concerned with slicing the original continuous path into segments at the exact points where each visible dash begins and ends, then deleting all the gunk until only a single set of “dash paths” remain. OP made it clear these new paths must not deviate from the original dashes’ start/end/curvature in any way, so that’s the not-so-obvious bit I focused on solving. (This is not my first slice-n-dice rodeo. Took me 2mins to see the solution; far longer to write these posts!)   Since AI’s Outline Path and Pathfinder Subtract like to remove the original stroke attributes, OP might want to get the stroke color, width, caps, etc. values (but not dash properties as you want the new line solid) from the original path at the beginning and apply those values to the new paths at the end. Which is trivial to do [1] and any JSX scripter will know how to do it, so I didn’t detail it beyond those last 2 lines of pseudocode.   As I say, normally I’d just write the finished script, cost that work, and offer it straight to OP, but I’m already full with client work.  Speaking of which, I must get back. So adieu, and JSX folks here are welcome to try my solution and see how it compares to the rest.   (BTW, OP really needs to post Before and After examples showing how they want the artwork constructed at the vector level. That would help everyone here a lot.)   -- [1] Unless you’re talking about styles applied in the Appearances panel then, yes, you’re SOOL as none of that stuff is scriptable and it stomps all over the style properties that are. But if OP wants plain unadorned vector paths for a pen plotter/laser cutter to precisely follow, with perhaps a hairline stroke so humans can still see them, I’m not sure why they’d want to reapply AI brushes and other fancy visual stuff. ... View more

Converting a dashed path to perfectly accurate individual line segments should not be too hard to script:   1. Duplicate the dashed path, and turn off the duplicate’s stroke. 2. Outline the dashed path’s stroke. This gives you filled ‘rectangular’ boxes. (If the dashes use rounded caps, turn those off first.) 3. Select both 1 & 2 and apply Pathfinder Divide. 4. Delete the unstroked path that’s left over. 5. Iterate over each point in each path item, collecting their coordinates in a hash table (pseudocode):   discard = {} keep = [] for pathItem in pathItems: for point in pathItem.points: key = point.x+','+point.y if key in discard: keep.push(point) else: discard[key] = pointObject for pointObject in table.values: pointObject.delete() for point in keep: point.parent.stroke = originalStrokeWidth   Simple algorithm: it’s looking for all occurrences of two overlapping points, i.e. the points at which each box was sliced down the middle by the original path. One of those points it keeps and the other it later discards along with all non-overlapping points. Apply a solid, not dashed, stroke to the remaining paths, and you should be golden.   AI’s ExtendScript doesn’t have commands for outlining and expanding strokes, so you’ll have to select the paths and use:   app.executeMenuCommand("Live Outline Stroke") app.executeMenuCommand("expandStyle")   and:   app.executeMenuCommand("Live Pathfinder Divide") app.executeMenuCommand("expandStyle")    Touch-wood, everything works as described above (althought never underestimate the AI APIs’ ability to screw your day up for the lulz).   Normally I’d offer to send you a finished, tested, working script and bill you a day’s work. Today, I am in a benevolent mood and also completely slammed, so there you go—some self-assembly required. Assuming noone else thought of it first, if/when you get it working, pop $100 to msf.org as a charitable donation and we’ll call it square. Good luck. ... View more

Fontself allows you to create new fonts in AI. It does not support editing of existing fonts, so is not appropriate to OP’s needs.   As others have suggested, if this is a one-off edit being made in a particular artwork, the simplest solution is just to outline the text and adjust its path in AI. OTOH, if this font is being used (e.g.) in a customer’s branding, it makes sense to create a modified version of the original font file to be used across all of the customer’s artworks.   Purchasing a professional font authoring app just to tweak an existing font is probably overkill. I’d suggest OP first tries fontforge.org, which is free.   Also, when saving the modified font file, be sure to change its font family and PostScript names as well, e.g. “Royal Signage Customer Name” and “RoyalSignageCustomerName”, so it cannot be confused with the original. ... View more

In BBEdit, go to Preferences > Languages and add 2 entries to the Custom filename extension mappings:   jsx ➞ JavaScript jsxinc ➞ JavaScript   You might also consider using Visual Studio Code. Adobe provides an ExtendScript plugin that adds debugger support. ... View more

Thanks. It’s possible that somewhere deep in the Illustrator source code there is something like the following (pseudocode) speed optimization: if (new style != current style) { apply the new style } // else do nothing except instead of “current style” (i.e. the style that’s currently applied to the text) someone put “default style” (i.e. the [Normal Character Style]) instead. Although that’s just an educated guess based on observation, and I’m sure there are other possible bugs that could manifest this faulty behavior.   There are multiple ways in which text can be styled (Character palette, Paragraph palette, Character Styles, Paragraph Styles, Appearances, scripting API, plugin API; any others?) and that all these competing sources of style information have to be merged into one before it can be applied to the text itself. Complex code (especially when it’s progressively added to over the years by different hands; e.g. to implement Appearances) could easily introduce/hide subtle logic errors.   I will write a bug ticket over the weekend and post a link to that for future reference once it’s submitted. ... View more

I have made a small additional fix in the above script, changing part 3 to: // 3. if text ends up overflowing after last step, step it back down while (hasOverflow()) { style.size = size - step step *= 1.1 } I realized there’s a small possibility that a small change in font size could cause a dramatic change in text height, should the text grow just large enough to wrap onto an extra line on one of the last steps. This corrects for that, reducing it until the overflow goes away.   The script doesn’t seek a perfect fit, just “good enough”. (This is why the font size may change very very slightly if you run it then run it again on the same text.) However, it should never leave the text overflowing, it should run quickly, and it should never get stuck in an infinite loop. And while it does not include a workaround for the “12pt Myriad Pro Regular” bug (which we now know is an Illustrator bug relating to “Normal Character Style”), at worst it will leave the text smaller than it could be, not too large to fit. ... View more

If you have other test .ai files that show incorrect behavior with the [corrected] fit_text_to_frame.py script above, please DM me. It’s possible my code has additional bugs/omissions in addition to the two I already patched above, in which case I can run your files here and hopefully reproduce and diagnose the problem.   …   The 12pt Myriad Pro Regular problem I mention because that one appears to be a bug in AI’s scripting implementation. (That AI itself defaults to 12pt Myriad Pro Regular for newly created text frames might not be unrelated. At any rate it smells.) I wasn’t even aware of it until I happened to run the fitting script using a 6pt Myriad Pro Regular text frame as starting point. After which it took me a while to narrow down the exact cause, because the observed behavior defied immediate explanation. (It was only by performing each “resize” instruction one at a time and visually confirming the result, I noticed that on one very particular step, 6pt → 6pt×2, the text size wasn’t increasing as it should. After which I stripped down to the test cases above, confirming it wasn’t my bug. Had I not happened to use that particular font and a factor/multiple of 12 in one of my test .ai files, I’d still be searching now.)   This is looking to be a general problem in AI’s scripting API, e.g. the following also fails to work correctly on Myriad Pro Regular text: tell application "Adobe Illustrator" tell text frame 1 of document 1 set size of paragraph 1 to 4 -- works redraw delay 0.3 set size of paragraph 1 to 8 -- works redraw delay 0.3 set size of paragraph 1 to 12 -- fails redraw size of character 1 -- returns 8.0 but should be 12.0! end tell end tell   ... View more

I have run some general experiments and noticed a bizarre behavior in Illustrator (25.2.2, 25.3.1, 26.0.1):   Create a new document and add a text frame containing text set in 6pt Myriad Pro Regular. Then run the following script: var textFrame = app.activeDocument.textFrames[0] textFrame.textRange.characterAttributes.size = 12 alert(textFrame.textRange.characterAttributes.size) or: tell application "Adobe Illustrator" tell document 1 set (size of text range of text frame 1) to 12 get (size of text range of text frame 1) end tell end tell The text fails to change size and remains at 6pt. Manually set the text to, say, 17.5pt and run the script: it fails to change size again.   Try it with a different font style or family, it works. Modify the script to set it to 11.5pt or 14pt, it works.   Run the same test in Illustrator 16.0.0 (CS6), it works.   If others would like to test and confirm, I would appreciate it. ... View more

Apologies, yes. That’s a bug in my math. Immediately beneath:   // 2. now do binary search for the largest size that will just fit the text frame   change:   var step = size    to:   var step = size / 2.0     and after:   // 3. if text ends up overflowing after last step, step it back down   change:   if (hasOverflow()) { style.size = size - step }   to:   if (hasOverflow()) { style.size = size - step * 2 }   I think that should be it now. (Sorry, long week.) ... View more

The above script does not care how many lines of text there are, only that they all fit into the text frame. If the text frame is tall enough to accommodate a single short line of large text, and the text frame is set to use auto-leading, it may be that as a longer piece of text is reduced in size it flows onto a second line. If OP wants to avoid that wraparound, the simplest solution would be to set the leading to a fixed value that is greater than the height of the text frame.   The kiwi automation engine I built a few years back has a load of options for fitting text and other content (example of capabilities here: [www.youtube.com/watch?v=a8LgiIMpI9s]). The above algorithm is similar to the one used in its `scale text to fit` rule, which has proved reliable, so I’m fairly confident it’ll work without issue. (I’m currently planning a new, cross-platform kiwi system, although whether that ends up being written in JavaScript or something else I’ve yet to decide.)   I’ll also update the older `fit_frame_to_text.jsx` script later on, as I noticed a couple minor bugs in it while writing this one. ... View more

OP’s request was clear enough: they want the text within a text frame to resize so that it fits into that frame without overflowing. What’s lacking is sufficient detail to provide a production-ready solution, e.g.:   Is all the text guaranteed to be the same size or can it be a mix of sizes? Should it step down by fixed amounts (1pt decrements? 5% of the initial size?) or to whatever exactly fits the frame? Are there any particular requirements regarding leading, or can we safely assume it is Auto? Is there a legal minimum size below which text must never go? Should it also increase to fill up excess space or decrease only? Does it need to support linked text frames? Does it need the ability to resize several text frames each by the same amount until none of them overflow? Does it need to be a live effect (expensive!) or is a script that they manually run sufficient?   As we’ve both said, if OP can post some sample files it will give us a better idea of what the job entails. If OP’s requirements are minimal, it’s a 5-minute modification to the free fitting script I linked to above, which someone here might do for free if OP can’t code. If it’s more involved, the development work can be budgeted and a proposal put forward. ... View more

Oops: minor brain fart on my part: the script that I linked fits frame to text, not text to frame as OP wants, so it would require some adaptation to perofrm the latter.   The simplest implementation is to detect if there is an overflow, and if there is then iterate across all the characters, reducing them by a fixed amount each time (step size); repeating until the overflow goes away. Can be very slow if the step size is small, but it does the job.   A slightly more sophisticated option is to use a binary search algorithm: i.e. if the text is overflowing then reduce the font size by 50% of its original size, then reduce or increase the font size by 25% of its original size depending on whether there is or isn’t an overflow; and repeat that process, halving the step size each time until it falls below some minimum percentage (e.g. <4%) or point size (e.g. 1pt), then check for an overflow and reduce it one last time if needed. Good for giving you an exact fit if that’s what you want, and quicker on average than the linear reduction algorithm since the number of steps it performs is constant (or near as).   I’ve written such fitting routines before—they’re a bit kludgy, but doable via AI’s existing scripting APIs. (I’m sure fitting text could be done quicker and more elegantly in a C++ plugin, but that’s a LOT more work to develop.) If OP would like such a script knocked together, they are welcome to DM me with their requirements. ... View more

It sounds like you want to automate the following manual process:   1. Choose Select > All  2. Choose Object > Compound Path > Make 3. Set the new object’s fill in the Colors palette.   That is something you may be able to automate just by recording those GUI actions in the Actions palette as you perform them manually on one artwork, then replay those recorded actions on all the rest.   If you prefer a scripted solution, here is a simple JavaScript to convert a set of overlapping black and white paths to a single compound (knockout) path and recolor it:   var doc = app.activeDocument // the layer containing the original artwork var layer = doc.layers[0] // create a new compound path var compoundPath = layer.compoundPathItems.add() compoundPath.artworkKnockout = KnockoutState.ENABLED // for simplicity, we'll assume the original artwork contains ungrouped simple paths only // dealing with text, compound paths, groups, etc is left as an exercise // move all paths into new compound path, preserving their order while (layer.pathItems.length > 0) { var item = layer.pathItems[layer.pathItems.length-1] // we'll also assume that all paths are filled CMYK black or CMYK white, and unstroked var isWhite = item.fillColor.black < 50 // move this path into the compoundPath item.move(compoundPath, ElementPlacement.INSIDE) // set it to appear solid/transparent according to its color item.artworkKnockout = KnockoutState.ENABLED item.polarity = isWhite ? PolarityValues.POSITIVE : PolarityValues.NEGATIVE } // define your rich black colors here (0 to 100 percent) var richBlack = new CMYKColor() richBlack.black = 100 richBlack.cyan = 60 richBlack.magenta = 40 richBlack.yellow = 40 // set the color of the compound path (this is counterintuitive but works) compoundPath.pathItems[0].fillColor = richBlack   Save that as (e.g.) “Knockout to Rich Black.jsx” then run it from File > Scripts > Other Script. (You can also put the .jsx file into AI’s Scripts folder to make it permanently appear in that menu.)   To keep the code simple I have assumed that each artwork file has a single layer containing only CMYK black and CMYK white filled paths stacked one atop another. This may or may not be sufficient depending on how your original artworks were built; e.g. if your artworks can contain a mixture of simple paths, compound paths, text frames, etc, or you have multiple logos per file, then extra code will be needed to handle those correctly. (If you need additional work done, you are welcome to DM me.) ... View more

Sure, but presumably OP has a reason for doing it anyway. (e.g. Multi-language packaging, where text density can vary greatly within a single line depending on whether each localized artwork has to hold 1, 2, or 3 languages. Yes, the resulting artworks may look awful from a design perspective. No, there’s nothing you can do as an artwork grunt as that’s what the customer requires.)   As for legal requirements, it’s simple enough to define a minimum font size below which the script will not go. One of the advantages of automated artwork production is that you encode all your brand guidelines, legal requirements, etc within the automation, ensuring consistency and conformance across all artworks.   If OP wishes to discuss details they are welcome to post additional information and some examples of the artworks they’re producing. ... View more

“Auto Size” dynamically resizes the text frame to fit the text, which is the opposite to what OP wants.   AFAIK there is no way to dynamically resize text to fit an area text frame. You can wrap a single line of point text inside a Mesh Envelope, which causes the text to scale horizontally to fit the mesh’s boundaries, but I suspect that’s not what OP wants.   OP could search existing third-party AI plugins to see if there is one that implements a custom text frame that offers this auto-fitting behavior. (Plugins have the advantage that they hook directly into AI’s low-level C++ APIs, which expose additional functionality not found in its scripting APIs.) Or they could hire a plugin developer to write one (although that won’t be cheap):   community.adobe.com/t5/illustrator/ct-p/ct-illustrator?page=1&sort=latest_replies&tabid=all&topics=label-thirdpartyplugins   If OP is willing to compromise on fully automatic behavior [1], it is certainly possible to resize text to fit by manually running a script, e.g.:   community.adobe.com/t5/illustrator-discussions/fit-frame-to-text-free-script/m-p/8715230   It’s a bit of a pain to script this as AI’s text frame objects, unlike ID’s, do not provide a convenient script-accessible “overflows” property, necessitating some creative kludging to detect overflowing text. So caveat emptor on that, although it seems to work well enough IME. (Detecting underflows is left as an exercise.)   --   [1] Ideally, AI would allow OP to attach the above script to the document’s text frames, so that the script runs automatically after a text frame has been edited. In theory, one could create a C++ plugin to provide this general-purpose “attachability” to scripters. This would be amazingly powerful. Alas, AI’s low-level C++ plugins have absolutely rotten integration with AI’s high-level scripting interface; thus wrapping a text frame in a custom plugin makes that text frame all but invisible to scripts. (This is a problem space I am currently spelunking w.r.t. text frames wrapped in AI’s own Envelopes plugin, and it is a royal PITA.) ... View more

Sounds like you could do this using Illustrator’s built-in variable data support. Search online for “Illustrator variable data” to find tutorials, etc. That would be easiest.   If you really want to do it via scripting, give each text frame a unique name in the Layers palette; e.g. {product name}, {strapline}. You can now replace the text like this: var doc = app.activeDocument doc.textFrames.getByName('{product name}').contents = "New\nTitle" doc.textFrames.getByName('{strapline}').contents = "Some\nMore\nText"   Getting the new text into the script (via dialog/CSV file/web service/whatever) is left as an exercise. You say you want anyone to be able to use this. If you wish to create a custom AI panel into which users can type their new text, you will also need to learn CEP (github.com/Adobe-CEP/Getting-Started-guides). If you’re thinking about hosting Illustrator on a web server, make sure you read Adobe’s licensing terms first. (You can only run AI on a private server on your company’s intranet, and only users who already have an AI license may use that service. For anything more, you need to use InDesign Server instead.) ... View more

It will help readers understand your requirements if you can post before and after screenshots of a few example logos.   (If you can’t post the actual logos for copyright/confidentiality reasons, some representative mockups will do.) ... View more

Photoshop is not the appropriate tool for layout work. Use InDesign.   Make up a “template” document containing 2 pages, with 4 image frames on each. Position a label image in each frame to serve as a placeholder, cropping out the part of the image you don’t need.   Once you’ve prepared that template, if you want a simple script to relink those placeholder images to four real images and export the document to PDF, I’m sure the InDesign forum can help you with that. ... View more

Have you taken the advice given on the Photoshop group, and looked into third-party PDF imposition software? While it’s possible you’ll find someone willing to create you a layout script for free (BTW, InDesign is the appropriate tool, not PS/AI), if you have to pay for a bespoke solution then an off-the-shelf app will be cheaper. ... View more

It has nothing to do with nested loops. (If you know Big-O notation, you’ll know when nested loops are/aren’t a performance concern.)   It has to do with OP’s pathological string-building algorithm, where the script starts with an empty string, appends a string to it, then appends another string, and repeats this process (e.g.) 1,000,000 times. OP appends one character each time using the “+” operator, so the first iteration has to copy a 0-character string plus a 1-character string into a newly created 1-character string, the second iteration has to recopy that new 1-character string plus another 1-character string into a newly created 2-character string, the third iteration that 2-character string plus a 1-character string into a new 3-character string, and so on, all the way until the 1,000,000th iteration, where it has to copy the previous 999,999-character string plus a 1-character string into a new one-million-character string. Which, if my math is correct, is a grand total of 500,000,500,000 characters copied.   And all except the very last one of those strings was only ever used once and immediately thrown away.   An optimizing interpreter/compiler (or an insightful programmer) observes that this is all massively wasteful, and knows it can eliminate most/all of that waste just by allocating a really large (e.g. 10 million character) section of empty memory right at the start of the process, which it can then gradually fill up by adding to the end of it. That way, the only strings being copied are the strings being appended, which in OP’s artificial example was a single-character string, thus equalling a grand total of one million characters copied instead of 500 trillion.   p.s. OP might also like to add TheDailyWTF.com to their regular reading list, wherein they can laugh at all the so-called “professional” programmers who don’t understand Computer Science either. (e.g. Try searching it for “StringBuilder” for stories that are particularly relevant here, albeit in other languages as JS doesn’t have one of those.) ... View more

For the third time, the difference in performance has nothing to do with the loop. It has to do with the code that you’ve written within your loop, which is an infamous pathological algorithm that causes massive amounts of [redundant] low-level memory copying when run in a non-optimizing interpreter/compiler. The quickest way to improve performance is to replace that very inefficient algorithm with a more efficient one. Which an optimizing JS interpreter does for you automatically; otherwise you have to sort it yourself.   It’s clear you don’t know enough Computer Science to understand why your algorithm bogs down so badly (you’re a power user, not a career software developer with a university education in CS, so it’s entirely reasonable for you not to know this stuff), and the sample code you posted is a contrived example, not a real production script with representative data to test against, so it really isn’t possible for anyone here to advise you on appropriate code changes to make.   Yes, it’d be wonderful if Adobe had a modern JS engine in all their apps, and had kept it up to date over the last 20 years. They are slowly working to address that by introducing UXP (the successor to ExtendScript + CEP), first to XD and currently to PS. Don’t be surprised if AI gets UXP last though; and don’t be surprised if it takes several more years to complete the transition: what may seem simple and obvious to you as the user is no doubt heinously complicated and time-consuming to the software engineers who have to implement it. Remember too: Adobe puts its money in developing the popular features that will sell the most products to the most users. Yes, all professional artworkers really ought to learn some automation skills: it can pay terrific dividends by reducing/eliminating repetitive scut work in the long term. But if a majority of Adobe users don’t choose to learn/use automation then you can’t blame Adobe for pushing new automation features down the priority list. So if you don’t mind waiting a few more years, eventually AI will have a nice modern optimizing interpreter to run your amazingly inefficient JS code amazingly efficiently. But right now you’re just howling in the wind complaining about it.   For now, either 1. go learn yourself enough CS to profile and optimize your code for yourself, or 2. pay someone with more extensive programming experience to develop part or all of your automation for you, and let them worry about making it go fast enough to satisfy your customer’s needs (whether by employing more efficient algorithms in the JS script, or by using a lower-level language such as C that provides professional programmers with lower overheads and precise control over how memory and other resources are managed). ... View more

Once more: you are comparing chalk with cheese. There is absolutely no reason to suppose a 20 year-old JavaScript interpreter will perform as well as a modern JavaScript interpreter that by now has had 20 years and probably a million-plus man-hours invested in making it go faster.   In any case, you are really measuring the wrong thing. If you want meaningful information, you should compare how the same interpreter performs for different amounts of data. For example, Illustrator’s 20yo JavaScript engine:     function test(samples) { var res = ["RESULTS:"] var n = 1000 while (samples > 0) { var t1 = Date.now() var s = "" for (var i = 0; i < n; i++) { s += "a" } var t2 = Date.now() res.push(s.length+"a = "+(t2-t1)+"ms") n *= 10 samples-- } alert(res.join("\n")) } var samples = 4 test(samples) /* RESULTS: 1000a = 0ms 10000a = 8ms 100000a = 682ms 1000000a = 109171ms */    (I only ran 4 samples there; I doubt a 5th would ever finish.) Compare a modern Node.js:   #!/usr/bin/env node function alert(s) { console.log(s) } function test(samples) { ... // same as above } var samples = 5 test(samples) /* RESULTS: 1000a = 0ms 10000a = 2ms 100000a = 17ms 1000000a = 173ms 10000000a = 1431ms */   (I was able to get a 5th sample under Node, though even it crashed with a memory error when I attempted 6.)   If you can’t already see the key difference between those two sets of numbers then go plot them both on paper. It is the shapes of those graphs which is significant. With the old JS engine, the time to complete the task increases quadratically (i.e. it rapidly flies through the roof). With a new JS engine, it increases remarkably linearly—no small achievement on such a pathological piece of code. What’s important is not measuring a script’s raw speed, but measuring its algorithmic efficiency. Inefficient algorithms will make even the fastest of computers run like a slug when fed a non-trivial volume of data to process. The modern interpreter appears to recognize the inefficient algorithm being used by your JS code and is optimizing under the hood the way in which it evaluates it to radically improve its performance. Whereas the old interpreter is a simple naive implementation that evaluates the inefficient JS code exactly as it’s written. (As I noted previously, the modern optimizing interpreter is most likely reducing the number of low-level memory allocations and memory copies it needs to perform to hold these growing strings.) …   If you really want to understand this stuff, go read up on Big-O notation and how different algorithms can have radically different performance profiles while performing the same job. As an automator though, all of this deep Computer Science stuff may be moot anyway, as your most important question should not be: “How fast does my script complete the job?”, but “Does my script complete the job significantly faster (and more accurately) than doing the same job by hand?”   If your script takes 5 minutes to run but replaces a error-prone manual process that previously took half an hour, who cares if it’s not running on the newest, most optimized JavaScript engine? Go make a cup of tea while you’re waiting for your computer to finish if you’re bored. Or, if it’s performng an daily production task, you should easily afford a second machine to run the script just from the salary hours per year it now saves you alone. And if your script does take half an hour to run, then either it’s doing a helluva lot of valuable production work or you’ve got a horribly inefficient algorithm running somewhere in it; in which case you need to performance-profile your code under different levels of load to pinpoint where its critical inefficiencies lie. My first major script took over 10 minutes to run a standard job; the update that replaced it a year later, less than 1 minute. Not because the computer got any faster, but because I spent the year inbetween learning about speed vs efficiency, common CS algorithms, Big-O notation, and so on. (Funnily enough, its #1 performance problem was caused by the same naive string concatenation algorithm you’re demonstrating here. I changed the way in which it assembled long strings as it ran, and it flew.) My advice: if you’re teaching yourself, start by going through a high school Computer Science textbook. Once you’ve grasped the basics, get yourself a copy of Steve McConnell’s Code Complete which you can pick up and read individual chapters if/as/when needed. Oh, and remember to factor in all the extra time you’ve spent learning CS when assessing your final cost-vs-benefit ROI. ’Cos it’s a rabbit-hole.:) Just like algorithms themselves, making code go fast tends to be slower, harder, and more complicated (and error-prone) than making code which goes slow but gets the job done. A good programmer doesn’t write code that is fast for fast’s sake, but code that is fast enough.   ... View more

That’s faster because it’s only doing a fraction of the work: the inner loop runs only once, the first time the outer loop runs, after which the inner loop doesn’t run again. I believe what you meant is:   while (i < cDauer) { var j = 0; while (j < cDauer) { vText = vText + "a"; vLength = vText.length; j++; } i++; }  That resets the j counter each time the outer loop repeats, same as in your first script. ... View more

I doubt it has anything to do with the loop itself, and everything to do with the general performance of different JavaScript interpreters.  Recent versions of Illustrator use an ancient (20 year old) JS interpreter.  Recent versions of QXP probably use a modern JS interpreter. Comparing JS interpreters of different vintages by different vendors is a fairly pointless exercise. The last 20 years have seen massive investments by JS vendors to improve their interpreters’ performance, so we’d naturally expect newer JS engines to be faster at running the same script.   As a separate point, the algorithm in your script is well known to be pathological in a naive (non-optimizing) interpreter: repeatedly allocating memory to hold a given string, then allocating a larger chunk of memory to hold both that string and the string being appended to it, then copying both of those strings to the new memory, and finally releasing the previous memory when it’s no longer needed. The longer the concatenated string grows, the more memory needs to be copied each time, and the longer the script takes to do its work.   (BTW, an optimizing interpreter might recognize this repeating pattern, assign more than enough memory to hold the initial string with plenty of room to spare, then copy the concatenated strings to the extra space at the end of end of that; thus reducing the amount of memory copying done for the same amount of work. I’ve no idea if any JS interpreters do this: you’d have to ask the people who write them.)   At any rate, the simplest way to improve performance is not to append to a string within the loop, but to append to an array and join that array once the loop is done. That reduces the amount of memory copying so your script runs faster:     var tempArray = []; for (var j = 0; j < cDauer; j++) { tempArray.push("a"); } var vText = tempArray.join(""); var vLength = vText.length;     ... View more

Could be. Best if OP can supply real before and after examples as screenshots and/or attachments. Re. thin lines appearing between images, that might be because there’s an actual gap between the elements in the artwork, or it could just be a display artefact of the PDF viewer. If the latter, I would suggest making the images fractionally larger than the grid they’re laid out on, so that their edges just very slightly overlap. ... View more

You’re right that snap-to-grid isn’t a feature accessible to scripting but I’m guessing OP just wants to position items precisely, which is trivial to do.   It would be helpful if OP could post screenshots of example artwork before and after, to clarify their original description. ... View more