El día 16 de diciembre de 2010 14:02, Alberto Curro <bertothun...@gmail.com> escribió: > > 2010/12/16 Francesc Alted <fal...@pytables.org> >> >> A Thursday 16 December 2010 12:26:48 Alberto Curro escrigué: >> >> > Me surgen entonces las siguientes dudas: >> > >> > - Licencia: ¿qué problemas pueden surgir? Estoy desconectado desde >> > hace un tiempo del mundillo del software libre, y ya no me acuerdo >> > si alguno de los módulos usados (4Suite, Reportlab) podría afectar >> > en la publicación de la solución en GPL. >> >> Nosotros elegimos GPL ya que dependiamos de una libreria GPL (creo que >> era pyinotify). Mi consejo es que, debido a la naturaleza viral de GPL >> la evites si puedes (BSD o MIT van muy bien: sencillas y no pretenden >> imponer la libertad). Sin embargo, hay que decir que mucha gente se >> siente a gusto con la GPL y la elige a propósito (no es mi caso). >> > > Bueno, en esta parte tendría que revisarla. Creo que ni 4Suite ni > Reportlab son GPL... > 4Suite tenía una licencia derivada de Apache 1.1 y creo que no es compatible con GPL. 4Suite ya no tiene soporte. El proyecto se ha transformado en Amara y mejorado muchísimo, entre otras cosas en prestaciones. Amara tiene licencia Apache 2.0, compatible con GPL v3.
> Como verás, no miento cuando afirmo que estoy pez y muy desconectado del > mundillo en los últimos 2 o 3 años. Ni se me había ocurrido MIT o BSD y, > sinceramente, pensándolo me gusta más esa filosofía: yo soy libre porque > quiero serlo, tú haz lo que quieras :) > > >> > - Tecnología: ¿hay soluciones mejores, o más eficientes, para el >> > procesamiento de los XML, XSLT, o mejores que reportlab? >> >> Hombre, hay infinitas :-) Nosotros por ejemplo no usamos XML para nada. >> Nos inventamos nuestro propio sistema de plantillas para generar los >> PDFs a partir de ficheros texto y un fichero de control (o formato) >> parecido a: >> >> [task] >> doctype = Factura amb copia >> input_encoding = cp850 >> output_name = Factura #123 >> ncopies = 2 >> host = dept-comptabilitat >> barcode = 123a20080619 >> >> [copy] >> dir = /el/meu/directori >> >> [email] >> from = pdflisti...@exemple.com >> to = p...@ferrer.es >> subject = Factura #123 >> bcc = factu...@exemple.com >> >> Por supuesto, se podian definir plantillas en PDF que se superinponian >> al listado definitivo. Como ves, no hay XML, así que va como un tiro. > > Básicamente usamos XML en su momento porque nos eran sencillo generar los > ficheros XML de entrada (en algún caso trabajábamos contra una solución > propietaria, y el nuestro era un aplicativo externo, simple imposición de > mercado), y también fue una decisión de diseño por la experiencia en ese > momento; estábamos usando XSLT para otras cosas y decidimos continuar por > esa línea. > > Personalmente ahora mismo, si puedo, escapo de XML como de la peste, > aunque reconozco sus virtudes en algunas cosas. Pero bueno, ya que está > hecho, se podría mantener como uno de los soportes a usar, pero no el único > (una de las primeras ideas que se me ocurrió tras verlo el otro día). > > jeje, Amara es una buena solución para huir de la peste del XML :P >> >> > - Repositorio: ¿qué forja debería usar para publicarlo? >> Amara se alojaba en bitbucket (mercurial) y usábamos trac. Ahora hemos migrado a github + redmine. >> No infinitas, pero muchas, así que tendrás que elegir una. Yo >> últimamente me he decantado por github.com (aunque eso te obliga a usar >> git como controlador de versiones). > > Usar git no tiene mayor problema, porque es el que uso ahora mismo en lo > personal y algo en lo profesional, aparte de SVN. > >> >> > A nivel técnico, el programa habría que revisarlo, dándole >> > posibilidades en cuanto a parámetros de entrada, posibles salidas, >> > una buena refactorización y puesta al día del código (os recuerdo >> > que fue nuestro primer software python, aprendimos python con él...) >> > etc., dado que ahora mismo lo que hace es un proceso de 1 única vía: >> > coge xml -> transforma XSL -> genera RML -> convierte con reportlab >> > -> almacena / imprime. >> >> Aparte de esto, el nuestro también envia por e-mail y fax (aparte de >> otros posibles métodos definidos por el usuario). > > Esas posibilidades son muy fáciles de implementar ahora mismo, casi una > chiquillada :) > >> >> > La solución en sí es muy sencilla: coge un fichero XML con datos, >> > lo procesa mediante XSLT, genera un documento RML y lo procesa con >> > Reportlab para generar el PDF final (y enviarlo a impresora o >> > guardarlo). Aparte de reportlab, se usaba 4Suite para el procesado >> > de XML, el motor XSLT y, por supuesto, Reportlab. >> > >> > Sin embargo, a nivel características era muy potente gracias a >> > Reportlab: se podían generar auténticas "virguerías" a nivel de >> > informes, con la complejidad que se requiriese; sólo deciros que >> > fuimos capaces de conseguir generar, punto por punto, línea por >> > línea, imagen por imagen, todos los tipos de informes usados por 3 >> > empresas de distintos tamaños (hablamos de facturas, informes >> > internos, albaranes, etiquetado para logística, etc.) eliminando el >> > uso de los formularios pre-impresos que venían usando, sin que se >> > notase el cambio. >> >> Ahi el nuestro no es tan flexible. Simplemente se pasa texto a PDF >> diciéndole el tamaño del papel y el número de filas y columnas que iban >> a caber. Simple, pero efectivo. > > Creo que ya lo he dicho, pero si no, ahí va: en nuestro caso era casi un > "must", porque uno de los requisitos era: quiero sacarme el papel de encima, > pero que siga imprimiendo o generando los PDFs igualitos a lo que había en > papel antes. Estuvimos echando un vistazo a posibilidades, y lo único que > parecía cumplir todos los requisitos era reportlab. >> >> > Eso sí, el mayor problema (y donde se consumía el tiempo) era en la >> > parte del diseño de las plantillas XSL y RML, que no habíamos >> > escrito un software de diseño de las plantillas, y se hacía a mano >> > :) Por otro lado, no era una maravilla en velocidad: un informe >> > normal tardaba alrededor de 1-1.5 segundos en estar en pantalla, un >> > informe muy largo (más de 20 páginas) o muy complejo... pues >> > imaginaos. La parte más lenta era la de transformación XML/XSLT >> > (incluido el parseo y validación del XML); después de esto iba >> > bastante bien, aunque reportlab en aquel momento no eran tampoco la >> > panacea en velocidad. >> No sé cómo hacíais el parseo/validación. A nosotros nos funciona muy rápido con las últimas versiones de Amara. -- lm >> Más lento parseando XML que el propio reportlab renderizando? Creo que >> se me han ido las ganas de trabajar con XML de por vida :-) Recuerdo >> claramente que nuestro cuello de botella era el reportlab, y se podian >> alcanzar velocidades de varios informes (de entre 1 y 10 pags) por >> segundo. > > Ten en cuenta que cuando hablo de un informe "normal" estoy hablando, por > ejemplo, de una factura: escribir los resultados de las queries en XML, > llamada al programa, se cargaban los módulos, validadaba el XML contra el > XSLT y el DTD, parseaba, transformaba, obtenía el RML... a partir de ahí era > renderizado de Reportlab, y aunque no era un guepardo... pues chico, la > impresión era esa, que no era la parte más lenta :) >> >> > Bueno, creo que ya me he explayado bastante por ahora, para lo que >> > eran unas simples preguntas; cualquier recomendación, consejo, >> > interés en el proyecto, o preguntas, aquí me tenéis. No os cortéis >> > :) >> >> Ya ves que compartimos sinergias :-) Nuestro paquete es libre, pero no >> está disponible en la red básicamente por el coste de crear el >> repositorio y hacer una página medio decente explicando el asunto >> (cuesta bastante tiempo, y si nadie te lo subvenciona pues...). De >> todas maneras, si quieres echarle un vistazo, puedes descargar el >> paquete de: >> >> http://www.pytables.org/temporal/pdflistings-0.6.1.dev.tar.gz >> > > Esta última parte es la que más me hace pensar: implicará tiempo y energía. > Todavía no sé si debería revisar el código y comenzar el desarrollo antes de > comenzar a trabajar con la forja y subir código, o directamente subirlo > "as-is", comentando las posibilidades en curso, y dejar que los interesados > colaboren a medida que quieran. > > Supongo que la segunda opción es la lógica, pero como siempre he trabajado > en proyectos ya existentes en las forjas, nunca en uno propio (ni desde > cero)... > > PD: Seguro que otros muchos comparten sinergias, pero estamos bastante > ocultos unos de otros (y ocupados)... > >> >> Saludos, >> >> -- >> Francesc Alted >> _______________________________________________ >> Python-es mailing list >> Python-es@python.org >> http://mail.python.org/mailman/listinfo/python-es >> FAQ: http://python-es-faq.wikidot.com/ > > > _______________________________________________ > Python-es mailing list > Python-es@python.org > http://mail.python.org/mailman/listinfo/python-es > FAQ: http://python-es-faq.wikidot.com/ > > _______________________________________________ Python-es mailing list Python-es@python.org http://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/
