[Proposal] Preserve TJ text arrays when regenerating PDF page content instead of flatting to Tj

[Amit Pathak]

Hi PDFium Team,

I have been working with PDFium's page content editing and regeneration functionality and would like to propose an enhancement related to the TJ text-showing operator.

PDFium supports parsing and rendering both Tj and TJ. However, when page contents are regenerated after editing, text originally represented using TJ arrays is serialized using Tj, effectively flattening the positioning adjustments present in the TJ array.

I have implemented support for generating TJ arrays during page content regeneration, preserving relevant glyph positioning and spacing adjustments where appropriate.

I would be interested in contributing this enhancement upstream. Before preparing a focused CL with tests, I would appreciate feedback on whether this functionality aligns with PDFium's design goals and whether there is a preferred approach for implementing it in the page content generation path.

Thanks
Amit Kumar Pathak

[Lei Zhang]

Hi,

Are you using the latest PDFium? How is your proposal different from
this commit? [1]

[1] https://pdfium.googlesource.com/pdfium/+/05e4858256a8b18e3c3a550d1b8b1a293f5232a2

> --
> You received this message because you are subscribed to the Google Groups "pdfium" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pdfium+un...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/pdfium/d97eeaad-38db-4fbc-a161-9bdd09897712n%40googlegroups.com.

[Amit Pathak]

HI Lei, 

Thanks for pointing me to this change.

I compared it with my implementation and realized that my PDFium branch was based on an older revision that predates this change.

There is one difference in the approach, though. My implementation tracks whether the original text object was represented using TJ (HasTJ()) and reconstructs it during content regeneration (RebuildTJStream()). Text originally represented using Tj continues to be generated as Tj.

So the behavior is essentially:

• Original Tj regenerated as Tj

• Original TJ regenerated as TJ

From my understanding, the referenced upstream change generates TJ based on the character positioning/kerning information and does not attempt to preserve the original Tj vs TJ operator choice.

My original goal was therefore slightly different: preserve the original text-showing operator representation during page content regeneration, in addition to retaining the positioning information for TJ.

Would preserving the original Tj/TJ representation be useful from PDFium's perspective or is canonicalizing regenerated text to TJ intentional and by Design??

Thanks
Amit Kumar Pathak

[Lei Zhang]

Since the TJ operator can do everything the Tj operator can do and
more, it seemed easier to just use TJ everywhere. Do you see any
significant advantages to preserving Tj?

> To view this discussion visit https://groups.google.com/d/msgid/pdfium/c409fb48-7f3d-4b05-9bbe-3142594b0726n%40googlegroups.com.

[Amit Pathak]

Thanks for the question. I was thinking more from a round-trip fidelity perspective than a rendering perspective..

Potential advantages of preserving Tj where possible are:

1. Minimal serialization changes: If a text object was originally "Tj" & doesn't require kernings, regenerating it as "Tj" avoids an unnecessary representation change.

2. Cleaner round-trip editing: Localized edits produce smaller and more focused content stream diffs instead of normalizing every text-showing operator to "TJ".

3. Slightly smaller content streams: "Tj" is a more compact representation for simple contiguous text. While compression reduces the impact, avoiding unnecessary "TJ" arrays still eliminates some serialization overhead.

4. "Representation fidelity: Since both "Tj" & "TJ" are valid PDF operators, preserving the original operator where possible retains more of the original content stream structure instead of canonicalizing it.

That said, I completely understand the trade-off. If PDFium intentionally prefers a single canonical serialization path for simplicity and maintainability, then using "TJ" everywhere is a perfectly reasonable design choice.

[Lei Zhang]

In the PDFium implementation, it looks for content streams with the
"dirty" bit set to indicate they need to be rewritten. Those content
streams are completely rewritten with no attempt to preserve the
original content stream. Given this behavior, trying to preserve the
original Tj operators for reasons 1, 2 and 4 is a lost cause.

That leaves reason 3. If you feel strongly about it and it is not too
much work, then feel free to submit a Changelist for that.

> To view this discussion visit https://groups.google.com/d/msgid/pdfium/7f759691-9aa3-48e3-9376-34adda507562n%40googlegroups.com.

[Amit Pathak]

For [3], will apply a minimal patch and also add unit test and  submit a Changelist.

[Amit Pathak]

Hi Lei

The CL is ready locally and all relevant unit tests are passing (10/10). However, I am currently unable to upload it to Gerrit because Chromium's Gerrit ReAuth is requiring a physical FIDO security key, which I don't currently have.

please suggest how you'd like me to proceed?