Consider the following LaTeX manuscript featuring a TikZ picture of a tall, rainbow shaded rectangle. The code is essentially copy-and-pasted from the example in the end of subsection 109.3 ('Using Shadings') of chapter 109 ('Shadings') of the TikZ & PGF manual for version 3.0.1a, p. 1088.
\docu...
@percusse: Be that as it may, the scaling is done before the rotation, and at the end of the scaling the top of the rectangle is violet, and the bottom - red.
Yes now rotate 90 degrees clockwise with respect to (3,0) and you get what you have. That's what is meant by Then, the coordinate system is rotated by 〈angle〉.
@percusse: I'm not quite clear about why "clockwise" and why "around (3,0)", but at any rate doing so will result in red on the left and green or cyan on the right.
@percusse: It doesn't really matter what the axis point of the rotation is, the only things that matter are that the rotation is the last transformation to be done, and that, just before the rotation takes place, the top of the rectangle is violet and the bottom is red. This implies -- since the rectangle is tall and thin -- that some of the violet-to-red spectrum will remain outside the clipping area, and it doesn't really matter, for the sake of the point I'm trying to make, which colors will end up included and which ones excluded.
>> For these reasons, things work slightly differently “in reality.” The shading is scaled and translated such that the point (50bp, 50bp), which is the middle of the shading, is at the middle of the path and such that the point (25bp, 25bp) is at the lower left corner of the path and that (75bp, 75bp) is at upper right corner. In other words, only the center quarter of the shading will actually “survive the clipping” if the path is a rectangle. If the path is not a rectangle, but, say, a circle, even less is seen of the shading.
You disagree with what? My first comment is just a quote which explains what is done. The colour at (25bp,25bp) is red. The colour at (75bp,75bp) is violet. So red ends up 'at the lower left corner' and violet 'at [the] upper right corner' of the path. Which part of that do you disagree with?
@cfr: I disagree with your statement "This is just what you see.". Unless something is horribly amiss with my vision, red is not at the lower left corner but along the right edge, whereas violet is not at the upper right corner but along the left edge.
Red is running along the bottom edge. It is red at the lower left corner. Violet runs along the top. It is violet at the upper right corner. That is, without rotation. With rotation, violet is at the lower left corner; red is at the upper right corner.
You are refusing to read further until 1087. This is explained exactly for such reasons. However, when a vertical shading is rotated, it must obviously be “magnified” so that it still covers the path. Things get worse when the path is not a rectangle itself. So that's why you see not a fat but a tall shading. I don't think this is an efficient way of learning these details. If you really want to learn these issues for good, you have to read Adobe PDF Reference v1.7 to start what PS objects are.
Then you can distinguish what TikZ/PGF is doing by itself and what is left for PDF rendering level.
@percusse: Not only did I read the sentence you highlighted, I even incorporated it in step #3 of the algorithm, however I did forget to include the corresponding paragraphs in the quote. It was an oversight, which I have now corrected. However, my argument was based on my rephrased algorithm with the numbered steps, and this algorithm did in fact include the information in the quote you highlighted, as I've just mentioned. So this doesn't help to answer my original post.
>> If you specify a rotation of 90◦ and if the path is not a square, but an elongated rectangle, the “desired” effect results: The shading will exactly vary between the colors at the 25bp and 75bp boundaries. (1087)
@cfr: Right. This is what we see in the image I posted. The question is: why does it work this way? It is inconsistent with the algorithm. This is the whole point of my post.
Why doesn't it help it is exactly behaving as written? I really don't understand anything from your questions. What should it behave like so and why? You are asking a moving target. Define the final product and say this is what it is describing then we can discuss.
You are treating as an 'algorithm' what is a rough description. It says that what actually happens is a bit different. It is not giving you a blow-by-blow account that you can take apart and put back together like this. It then tells you what the upshot of what it actually does is. If you want the blow-by-blow details of how that's achieved, read the code. the manual tells you explicitly that it is not trying to give you that blow-by-blow account. You're claiming that exactly this, that and the other should give the result, when you're told this, that and the other don't quite do that.
@cfr: What makes you think the algorithm is a rough description? The paragraph that starts with the sentence 'For these reasons, things work slightly differently “in reality.”' goes on to formulate very precisely what actually happens. It's just a stylistic choice of how to present the algorithm: by first listing an easy-to-follow-but-not-entirely-accurate "1st draft", and then revisiting the part that was stated inaccurately and restating it with full precision. This non-linear presentation of the algorithm doesn't take away from the algorithm's precision.
Discussion on question by Evan Aad: H…
Discussion on question by Evan Aad: H…