We're sorry Aspose doesn't work properply without JavaScript enabled.

Free Support Forum - aspose.com

Aspose PDF Replace text wrong measure- wrong position

We replace placeholders in customer-supplied PDFs



For normally oriented placeholders we have to re-set the font to achieve an acceptable result.



For vertically oriented placeholders, aspose produces unexpected results.



A debugging session yielded that the measurement of the box is wrong, e.g height = 0.



Setting the box height manually (for test purposes) solves that problem partially: the Position is correct, but the replacement is not complete. (XXXXXX => 12 instead of 123456)



Re-setting the font (which works for other pdf’s)

breaks the positioning again and the text is wrong.



Extracted PDF stream (with PDFXplorer) when only 12 is shown (on correct position):



/T1_1 1 Tf

0 7 -7 0 57.2864 49.3926 Tm

[(Ar)26(t)-5(. 712728\226)] TJ

[0(1)0(2)0 0 0 0] TJ



Extracted PDF stream (with PDFXplorer) when only 12 is shown (on wrong position):



/T1_1 1 Tf

0 7 -7 0 57.2864 49.3926 Tm

0 7 -7 0 56.7613983154297 49.3926010131836 Tm

[(Ar)0(t)0(. 712728\226)] TJ

/C0_0 1 Tf

0 7 -7 0 57.2723999023438 49.3926010131836 Tm

[00] TJ

0 7 -7 0 57.2864 49.3926 Tm

We got further.

This issue is caused by an embedded subset font.

123456 doesn’t render completely because the characters für 3456 are missing.

Replacing the textfragment’s font with the original makes the fragment lose ist correct position.

How should we proceed from now on?

Hi Chris,


Thanks for using our API’s.

Can you please share your resource/input PDF files and code snippet which you are using, so that we can test the scenario in our environment. We are sorry for this inconvenience.

Hi Nayyer,



We’ve prepared a solution for test purposes.



The cases we’ve covered:

- 2 different documents with vertically oriented text fragments

- 2 different documents with horizontally oriented text fragments



- Only text replace

- Text replace + overriding font by “arial”

- Text replace + overriding font by the fragment’s font Name





The part You’d need to watch for is near the barcode - usually on the last page - and Looks like “Art. 555555 - XXXXXX” where XXXXXX is the placeholder we need to replace.



Before You start, please install the Fonts provided with the solution on your System.

Also, please make sure that the license file is located under “resources”.



You can find the input files in the “Problematic PDF” Folder, the Output files for each replacement type in the /bin/Debug/Output Folder.



We hope we’ve provided enough Information for You

Hi Chris,


Thanks for sharing the sample project.

I am working on testing the scenario in my environment and will keep you posted with my findings.

Hi Nayyer,



We’ve found a strange fix for a part of our issue:



We’ve to replace the fragment twice, discarding the first result. This is strange. (And the reason why replacing in the previously uploaded solution sometimes works: several replacements in row - on the same document)



------------------------------------------------------

The same issue:

The specific PDF has 2 fragments to replace.

The facade to replace ignores the second fragment on another page.

Using the low-level text fragment method works, but:

1) The second fragment gets distorted like in the examples before.

2) The PDF almost doubles in size compared to using Facades.



Editing the PDF by increasing the TextBox size:

- Text gets replaced correctly

- The text isn’t rendered on the correct Position



Using the workaround “Replace twice, discard first result” with low-level text-fragments instead of Facade yields an entirely blank PDF. Same file size, blank pages.





This is an urgent issue. Our customer expects that ALL his PDF’s are processed correctly and ASAP. They already invested enough time to convert the PDF fonts to embedded non-subset fonts.

Chris2Stein:
Hi Nayyer,

We’ve prepared a solution for test purposes.

The cases we’ve covered:

  • 2 different documents with vertically oriented text fragments

  • 2 different documents with horizontally oriented text fragments

  • Only text replace

  • Text replace + overriding font by “arial”

  • Text replace + overriding font by the fragment’s font Name

The part You’d need to watch for is near the barcode - usually on the last page - and Looks like “Art. 555555 - XXXXXX” where XXXXXX is the placeholder we need to replace.

Before You start, please install the Fonts provided with the solution on your System.
Also, please make sure that the license file is located under “resources”.

You can find the input files in the “Problematic PDF” Folder, the Output files for each replacement type in the /bin/Debug/Output Folder.

We hope we’ve provided enough Information for You

Hi Chris,

Thanks for your patience.

I have tested the above stated scenario and have managed to reproduce the same issue that images are not being rendering inside PDF file when referenced from network path.For the sake of correction, I have logged it as PDFNEWNET-40347 in our issue tracking system. We will further look into the details of this problem and will keep you posted on the status of correction. Please be patient and spare us little time. We are sorry for this inconvenience.

Chris2Stein:
Hi Nayyer,

We’ve found a strange fix for a part of our issue:

We’ve to replace the fragment twice, discarding the first result. This is strange. (And the reason why replacing in the previously uploaded solution sometimes works: several replacements in row - on the same document)


The same issue:
The specific PDF has 2 fragments to replace.
The facade to replace ignores the second fragment on another page.
Using the low-level text fragment method works, but:

  1. The second fragment gets distorted like in the examples before.
  2. The PDF almost doubles in size compared to using Facades.

Editing the PDF by increasing the TextBox size:

  • Text gets replaced correctly
  • The text isn’t rendered on the correct Position

Using the workaround “Replace twice, discard first result” with low-level text-fragments instead of Facade yields an entirely blank PDF. Same file size, blank pages.

This is an urgent issue. Our customer expects that ALL his PDF’s are processed correctly and ASAP. They already invested enough time to convert the PDF fonts to embedded non-subset fonts.

Hi Christian,

Thanks for sharing the details.

The information has been associated with earlier logged issue and as soon as we have some definite updates regarding the resolution of this problem, we will let you know. Please be patient and spare us little time. We are sorry for your inconvenience.