By Fernando Martínez de la Cueva and Lleïr Borràs Metje

Rails es un framework web, esto no es un juicio sino que Rails se autodefine de ese modo. Rails ha nacido en y para la web que es un mundo de pantallas.

Sin embargo los humanos vivimos inmersos en una cultura no-web, en una cultura con más de 500 años de tradición en el uso del papel.

Nuestra vida esta rodeada de objetos hechos de papel o relacionados con él y es muy difícil dejarlo atrás de golpe:
* Los libros,
* Los títulos de propiedad,
* Los contratos,
* El periódico,
* La lista de la compra...
¡Incluso la ilustración de “Aplicación” en wikipedia es una metáfora de una hoja de papel! [http://es.wikipedia.org/wiki/Aplicación_informática]

No es un problema exclusivo de Rails (PHP, ASP …) cualquier lenguaje de programación o tecnología de los últimos años se ha enfrentado a esta circunstancia.

La principal dificultad viene de las diferencias entre medios de las cosas que son respectivamente características de los medios impresos y los, llamemosles, "proyectados":

Algunos ejemplos de estas diferencias:

PAPEL-IMPRESO / PANTALLA
Tamaño/formato predecible / Tamaño variado
Alta resolución ~300ppp / Baja resolución ~72ppp
Márgenes imprescindibles / Márgenes opinables
Predominantemente vertical / Vista horizontal

Nosotros, como muchos otros, nos hemos tenido que enfrentar a éste problema. Lo que queremos plantear aquí es un resumen de nuestra experiencia en el proceso para ayudar a otros, para que este camino de ensayo y error lo puedan recorrer un poco más informados y tomar sus decisiones menos a ciegas de lo que las tuvimos que tomar nosotros en su día.

No existe una receta mágica para la solución, ya que depende mucho de las necesidades de vada aplicación. Un ejemplo de ello es la disyuntiva entre el rendimiento y el control que surge al valorar la posibilidad de emitir informes en PDF cuyo aspecto puede controlarse de manera bastante precisa pero cuyo proceso siempre acarrea un coste mayor en recursos.

Entrando en detalle, haremos un recorrido por las tecnologías a las que nosotros nos hemos enfrentado personalmente, y de las que contaremos nuestras experiencias:

* Pdf_writter (los primeros pasos)
* RTex1 (plugin para usar plantillas en LaTeX con Ruby embebido)
* RTex2
* HTMLDoc (basado en el añejo ejecutable de los sistemas *nix)
* Jasper Reports (el Crystal Reports de los pobres)
* Act as flying saucer (y entonces llegó java)
* Prawnto (la historia del mendicant)
* Render_as_PDF (presentacion del plugin de Lleir)
* XHTML1strict + CSS2.1 (presentacion de la solución de Fernando)

Para iluminar este (tortuoso) camino valoraremos en cada tecnología una serie de criterios que a nosotros nos han ayudado a elegir y juzgar entre las diferentes soluciones:

* Rapidez/facilidad de desarrollo (~subjetiva)
* Facilidad de modificar/Mantenibilidad (basada en nuestra experiencia)
* Rendimiento en máquina
* Precisión de la salida (respecto a esperado/modelo)
* Soporte de Parciales
* Soporte de Imágenes
* Control de rupturas (Saltos de Página)
* Soporte/control de tipografías
* Posibilidad de validación
* Compatibilidad con versiones Rails
* Compatibilidad con navegadores

Una vez evaluada cada una de las alternativas nos gustaría presentar una comparativa de tecnologías de reporting en Rails a modo de resumen o de 'chuleta' si se quiere para ayudar a los asistente a tomar sus propias decisiones informadas

Finalmente animaremos a cada uno a evaluar sus propias necesidades y prioridades basándonos en nuestro propio ejemplo (ya que cada uno de nosotros hemos adoptado diferentes soluciones) y a que experimenten, eso sí, sabiendo a que se atienen al enfrentarse a los temibles _árboles muertos_.