Skip to content

getRawTextContent does not returns words' pieces in proper coordinate order #421

Open

Description

@gkostov

Hey,

getRawTextContent seems to assume that word pieces in the bidiTexts array appear in ascending order of their y coordinate but they probably do appear as they are being added by the PDF rendering software. I have a file where a line of text looking on screen like

Some label 12.3 4455

appears in that array as

Some label | 3 | . | 2 | 1 | 5 | 5 | 4 | 4

that is, the character groups are properly following one after the other but the order of individual characters within the groups is reversed. And getRawTextContent() naively returns

Some label 3.21 5544

The y number of each item correctly shows the correct position but the code is not considering that (it only checks the absolute y difference).

So I wonder if this has a known solution before I go and change the code myself?

Cheers for the nice work.

Activity

  1. modesty commented on Mar 1, 2026

    @modesty
    Owner

    can you upload the PDF?

  2. gkostov commented on Mar 1, 2026

    @gkostov
    Author

    There is personal identification information in there so can't upload here. May I send it to your email (that's on your Github account)? Thanks for your help!

  3. gkostov commented on Mar 1, 2026

    @gkostov
    Author

    Hm, just checked again and it seems the problem is not in getRawTextContent directly because the bidiTexts already has those characters concatenated. I saw the raw character elements appearing in pdfData.Pages[0].Texts. And even if I've not yet seen that array to be processed somewhere the y values in there indicate the correct ordering of the characters. I need to trace the code more to see where exactly the concatenation goes wrong.


    It seems

    getTextContent: function PartialEvaluator_getTextContent(
    is what builds the bidiTexts array and it added characters in order of appearance from the parser of the binary stream.

  4. modesty commented on Mar 1, 2026

    @modesty
    Owner

    you can email me or create new PDF, either way works.

  5. tanin47 commented on Apr 28, 2026

    @tanin47

    I can provide an example. The PDF was made with Google Doc.

    getRawTextContent() returns the line in the reversed order

    sample.pdf

  6. gkostov commented on May 3, 2026

    @gkostov
    Author

    I saw the new sorting method added with b0067d7 , which is also available in the 4.0.3 release. I am curious if this commit is related to the present issue (it does not solve it because it is sorting the bidiTexts array)?

  7. gkostov commented on May 4, 2026

    @gkostov
    Author

    Been chasing this again and I found that the showSpacedText handler here

    var spacingLength = -e * fontSize * textHScale;
    sets the spacing to a negative value which results in proper shifting of the .x coordinate of each character from right to left. I still don't know why this is so but it does a good job. While the "TJ" handler here
    chunk += fontCharsToUnicode(items[j], font);
    (TJ appears to be equal to showSpacedText) simply concatenates the characters so they progress to the right. Unfortunately the simple swap of chunk += fontCharsToUnicode(items[j], font) with chunk = fontCharsToUnicode(items[j], font) + chunk doesn't work great - it produces those numbers in the correct order but reverses the order of words. The result is like:

    4455 12.3 Some label

    I think this is a step closer to the solution but I need to leave it for now.

    Cheers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions