>> I had a similar idea. My first attempt looked like this:
>>
>> - I've added a method to the class TextPosition to get the
>> AffineTransform
>> - I've used the getX/getY-methods to get the starting-coords
>>
>> But then I realized, that I can't get the unmodified starting-
>> coords from TextPosition.
>> They are always altered in some way concerning the rotation. So
>> finally I had to
>> decide if I add 3 new methods (1 for the AffineTransform and 2 for
>> X and Y) to the class
>> TextPosition or if I just get the textPos and put the logic into
>> PageDrawer.showCharacter().
>> I've choosen alternativ 2.
>
>OK. I'm just not sure how many other callers in the future may need
>to duplicate the logic. At a minimum, I think the comment for the
>getTextPos() function should document that the X and Y coordinates
>have not been adjusted to change the location of 0,0 because all
>other functions are returning coordinates that have been adjusted.
>Returning an adjusted matrix seems more consistent, but a comment
>would help to notify callers that it is different.
Ok, I agree. I will add a comment to the method, to explain what the caller
will get. If there will be other callers in the future, it'll be no problem
to put the logic into the class TextPosition.
>There is a slight difference between getX() and getXDirAdj(). getX()
>is adjusted based on page rotation and getXDirAdj() is adjusted based
>on text direction. To be honest, I don't know when the page rotation
>values (i.e. getX()) would be needed, but that is how the code
>originally worked and there were other functions in PDFBox that were
>calling it and I kept it there for backwards compatibility. If no
>one needs the page rotation adjusted values (i.e. getX()) and
>functions do need non-adjusted values, then we can change getX() to
>return the non-modified values.
I've studied the code again and thanks to your explanation I've got the point.
Of course, there is a difference and I guess that is the missing fact I'm
looking for
answering my question about rotating the font by 180 degrees if the page
rotation != 0:
patched source from PageDrawer.showCharacter
Matrix textPos = text.getTextPos().copy();
float x = textPos.getXPosition();
// the 0,0-reference has to be moved from the lower left (PDF) to the upper
left (AWT-graphics)
float y = pageSize.height - textPos.getYPosition();
// Set translation to 0,0. We only need the scaling and shearing
textPos.setValue(2, 0, 0);
textPos.setValue(2, 1, 0);
AffineTransform at = textPos.createAffineTransform();
// If there is a rotation, we have to add a additional rotation by 180°.
// Don't no why.yet. I guess there is a problem with clockwise- and
counterclockwise-rotation
if (at.getShearX() != 0 || at.getShearY() != 0)
at.quadrantRotate(2);
I'll try some other examples with different page-rotations and text-orientations
to check if the rotation by 180 degrees is needed like implemented or not.
Andreas
----------------------------------------------------------------
- Geschaeftsfuehrung: Chittur Ramakrishnan (Vorsitzender),
Stefan Niehusmann -
- Sitz der Gesellschaft: Dortmund -
- Eingetragen beim Amtsgericht Dortmund -
- Handelsregister-Nr. HR B 21222 -
- USt.-IdNr. DE 2588 96 719 -
