Nihiltres
My feedback
8 results found
-
9 votesNihiltres
supported this idea
·
-
15 votesNihiltres
supported this idea
·
-
4 votes
Hi Kazimierz,
You can modify the center of the radial gradient. Just choose the Gradient tool (G) with the objects selected (and gradient applied). Drag it across the shape. The start point comes the center of the gradient.
Does that work for you?
-Yogesh
Nihiltres
supported this idea
·
-
197 votes14 comments · Illustrator (Desktop) Feature Requests » Effects, Appearance, Graphic Styles · Admin →
Ai allows to use Halftone effects via Effect -> Pixelate -> Color halftone.
What specific cases are not solvable through the use of this?
Nihiltres
supported this idea
·
-
3 votes
Nihiltres, UnitValue is an object with properties
baseUnit - type of UnitValue data type
type - type of String data type
value - type of Numeric data type.
When using unary operator on object, the underlying value property of the object is modified.
Example:
var uv = new UnitValue(2, "px");
"-uv" will result in uv.value modified from "2" to "-2" and stays as Numeric data type.
Any unary operator on object as whole will return the object itself.
Alternatively you can achieve the result you expected by directly manipulating the value instead of the object
var uv = new UnitValue(2, "px");
"-uv.value" this will return the Numeric data type with negating the value, in this case it will convert the number 2 to -2
I do see it is working as documented, I would like to hear your view with the above information.
Unary operators (~, !,…
An error occurred while saving the comment An error occurred while saving the comment Nihiltres
commented
The issue is important not so much because it is a bad bug to work around but because it is directly misleading. I spent needless time debugging my script because I eliminated other possibilities before testing whether the built-in features functioned as described.
As a minor addendum: the "~" unary operator also produces a modified-UnitValue result instead of a numerical result, and it should have either its behaviour or documentation updated too.
Nihiltres
shared this idea
·
-
24 votesNihiltres
supported this idea
·
-
3 votesNihiltres
supported this idea
·
-
53 votesNihiltres
supported this idea
·
Thank you; I know how to use operators. I am saying that the documentation is misleading. Specifically, I'm complaining about the table at https://extendscript.docsforadobe.dev/extendscript-tools-features/specifying-measurement-values/#unary-operators-
The entry in the linked table currently says for the ~ operator "The numeric value is converted to a 32-bit integer with inverted bits.", which implies that it returns a UnitValue object with a mutated value property. That's accurate enough. Similarly, the entry for the ! operator is accurate because the result is in fact a boolean value.
The entries for the + and - unary operators say "Result is the numeric value." and "Result is the negated numeric value." respectively, which is inaccurate: the result is not the (negated) numeric value but a UnitValue with no change or a negated value respectively.
If you want to base the implementation on the ECMAScript standard, then you should change the behaviour so that the + and - unary operators return Number values as specified by the standard. This would be desirable at minimum for the + unary operator, because as currently implemented, its *only* effect is to copy the original. The + unary operator is frequently used in JavaScript as shorthand for a conversion to Number type, and the current design does not work with that pattern.
However, since changing the effect of operators may break any extant scripts that rely on the current behaviour, it's likely undesirable to change the behaviour. That's why I suggested updating the documentation instead.
If I had the power to fix the documentation myself, I would change "Result is the numeric value." to "Result is a new UnitValue with the same type and value as the original" and change "Result is the negated numeric value." to "Result is a new UnitValue with the same type and negated value from the original". Those are clear, correct ways to describe the current behaviour. I would also change the entry for the ~ operator to read instead something like "Result is a new UnitValue with the same type, but value converted to a 32-bit integer and inverted bitwise."
Even if it's possible to *interpret* the current wording in a way that reflects the behaviour, my complaint is itself evidence that some people are mislead by that wording. Therefore, it would be an improvement to change the wording. :)