Illustrator batch action... slow and even slower after short time

[TimosPodroushnyack]

I have around 50.000 qr codes generated through zint, And I made an action witch changes the rgb to cmyk and to 100k black and after that saves them in different folder

the thing is... 1) because it is opening them normally with full preview... its kinda slow at this process (around 15 files per minute on ram disk, with 5kb files)

2) after while running this action in batch mode... computer starting lagging and the posses starts to slow down until illustrator or just stop executing the action, or run out of memory !?!

besides that, is there any way the action to run in ((background)) without showing the layout?

[TimosPodroushnyack]

1) because it is for printing

2) because the database and substructure what populates the qr codes files are set to eps

3) because sometimes at printing it creates white lines artifacts between the qr code boxes

4) A) because the background is mildly different on different pages and B) because the placeholder for qr codes have been already set with the clean size in mind

[Stephen_A_Marsh]

1) because it is for printing

Most modern separated press workflows can easily convert vector/text content that is 0r0g0b (rgb black) to 0c0m0y100k (cmyk black only), so unlike in years gone by one can safely leave these elements as RGB in the upstream workflow if one knows that the output will convert to 100K. For most digital print output, it may not matter if the input data is RGB.

2) because the database and substructure what populates the qr codes files are set to eps

So the input for creation of the QR code is EPS, I get that… However this does not necessarily mean that the software/process receiving the QR codes should need them to be in EPS. What if the next intermediate or final step in the process or workflow could use native .ai or .pdf files instead? EPS is generally considered a depreciated file format in this modern age (however it does still have some obscure uses/benefits).

Or do you mean that the next stage in the automated workflow requires EPS to incorporate the 50,000 QR codes into 50,000 separate jobs? What if the next stage could use other file formats, could there be a benefit to not using vector EPS?

3) because sometimes at printing it creates white lines artifacts between the qr code boxes

OK, that makes sense. For sake of argument, what if instead of using Illustrator you created a batch action in Photoshop that rasterized these files at final size at a high resolution and saved out a bitmap colour mode file (binary, very small file size). Could this run faster than the Illustrator batch action that slows down? Would the raster QR code be equivalent of the vector version for this specific use case?

4) A) because the background is mildly different on different pages and B) because the placeholder for qr codes have been already set with the clean size in mind

Bitmap (binary, 1-bit) mode raster files are usually treated with the white areas as transparent and the black areas as process black. Even if these were grayscale mode (256 gray levels) mode raster files, blending modes such as darken or multiply will treat the white as transparent. What software is making use of the QR codes in a layout? What is the final output method from the layout (print, export to PDF etc)?

The point of my questions and these replies is to hopefully show you that there are always options and that just because you think you may need to go down a certain path, there can be other valid ways to the same end result. Ideally the QR codes would be generated correctly in the first place.

[TimosPodroushnyack]

To leave it as RGB its really not an option, because it creates multiple problems, I work almost with 30 Print houses in different countries... and yes many of them have serious problem with RGB... besides that for many print houses I have specific export color convartion profiles what will interfere with rgb elements there for this is really not a solution

convert to bitmap its not a solution ether.. because on export it will be resized to the full standard of all the document witch will make many qr's blurry and besides that.. there is a version of the catalogs for online use where the images resolution will be even worse so the qr's will look horrible

to use other format than eps have some other implications... on already build up catalogs what need only updates on some things (adding and subtracting pages, elements etc), and there is not a real reason why to use other vector format than eps... since the qzint exports in eps in the first place, they are small and simple

for now I manually changed with batch text editor the qr codes to remove the white background and convert them to CMYK 100%K color... but it leaves me with un-merged paths

[Stephen_A_Marsh]

Thank you for the more detailed reply, now we are getting somewhere!

Hey, I’m glad that you could figure out how to edit the EPS code to remove the white background and convert the RGB to 100K only.

Now that you can simplify your action, does it run any faster?

Could working out how to do this via scripting improve the batch speed? As I said earlier, even if it takes 1 second to process a QR code, this is still at least 50,000 seconds, however it sounds as if you don’t have many options, some post processing is still going to be required.

[TimosPodroushnyack]

nop... (almost no) they are around 15% faster

[TimosPodroushnyack]

and I'm really don't know how to write a script for that

[Stephen_A_Marsh]

I don’t even know if the simplify command can be scripted! However you are in the right place.

[Silly-V]

Stephen - where did you get the need for "simplify" from?

Timos - I'd like to help with writing a script that does some very basic stuff - a friend will be visiting me tomorrow and I wanted to teach him some scripting, so I'm hoping to use this example.

My strategy would be to use two documents with the script. First document will be a placeholder where a placed EPS sits, which will be continually replaced by the next EPS. Using copy and paste, or the scripting duplicate command, the contents of the 2nd document will be replaced and pasted over to bring in the newly placed item from the 1st document. Then in the 2nd document (it will be used for processing and output), the embedding and path merging will occur. This document will then be saved with the file name as EPS, which hopefully will solve the issue.

[Stephen_A_Marsh]

Hi Vasily, from the original action posted by Timo:

The pathfinder and simplify steps are there to remove any possibility of white lines showing where the blocks touch (however it is really the pathfinder command that does this, simplify just removes most of the unnecessary points left over after the pathfinder. So the real question is, can the pathfinder operation be scripted? If not, stroking by a small value could perhaps fill in the gaps.

After:

Before:

[Silly-V]

The PathFinder can be scripted through a couple of ways - one is simply playing a recorded pathfinder action, and the other one is by using the app.executeMenuCommand() function to group and use the Live PathFinder effect of Add - and then using an expandStyle to produce the merged result. As for simplify, it can also be recorded into an action and played so that the recorded dialog inputs are all stored for all future playback. However, it could also be scripted relatively easy for these kinds of polygons where you pretty much expect all the points to match up either vertically or horizontally. The algorithm would be to detect if any point between 2 points is on the same x or y coordinate as the 2 surrounding ones, and then remove the middle point if so.

[TimosPodroushnyack]

any news?