On Nov 12, 2008, at 9:47 AM, <[EMAIL PROTECTED]> wrote:
I'm trying to find a solution to the text rotation problems that
satisfy the current regression tests and that work on some files that
I found bugs with. I've a hit a point though where I need insight
from people who know more about the graphics and non-text part of
PDFBox.
..... snip
That's a good summary of the whole problem. Well done.
thanks.
But first off all, I realized that there is perhaps a
missunderstanding on my side.
There is one key question for me. What do I have to do to get a
DINA4-page with a landscape orientation?
Do I have to rotate every element on the page, which has always the
same dimension with portrait orientation?
Or do I just have to flip the x-y dimensions of the page and the
every element is placed, as if the page has a portrait orientation?
For example:
1.
- PageSize = DINA4-PORTRAIT = PDRectangle(PDPage.PAGE_SIZE_A4)
- rotation = 90
- element orientation = vertical??
- Textpositioning 0<x<596 and 0<y<843
2.
- PageSize = DINA4-LANDSCAPE = DINA4-PORTRAIT with flipped
dimensions = PDRectangle(843,596)
- rotation = 0
- element orientation = horizontal
- Textpositioning 0<x<843 and 0<y<596
I fear the first case will be the right one. Especially if we talk
about the NoRotate-flag, which is part of pdf since 1.3
I'm using the second one and it works, but it seems to be wrong.
Your rotation.pdf has portrait-dimensions and a rotation of 90.
The examples that I have been debugging with are the first case. In
theory though, both could occur.
Back to our problem. Looking for answers about the rotation-
behaviour of all non-text-elements,
I realized that all these elements are drawn different from text-
elements. I created a simple
word-doc with two boxes and some text and generated a pdf-doc using
Adobe PDFMaker.
If you try to show the pdf with the PDFReader from pdfbox the boxes
are rotated but not the text.
Was this from the trunk version (i.e. store adjusted coordinates) or
your patched version (i.e. store non-adjusted coordinates)?
One conclusion seems to be: of course the whole coords-flipping and
moving thing in the PDFStreamEngine doesn't rotate the text.
We have to find out how the rotation is handled by non-text-
elements. After solving this puzzle, we perhaps know how to proceed.
Yes. Your other post that references the text matrix is the missing
part of the puzzle that is not currently in PDFBox. The current code
assumes that all text is "right to left / horizontal". The notion of
width and height in TextPosition also needs to be reconsidered
because those assume some form of direction. Having starting and
ending coordinates may make more sense.
Because the direction of the text is dependent on the matrix and the
page rotation, I'm more inclined to store the adjusted coordinates in
TextPosition so that every user of the object does not need to adjust
the coordinates themselves.
thanks,
brian
