En mi caso para documentos de openoffice writer muy grandes y con dibujos me encontraba con el mismo problema.
Cojí el.odt, lo renombré a zip lo descomprimi, localice el fichero con todo el texto y descubri que solo tenía 2 líneas. 1.- La obligatoria del Document de XML 2.- Todo el texto de más de 100 páginas ¡EN UNA SOLA LINEA!
Lo partí en 10 o 12 lineas en lugares aleatorios (pero sin partir las etiquetas XML) y el documento volvió a ser el que era.
Debí reportarlo, pero me olvidé y no me he acordado hasta ahora.
No es tan importante corregir tu mismo el problema como reportarlo a los desarrolladores para que sea corregido en futuras versiones. Y siempre estais a tiempo de eso!!
Eso se puede cambiar: Tools | Options | Load/Save | General, y desmarcar "Size optimization for XML format".
No creo que sea eso, ya que creo que el motivo de meter todo el código en una sola línea, es precisamente la eficiencia (y no sólo al almacenar más comprimido), y los que lo quieren desmarcado es para almacenar el archivo descomprimido en un sistema de control de versiones.
Hola. Realmente no sé cómo estará implementada la lectura del XML de OO, pero es posible que se vayan cargando en memoria con un "fgets", que lee línea a línea.
Si este fuera el caso, tendría que reservar un buffer infernalmente grande y leerlo todo de una tacada, mientras que con los saltos de línea artificiales podría ir leyendo por partes. Repito, no sé cómo está implementado, así que es una conjetura.
Te contaré otro secreto, los programas leen los archivos de texto como haya querido el programador, o los programadores de las librerías que usa. Puede ser por bloques, caracter a caracter, por medio de buffers de líneas, mapeando el fichero entero en memoria...
Un simple ejemplo en el que una línea exagaradamente larga puede ralentizar la carga: si se usa el getline de c++ que lee a una string, esa string puede tener que redimensionarse un buen montón de veces, y en cada una de ellas tener que copiar todo lo ya leído.
¿Porque pudo fallar?
(Puntos:4, Interesante)( Última bitácora: Martes, 26 Julio de 2005, 18:56h )
En mi caso para documentos de openoffice writer muy grandes y con dibujos me encontraba con el mismo problema.
Cojí el
1.- La obligatoria del Document de XML
2.- Todo el texto de más de 100 páginas ¡EN UNA SOLA LINEA!
Lo partí en 10 o 12 lineas en lugares aleatorios (pero sin partir las etiquetas XML) y el documento volvió a ser el que era.
Debí reportarlo, pero me olvidé y no me he acordado hasta ahora.
Re:¿Porque pudo fallar?
(Puntos:2)Re:¿Porque pudo fallar?
(Puntos:2, Interesante)( http://www.badopi.org/ | Última bitácora: Martes, 18 Septiembre de 2012, 18:45h )
Eso se puede cambiar: Tools | Options | Load/Save | General, y desmarcar "Size optimization for XML format".
No creo que sea eso, ya que creo que el motivo de meter todo el código en una sola línea, es precisamente la eficiencia (y no sólo al almacenar más comprimido), y los que lo quieren desmarcado es para almacenar el archivo descomprimido en un sistema de control de versiones.
Escribiendo de demasiadas cosas [barnacity.net] desde 2003.
Re:¿Porque pudo fallar?
(Puntos:2)( http://gberner.jugosos.net/ | Última bitácora: Jueves, 30 Noviembre de 2006, 17:54h )
There's a Leopard sneaking in my Windows
Re:¿Porque pudo fallar?
(Puntos:2, Interesante)( http://sysvalve.blogspot.com/ )
Si este fuera el caso, tendría que reservar un buffer infernalmente grande y leerlo todo de una tacada, mientras que con los saltos de línea artificiales podría ir leyendo por partes. Repito, no sé cómo está implementado, así que es una conjetura.
Saludos.
Re:¿Porque pudo fallar?
(Puntos:3, Informativo)( http://barrapunto.com/ | Última bitácora: Domingo, 26 Junio de 2011, 17:42h )
Un simple ejemplo en el que una línea exagaradamente larga puede ralentizar la carga: si se usa el getline de c++ que lee a una string, esa string puede tener que redimensionarse un buen montón de veces, y en cada una de ellas tener que copiar todo lo ya leído.
Salu2