Consistent treatment of concatenating sInverseTx seems right although
I am not sure of the overall picture here.
Quartz uses "y increases upwards"
https://developer.apple.com/library/ios/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_overview/dq_overview.html#//apple_ref/doc/uid/TP30001066-CH202-CJBBAEEC
2d uses "y increases downwards"
https://docs.oracle.com/javase/tutorial/2d/overview/coordinate.html
It seems like this transform
static CGAffineTransform sInverseTX = { 1, 0, 0, -1, 0, 0 };
might have been to compensate to adjust into the quartz coordinate system
But we should then see this elsewhere .. not just for text - and I do
see it here for example :-
b ImageSurfaceData.m 941 CGContextConcatCTM(qsdo->cgRef,
CGAffineTransformMake(1, 0, 0, -1, 0,
isdo->height));
However printing perhaps handles it differently.
The PrinterView subclass of NSView overrides isFlipped :-
- (BOOL)isFlipped
{
return TRUE;
}
But I'd expect to see flipped text, not just incorrectly rotated text, if
this were the problem, so I am far from sure about all of this
-phil.
***
*On 12/10/14 5:31 AM, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk 9/8u40.
Device transformation "fDevTx ", which was added in [1] and fFontTx
contains different "directions".
Both of them are used in calculation of advances, because of that in
some cases we get incorrect/opposite text rotation.
Note that I am not sure that fFontTx itself is correct, because it is
used in printing, which is broken also since a beginning. But for now
I simply change the newly added fDevTx to fix a regression.
[1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/a8b9df782017
Bug: https://bugs.openjdk.java.net/browse/JDK-8065373
Webrev can be found at:
http://cr.openjdk.java.net/~serb/8065373/webrev.00
