Compare Files - Acrobat

[Varinder_Saini]

Reviewing and comparing documents can take forever, especially when multiple people are involved in the process. Consider the scenario: You receive a new version of the press release you’ve been working on from your PR Agency. Press release is due tomorrow. So, now you have the mammoth task of comparing it to the previous version to identify all the changes. Any change gone unnoticed could pose huge legal and reputation risk. When deadlines are looming, finding and reviewing a few small changes in a 30-page document can be a frustrating experience!

This is where Acrobat DC's  new “Compare Files” feature comes handy. With the all-new Compare Files tool, you can now quickly and accurately detect differences between two versions of a PDF file. You can find more information at :

Compare two versions of a PDF file in Adobe Acrobat.

Compare two versions of a PDF: Tips and tricks | Adobe Content Corner

Thanks

Varinder

[Laubender]

Hi Varinder,

two observations on comparing two related PDFs with "Compare Text":

1. It would be cool if Acrobat's "Compare Text" feature could do single comparisons on "paragraph basis".
I found, that often the smallest unit of a single "comparison" is made accross the border of a single paragraph.

Or is a feature there where I can control this?
E.g. Let a single paragraph sign be the border of a single "comparison".

2. If text is hyphenated differently—the compared text is running in text frames of different width—but otherwise the text is all the same, Acrobat will highlight a difference. The result is a false positive, so to say.

Note: Just did some first "baby steps" using "Compare Files".

Regards,
Uwe

[Varinder_Saini]

Thanks Uwe for the feedback. We are aware of the hyphenated scenario. But is it really a false positive? I understand the text is same but from rendering or printing perspective there is actually a diff.

Keep providing the feedback

Thanks

Varinder

[Laubender]

Thanks, Varinder.
Now the problem with the "false positive" is showing a basic problem with comparing text.
You opened this thread in the InDesign forum. So let's discuss this in an InDesign related perspective.

In my example the user made a change in layout.
Not a change in "contents" when we see "unformatted" text as "contents" of a text frame.

No character was added, no character was removed. The hyphen was created automatically by InDesign's composer applied to the paragraph. If I'd compare the text on a string by string bases out of InDesign, I would see no difference.

On the Acrobat's side Acrobat is not able to see hyphenated text other than text where hyphens are added as characters.
And that's only naturally: The hyphen is "rendered" as true character by exporting the text frame to PDF. in InDesign we have no access to the hyphen itself. We cannot select it.

This is something like a dichotomy and cannot be solved.

Two strategies with this:

1. On the InDesign side

The code for doing hyphens could perhaps be rewritten within InDesign's text feature and the hyphen done with hyphenation can be not only seen as a special character internally, but also would be exported as something like a special character or as a character with an annotation perhaps to hand over its meaning to a PDF. It's very unlikely, that this would happen in the near future, I think.

2. On the Acrobat side

Acrobat's "Compare Text" feature should be enhanced to gather the "meaning" of hyphen characters when detected at the end of a line. For now we have to live with the problem, I think.

Btw. If the "Read Aloud" feature of Acrobat would read the two examples, I think it would not stumble over the fact, that the one word is hyphenated and the other one is not.

Regards,
Uwe

[Pickory]

Hi,

I think both are correct. Hyphenated or not, the word has the same meaning, so no change. There should be an option to distinguish the two scenarios.

P.

[Varinder_Saini]

I agree.

Thanks

Varinder

[Laubender]

Hi Varinder,

I discovered that a change in tracking text will not be recognized as change.

See this simple example:

InDesign document A without tracking:

InDesign document B with tracking applied:

How I did the comparison:

The result:

Obviously Acrobat did not recognize the change in Formatting.

So how about ligatures?
Is the use or the absence of ligatures considered a change?

Apparently not:

No ligature:

vs ligature used:

Result: "No changes found"

Regards,
Uwe

[MW Design]

With the ligature example, it may be due to how the ligs are made in the font being used and whether Acrobat is decomposing them or not.

[Laubender]

Hm.

The question is:

Should Acrobat "Compare Files" feature see a change if ligatures are used vs not used?

What would we, what can we—the InDesign users—expect from a compare feature using PDFs?

Wouldn't it make more sense to compare InDesign documents rather than to compare exported or distilled PDFs?

The number of unresolvable issues could be endless by comparing PDFs.
False positives, none-detected changes. Misleading messages for true changes.

Regards,
Uwe

[MW Design]

Hi Uwe,

If a font uses overlapping composites, I think Acrobat would have no choice but to see them as their distinct glyphs as that's what they really are despite their appearance. However, if the ligs are a distinct non-composite single glyph, Acrobat should pick that up. But in the first instance above, I cannot see how Acrobat would know that what appears as a single glyph is a change because technically it isn't.

Anyway, my personal take on the compare feature is meh. I cannot see me ever using it. I don't get changes sent to me as PDFs from which I then need to copy text from. I generally get Word files that supersede a previous Word file. Perhaps my customers think I am too stupid to compare PDF versions and make the appropriate changes...

I think the Acrobat team is searching for features to add that may or may not have real-life uses. At this point I don't think comparing PDFs is a useful feature--at least in the scenario given. And I cannot think of any other reason either that has ever effected me as a contractor or even when I was an employee of a mid-sized corporation for a short period.

Mike

[Laubender]

MW Design wrote:

… If a font uses overlapping composites, I think Acrobat would have no choice but to see them as their distinct glyphs as that's what they really are despite their appearance.

Hi Mike,

I inspected the PDF files and can see that there is a distinction in the content stream.
So in theory "Compare Files" could make out a difference.

To make that clear I did two screenshots from Acrobat DC and added some comments.

Obviously no ligature used:

Ligature used:

As you can see there is a different encoding used for the ligature.

Regards,
Uwe

[Varinder_Saini]

Uwe,

Could you share these sample files with me and we will look at the issues. I will reach you offline for getting these.

Thanks

Varinder

[Laubender]

Varinder.Saini wrote:

Uwe,

Could you share these sample files with me and we will look at the issues. I will reach you offline for getting these.

Thanks

Varinder

Hi Varinder,

there is nothing confidential in my sample with ligatures.
Download them from my Dropbox link here:

Dropbox - 161214-1-Ligatures.zip

The PDFs were exported from InDesign CC 2015.4 with a PDF/X-4 export preset where the option "PDF with Tags" was enabled.

Regards,
Uwe

[Varinder_Saini]

Mike,

Compare feature is there in Acrobat since last 10 years. Customers use this feature and it's critical part of their quality control during the review workflow. In Acrobat DC we improved the comparison engine and the UI.

The use case is more for the reviewer rather than author. As a lawyer if I am getting an updated copy of contract, I would like to see what's different in the newer version. Similar as a Marketing Manager I want to review the new marketing collateral that agency sent me to find out whether they incorporated my comments or not.

Also since PDF as a file format doesn't have a structure information the comparison is based on heuristics and we always strive to improve upon them. So it's not 100% perfect but it's the best PDF comparison solution out there.

Thanks

Varinder

[Laubender]

Hi Varinder,

as it seems to me the "ligature" case is pointing to a bigger problem.
A whole class of problems, I think.

Alternate glyphs are not considered as changes.

Example for "a" with Minion Pro:

Now comparing "a":

to it's third alternate glyph listed in the Glyphs panel:

Result:

I think, it would be good to list the limitations of "Compare Files" somewhere in the Help files.
Don't know if the majority of users saving or exporting PDFs have access to alternate glyphs in an OTF font and using them, but for us InDesign users it's important to know if alternates are used or not in documents we like to compare.

Here a list of cases that I tested and think they are not supported:

1. Changes in "white space" between characters.

Character level
Tracking

Kerning

Paragraph level

All the width settings we can define to change the composition of text wider or narrower.

2. Changes in used glyphs

Ligatures, used alternates

3. Changes in applied language

A used /Span<</Lang(en-US) vs /Span<</Lang(de-DE) in the PDF's content stream will not be evaluated and considered as change.

And that's really bad especially in workflows where we publish to various media and accessibility plays an important role.

Regards,
Uwe

[Varinder_Saini]

Uwe,

Wow. Thank you so much for the detailed analysis and feedback. This is really helpful. I will get in touch with you soon to understand the applied language case.

-Varinder

[Uttam]

Hi Uwe,

We currently don’t identify changes in char spacing, char scaling, changes in white spaces etc. So as of now, this is as designed. Can you please elaborate more on how common is this scenario for InDesign users?

For the ligature and hyphen issues, we have added them as a backlog candidate for the future release.

Thanks

Uttam

[Laubender]

Hi Uttam,

hm. Changes in character scaling is a good topic.

Sample A

vs:

Sample B

Result:

A = B

Don't know what to think of this…

I mean: It's not common to scale characters, but that does not mean it is not done. And would perhaps break a corporate design rule on typography, a client's rule, whatever… Then it would be good if that violation could be detected. I've seen client's work where all characters are scaled and scaling is part of a paragraph style definition. And then not scaling would break the rules.

We currently don’t identify changes in char spacing, char scaling, changes in white spaces etc.

I am curious what etc. could mean…

Regards,
Uwe

[Varinder_Saini]

Uwe,

Thanks for explaining it in detail. And yes I posted here specifically to get InDesign perspective. I agree that there should be a way for Acrobat to detect hyphens and not treat them as a difference. We will add this to our backlog and resolve this in our future release.

Thanks

Varinder