Maybe the following can explain better what is happening. The strange thing happening when the text is getting shorter and the node is getting higher and getting shorter as the text gets longer is due to the constraints being respected.
\documentclass[tikz]{standalone}
\usetikzlibrary{shapes.geometric}
\begin{document}
\begin{tikzpicture}
\tikzstyle{every node}=[trapezium, draw, minimum width=3cm,
trapezium left angle=120, trapezium right angle=60]
\node[trapezium stretches=false,minimum height=1cm]
at (0,0) {A};
\node[trapezium stretches=false,minimum height=1cm]
at (0,1.5) {\fbox{A long }};
\node[trapezium stretches=false,minimum height=1cm]
at (0,3) {\fbox{A long text}};
\draw[thick,green,|-|] (-1.5,-.5) -- (1.5,-0.5);
\draw[thick,green,|-|] (-1.5,0.5) -- (-1.5,-0.5);
\draw[thick,blue,|-|] (-1.5,1) -- (1.5,1);
\draw[thick,blue,|-|] (-1.5,1) -- (-1.5,2);
\draw[thick,red,|-|] (-1.5,2.5) -- (1.5,2.5);
\draw[thick,red,|-|] (-1.5,2.5) -- (-1.5,3.5);
\end{tikzpicture}
\end{document}
We see that the minimum width and minimum height is respected and then if there is any room then the node is getting higher because there is no constraint for that. In other words there is only constraint on the minima not maxima hence in the bottom example minima is respected and then the angles are tried to match. If the node is shorter and the angles are fixed then minimum height won't be respected etc. Hence for this there are some options are proposed namely the stretch options. If we turn all the false keys to true, we get
So the angel of the shape is deformed to comply with the constraints. Similarly the trapezium stretches body key only stretches the width. But if the angle is set then it's a matter of respecting the constraints and then checking if the angle is feasible. So a different type of constraint is needed. This might be using labels at the center anchor or drawing it on top of the nodes regardless of the size etc.
The problem of the OP was already solved by Stephan Lehmke in a comment. It was as simple as a typographic error, (a y changed by a j). I have to say that I was unable to see the error, although it was the first thing which I thought, and I inspected carefully the two strings, failing to see any difference (?).
So, trying to discover what the problem was, I read the PDF specification about color spaces and patterns, and learnt some things. Since the OP asked in a comment for clarification about these issues, I decided to write this short answer. I don't go after the 500 bounty, which I think I don't deserve :-)
In page 181 of the PDF specification, the "Uncoloured Tiling Patterns" are described. These are the kind of patterns used by TikZ, so this is the relevant part of the specification.
These kind of patterns do not include information about the color in which the pattern strokes or fills have to be drawn. They only define "how to draw" the pattern, but not "in which colour". Instead, the colours of the fills and strokes have to be specified when the pattern is used. This allows to the define the pattern once, and then apply it to different parts of the document with different colour.
To specify the color in wich the pattern has to be drawn, the operation SCN is required, to set the color of the strokes, and/or scn for the color of the non-strokes (fills). This operation requires two parameters, the first one being a tuple of components which specify the color (three components for a RGB model, four for a CMYK model), and the second one is the name of a "Pattern colour space", which has to be defined before.
In the code provided by the OP, the "Pattern Colour Space" is /pgfpcmyk. However this is an internal variable which can have any name we like. This variable is defined as a Pattern Colour Space in:
/pgfpcmyk [/Pattern /DeviceCMYK]
which specifies that this particular pattern color space uses CMYK and it is an "uncoloured pattern" (because /Pattern is defined as "Type 1" and "Paint type 2" in the code generated by TikZ).
Once this pattern colour space is defined, it can be used as argument of csn like this, for example:
/pgfpcmyk cs 0 0 0 1 /pgfpat4 scn
This sets first the non-stroking colourspace to /pgfpcmyk (this is done by cs operator), which was defined above as a pattern colour space, and then the value of the non-stroking colour called /pgfpat4 (used later to paint one particular instance of the pattern) as the value 0 0 0 1 (which is black in CMYK).
If the pattern colour space would be using RGB (as TikZ does by default by inserting the definition /pgfprgb [/Pattern /DeviceRGB], then the above line would have to specify the color using only three numbers, for the R,G,B components.
Also note that the particular name of the variables /pgfpcmyk or /pgfprgb do not imply that those pattern colour spaces use CMYK or RGB, respectively. It all depends how they are defined before.
Best Answer
If you explicitly load
xcolorwith the[rgb]option (BEFORE loadingtikz), all colors defined in whatever color spaces are converted torgb. The following MWE demonstrates this. This allows you to use virtually any color space supported byxcolor. Handy.As for transparency you can find numerous pointers as indicated by @Phelype Oleinik for example.