Lazy prepress
This article is a kind of repost of my own article, published on another (little visited) site. Why am I posting an article here? On this site, many prepressnikov hanging out, and the breadth of his soul I want to help them. Idle-by-but! that is, for nothing. (c)
I want to immediately make a reservation - I do not know how to teach. Well, it is simply not possible to orator by nature so that others do not just like the idea, but also understand something of what was said.
This article (and I hope the subsequent ones too) is aimed primarily at people preparing layouts for flexo printing. Accordingly, the main idea of ​​the scripts will be connected and “adjusted” under the conditions of flexographic printing.
Adobe Illustrator is not only a visual environment for the artistic development of layouts, but also
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 stop at the scripts in the JavaScript environment, since this is the only language that I know relatively well.
I do not plan to go into the details of JavaScrtipt's work, if interested - study it with examples of web programming. The foundation
similar, only the difference in objects and tree structure of objects. Here we begin with this structure.
The structure of the document can be represented (in a simplified form) as follows:
Based on this representation of the structure of the document, you can build a logical chain of access to a specific object. Something of the kind: ActiveDocument . Mounting area_â„– (if there are more than 1) . Layer number (If there are more than 1 and you need an object on a specific layer). Object
In principle, everything is logical. Some items in this logical construction can be omitted. For example, you want to process an entire array of existing objects, without specifying artboards and / or layers. In this case, the upgraded logical chain will look like this: ActiveDocument . Object [No. ]
The variant of constructing logical chains of queries varies from the specific goal set.
Now let's consider how many and what kind of objects are all present in an open document and how this knowledge can be obtained programmatically.
Again, based on a logical chain, you can write a query of the type: variable = ActiveDocument . Objects The amount .
In JS it will look like this:
')
Is everything simple? Completely! Moving on.
Before proceeding, I would like to draw attention to the list of objects that we can change (not a complete list):
Alas, unfortunately, the creators of Illustrator have developed a rather weak engine of scripting languages. 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 the graphical environment of the program.
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 silly work. And you and I 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, when we have the number of objects in the document, done? For example, repaint!
Before repainting objects (it doesn’t matter which, text or complex, primitives or object strokes) it is necessary to understand the structure of the color of this object.
And the structure is quite simple (actually, everything is simple, if you understand the logic of the authors):
Object Filling .Color Channel ,
where Object is the object itself currently being processed;
Fill - the fill type (the options are: homogeneous, gradient, SPOT, SPOT-gradient, Mesh);
Color Channel - depends on color space and type of fill; has options - Cyan, Magenta, Yellow, Black (CMYK); Red, Green, Blue (RGB); Tint (Spot, Grayscale);
Thus, filling an object with color in the JS environment is as follows:
If we consider setting the object's stroke color, then the entry will be of the following plan:
those. the difference in setting the fill color (monophonic) and stroke only in specifying the fill type: fillColor or strokeColor .
But we can, after all, indicate not a uniform fill for the object, but a gradient? 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 start of the fill (one edge) to the end of the fill (opposite edge of the fill), which has its own colors. Those. 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 language:
The first line produces an indication of 100% black for 1 key point of the object, the second line indicates 0% black for the second point (the final one, in this case).
But, as you understand, the number of key points in a gradient fill is ALWAYS at least 2, but there are also many more.
In this case, remembering another school course of computer science (or a university course, if it is more convenient), we need to write a cycle that processes ALL key points in our gradient fill.
We write such a block:
It’s pretty simple, in addition, to understand the logic of developers at ADOBE, who so deeply stuck in the properties of access to key fill points. At one time I spent a lot of effort to get to these possibilities of changing colors.
Let's summarize a little of everything we have learned so far:
Two new teams have met in this module - the fill type check.
If the object is graphical (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 monochromatic fill, paint the object black.
At the current moment, perhaps, I will stop. If the article receives feedback on the continuation - continue, of course.
I want to immediately make a reservation - I do not know how to teach. Well, it is simply not possible to orator by nature so that others do not just like the idea, but also understand something of what was said.
This article (and I hope the subsequent ones too) is aimed primarily at people preparing layouts for flexo printing. Accordingly, the main idea of ​​the scripts will be connected and “adjusted” under the conditions of flexographic printing.
Adobe Illustrator is not only a visual environment for the artistic development of layouts, but also
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 stop at the scripts in the JavaScript environment, since this is the only language that I know relatively well.
I do not plan to go into the details of JavaScrtipt's work, if interested - study it with examples of web programming. The foundation
similar, only the difference in objects and tree structure of objects. Here we begin with this structure.
The structure of the document can be represented (in a simplified form) as follows:
- Document
- Mounting area
- Layers
- Group of objects
- Objects (primitives or compound, text blocks, etc.)
Based on this representation of the structure of the document, you can build a logical chain of access to a specific object. Something of the kind: ActiveDocument . Mounting area_â„– (if there are more than 1) . Layer number (If there are more than 1 and you need an object on a specific layer). Object
In principle, everything is logical. Some items in this logical construction can be omitted. For example, you want to process an entire array of existing objects, without specifying artboards and / or layers. In this case, the upgraded logical chain will look like this: ActiveDocument . Object [No. ]
The variant of constructing logical chains of queries varies from the specific goal set.
Now let's consider how many and what kind of objects are all present in an open document and how this knowledge can be obtained programmatically.
Again, based on a logical chain, you can write a query of the type: variable = ActiveDocument . Objects The amount .
In JS it will look like this:
')
var docRef = app.activeDocument; var docRefAll = docRef.pageItems.length; // Is everything simple? Completely! Moving on.
Before proceeding, I would like to draw attention to the list of objects that we can change (not a complete list):
- text objects;
- graphic primitives;
- compound objects;
- mounting areas;
- layers.
Alas, unfortunately, the creators of Illustrator have developed a rather weak engine of scripting languages. 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 the graphical environment of the program.
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 silly work. And you and I 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, when we have the number of objects in the document, done? For example, repaint!
Before repainting objects (it doesn’t matter which, text or complex, primitives or object strokes) it is necessary to understand the structure of the color of this object.
And the structure is quite simple (actually, everything is simple, if you understand the logic of the authors):
Object Filling .Color Channel ,
where Object is the object itself currently being processed;
Fill - the fill type (the options are: homogeneous, gradient, SPOT, SPOT-gradient, Mesh);
Color Channel - depends on color space and type of fill; has options - Cyan, Magenta, Yellow, Black (CMYK); Red, Green, Blue (RGB); Tint (Spot, Grayscale);
Thus, filling an object with color in the JS environment is 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 object's stroke color, then the entry will be of the following plan:
docRef.pageItems[0].strokeColor.cyan = 0…100; those. the difference in setting the fill color (monophonic) and stroke only in specifying the fill type: fillColor or strokeColor .
But we can, after all, indicate not a uniform fill for the object, but a gradient? 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 start of the fill (one edge) to the end of the fill (opposite edge of the fill), which has its own colors. Those. 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 language:
docRef.pageItems[0].fillColor.gradient.gradientStops[0].color.black=100; docRef.pageItems[0].fillColor.gradient.gradientStops[1].color.black=0; The first line produces an indication of 100% black for 1 key point of the object, the second line indicates 0% black for the second point (the final one, in this case).
But, as you understand, the number of key points in a gradient fill is ALWAYS at least 2, but there are also many more.
In this case, remembering another school course of computer science (or a university course, if it is more convenient), we need to write a cycle that processes ALL 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 pretty simple, in addition, to understand the logic of developers at ADOBE, who so deeply stuck in the properties of access to key fill points. At one time I spent a lot of effort to get to these possibilities of changing colors.
Let's summarize a little of everything 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 teams have met in this module - the fill type check.
If the object is graphical (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 monochromatic fill, paint the object black.
At the current moment, perhaps, I will stop. If the article receives feedback on the continuation - continue, of course.
Source: https://habr.com/ru/post/185192/
All Articles