Lo primero es un poco de historia. ¿Qué es DjVu? y ¿Por qué vamos a usar este formato?

DjVu es un formato de archivo informático diseñado principalmente para almacenar imágenes escaneadas. Se caracteriza por incorporar avanzadas tecnologías tales como separación de capas de imágenes, carga progresiva, codificación aritmética y compresión sin pérdida para imágenes bitonales (dos colores), permitiendo que imágenes de alta calidad se almacenen en un mínimo de espacio.

En líneas generales, DjVu es un formato de fichero abierto y existen soluciones privativas para trabajar con él, aunque sus autores originales mantienen una versión con licencia GPL llamada DjVuLibre. Esta versión libre será la que nosotros utilicemos para digitalizar nuestros documentos y está disponible en los repositorios de las grandes distros.

Y bien, ¿qué necesitamos para empezar a usar DjVu? Lo primero es tener instalado DjVuLibre en nuestro sistema, un escáner compatible con SANE funcionando y un visor de ficheros DjVu. El proceso de digitalizado consta de tres partes:

1. Escaneado página por página del documento.
2. Compresión de las imágenes con las utilidades ofrecidas por DjVuLibre.
3. Crear el documento con las imágenes resultantes.

Una vez hemos escaneado las páginas de nuestro documento, pasamos a comprimirlas de la siguiente manera.

$ cd ruta_de_nuestras_imagenes
$ c44 portada_color.pnm portada_color.djvu
$ cjb2 pagina1_bn.pnm pagina1_bn.djvu

Como vemos utilizaremos el compresor c44 para comprimir las imágenes a color, como la portada, páginas con fotografías, etc. y el compresor cjb2 para las páginas en blanco y negro con texto y gráficos sencillos. Éste paso hará que nuestras imágenes pasen de tener al rededor de 2Mb a unos escasos 30-200kb dependiendo de cada caso.

Llega el momento de unir todas las páginas en nuestro documento DjVu de la siguiente forma:
$ djvm -c documento.djvu portada_color.djvu pagina1_bn.djvu

Realmente sencillo. Tan sólo pasamos como argumentos el nombre del nuevo documento seguido de todas nuestras páginas en orden. Ahora ya sólo queda abrir documento.djvu con nuestro visor favorito.

Este proceso, aunque sencillo, puede extenderse en el tiempo en el caso de digitalizar documentos de gran tamaño, por eso he creado un pequeño script que automatiza en gran medida el proceso de digitalización. Podéis descargarlo desde http://pub.jotahacker.es/digitalizar/.

Para ir abriendo boca, traigo unas capturas de pantalla viéndolo en acción. Por supuesto son bienvenidas todas las sugerencias, opiniones, quejas, etc. A mi en particular me gusta mucho el aspecto que está cogiendo la GUI.

Tan solo un paso más para conquistar el mundo…

Si queréis oir mi voz, y así, digamos que conocerme un poco más, podéis pasaros por ahí y escucharlo

El cambio más importante, y creo yo, más necesario para el avance y difusión de Nhopkg, es la gestión de las dependencias. Ese tema tan delicado para la gente que viene de Windows y que normalmente no comprenden y les desborda. Es un tema importante, y todo gestor de paquetes que se precie debería gestionar lo mejor posible las dependencias. Yo tenía varias cosas claras. La primera era que no tenía nada que perder, es decir, podía intentar desarrollar un buen gestor de dependencias y conseguirlo, o no hacerlo. De preferir, preferiría conseguirlo, pero digamos que no contaba con la presión de tener que hacerlo por narices. Ese punto me ayudo (eso creo) para poder trabajar despejado y seguro. La segunda cosa clara y también importante era que debería ser un gestor de dependencias universal, al igual que pretendo que Nhopkg en su conjunto lo sea. ¿Universal por qué? Sencillo, ya existen otros que no lo son, y además unas de las pautas de Nhopkg es el ser universal. No podía ni quería cambiar eso.

Resumiendo, no me jugaba nada y tenía que hacer un buen gestor de dependencias (universal). Vosotros, los usuarios finales, seréis los que daréis vuestro veredicto final, y el que realmente valga, pero yo por el momento con el trabajo que he realizado estoy muy orgulloso. A mi parecer he desarrollado un gestor de dependencias que no tiene por que envidiar a los de otros gestores de paquetes. Eso creo. Y además me parece uno de los pasos más importantes en el desarrollo de Nhopkg. Es cierto que tendrá mil y un fallos (o más) y que versión tras versión, actualización tras actualización intentaré mejorarlo y resolver problemas, pero tal y como está el estado de desarrollo de Nhopkg y la juventud del proyecto, yo opino que está realmente bien.

Pero no solo el gestor de paquetes es una de las mejoras. Hay otras muchas, que aunque quizás menores, yo considero importantes.

Por ejemplo, aunque todavía no está decidido si entrará en esta última versión (0.5), estoy trabajando en una opción (en realidad serán varias) para que desde el mismo Nhopkg se puedan transformar paquetes .deb, .rpm y .tgz (usados por otros gestores de paquetes) a los paquetes .nho sin necesidad de tener instalado ni dpkg, ni rpm, ni, en definitiva, sus correspondientes gestores de paquetes. Ésto ya lo hace alien pero para ello necesita de rpm y dpkg. Por lo cual, esta nueva cualidad de Nhopkg será importante.

Entre las pequeñas mejoras incorporadas, también podría destacar la mayor información que se facilita al usuario final sobre los paquetes, como la descripción del paquete, la licencia usada, la arquitectura y más.

Se ha reducido considerablemente el tiempo que tardaba Nhopkg en crear un paquete binario, que para los paquetes más pesados, a veces se hacía demasiado larga la espera. En la versión 0.5 se ha acortado de forma significante.

Otra de las novedades es que la futura publicación de Nhopkg 0.5 será bajo la licencia GNU GPL v3 en detrimento de la versión anterior de esta licencia.

Y ahora que recuerde, pocas novedades importantes más, además de los fallos y bugs que se suelen corregir de una versión a otra.

En un principio la liberación de Nhopkg 0.5 será para el primer día de Febrero (01-02-09). Es la primera vez que estipulo una fecha de salida para Nhopkg desde que existe, e intentaré cumplirla. De no llegar a la fecha, por la razón que sea, no se liberará hasta que yo considere que está listo. La fecha es tan solo una meta que me he fijado, para así trabajar con alguna referencia. Lo que no quiero es liberar la versión 0.5 y que empiecen a aparecer fallos por todos lados. Aparecerán fallos de todas formas, pero prefiero asegurarme de que no me los haya encontrado yo antes de liberarla

Por último, quería agradecer a Pillate un Linux y especialmente a pragmart por todo el apoyo que me ofrecen con respecto a Nhopkg y mis proyectos. Aunque parezca mentira, pero este tipo de cosas le hacen a uno seguir a delante.

Edito: Para esta versión pretendo que haya un soporte mayor para distintos idiomas. Si crees que puedes aportar algo, ponten en contacto conmigo. Actualmente solo hay soporte para inglés y español. Puedes contribuir con idiomas diferentes a éstos, ayudar con los existentes o con variantes, Ej.: es_VE, es_MX, etc.