xml - descargar - fop apache example
¿Cuál es la cadena de herramientas recomendada para formatear XML DocBook? (13)
He visto Mejores herramientas para trabajar con documentos DocBook XML , pero mi pregunta es un poco diferente. ¿Cuál es la cadena de herramientas de formato actualmente recomendada, en comparación con la herramienta de edición, para XML DocBook?
En "The Art of Unix Programming" de Eric Raymond de 2003 (¡un excelente libro!), La sugerencia es XML-FO (XML Formatting Objects), pero desde entonces he visto sugerencias que indican que XML-FO ya no está en desarrollo. (Aunque ya no puedo encontrar esa pregunta en StackOverflow, tal vez fue errónea).
Supongamos que estoy interesado principalmente en Unix / Linux (incluido MacOS X), pero no ignoraría automáticamente las soluciones solo de Windows.
¿ El FOP de Apache es la mejor manera de hacerlo? ¿Hay alguna alternativa?
Con FOP obtienes las características que alguien decidió que querían lo suficiente como para implementarlas. Diría que nadie que se tome en serio la publicación lo usa en producción. Estás mucho mejor con RenderX o Antenna House o Arbortext . (Los he usado en los proyectos de implementación de la última década). Depende de los requisitos de su negocio, cuánto desea automatizar y cuáles son las habilidades, el tiempo y los recursos de su equipo. No es solo una cuestión tecnológica.
Con respecto a la pregunta sobre la FOP de Apache: cuando establecimos nuestra cadena de herramientas (similar a lo que sugirió Gustavo) obtuvimos muy buenos resultados utilizando el motor RenderX XEP . La salida de XEP parece un poco más pulida, y hasta donde recuerdo, FOP tuvo algunos problemas con las tablas (esto fue hace unos años, esto podría haber cambiado).
El artículo llamado The DocBook toolchain también puede ser útil. Es una sección de un HOWTO en DocBook escrito por Eric Raymond.
He estado escribiendo manualmente con DocBook, bajo cygwin, para producir HTML de una página, HTML de muchas páginas, CHM y PDF.
Instalé lo siguiente:
- El repositorio docbook stylesheets (xsl).
- xmllint, para probar si el xml es correcto.
- xsltproc, para procesar el xml con las hojas de estilo.
- Fop de Apache , para producir PDF. Me aseguro de agregar la carpeta instalada a la RUTA.
- Taller de Ayuda HTML de Microsoft para producir CHM. Me aseguro de agregar la carpeta instalada a la RUTA.
Editar : En el siguiente código, estoy usando más de los 2 archivos. Si alguien quiere una versión limpiada de los scripts y la estructura de la carpeta, contácteme: guscarreno (squiggly / at) googlemail (period / dot) com
Luego uso un configure.in:
AC_INIT(Makefile.in)
FOP=fop.sh
HHC=hhc
XSLTPROC=xsltproc
AC_ARG_WITH(fop, [ --with-fop Where to find Apache FOP],
[
if test "x$withval" != "xno"; then
FOP="$withval"
fi
]
)
AC_PATH_PROG(FOP, $FOP)
AC_ARG_WITH(hhc, [ --with-hhc Where to find Microsoft Help Compiler],
[
if test "x$withval" != "xno"; then
HHC="$withval"
fi
]
)
AC_PATH_PROG(HHC, $HHC)
AC_ARG_WITH(xsltproc, [ --with-xsltproc Where to find xsltproc],
[
if test "x$withval" != "xno"; then
XSLTPROC="$withval"
fi
]
)
AC_PATH_PROG(XSLTPROC, $XSLTPROC)
AC_SUBST(FOP)
AC_SUBST(HHC)
AC_SUBST(XSLTPROC)
HERE=`pwd`
AC_SUBST(HERE)
AC_OUTPUT(Makefile)
cat > config.nice <<EOT
#!/bin/sh
./configure /
--with-fop=''$FOP'' /
--with-hhc=''$HHC'' /
--with-xsltproc=''$XSLTPROC'' /
EOT
chmod +x config.nice
y un Makefile.in:
FOP=@FOP@
HHC=@HHC@
XSLTPROC=@XSLTPROC@
HERE=@HERE@
# Subdirs that contain docs
DOCS=appendixes chapters reference
XML_CATALOG_FILES=./build/docbook-xsl-1.71.0/catalog.xml
export XML_CATALOG_FILES
all: entities.ent manual.xml html
clean:
@echo -e "/n=== Cleaning/n"
@-rm -f html/*.html html/HTML.manifest pdf/* chm/*.html chm/*.hhp chm/*.hhc chm/*.chm entities.ent .ent
@echo -e "Done./n"
dist-clean:
@echo -e "/n=== Restoring defaults/n"
@-rm -rf .ent autom4te.cache config.* configure Makefile html/*.html html/HTML.manifest pdf/* chm/*.html chm/*.hhp chm/*.hhc chm/*.chm build/docbook-xsl-1.71.0
@echo -e "Done./n"
entities.ent: ./build/mkentities.sh $(DOCS)
@echo -e "/n=== Creating entities/n"
@./build/mkentities.sh $(DOCS) > .ent
@if [ ! -f entities.ent ] || [ ! cmp entities.ent .ent ]; then mv .ent entities.ent ; fi
@echo -e "Done./n"
# Build the docs in chm format
chm: chm/htmlhelp.hpp
@echo -e "/n=== Creating CHM/n"
@echo logo.png >> chm/htmlhelp.hhp
@echo arrow.gif >> chm/htmlhelp.hhp
@-cd chm && "$(HHC)" htmlhelp.hhp
@echo -e "Done./n"
chm/htmlhelp.hpp: entities.ent build/docbook-xsl manual.xml build/chm.xsl
@echo -e "/n=== Creating input for CHM/n"
@"$(XSLTPROC)" --output ./chm/index.html ./build/chm.xsl manual.xml
# Build the docs in HTML format
html: html/index.html
html/index.html: entities.ent build/docbook-xsl manual.xml build/html.xsl
@echo -e "/n=== Creating HTML/n"
@"$(XSLTPROC)" --output ./html/index.html ./build/html.xsl manual.xml
@echo -e "Done./n"
# Build the docs in PDF format
pdf: pdf/manual.fo
@echo -e "/n=== Creating PDF/n"
@"$(FOP)" ./pdf/manual.fo ./pdf/manual.pdf
@echo -e "Done./n"
pdf/manual.fo: entities.ent build/docbook-xsl manual.xml build/pdf.xsl
@echo -e "/n=== Creating input for PDF/n"
@"$(XSLTPROC)" --output ./pdf/manual.fo ./build/pdf.xsl manual.xml
check: manual.xml
@echo -e "/n=== Checking correctness of manual/n"
@xmllint --valid --noout --postvalid manual.xml
@echo -e "Done./n"
# need to touch the dir because the timestamp in the tarball
# is older than that of the tarball :)
build/docbook-xsl: build/docbook-xsl-1.71.0.tar.gz
@echo -e "/n=== Un-taring docbook-xsl/n"
@cd build && tar xzf docbook-xsl-1.71.0.tar.gz && touch docbook-xsl-1.71.0
para automatizar la producción de las salidas de archivo mencionadas anteriormente.
Prefiero usar un enfoque nix para las secuencias de comandos simplemente porque el conjunto de herramientas es más fácil de encontrar y usar, sin mencionar que es más fácil de encadenar.
He estado utilizando dos utilidades CLI para simplificar mi cadena de herramientas docbook: xmlto y publican.
Publican me parece elegante pero lo suficiente para las necesidades de publicación de Fedora y Redhat.
Lanzo / estoy trabajando en un proyecto de código abierto llamado librería, que es un RubyGem que instala un pipeline / toolchain Docbook-XSL completo. Incluye todo lo necesario para crear y editar archivos fuente de Docbook y generar diferentes formatos (actualmente pdf y epub, y crece rápidamente).
Mi objetivo es hacer posible pasar de cero a exportar (pdf o lo que sea) desde su fuente de Docbook en menos de 10 minutos.
El resumen:
bookShop es un marco OSS basado en ruby para docbook toolchain felicidad y productividad sostenible. El marco está optimizado para ayudar a los desarrolladores a acelerar rápidamente, permitiéndoles saltar y desarrollar más rápidamente sus flujos de DocBook-to-Output, favoreciendo la convención sobre la configuración, configurándolas con las mejores prácticas, estándares y herramientas desde el primer momento. .
Aquí está la ubicación de la gema: https://rubygems.org/gems/bookshop
Y el código fuente: https://github.com/blueheadpublishing/bookshop
Las hojas de estilo de DocBook, además de FOP, funcionan bien, pero finalmente decidí usar RenderX, que cubre el estándar más a fondo y tiene algunas bonitas extensiones que las hojas de estilo DocBook aprovechan.
El libro de Bob Stayton, DocBook XSL: The Complete Guide , describe varias cadenas de herramientas alternativas, incluidas las que funcionan en Linux o Windows (casi seguramente también MacOS, aunque no he usado una Mac personalmente).
Para la salida HTML, utilizo las hojas de estilo Docbook XSL con el procesador XSLT xsltproc.
Para la salida de PDF, uso dblatex , que se traduce a LaTeX y luego uso pdflatex para compilarlo en PDF. (Utilicé Jade, las hojas de estilo DSSSL y jadetex antes).
Prefiero usar Windows para la mayoría de mi creación de contenido (editor de Notepad ++). Publican en Linux es una buena cadena de herramientas para crear una buena estructura de documentación y salidas de procesos. Uso Dropbox (también hay otros servicios para compartir documentos, que deberían funcionar bien en ambas plataformas) en mi máquina con Windows y en la máquina Virtual Linux. Con esta configuración, he podido lograr una combinación que funciona muy bien para mí. Una vez que se completa el trabajo de edición en Windows (que se sincroniza inmediatamente con la máquina Linux), cambio a Linux para ejecutar la creación de publican y crear salidas HTML y PDF, que de nuevo se actualizan en mi carpeta de Windows mediante Dropbox.
Si estás en Red Hat, Ubuntu o Windows, puedes echar un vistazo a Publican, que se supone que es una cadena de herramientas de línea de comandos bastante completa. Red Hat lo usa ampliamente.
- Wiki aquí: https://fedorahosted.org/publican/
- Doc aquí: http://jfearn.fedorapeople.org/Publican/
- Fuente tarballs y exes aquí: https://fedorahosted.org/releases/p/u/publican/
Un enfoque popular es usar DocBook XSL Stylesheets .
Usamos
- Serna XML Editor
- Eclipse (edición xml simple, principalmente utilizada por técnicos)
- propio complemento Eclipse específico (solo para nuestras notas de lanzamiento)
- Maven docbkx plug-in
- Maven jar con hoja de estilo corporativa específica, basada en las hojas de estilo docbook estándar
- Plug-in Maven para convertir csv a la tabla DocBook
- Plug-in de Maven para extraer datos de BugZilla y crear una sección de DocBook a partir de él
- Hudson (para generar el documento (s) PDF)
- Nexus para implementar los documentos PDF creados
Algunas ideas que tenemos:
Implemente con cada versión de producto no solo el PDF, sino también el documento DocBook completo original (ya que en parte escribimos el documento y en parte lo generamos). Guardar el documento completo de DocBook los hace independientes para los cambios en la configuración del sistema en el futuro. Es decir, si el sistema cambia, a partir del cual se extrajo el contenido (o se lo reemplaza por sistemas diferentes), ya no podríamos generar el contenido exacto. Lo que podría causar un problema, si necesitáramos volver a lanzar (con diferentes hojas de estilo) todo el ranche de productos de los manuales. Igual que con los tarros; estas clases compiladas de Java también se colocan en Nexus (no desea almacenarlas en su SCM); esto también lo haríamos con el documento DocBook generado.
Actualizar:
Fresh creó un Plug-in Maven HTML Cleaner , que permite añadir contenido DocBook a un sitio del proyecto Maven (versión Beta disponible). Los comentarios son bienvenidos a través del Foro de Discusión Abierta .
Usamos XMLmind XmlEdit para editar y el complemento docbkx de Maven para crear resultados durante nuestras compilaciones. Para un conjunto de buenas plantillas, eche un vistazo a las que proporcionan Hibernate o Spring .