Hola,
Cita:
|
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.
Cita:
|
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.
Cita:
|
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...)
Cita:
|
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...
11-09-2007
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.
Temas Similares
Modo Híbrido
