search

ftilmann / latexdiff

Compares two latex files and marks up significant differences between them. Releases on www.ctan.org and mirrors
GNU General Public License v3.0
514 stars 72 forks source link

ONLYCHANGEDPAGE emits the wrong page on longtable s #169

Closed yfarjoun closed 5 years ago

yfarjoun commented 5 years ago

I've included latexdiff-vc in a project with continuous integration...thanks for your work on this!!!

In case you want to see it in action: https://github.com/samtools/hts-specs in particular, you can look at this recently merged PR: https://github.com/samtools/hts-specs/pull/328. the "bot" comments contain links to files generated with latexdiff-vc.

Here's my issue:

In the presence of a difference in a longtable that spans multiple pages, asking latexdiff-vc to emit only the changed pages results in only the first page, even if the difference is on the second page.

Using the included files, I ran 

latexdiff-vc  --pdf --subtype ONLYCHANGEDPAGE  --graphics-markup=none test_table.tex test_table2.tex

As you can see only the first page is emitted, but the difference is in the second page.

example.tar.gz

Omitting the --subtype ONLYCHANGEDPAGE shows the difference on the second page.

jmarshall commented 5 years ago

It appears to have picked the wrong page on the tabular here too: https://github.com/samtools/hts-specs/pull/398#commitcomment-32968930 — the actual changes are page 7.

ftilmann commented 5 years ago

This is a known weakness of ONLYCHANGEDPAGE. From the manual ONLYCHANGEDPAGE ... also highlights changed pages, without the need for post-processing, but might not work reliably if there is floating material (figures, tables). The longtable is not exactly floating material but has presumably a similar issue of first being internally processed before then being rendered in one go.

Have you tried latexdiff-vc option --only-changes, which uses the ZLABEL style for achieving the same outcome but needs post-processing (done automatically by latexdiff-vc, but I am not sure it suits your workflow). I am not sure if it will work for your issue, though. If it doesn't then I am afraid this bug will be very hard to fix as it would essentially require getting into the longtable.
A clumsy work-around could possibly be constructed by some post-processing if a ZLABEL markup is found within a long table to artificially add additional labels at the beginning and end of the table (this would imply that always the whole longtable would be shown whenever there is any change in it). Because of its clumsiness I am note sure this is a good idea, though, and probably wouldn't be a priority).

Anyway, maybe you are lucky and the --only-changes / ZLABEL approach already works.

yfarjoun commented 5 years ago

Thanks for the thoughful response. I'll try out --only-changes

yfarjoun commented 5 years ago

at first glance it seems to be working. did require an upgrade of gs (9.19 wasn't good enough) but after that hiccup it started chopping the results to the right pages.

Thanks again!