Programa para generar ayuda en chm o uso alternativo de pdf

[Nasca]

Les cuento un poco, hasta ahora me he valido de Openoffice para montar los textos de ayuda de mi aplicación. Básicamente lo elegí por su estupendo sistema de estilos que simplifica la edición de contenido y por los decentes Pdfs que genera, incluyendo los Bookmarks si te has tomado la molestia de montar un índice.
No tendría problema en usarlos como ayuda "interactiva" de mi programa si encontrara la forma de poder abrir un pdf en un punto concreto del mismo, al estilo de la ayudas normales. Pero hasta ahora no lo he conseguido. ¿Hay alguna forma?

Por ello, y salvo que me ayuden con el pdf, me estoy planteando en montar la ayuda al modo de archivos chm. Estoy probando ahora mismo el HelpMaker de Vizacc y parece bastante bueno e incluso permite una exportación a pdf aceptable. Mi pregunta:
¿Qué sistema de ayuda y programas de edición de ayudas me recomiendan?

[[poliburro]]

Mi favorito por su gran potencia, aunque algo carito, es el Windows Help Designer. El que por cierto, está escrito en delphi.

[Nasca]

He estado haciendo pruebas con Word-2-Chm, previo guardado en formato .doc de los archivos de openoffice. El resultado no es del todo malo aunque tendría que depurar algunos detalles.

Estoy también explorando la opción de usar directamente los ficheros pdf generados por OpenOffice. He encontrado un camino para mostrar una página a través de DDE, ahora estoy peleando por hacer lo mismo a través de los bookmarks del índice de la aplicación.
¿Alguno tiene experiencia al respecto? la agradecería bastante. De todas formas hoy me parece que va a ser un google-day.

De todas formas creo que el meter la ayuda en un pdf tiene algunas ventajas:

1) Se puede jugar con los hipervínculos internos igual que en archivos chm.
2) Igual para enlaces externos.
3) Se tiene control total sobre el aspecto final de la ayuda en la instalación del cliente al embeber las fuentes.
4) Es un formato muy bueno para imprimir.
5) OpenOffice es un buen y fiable editor.
6) No tendrías que ir lidiando con nuevos editores o conversiones automáticas mejorables.
7) Multiplataforma, a pesar de visores de archivos chm para otros S.O.

¿Algún error que no vea o sugerencia?

[Nasca]

Por si alguno le sirve pongo lo que he averiguado con respecto al uso como ayuda de un archivo pdf.

* Se necesitan marcadores internos en el pdf para hacer viable el sistema
* Los marcadores se pueden definir perfectamente mediante OpenOffice (Bookmarks o Marcadores de Texto según el idioma)
* La exportación nativa de OO a pdf no los exporta
* Si se usa la macro extendedPDF si se puede exportar dichos marcadores sin problemas
* Para hacer uso de los mismos en Delphi hay que tirar de DDE u OLE
* En DDE se pueden llamar, después de abrir el documento, mediante: DocGoToNamedDest
* y en esas estoy, peleando con DDE para detectar que está abierto Acrobat y ...

Una ventaja adicional para montar la ayuda mediante un archivo OpenOffice -> Pdf, es la posibilidad de mandar a imprenta (en lulu.com por ejemplo) nuestros manuales. Con un retoque mínimo de los formatos de página pares-impares tendríamos un libro a la carta para enviárselo a nuestros clientes.

Bueno, creo que esto es todo al respecto, aunque al final ha sido casi un monólogo espero que la info sea útil para alguien, a mí me ha costado un día de trabajo con google y me queda otro más para afinar del todo el sistema.

[dec]

Hola,

Bueno. Has mencionado no pocas ventajas, y creo que tal vez sería bueno conocer algunos de los posibles inconvenientes de usar PDF como "sistema de ayuda". Pero me voy a centrar en Windows, así que algunas de las siguientes "desventajas" no se dan en Linux, por ejemplo:

- De entrada no hay lector de PDF instalado en el sistema. Esto puede ser un problema menor, pues incluso podríamos incluir uno con nuestro programa, empero, lo cierto es que otros formatos (pienso en HTML) cuentan con el software necesario para su visualización en Windows sin que haya que añadir nada más.

- HTML puede ofrecer también enlaces internos y externos. HTML (con o sin CSS) también permite trabajar en el aspecto estético, pudiendo incluir encabezados, estilos de fuentes distintos, menús, etc. También es posible jugar con el concepto de "página" en HTML. Incluso podríamos ir más allá, pues junto a HTML podemos usar JavaScript, lo que puede abrir todo un mundo de posibilidades.

- Con HTML pueden conformarse archivos comprimidos al estilo de los conocidos CHM. Este tipo de archivos tampoco necesitan software adicional en el sistema. Para CHM, además, hay toda una API con la que podremos hacer virgerías: mostrar temas específicos, ventanas de todo tipo, buscar en índices de palabras. Los propios archivos CHM se "ven" en un programa que permite buscar en su interior, manejar "temas favoritos", entre otras cosas.

- Aunque disponer de OpenOffice es gratuito, lo cierto es que para editar archivos HTML no es necesario sino el bloc de notas. Vale que normalmente usamos otros programas que nos ofrecen mejores características, pero, por poder hacerse (cambios rápidos, correcciones sencillas), con el propio bloc de notas podemos editar los archivos HTML.

- Si necesitamos un PDF... tal vez podríamos conseguir alguna herramienta que nos permita convertir los archivos HTML a PDF. Y, por otro lado, los archivos HTML son la base de los archivos CHM, por ejemplo. Incluso subir el manual de ayuda (en HTML) para su visualización en una página Web sería algo "natural" para HTML.

En definitiva... creo que iba a intentar exponer una serie de supuestas desventajas de usar PDF, y sólo por tratar de dar otro punto de vista, nada más, pero, sin embargo, creo que al final me ha salido una especie de alegato a favor del formato HTML como base de nuestros sistemas de ayuda. Se admiten todas las críticas del mundo, claro está.

[Nasca]

Bueno, voy a argumentarte en contra aunque solo sea por autoconvencerme.

"Visor de serie".
Tener una versión del Acrobat Reader (por ejemplo no valdría Foxit por el uso de DDE, salvo que añadamos métodos alternativos para soportarlo) instalada es un requisito inicial bastante razonable para cualquier aplicación en los tiempos que corren.

Enlaces internos y externos
También los permite el pdf. Partiendo de OpenOffice para la generación final del pdf, tenemos ciertas ventajas. Con la ayuda de los estilos (que viene a ser el CSS web) podemos modificar al gusto el aspecto estético con varios click, incluyendo encabezados, fuentes, espaciodos, alineaciones, ...

CHM
El archivo CHM no tiene muchas ventajas con respecto a un PDF con bookmarks generados automáticamente mediante el índice del documento de OpenOffice, que además se gestiona automáticamente. Y para la búsqueda contamos con las herramientas del propio visor. Lo que no tenemos es el índice de palabras. Sobre las virguerías y los temas, es cierto que no se puede hacer mucho al respecto, dudo mucho que por ejemplo se puedan incrustar objetos OLE en el pdf como si se puede en chm. Supongo que ahí están las necesidades concretas de cada proyecto.

Edición de archivos HTML
Es cierto que para archivos html no se necesita nada mas que el vim pero también hay que tener en cuenta la curva de aprendizaje que eso supone. No se puede poner a cualquiera a hacer manuales en html, sin embargo un manual en Word u OpenOffice solo requiere ciertas prevenciones o reglas que pueden entender cualquiera que haya usado un poco alguno de los dos. La curva de aprendizaje es peor en html.

Conversiones varias
Hay herramientas para generar pdf desde html y chm, pero también las hay para generar ambos desde archivos ofimáticos (word u openoffice). Porque hay que recordar que el inicio real del "sistema pdf" es un documento de texto "avanzado".

De todas formas creo que tienes razón en una cosa: No se puede obviar la utilidad de los archivos HTML, así que voy a investigar las posibilidades de exportación de los archivos de texto a ese formato. Creo que incluso puede dar muy buen resultado pasarle tidy al resultado generado desde el editor de texto.

[dec]

Hola,

Empezado por Nasca

"Visor de serie".
Tener una versión del Acrobat Reader (por ejemplo no valdría Foxit por el uso de DDE, salvo que añadamos métodos alternativos para soportarlo) instalada es un requisito inicial bastante razonable para cualquier aplicación en los tiempos que corren.

No estoy se acuerdo por varios motivos. Primero, no estoy acostumbrado. Veo manuales PDF en programas "de cederrón", pero, cuando me bajo un programa de la Red (de los muchos que bajas por probar o simplemente echar un vistazo) no es normal que se incluya el Acrobat. De hecho el Acrobat puede ocupar más de 10 veces lo que ocupe nuestro programa. Y además el tener que incluir Acrobat nos obligará a estar pendiente de ello: actualizaciones, versiones, en definitiva, nos estaremos echando esa tarea encima: nuestro instalador tendrá que tener en cuenta si existe Acrobat, si no existe instarlo, etc., etc., etc.

Empezado por Nasca

Enlaces internos y externos
También los permite el pdf. Partiendo de OpenOffice para la generación final del pdf, tenemos ciertas ventajas. Con la ayuda de los estilos (que viene a ser el CSS web) podemos modificar al gusto el aspecto estético con varios click, incluyendo encabezados, fuentes, espaciodos, alineaciones, ...

Sólo comentaré que los enlaces no es que se permitan en HTML, es que son "la madre del cordero". Sin enlaces no habría hipertexto, ni HTML ni nada. HTML no es que permita enlaces, por tanto, es que son intrínsecos al lenguaje, se los presupone, de alguna manera. Digamos que PDF pudo copiar esa "feature" de HTML... aunque no estoy seguro.

He insisto un vez más y luego diré porqué. Para editar HTML no se precisa nada más que un bloc de notas cualquiera. No sólo no hace falta OpenOffice (una Suite de 100 MB), sino que cualquier editor, el del MSDOS llegados al caso sirve para editar HTML. Pero no sólo eso (y a esto venía mi insistencia), sino que con el mismo simple editor podremos dar el formato que queramos: tablas, cabeceras, etc. Y recordemos que HTML es texto plano. No hay "códigos extraños" ni "binario" ni nada por el estilo: es pura y simplemente texto plano con unas "etiquetas" que determinan la estructura del documento.

Empezado por Nasca

CHM
El archivo CHM no tiene muchas ventajas con respecto a un PDF con bookmarks generados automáticamente mediante el índice del documento de OpenOffice, que además se gestiona automáticamente. Y para la búsqueda contamos con las herramientas del propio visor. Lo que no tenemos es el índice de palabras. Sobre las virguerías y los temas, es cierto que no se puede hacer mucho al respecto, dudo mucho que por ejemplo se puedan incrustar objetos OLE en el pdf como si se puede en chm. Supongo que ahí están las necesidades concretas de cada proyecto.

En realidad no es que a CHM se le puedan incrustar objetos OLE. Si no me equivoco es a HTML al que pueden incrustársele este tipo de objetos. El CHM es en realidad "Compiled HTML", y una especie de "visor" incorporado para ese HTML comprimido. Ahora bien, con lo del API me refería a que en Delphi, sin ir más lejos, contamos con código fuente para trabajar con archivos CHM. Sí; también para trabajar con PDF, pero, según mi experiencia (limitada, por supuesto) trabajar con CHM resulta más sencillo. Ahora bien, las cosas como son, CHM es un formato de ayuda "obsoleto" en cierto modo... puesto que ahora hay nuevas herramientas que están llamadas a sustituirlo. Si no me equivoco estas nuevas herramientas se basan también en archivos HTML, entre otros (XML... XSLT...)

Empezado por Nasca

Edición de archivos HTML
Es cierto que para archivos html no se necesita nada mas que el vim pero también hay que tener en cuenta la curva de aprendizaje que eso supone. No se puede poner a cualquiera a hacer manuales en html, sin embargo un manual en Word u OpenOffice solo requiere ciertas prevenciones o reglas que pueden entender cualquiera que haya usado un poco alguno de los dos. La curva de aprendizaje es peor en html.

En esto puedo estar más o menos de acuerdo contigo. Pero, no del todo. HTML no es tan complicado... y sobre todo no lo es si antes se ha preparado un documento "plantilla", por ejempo, sobre el que pueda trabajarse más sencillamente. Pero, en realidad no es demasiado complejo y su curva de aprendizaje (siempre quise decir algo así) no debe estar muy separada de la curva de aprendizaje de OpenOffice... otra cosa es dedicarse a hacer páginas Web, claro está, pero, manejarse más o menos con HTML... no creo que cueste mucho, sinceramente lo digo.

Una opinión para concluir este mensaje: PDF para manuales de usuario. HTML, CHM (ó superiores) para sistemas de ayuda. Porque no es lo mismo. Veo las ventajas de PDF sobre HTML/CHM (por ejemplo) para usarlo como manual de usuario, pero, veo también las desventajas de usar PDF como sistema de ayuda. Y si nos fijamos en los programas que hay por ahí... no encuentro muchos sistemas de ayuda basados en PDF, y sí manuales en este formato. Pero quién sabe... quién sabe...