Microsoft abrirá los formatos de Office

A falta de saber posibles intereses ocultos, me parece una buena noticia. Ya podré abrir y trabajar con los documentos en formato Office que me pasan mis compañeros y que te "obligaban" a tener Office.

Por otro lado, sobre la disputa entre Office y OO.org, es cierto que en Windows OO.org tarda más, pero a mi me compensa esperar un minuto (que no es tanto) a que se abra y que consuma un poco más de procesador, a tener que soltar más de 400 euros que cuesta el Office.

Además el OO.org cubre todas mis necesidades para una suite ofimática. El que necesite más funcionalidades que no tenga el OO.org o le moleste esperar a que arranque y prefiera soltar la pasta, pues que lo haga.

Lo que pasa es que aquí comparamos uno con otro como si los dos fueran gratis y queremos que el OO.org haga lo mismo sin costar nada. Cada uno tiene sus ventajas e inconvenientes, pero seamos objetivos a la hora de comparar, que el día que no quede más remedio que pagar por el Office (si llega ese día), creo que los inconvenientes que planteáis muchos no os parecerán tan graves.

Saludos!

zheo escribió:Me gustaría saber en qué parte de la fuente se afirma esto, o si sólamente es una simple opinión personal, porque vamos, MS podría ahora mismo regalar su empresa que seguro que lo hacía con mala intención.

Por otro lado es una noticia vieja, aunque ahora se haga oficial. Hace tiemp oque MS juega mucho con XML como formato oficial para sus programas Visual studio) y esto estaba medio anunciado y ya se veía venir

http://news.com.com/2100-1013_3-5146581.html

jasev escribió:
¿Tú no te has leído el enlace que te he puesto, verdad? Exactamente la parte donde dice que Office utiliza componentes que ya existen en el kernel del sistema, con lo que los tiempos de carga necesariamente tienen que descender.

¿Tu no has leido lo que te he puesto no? No me refiero a tiempos de CARGA del programa, sino a tiempos de PROCESO del archivo cargado. No es normal que tarde 10 veces más en hacer las mismas operaciones sobre un fichero en concreto o en abrirlo (y por favor no me salgas con lo de que tiene muchas librerias en el kernel que eso solo importa a la hora de abrir el programa, no a la hora de hacer calculos sobre un fichero).

Pero claro, una vez más te sales por la tangente.

Bueno yo no he leido los links q habeis dado nadie, pero...

Johny27 escribió:¿Tu no has leido lo que te he puesto no? No me refiero a tiempos de CARGA del programa, sino a tiempos de PROCESO del archivo cargado. No es normal que tarde 10 veces más en hacer las mismas operaciones sobre un fichero en concreto o en abrirlo (y por favor no me salgas con lo de que tiene muchas librerias en el kernel que eso solo importa a la hora de abrir el programa, no a la hora de hacer calculos sobre un fichero).

eso no me lo creo. Sera pq el OO q yo estoy acostumbrado a usar es el de Linux, que va de PM, pero tardar 10 veces mas?? ni de coña vamos.
De todas maneras, si como te decian, en tu fuente es donde comparan Paint.NET con the GIMP, muy fiable no debe ser, perdona q te diga eh?

Puede que comparen uno con otro, pero eso no viene a cuento. Te dejan los ficheros de prueba para que tu mismo compruebes sus resultados, cosa que no habrían hecho si no estuvieran seguro de lo que encontrar.

zheo, si no me equivoco, la noticia sí es nueva, lo de que lo vaya a mandar al ECMA para su estandarización, así que, es una buena noticia, al menos un paso hacia adelante.

De todas formas, jiXo, el enlace de las patentes sí es viejo, aunque supongo que si no hay información al respecto es porque sigue siendo así.

Un saludo.

Johny27 escribió:
¿Tu no has leido lo que te he puesto no? No me refiero a tiempos de CARGA del programa, sino a tiempos de PROCESO del archivo cargado. No es normal que tarde 10 veces más en hacer las mismas operaciones sobre un fichero en concreto o en abrirlo (y por favor no me salgas con lo de que tiene muchas librerias en el kernel que eso solo importa a la hora de abrir el programa, no a la hora de hacer calculos sobre un fichero).

Pero claro, una vez más te sales por la tangente.

Tambien es normal que los archivos ocupen 10 veces mas? Porque yo recuerdo una preciosa prueba de archivo.doc con una frase ocupando mas de 200k y archivo.xdt (o lo que fuera por la epoca) ocupando 10k o menos...

De todas formas yo me pregunto por que van tan lentos ambos si vienen a hacer lo mismo que yo hacia con Amipro de windows 3.11 que tenie corrector en catalán incluido.

Sea como sea el que manda un archivo para que lo vea alguien en .doc es un desgraciado, porque para eso ya está el pdf que va que da gusto. Ya no es cuestion de compatibilidad solo, es de que hay cada inutil suelto...

Hay algo que no entiendo, si abren el formato, porque hiba a ser un problema en implantarlo en cualquier aplicación? Si es abierto es abierto no?

Saludos

jiXo escribió:La noticia, en principio buena, tiene también su cruz: el formato de Microsoft será un serio candidato a ser elegido estandar oficial para documentos, pero sin embargo seguirá cubierto por patentes de software que podrían dificultar su implementación en otras aplicaciones.

R064N escribió:Hay algo que no entiendo, si abren el formato, porque hiba a ser un problema en implantarlo en cualquier aplicación? Si es abierto es abierto no?

Saludos

Porque pueden abrirlo (para que los gobiernos vean que no hacen nada raro y se fien) pero que prohiban implantarlo por otras aplicaciones que no sean los suyos.

Una cosa es mostrar el codigo y otra liberarlo.

Johny27 escribió:
¿Tu no has leido lo que te he puesto no? No me refiero a tiempos de CARGA del programa, sino a tiempos de PROCESO del archivo cargado.

Pues mira, sí que me lo había leído. Y por eso puedo decir, en voz alta, que mientes. No hay nada en ese enlace que hable de tiempos de proceso de archivo cargado.

"It is literally taking up about 10 times the processing time and memory to just load the application itself along with a blank file"

Habla del tiempo en cargar la aplicación y abrir el archivo. Esa era la base de todo el artículo.

(y por favor no me salgas con lo de que tiene muchas librerias en el kernel que eso solo importa a la hora de abrir el programa, no a la hora de hacer calculos sobre un fichero).

No necesariamente; depende de cómo esté construida la aplicación. Aunque es cierto que no es lo más probable.