<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comentarios en: Mejoras en la exportación de contratos</title>
	<atom:link href="http://blog.negonation.com/es/mejoras-en-la-exportacion-de-contratos/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.negonation.com/es/mejoras-en-la-exportacion-de-contratos/</link>
	<description>Justice is ripe for disruption</description>
	<pubDate>Tue, 06 Jan 2009 05:52:23 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: David García</title>
		<link>http://blog.negonation.com/es/mejoras-en-la-exportacion-de-contratos/#comment-58849</link>
		<dc:creator>David García</dc:creator>
		<pubDate>Mon, 14 Jul 2008 10:14:36 +0000</pubDate>
		<guid isPermaLink="false">http://blog.negonation.com/es/?p=411#comment-58849</guid>
		<description>Hola Pedro, aqui van las respuestas a tus preguntas:
- En efecto el conversor JodConverter es perfectamente estable ya que no es "más" que un puente sobre las librerias UNO de OpenOffice. 
Aquí quien no és estable es OpenOffice es modo servidor (sobretodo la versión 2.2) que revienta a las n invocaciones. 
Además el acceso a estas librerias UNO ocurre dentro de un bloque sincronizado dentro de JodConverter, por lo que puedes tener como mucho 1 conversión concurrente a la vez.
Nosotros hemos añadido a los conversores de JodConverter la capacidad de poder controlar el ciclo de vida de los procesos OpenOffice además de tener n workers pudiendo tener n conversiones concurrentes por servidor.

-Respecto a lo de los elementos no convertibles no tengo respuesta dado que nosotros convertimos nuestros contratos en XHTML (WYSIWIM) con una estructura sin atributos de estilo asociados. Realizamos conversiones como las que comentas pero solo en procesos de importación. Ahí empleamos procesos de transformación sobre el arbol DOM generado con el XHTML en un conponemte externo al conversor.

-Lo del código modificado estamos maquillandolo para que quede bonito (Añadir Javadocs necesarios, paquetizado consistente con el resto de JODConverter) y lo submitaré a la gente de artofsolving por si lo quieren añadir. Si les gusta seguramente lo podras ver en proximos releases, si no les gusta... un zip y lo subo como attachment en próximos posts por si a alguien le es de utilidad.

Un saludo y gracias a ti por tu interes.

Dave</description>
		<content:encoded><![CDATA[<p>Hola Pedro, aqui van las respuestas a tus preguntas:<br />
- En efecto el conversor JodConverter es perfectamente estable ya que no es &#8220;más&#8221; que un puente sobre las librerias UNO de OpenOffice.<br />
Aquí quien no és estable es OpenOffice es modo servidor (sobretodo la versión 2.2) que revienta a las n invocaciones.<br />
Además el acceso a estas librerias UNO ocurre dentro de un bloque sincronizado dentro de JodConverter, por lo que puedes tener como mucho 1 conversión concurrente a la vez.<br />
Nosotros hemos añadido a los conversores de JodConverter la capacidad de poder controlar el ciclo de vida de los procesos OpenOffice además de tener n workers pudiendo tener n conversiones concurrentes por servidor.</p>
<p>-Respecto a lo de los elementos no convertibles no tengo respuesta dado que nosotros convertimos nuestros contratos en XHTML (WYSIWIM) con una estructura sin atributos de estilo asociados. Realizamos conversiones como las que comentas pero solo en procesos de importación. Ahí empleamos procesos de transformación sobre el arbol DOM generado con el XHTML en un conponemte externo al conversor.</p>
<p>-Lo del código modificado estamos maquillandolo para que quede bonito (Añadir Javadocs necesarios, paquetizado consistente con el resto de JODConverter) y lo submitaré a la gente de artofsolving por si lo quieren añadir. Si les gusta seguramente lo podras ver en proximos releases, si no les gusta&#8230; un zip y lo subo como attachment en próximos posts por si a alguien le es de utilidad.</p>
<p>Un saludo y gracias a ti por tu interes.</p>
<p>Dave</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pedro Perez</title>
		<link>http://blog.negonation.com/es/mejoras-en-la-exportacion-de-contratos/#comment-58831</link>
		<dc:creator>Pedro Perez</dc:creator>
		<pubDate>Mon, 14 Jul 2008 09:22:15 +0000</pubDate>
		<guid isPermaLink="false">http://blog.negonation.com/es/?p=411#comment-58831</guid>
		<description>Muy interesante esto que poneis

Un par de preguntas

-La pagina que hay en http://www.artofsolving.com/online-document-converter si parece que convierte perfectamente, por que decis que aun no es lo suficientemente estable?
-Como habeis resuelto la conversion cuando hay elementos que no se pueden convertir (fuentes,posiciones etc),mostrais la salida directa del conversor o tratais eso?
-Donde esta ese codigo modificado que comentais?

Gracias y seguir asiiiii.</description>
		<content:encoded><![CDATA[<p>Muy interesante esto que poneis</p>
<p>Un par de preguntas</p>
<p>-La pagina que hay en <a href="http://www.artofsolving.com/online-document-converter" rel="nofollow">http://www.artofsolving.com/online-document-converter</a> si parece que convierte perfectamente, por que decis que aun no es lo suficientemente estable?<br />
-Como habeis resuelto la conversion cuando hay elementos que no se pueden convertir (fuentes,posiciones etc),mostrais la salida directa del conversor o tratais eso?<br />
-Donde esta ese codigo modificado que comentais?</p>
<p>Gracias y seguir asiiiii.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
