There seems to be a minor bug about text positioning when Tf is the only drawing operation in the container or it's the first element at the top of the hierarchy.
This issue probably originates from the identity matrix returned by ContentScanner.GraphicsState.GetInitialCtm, as it doesn't take into account the y-axis' negative orientation -- I have managed to get around it by setting the initialCtm to:
initialCtm = new Matrix(1, 0, 0, 1, 0, -scanner.CanvasSize.Height);
instead of:
initialCtm = new Matrix(); // Identity.
I'm not sure whether such fix may cause unintended side effects.
Unfortunately I cannot publicly post my PDF sample, but would be happy to email it if you would like to investigate.
Cheers, Jim
Last edit: Stefano Chizzolini 2015-04-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's an interesting observation -- I would really appreciate if you could manage to send me your sample file through the project's mail, so I can look closer at the issue.
thank you!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've sent a couple examples, although the hack above helped for the particular piece of text I needed to find, other elements positions are adversely affected.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Jimmy,
examining your samples I was able to easily trace and fix the bug (see BUG:68): the problem was that the position of FormXObject contents was calculated relative to the form box instead of the page box which incorporated it.
FYI, FormXObjects are reusable content templates which can be painted on pages.
Here it is what I found in your sample:
1) Page contents (note the translation {cm [1, 0, 0, 1, 2324.719, 71.99999]} and then the painting of the form named 'Fm' {XObject [{Do [Fm]}):
There seems to be a minor bug about text positioning when Tf is the only drawing operation in the container or it's the first element at the top of the hierarchy.
This issue probably originates from the identity matrix returned by ContentScanner.GraphicsState.GetInitialCtm, as it doesn't take into account the y-axis' negative orientation -- I have managed to get around it by setting the initialCtm to:
instead of:
I'm not sure whether such fix may cause unintended side effects.
Unfortunately I cannot publicly post my PDF sample, but would be happy to email it if you would like to investigate.
Cheers, Jim
Last edit: Stefano Chizzolini 2015-04-29
That's an interesting observation -- I would really appreciate if you could manage to send me your sample file through the project's mail, so I can look closer at the issue.
thank you!
I've sent a couple examples, although the hack above helped for the particular piece of text I needed to find, other elements positions are adversely affected.
Hi Jimmy,
examining your samples I was able to easily trace and fix the bug (see BUG:68): the problem was that the position of FormXObject contents was calculated relative to the form box instead of the page box which incorporated it.
FYI, FormXObjects are reusable content templates which can be painted on pages.
Here it is what I found in your sample:
1) Page contents (note the translation
{cm [1, 0, 0, 1, 2324.719, 71.99999]}and then the painting of the form named 'Fm'{XObject [{Do [Fm]}):2) Form 'Fm' contents (note the relative translation
{Td [0, -12.632]}):Now the problem is solved, thank you.
Stefano
Last edit: Stefano Chizzolini 2015-05-01
Many thanks Stefano, Integrated the changes and now working wonderfully. Thanks for your prompt support!