July 1, 2013 at 12:10Lazy prepress
- From the sandbox
- Tutorial
This article is a kind of repost of my own article, published on another (low-visited) site. Why am I posting the article here? There are a lot of prepressors hanging out on this site, and I want to help them in the breadth of my soul. Bezd-woz-mezd-but! that is, for nothing. (c)
I want to immediately make a reservation - I do not know how to teach. Well, it’s simply not possible from nature to oratory so that others will not just be inspired by the idea, but also understand any of the above.
This article (and I hope the subsequent ones too) is aimed primarily for people preparing layouts for printing flexographic productions. Accordingly, the main idea of the scripts will be connected and “adjusted” to the conditions of flexographic printing.
The program Adobe Illustrator is not only a visual environment for the artistic development of layouts, but also
It has in its arsenal a relatively good scripting language engine that allows you to run third-party scripts for various actions with the document and objects. This engine supports such scripting languages as: JavaScript, VisualBasic Script, AppleScript (the latter, as the name implies, is a possible brainchild of the Apple Corporation).
I want to dwell on scripts in the JavaScript environment, as this is the only language that I know relatively well.
I do not plan to go into the details of JavaScrtipt, if it is interesting, study it with examples of web programming. The basis is
similar, only the difference in objects and the structure of the tree of objects. And we will start with this structure.
The structure of the document can be represented (in simplified form) as follows:
Based on this representation of the document structure, it is possible to construct a logical chain of access to a specific object. Something like this: Active Document . Mounting Area_№xxx (if there are more than 1) . Layer No. xxx (If there are more than 1 of them and you need an object on a specific layer). Object
In principle, everything is logical. Some points in this logical construction can be omitted. For example, you want to process an ALL array of existing objects, without specifying artboards and / or layers. In this case, the upgraded logical chain will look like this: ActiveDocument . Object [No.xxx]
The option of constructing logical query chains varies from a specific goal.
Now let's look at how many and what all the same objects are present in an open document and how this knowledge can be obtained programmatically.
Again, relying on a logical chain, you can write a query like: variable = ActiveDocument . Objects . Quantity .
In JS, it will look like this:
Is everything simple? Quite! We move on.
Before continuing, I would like to draw attention to the list of objects that we can modify (by no means a complete list):
Alas, unfortunately, the creators of Illustrator developed a rather weak scripting language engine. This imposes a number (and considerable) restrictions on our actions. With each of the above objects it will be possible to make a very small amount of changes. Much less than you can afford in a graphical environment.
So does it really make sense to write scripts if their capabilities are so limited? Of course it does. If only because manually processing several thousand objects is not only monotonous, but also rather stupid work. And we are smart people, and even lazy. And they pay us for the result, in no way paying attention to how exactly we achieved this result and what it cost us.
And what can we do now that we have the number of objects in the document? For example, repaint!
Before repainting objects (it doesn’t matter which ones, textual or complex, primitives or strokes of objects), it is necessary to understand the color structure of this object.
And the structure is quite simple (in fact, everything is simple, if you understand the logic of the authors):
Object . Fill .TsvetovoyKanal ,
where object - in fact he is currently being processed object;
Fill - the type of fill (possible options: homogeneous, gradient, SPOT, SPOT-gradient, Mesh);
Color channel- depends on the color space and type of fill; has options - Cyan, Magenta, Yellow, Black (CMYK); Red, Green, Blue (RGB); Tint (Spot, Grayscale);
Thus, filling the object with color in the JS environment looks as follows:
If we consider setting the color of the stroke of the object, then the record will be of the following plan:
those. the difference in setting the fill color (solid) and the stroke is only in the indication of the type of fill: fillColor or strokeColor .
But can we, after all, indicate not a uniform fill for an object, but a gradient one? Of course we can. To do this, we need to understand what a gradient fill is from the point of view of the script.
Gradient fill is a set of key points on a straight line from the beginning of the fill (one edge) to the end of the fill (the opposite edge of the fill), which has its own colors. Those. the black-to-white fill will look something like this:
Point1 [color array of the form 0,0,0,100] ... Point2 [color array of the form 0,0,0,0]
in JS:
The first line indicates 100% black for 1 key point of the object, the second line indicates 0% black for the second point (end, in this case).
But, as you know, the number of key points in the gradient fill is ALWAYS at least 2, but it happens much more.
In this case, recalling the school course in computer science (or the university course, if more convenient), we need to write a cycle that processes ALL the key points in our gradient fill.
We write such a block:
It’s quite simple, in addition, to understand the logic of the developers at ADOBE Corporation, who have so “deeply” stuck the properties of access to key fill points. At one time, I spent a lot of effort to get to these color changing options.
Let's summarize everything that we have learned so far:
Two new commands met in this module - checking the fill type.
If the object is graphic (not text blocks) and at the same time it has a gradient fill, then we process each key fill point.
If the object is graphic (not text blocks) and at the same time it has a monophonic fill - paint over the object in black.
At the current moment, perhaps I will stop. If the article receives feedback on the continuation, we will continue, of course.
I want to immediately make a reservation - I do not know how to teach. Well, it’s simply not possible from nature to oratory so that others will not just be inspired by the idea, but also understand any of the above.
This article (and I hope the subsequent ones too) is aimed primarily for people preparing layouts for printing flexographic productions. Accordingly, the main idea of the scripts will be connected and “adjusted” to the conditions of flexographic printing.
The program Adobe Illustrator is not only a visual environment for the artistic development of layouts, but also
It has in its arsenal a relatively good scripting language engine that allows you to run third-party scripts for various actions with the document and objects. This engine supports such scripting languages as: JavaScript, VisualBasic Script, AppleScript (the latter, as the name implies, is a possible brainchild of the Apple Corporation).
I want to dwell on scripts in the JavaScript environment, as this is the only language that I know relatively well.
I do not plan to go into the details of JavaScrtipt, if it is interesting, study it with examples of web programming. The basis is
similar, only the difference in objects and the structure of the tree of objects. And we will start with this structure.
The structure of the document can be represented (in simplified form) as follows:
- Document
- Artboard
- Layers
- Group of objects
- Objects (primitives or compound, text blocks, etc.)
Based on this representation of the document structure, it is possible to construct a logical chain of access to a specific object. Something like this: Active Document . Mounting Area_№xxx (if there are more than 1) . Layer No. xxx (If there are more than 1 of them and you need an object on a specific layer). Object
In principle, everything is logical. Some points in this logical construction can be omitted. For example, you want to process an ALL array of existing objects, without specifying artboards and / or layers. In this case, the upgraded logical chain will look like this: ActiveDocument . Object [No.xxx]
The option of constructing logical query chains varies from a specific goal.
Now let's look at how many and what all the same objects are present in an open document and how this knowledge can be obtained programmatically.
Again, relying on a logical chain, you can write a query like: variable = ActiveDocument . Objects . Quantity .
In JS, it will look like this:
var docRef = app.activeDocument;
var docRefAll = docRef.pageItems.length; //выясняем количество объектов в активном документе
Is everything simple? Quite! We move on.
Before continuing, I would like to draw attention to the list of objects that we can modify (by no means a complete list):
- Text objects
- graphic primitives;
- compound objects
- assembly areas;
- layers.
Alas, unfortunately, the creators of Illustrator developed a rather weak scripting language engine. This imposes a number (and considerable) restrictions on our actions. With each of the above objects it will be possible to make a very small amount of changes. Much less than you can afford in a graphical environment.
So does it really make sense to write scripts if their capabilities are so limited? Of course it does. If only because manually processing several thousand objects is not only monotonous, but also rather stupid work. And we are smart people, and even lazy. And they pay us for the result, in no way paying attention to how exactly we achieved this result and what it cost us.
And what can we do now that we have the number of objects in the document? For example, repaint!
Before repainting objects (it doesn’t matter which ones, textual or complex, primitives or strokes of objects), it is necessary to understand the color structure of this object.
And the structure is quite simple (in fact, everything is simple, if you understand the logic of the authors):
Object . Fill .TsvetovoyKanal ,
where object - in fact he is currently being processed object;
Fill - the type of fill (possible options: homogeneous, gradient, SPOT, SPOT-gradient, Mesh);
Color channel- depends on the color space and type of fill; has options - Cyan, Magenta, Yellow, Black (CMYK); Red, Green, Blue (RGB); Tint (Spot, Grayscale);
Thus, filling the object with color in the JS environment looks as follows:
docRef.pageItems[0].fillColor.cyan = 0…100; //(для голубого канала цвета объекта №0 (нумерация идет с 0, т.е. объект №0 — самый первый, самый «верхний» объект в документе)
docRef.pageItems[0].fillColor.red = 0…255; //(красный канал в схеме RGB)
docRef.pageItems[0].fillColor.tint = 0…100; //(процент заливки SPOT-цветом или процент заливки черным из схемы Grayscale)
If we consider setting the color of the stroke of the object, then the record will be of the following plan:
docRef.pageItems[0].strokeColor.cyan = 0…100;
those. the difference in setting the fill color (solid) and the stroke is only in the indication of the type of fill: fillColor or strokeColor .
But can we, after all, indicate not a uniform fill for an object, but a gradient one? Of course we can. To do this, we need to understand what a gradient fill is from the point of view of the script.
Gradient fill is a set of key points on a straight line from the beginning of the fill (one edge) to the end of the fill (the opposite edge of the fill), which has its own colors. Those. the black-to-white fill will look something like this:
Point1 [color array of the form 0,0,0,100] ... Point2 [color array of the form 0,0,0,0]
in JS:
docRef.pageItems[0].fillColor.gradient.gradientStops[0].color.black=100;
docRef.pageItems[0].fillColor.gradient.gradientStops[1].color.black=0;
The first line indicates 100% black for 1 key point of the object, the second line indicates 0% black for the second point (end, in this case).
But, as you know, the number of key points in the gradient fill is ALWAYS at least 2, but it happens much more.
In this case, recalling the school course in computer science (or the university course, if more convenient), we need to write a cycle that processes ALL the key points in our gradient fill.
We write such a block:
gradNumb = docRef.pageItems[0].fillColor.gradient.gradientStops.length; //(мы считываем количество ключевых точек градиентной заливки)
for (k = 0; k < gradNumb; k++) { //(открываем цикл обработки ключевых точек заливки)
docRef.pageItems[0].fillColor.gradient.gradientStops[k].color.black = 0; //(указываем 0% для черного канала в каждой ключевой точке заливки)
}
It’s quite simple, in addition, to understand the logic of the developers at ADOBE Corporation, who have so “deeply” stuck the properties of access to key fill points. At one time, I spent a lot of effort to get to these color changing options.
Let's summarize everything that we have learned so far:
var docRef = app.activeDocument;
var docRefAll = docRef.pageItems.length;
for (n = 0; n < docRefAll; n++) {
if ((docRef.pageItems[n] == »[PathItem]«) && (docRef.pageItems[n].fillColor == »[GradientColor]«)) {
gradNumb = docRef.pageItems[n].fillColor.gradient.gradientStops.length;
for (k = 0; k < gradNumb; k++) {
docRef.pageItems[n].fillColor.gradient.gradientStops[k].color.black = 0;
}
}
if ((docRef.pageItems[n] == »[PathItem]«) && (docRef.pageItems[n].fillColor == »[CMYKColor]«)) {
docRef.pageItems[n].fillColor.black = 100;
}
}
Two new commands met in this module - checking the fill type.
If the object is graphic (not text blocks) and at the same time it has a gradient fill, then we process each key fill point.
If the object is graphic (not text blocks) and at the same time it has a monophonic fill - paint over the object in black.
At the current moment, perhaps I will stop. If the article receives feedback on the continuation, we will continue, of course.