Diff-pdf: herramienta para comparar visualmente dos PDF

 (github.com/vslavik)
1 puntos por GN⁺ 2024-07-03 | 1 comentarios | Compartir por WhatsApp
  • diff-pdf es una herramienta para comparar visualmente dos archivos PDF; al ejecutarse por defecto, devuelve el código de salida 0 si no hay diferencias y 1 si las hay
  • Con la opción --output-diff, puede generar un PDF con las diferencias resaltadas visualmente
  • La opción --view abre una pantalla simple de comparación con GUI para revisar páginas y hacer zoom; con las flechas Ctrl/Cmd se puede mover la posición relativa de las dos páginas
  • Se ofrecen paquetes precompilados o rutas de instalación mediante gestores de paquetes para Windows, macOS, Fedora, CentOS 8 y openSUSE
  • El repositorio se ofrece as-is y no está en desarrollo activo, por lo que es difícil esperar soporte para solicitudes de funciones o correcciones; las mejoras se aceptan en forma de pull requests

Qué hace diff-pdf

  • diff-pdf recibe dos archivos PDF como argumentos y los compara visualmente
  • La salida por defecto es solo el código de salida
    • 0 si no hay diferencias
    • 1 si los dos PDF son distintos
  • Para crear un PDF con las diferencias resaltadas, se usa la opción --output-diff
$ diff-pdf --output-diff=diff.pdf a.pdf b.pdf

Modo de comparación con GUI

  • Con la opción --view, se pueden comparar los dos archivos en una GUI simple
$ diff-pdf --view a.pdf b.pdf
  • En la ventana de la GUI se pueden ver las páginas del PDF y ampliar los detalles
  • Con las flechas Ctrl, o Cmd en macOS, se puede mover la posición relativa de las dos páginas
    • Es útil para revisar diferencias en las que solo cambió la posición
  • Con Ctrl+< y Ctrl+> se puede ver el documento izquierdo y el derecho, respectivamente
    • En macOS se usa Cmd+< y Cmd+>
  • Con Ctrl+D se puede volver a la vista de diff
  • La lista completa de opciones se puede consultar con $ diff-pdf --help

Instalación de binarios

  • La versión precompilada para Windows se ofrece como archivo ZIP en latest release
    • Se puede ejecutar desde cualquier ubicación después de descomprimirla
  • En Windows, si se usa Chocolatey, se instala con el siguiente comando
$ choco install diff-pdf
  • En macOS, si se usa Homebrew, se instala con el siguiente comando
$ brew install diff-pdf
  • En macOS, si se usa MacPorts, se instala con el siguiente comando
$ port install diff-pdf
  • En Fedora y CentOS 8 se instala con el siguiente comando
$ sudo dnf install diff-pdf

Compilación desde el código fuente

  • El sistema de build usa Automake, por lo que se necesita un entorno Unix o similar a Unix, como Cygwin/MSYS
  • El procedimiento habitual de compilación es el siguiente
$ ./bootstrap
$ ./configure
$ make
$ make install
  • ./bootstrap solo es necesario al compilar código fuente obtenido desde un sistema de control de versiones, es decir, cuando no existen configure ni Makefile.in
  • Las bibliotecas necesarias son las siguientes
    • wxWidgets >= 3.0
    • Cairo >= 1.4
    • Poppler >= 0.10

Dependencias por plataforma

  • En CentOS se instalan las herramientas de desarrollo y paquetes relacionados con wxGTK y Poppler GLib
$ sudo yum groupinstall "Development Tools"
$ sudo yum install wxGTK wxGTK-devel poppler-glib poppler-glib-devel
  • En Ubuntu 24.04 / Debian 12 o superior se usa libwxgtk3.2-dev
$ sudo apt-get install make automake g++
$ sudo apt-get install libpoppler-glib-dev poppler-utils libwxgtk3.2-dev
  • En versiones anteriores de Ubuntu / Debian se usa libwxgtk3.0-gtk3-dev
$ sudo apt-get install make automake g++
$ sudo apt-get install libpoppler-glib-dev poppler-utils libwxgtk3.0-gtk3-dev
  • En macOS, después de instalar Xcode Command Line Tools, se gestionan las dependencias con Homebrew o MacPorts
$ xcode-select --install
$ brew install automake autoconf wxmac poppler cairo pkg-config

$ sudo port install automake autoconf wxWidgets-3.0 poppler cairo pkgconfig
  • En Windows, las bibliotecas que usan Cairo y Poppler no vienen incluidas por defecto, por lo que se necesitan más dependencias
    • Incluyen fontconfig, freetype, glib, libpng, pixman, gettext, libiconv, libjpeg, zlib, entre otras

Compilar en Windows con MSYS + MinGW

  • Para compilar en Windows se requiere un entorno MSYS2 y una instalación de MinGW con compilador C++
  • En la shell MSYS2 MinGW, hay que moverse al directorio del código fuente de diff-pdf
  • Se instalan componentes adicionales de MSYS
$ pacman -Syu
$ pacman -S automake autoconf pkg-config make zip pactoys
$ pacboy -S gcc:p poppler:p wxWidgets:p
  • Luego se compila igual que en el procedimiento Unix
$ ./bootstrap  # necesario solo al compilar desde el repositorio git
$ ./configure
$ make
  • Para crear un archivo ZIP que incluya las DLL necesarias, se ejecuta el siguiente comando
$ make windows-dist

Estado de instalación y mantenimiento

  • En Unix se instala con el make install habitual
  • En Windows no se necesita una instalación aparte; basta con copiar los archivos a la ubicación deseada
    • Si se compiló con el procedimiento anterior, los archivos necesarios están dentro del archivo ZIP generado
  • El repositorio se ofrece as-is y el código no está en desarrollo activo
    • Para mejorarlo, se recomienda hacer cambios directamente y enviar un pull request
    • Es difícil esperar soporte para implementar solicitudes de funciones o correcciones

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-07-03
Opiniones en Hacker News

  • Hice que Claude 3.5 Sonnet creara un prototipo web rápido que usa PDF.js para renderizar PDFs en un canvas y mostrar las diferencias visuales por página.
    Los prompts fueron dos: uno para aceptar dos PDFs con arrastrar y soltar, mostrar las páginas lado a lado y resaltar las diferencias en una tercera imagen; y otro para reescribirlo sin usar React en absoluto.
    Resultado: https://tools.simonwillison.net/compare-pdfs
    En la práctica funciona bastante bien. Captura de pantalla: https://gist.github.com/simonw/9d7cbe02d448812f48070e7de13a5...

    • Me interesa saber cómo usar Claude 3.5 de forma efectiva. Hace unos días pedí acceso a la API y, además de console.anthropic.com, me gustaría recibir recomendaciones de herramientas para aprovechar bien Claude en local poniendo la clave de API
    • Me pregunto cuánto trabajo adicional hizo falta para llegar hasta ahí solo con esos prompts. Es bastante impresionante
    • Es difícil discutir con un comentario de hace 4 días, pero no veo cuál es la diferencia entre los dos PDFs
      No pude encontrar la diferencia real; quizá incluso estoy alucinando

  • En un trabajo anterior tenía que validar la salida de un sistema de publicación en producción poco estable, así que probé decenas de herramientas de comparación de PDFs disponibles en ese momento. La mejor fue Delta Walker; era software propietario comercial solo para Mac, pero tenía un precio razonable, era preciso y manejaba bien PDFs largos con muchos gráficos.
    También evalué esta herramienta diff-pdf y se quedaba corta en algunos aspectos, pero fue hace tanto que ya no recuerdo los detalles. La mayoría pasaba por alto cambios o daba falsos positivos, y esta herramienta daba más pena porque, al ser open source, era fácil de automatizar con scripts

    • Parece que Delta Walker ahora también soporta Windows y Linux: https://www.deltawalker.com/download
    • “Draftable” era excelente
    • Si exportas las páginas como imágenes y comparas la diferencia de píxeles, ¿no puedes encontrar con precisión las diferencias en el PDF?

  • Relacionado con esto, puede serle útil a alguien. Se puede hacer comparación visual de PDFs con ImageMagick
    magick compare -density "$DENSITY" -background white "$1[0]" "$2[0]" "$TMP"
    Aquí density es 100, $1 y $2 son los nombres de los archivos a comparar, y $TMP es el archivo de salida. Para soportar varias páginas hace falta algo más de trabajo, así que uso este script: https://gist.github.com/mbafford/7e6f3bef20fc220f68e467589bb...
    Este script también muestra las diferencias directamente en la terminal con imgcat. Además, con algo como convert -metric phash "$1" null: "$2" -compose Difference -layers composite -format '%[fx:mean]\n' info: también se puede obtener en ImageMagick una diferencia de hash perceptual.
    Aprovechando que se puede configurar una herramienta diff personalizada en git, agregué [diff "pdf"] command = ~/bin/git-diff-pdf a .gitconfig, y en .gitattributes configuré *.pdf binary diff=pdf. ~/bin/git-diff-pdf ejecuta tanto la diferencia de la salida pdftotext -layout de poppler como pdf-compare-phash.
    Para usar este diff personalizado en git show hay que agregar un argumento, como git show --ext-diff, pero en git diff se usa automáticamente

    • Integrarlo hasta con los atributos de git es otro nivel. Aunque uno use ImageMagick durante 10 o 20 años, todavía sorprende lo potente que es; es un software open source realmente inspirador

  • He estado usando esto en un pipeline de CI para mantener una app de generación de PDFs crítica para el negocio en el área médica. La app empezó más o menos en 2010, y el helper de RSpec que uso está aquí: https://gist.github.com/thbar/d1ce2afef68bf6089aeae8d9ddc05d...
    El código tiene un PDF de referencia guardado en git, y la suite de pruebas lo vuelve a generar para verificar que nada haya cambiado.
    Es de gran ayuda para auditar cambios visuales o upgrades de la biblioteca de PDF

    • Me pregunto si están usando un digest firmado dentro del PDF
    • ¿No se podría verificar comparando solo la fuente del PDF o su hash?

  • Me recuerda a una herramienta que Bob Nystrom creó para ayudarse mientras trabajaba en la versión física del libro Crafting Interpreters: https://journal.stuffwithstuff.com/2020/04/05/crafting-craft...
    Vale la pena leer el artículo completo, pero si solo quieres ver la parte relevante, busca “I wrote a Dart script that would take a PDF of the book”

  • En la Micro:bit Educational Foundation (microbit.org) hemos estado usando esta herramienta para cubrir huecos en las herramientas de diseño de hardware, y la usamos para revisar diferencias visuales en esquemáticos y archivos Gerber durante las iteraciones de diseño de PCB.
    Es cierto que terminar usándola así es un poco peculiar, pero si quieres tener total certeza de que la disposición del circuito de radio no cambió en absoluto al hacer una modificación menor en otra parte de la placa, un diff visual encaja perfecto.
    Dicho eso, en el próximo proyecto me gustaría probar un enfoque más integrado con herramientas EDA. Me interesaría saber si alguien ha seguido un camino parecido

  • También se puede hacer con Beyond Compare. No es gratis, pero tampoco es muy caro: https://www.scootersoftware.com/

    • Beyond Compare es una de esas herramientas que valen lo que cuestan y que uno paga de su propio bolsillo, sin esperar a que el empleador la compre. Sus funciones valen oro por el precio, es multiplataforma y la licencia es muy generosa. No hay ninguna herramienta de comparación libre y de código abierto que esté a la altura de BC.

  • Esta herramienta me gusta más: https://www.qtrac.eu/diffpdf.html
    En lugar de mostrar las diferencias superpuestas, permite una comparación lado a lado en la GUI.

    • Según la descripción de GitHub, usando el argumento --view se pueden comparar visualmente dos archivos en una GUI simple.
      $ diff-pdf --view a.pdf b.pdf
      Se abre una ventana donde se pueden ver las páginas de cada archivo y hacer zoom en los detalles. También se puede mover la posición relativa de ambas páginas con Ctrl+flechas, o Cmd+flechas en MacOS, lo que resulta útil para encontrar diferencias que consisten solo en desplazamientos.
    • También hay una versión de código abierto/gratuita de esto, y la uso regularmente: https://www.qtrac.eu/diffpdf-foss.html
      En Fedora se puede instalar con el paquete diffpdf. Ya no recibe mantenimiento, pero funciona muy bien y admite GUI con vista lado a lado, arrastrar y soltar, modo de texto y modo visual.
    • Uso BeyondCompare 5 para este propósito.

  • En el equipo usamos esta herramienta regularmente para comparar PDF de servicios de terceros que podrían haber cambiado después de modificaciones en nuestro código.

  • Curiosamente, GitHub considera que este proyecto es 46% shell por un wxwin.m4 bastante grande.

    • He visto algo parecido en proyectos privados personales. Parece que el análisis de proporción de lenguajes de GitHub está roto. Es un proyecto de Python y solo tiene unos pocos notebooks de Jupyter, además de muchísimos archivos Python; por cantidad de líneas, diría que el 80% son archivos Python, pero GitHub ve el proyecto como 50% Jupyter.