Saltos de línea en FB2 y EPUB.

[silicon]

El problema de este hilo es que xela quiere que los fb2 que ha convertido desde epub con calibre se vean igual como se muestran en el ADE.

Se puede hacer, pero sólo si se dedica a editar a mano un montón de cosas, porque la conversión que hace el calibre desde cualquier formato a fb2 es bastante simplona y no exporta el css.</p>.

Si el problema reside en esto, entonces mis indicaciones estan totalmente erradas.

Para empezar debo decir que cada formato tiene sus limitaciones. Hay algunos muy limitados (como el LRF), otros menos limitados (como el FB2) y alguno con muy pocas limitaciones (como el EPUB).
Cuando conviertes un formato a otro siempre vas a terminar con las limitaciones de AMBOS formatos. Por tanto es siempre buena idea partir de un formato que casi no tenga limitaciones (HTML o DOC son mis recomendaciones).

Pongamos un ejemplo:
Imaginemso un libro que tiene sobrerayados, listas y tablas.
Todos estos elementos se soportan perfectamente en formto HTML o DOC, con lo que no tienen problemas.
Pero si pasamos este formato a MOBI, perderemos automaticamente los sobrerayados. Si despues pasasemos a EPUB, tendriamos un epub sin sobrerayados, aunque este formato los soporte perfectamente.

Imaginemos que pasamos a FB2. En ese momento perderiamos las listas (no hay etiquetas en FB2 para las listas o para los sobrerayados). Su posterior conversion a EPUB haria perder esas cualidades.

Pero si los pasamos a LRF, ademas perderemos las tablas.

Recordar que nunca es buena idea convertir de un formato de libro electronico a otro, pues hay perdidas inevitables ocasinadas por las limitaciones del formato. A ello debemos añadir que ningun conversor es perfecto y esto añadira aun mayor distorsion. El calibre es bastante podre en este aspecto y genera libros que ni siquiera a veces ni pasan un test de compatibilidad con el estandar.

Por si aun hubiera pocos problemas, el FB2 es un formato muy mal definido. El estandar no es conciso y que los ejemplos esten en ruso no ayuda nada. En cuanto a la parte de estilos esta sin definir. Esto hace que cada programa soporte los estilos de manera diferente o que simplemente no los soporte. Intentar algo tan simple como alinear un titulo a la izquierda usando el FBReader y vereis que no funciona. Por otra parte con el CR3 podeis hacer cosas que claramente no estan en el estandar y este programa las interpretara como un campeon.

Por tanto la mejor idea es partir de un DOC o de un HTML y a partir de ahi generar el resto de los formatos. Es la estrategia que he seguido con el QualityEpub y podreis ver que los resultados son siempre buenos.

Espero haberos resultado de utilidad. Si alguien quiere conocer en mas profundidad las diferentes limitaciones no tiene mas que preguntar.

[Nem0]

El HTML no debe respetar las lineas en blanco ni los espacios, pues asi esta definido. El HTML almacena el contenido de la pagina y no su representacion. Las indicaciones de la representacion correcta deben estar definidas mediante el CSS.

Eso es exactamente lo que yo he dicho (lo que pasa es que tampoco hay porque vender las carencias como si fueran méritos).

El "caracter invisible" en realidad es la indicacion de un espacio que no se debe eliminar. Es la abreviatura de "No Break EsPace". Considero que no es ninguna chapuza (al menos en HTML) y si un programa los "pierde" hemos de concluir que el programa es erroneo y deberiamos avisar al programador (o cambiar de programa).

Ninguna entidad-HTML es una chapuza en sí misma. La chapuza (o la torpeza, si así parece mejor) está en la manera en que se usa y en lo que se espera de ella. Los que crean que así garantizan la permanencia y universalidad de las lineas en blanco... están en un error (ojalá las cosas fueran tan fáciles). Solo va a funcionar en el propio HTML y en algún derivado. Y ni siquiera lo hará en todos los visores/conversores pues si está presente alguna indicación sobre la "Codificacion" (y dejo a otros que glosen el término) se tiende a prescindir de las entidades (aunque no siempre, pero de ahí lo inseguro de su permanencia), como si te estuvieran haciendo un favor (y hay que rebuscar entre los menús la opción de "no reemplazar entidades"). En cualquier caso, el NBSP se convierte en un "espacio corriente y moliente" al cambiar a otro formato no-html (de ahí la poca universalidad de esa solución, aunque claro, quienes no van a exportar nada tampoco encontrán problema alguno).

[Nem0]

Por tanto la mejor idea es partir de un DOC o de un HTML y a partir de ahi generar el resto de los formatos. Es la estrategia que he seguido con el QualityEpub y podreis ver que los resultados son siempre buenos.
.

Estoy completamente de acuerdo... Pero solo es una condición necesaria, lamentablemente no es suficiente. Partiendo de un DOC o un HTML perfetamente se pueden perder las lineas en blanco en las conversiones (además de otras muchas incompatibilidades, alguna de las cuales has nombrado).

Para aumentar las garantías de universalidad (que sea visionable en todos lados y convertible fielmente a todos los demas formatos) también hay que cuidar la redacción de los textos. No se deben usar opciones de presentación demasiado sofisticadas, por muy bellas que resulten, y aunque ello lleve el aspecto resultante hacia la simpleza. Entre un aspecto "perfecto" pero no-universal y uno más "burdo" pero si-universal, YO me decanto hacia lo segundo (otros harán lo que quieran). Y así, muchas veces hay que conformarse con lo menos malo, asumiendo soluciones (burdas pero universales, como LINEAS SUCIAS en vez de LINEAS VACIAS) que no podrán competir en elegancia con otras más "locales".

[silicon]

Lamento no estar de acuerdo contigo. En mi opinion:
- La forma de funcionar que tiene el HTML no es una carencia ni una virtud, sino un concepto diferente.
Si quieres un retorno de carro usas la etiqueta <BR> y queda definido, sin duda alguna que este retorno debe esistir. Si deseas una linea en blanco pones una linea con un caracter blanco no eliminable. Y queda claro que ahi hay un parrafo vacio.
Esto se realizo así para que los diferentes sistemas por los que viajase la pagina no perturbaran la informacion, independientemente del numero maximo de caracteres por linea que admitieran.

-Las entidades HTML son formas de representar caracteres especiales que pudieran no estar en el teclado o que fueran mayores de 127. De esa manera se asegura que podran viajar por cualquier tipo de ordenador, aunque use 7 bits por caracter. Recuerda que la entidad &nbsp; no es un espacio en blanco (ASCII 32) si no el caracter Espacio no eliminable (ASCII 160). Si algun programa lo convierte a un espacio en blanco corriente, lo esta haciendo mal.

- La presentacion es importante, aunque ciertamente las filigranas pueden dar problemas. El problema aparece cuando el formato de destino no es capaz de soportar esa filigrana.
Pero en el caso de los formatos de libros electronicos, estos estan en UTF-8. Por tanto son capaces de representar cualquier caracter definido por una entidad html sin problemas (aunque el libro despues puede no saber representar ese caracter).
Por tanto, en el caso que nos ocupa, el conversor debe ser capaz de traducir los &nbsp; al caracter 160. Si no lo hace es porque tiene un error de programacion que deberiais reportar al programador. Seguramente os lo agradecerá.
En tu caso has optado por poner una coma. Te sugiero que pongas el caracter 160 en lugar de la coma y seguramente todo te funcionara a la perfeccion.
Otras posibilidades serian:
Caracter &ZWSP;, ASCCI 8203. Es un espacio que no ocupa nada. Por tanto es totalmente invisible.
Caracter 8202. Es un espacio estrecho. Es decir, que ocupa la mitad de un espacio normal.
Caracter 8239. Espacio no eliminable y estrecho.
Y otros mas exotericos que podras encontrar en http://www.fileformat.info/info/unic...ry/Zs/list.htm

Y finalmente insisto que los problemas suelen aparecer cuando conviertes un libro a traves de varios formatos en cascada. Lo suyo es pasar de HTML o DOC directamente al formato que queramos. Cualquier paso intermedio lleva siempre aparejada una perdida de informacion.

[silicon]

Como el movimiento se demuestra andando, nada mejor que hacer una prueba.

Descargaros este libro (no tiene derechos de autor, pues nadie sabe quien es el autor y seguramente lleva muerto casi cinco siglos):
An__nimo_-_La_vida_del_lazarillo_de_Tormes.epub - 140.1 Kb

Esta en formato epub y puedo asegurar que cumple el estandar. Contiene lineas en blanco a base de insertar el caracter &nbsp; (ASCII 160). Ojo, pues no contiene la entidad HTML sino el caracter en formato UTF-8, lo cual cumple perfectamente el estandar.

Convertirlo a FB2 y verificar si las lineas en blanco desaparecen o no. Seguramente el conversor no sea lo suficientemente bueno como para identificar las lineas que solamente tienen este caracter y convertirlas en la etiqueta "<empty-line/>", que es lo que marca el estandar FB2, pero al menos si que deberian verse como lineas en blanco. En caso de ser así, ya sabes que puedes usar esto en lugar de un apostrofe.