Cuál es el mejor formato para coolreader?

[Terisa]

Yo soy usuario de Linux. ¿Como he de llamar entonces a los RTF generados por mi sistema? ¿acaso RTF-pirata?. ¿Y la gente de Mackintosh? ¿y los de otros sistemas más raros aún? Antes de que existiera internet, RTF era el estandar (publico y libre por aquel entonces) con el que circulaban los archivos por el modem.

De la wikipedia:

The Rich Text Format (often abbreviated RTF) is a proprietary^[6][7][8] document file format with published specification developed by Microsoft Corporation since 1987 for Microsoft products and for cross-platform document interchange.^{[citation needed]}

Efectivamente, 1987 es anterior a Internet, pero sigue siendo de MIcrosoft.

Una de abuelita cebolleta: yo he conocido esos sistemas más raros aún, por ejemplo CPM 20/1. Al año siguiente ya use el DOS, y currando en el 90 en un despliegue de medios tenía el Windows 3 (ni el 3.1 oiga), con su Word... y su RTF. Y lo de los archivos por el módem circulando en RTF... y en mogollón de formatos, el formato del archivo que estás enviando no tiene nada que ver con el protocolo de intercambio de datos por el módem... que no tiene nada que ver con esto.

De todas formas, lo aclaro un poco más: igual que existe el GIF 1.0 libre, el PDF 1.0 libre, ect... tambien existe el RTF 1.0 libre (respecto al cual Microsoft no puede decir, legalmente, ni pio).

Será por fechas: 1987: RTF 1.0. No existe RTF libre en el sentido que dices, lo diseñó Microsoft, igual que el PDF tiene su origen en Adobe. Otra cosa es que luego ese estándar se publique.

De esas anectodas historicas, lo unico que puede ser de interés para el publico es que [b]la extension de un formato (pdf, doc, html) cada dia siginifica menos, puesto que salen más y más variantes. Cualquier generalizacion que se haga (la tipica "a mi el formato TAL no le vale a mi ereder") vale muy poco. Puesto que los formatos no informan (exteriormente) de su version.

Pues ahí tampoco. La incompatibilidad de formatos en Office Microsoft la ha dejado clara, ha cambiado la extensión. No tengo especial cariño a Office, pero algunas cosas las hace bien.

[Nem0]

[y aqui paso de lo de los huevos]...

Todos los word de Microsoft generan RTF genuinos

Me reafirmo en lo dicho: Si dentro del Word del Office de Microsoft grabas un documento como RTF, el resultado va a ser mucho menos exportable que si ese mismo documento lo grabas como RTF dentro del WORD PAD (el editor menor que viene de regalo con el sistema, y no confudirlo con el NotePaD/block de notas).

Pues bueno, ese el HECHO. Ahora para explicar el "¿por que?" pues lo haces en los terminos que menos conflictos logicos te provoque. Por ejemplo, en vez de calificar el RTF del Pad como genuino/primigenio/primitivo, en su lugar puedes calificar al RTF del Word como más desarrollado, más avanzado, más potente (y lo que se quiera, aunque yo insistiría en mencionar tambien que "más restringido" en el sentido de que menos dispositivos lo van a aceptar bien).

Mas consejas:
Si estas trabajando en WORD con un documento con contenidos multimedia y....
[caso-1] tienes pensado enviarselo a alguien, entonces no lo salves como DOC, no te queda otra que grabar en RTF. (puesto que hay muchas versiones de DOC y son incompatibles hacia atras y si tu amigo-receptor no tiene instalado el mismo Office que tu no lo podra ver)

[caso-2] no se lo vas a pasar a nadie, sino que es para verlo en tu eReader (que en su prospecto pone que acepta DOC/RTF), es ese caso (contenidos multedia: imagenes, links, tablas, etc..) es mejor grabarlo como DOC, pero siempre en la version más antigua que te ofrezca tu Office Word. Asi conseguiras mejores resultados que como RTF. Es una opcion poco comentada en los foros (quizá porque va contra el eslogan de que "lo nuevo es mejor", pero que funciona.

[caso-3] lo quiere para tu eReader, pero este no entiene DOC. Pues entonces has de llevarlo a un conversor (para convertirlo en fb2 o epub), y la mayoria de ellos van mejor con RTF que con DOC.

[caso-4] tu e-reader es muy simplón (y ya pido perdón ahora por el adjetivo) y no acepta ni epub ni html y el pdf lo ve fatal (o no sabes ajustarlo). Pues en ese caso separa de tu documento los contenidos especiales: imagenes y tablas, y deja solo texto. LLevalo (copiar/pegar) al Word Pad y grabalo como RTF, luego le adjuntas los JPG (imagenes) y los XLS (tablas) que le precise, metido todo dentro de un ZIP. Como metodo es muy tosco, pero es una opcion sencilla para cuando sea un texto con unas pocas imagenes, a las que mencionas como referencia en el texto (en plan "vease imagen tal y cual").

* * *

... yo hago un RTF y vosotros los probais. Asi detectamos las incompatibilidades y las sorteamos. Probablemente se puedan incluir muchas cosas en el RTF, aparte del texto puro y duro, sin perder compatibilidad. ¿Estas por la labor?

Por mi....te adelanto algun trabajo:
LO QUE FUNCIONA SEGURO:
---Fuentes y tamaños de texto (aunque yo recomendaria atenerme a las familias basicas)
---Efectos clasicos: negrita, cursiva, subrayado. (el tachado lo retiraria, lo mismo que el efecto sub/supra indice). Y desde luego nada de efectos novedosos: sombras, sobrerayados, falsas-mayusculas, ect..
---Alineamientos de parrafo (izquierda, centro, derecha). Hay que renunciar al AJUSTADO, y tambien a las VIÑETAS.

LO QUE SUELE FALLAR EN UNA CIRCUSTANCIA U OTRA:
---Interlineado. (en caso de usarlo, que sea Unico para todo el documento, no andar a variarlo).
---Identacion. (Olvidarse de las sangrias y de jugar con los margenes, y rezar para que sobreviva la identacion de la primera linea).
---Guion largo.
---Todo objeto no textual (la ya dichas imagenes, tablas, links, notas pie pagina, ect..).

[Nem0]

_____
NOTA:
Todas las consejas anteriores son para usuarios de Windows.
Para los usarios de Mac y Linux....

Si tu RTF es de solo texo no hay mayor problema, pero como tenga imagenes o links entonces...
---Si vas a leerlo en un eReder o dispositivo similar con el icono "manzana"... no problemo.
---Si vas a enviarselo a alguien que usa Linux o Mac.... no problemo.
---Si vas a enviarselo a alguien que usa Windows... malo, malo. Para saltarse el bloqueo o bien quitas las imagenes (dejándolo "generico") o bien lo grabas al modo Microsoft, para ello recomiendo el OPEN OFFICE.
---Si no sabes a donde va a ir a parar... mejor que lo conviertas a otro formato. Aunque aviso que el CALIBRE no os va a funcionar (salvo que previamente "normalices" ese RTF con open office")

_____
NOTA:
Si eres usuario de Windows y alguien te pasa RTF no-Microsoft, en general ni te darás cuenta salvo que contenga objetos especiales. En ese caso recomiendo que ejecutes el WINRAR y lo abras con su navegador: lo visualizará como una carpeta.... con texto e imagenes por separado.

[silicon]

Me reafirmo en lo dicho: Si dentro del Word del Office de Microsoft grabas un documento como RTF, el resultado va a ser mucho menos exportable que si ese mismo documento lo grabas como RTF dentro del WORD PAD (el editor menor que viene de regalo con el sistema, y no confudirlo con el NotePaD/block de notas).

Pues bueno, ese el HECHO. Ahora para explicar el "¿por que?" pues lo haces en los terminos que menos conflictos logicos te provoque. Por ejemplo, en vez de calificar el RTF del Pad como genuino/primigenio/primitivo, en su lugar puedes calificar al RTF del Word como más desarrollado, más avanzado, más potente (y lo que se quiera, aunque yo insistiría en mencionar tambien que "más restringido" en el sentido de que menos dispositivos lo van a aceptar bien).

La cosa no tiene ningun misterio.
Tal y como he comentado en el mensaje precedente hay 9 versiones diferentes de RFT. Segun ha ido pasando el tiempo el formato ha ido dufriendo actualizaciones que implementan nuevas caracteristicas (algo asi como lo que ha ocurrido con el HTML). En concreto tengo noticias de las siguientes:

1987: RTF 1.0
1993: RTF 1.2
Enero de 1994: RTF 1.3
Abril de 1997: RTF 1.5
Mayo de 1999: RTF 1.6
Agosto de 2001: RTF 1.7
Abril de 2004: RTF 1.8
Marzo de 2008: RTF 1.9.1

Ya en el RTF 1.0 se incluia el soporte de imagenes (en concreto imagenes BMP) usando notacion hexadecimal. Por tanto un lector de RTF que no soporta imagenes no se puede decir que sea compatible RTF, pues este formato SIEMPRE las incluyo.
El siguiente gran cambio fue en la version RTF v1.5
En esta version se recomendo no usar BMP e incluir las imagenes como JPG y PNG. Ademas se dio soporte a un sistema para representar caracteres unicode. En esta version hay soporte de texto justificado, notas al pie, tablas, listas y margenes. Como principal limitacion, no se soportan tablas embebidas (tablas dentro de otras tablas)
Fijate que esto hablando de una especificacion del año 1997. Sacar un lector en el año 2008 (nacimiento de los primeros lectores de tinta electronica) y no soportar estos elementos es algo vergonzoso. Pero no tan vergonzoso como tener la cara de decir que es compatible RTF cuando no se cumple una especificacion que ya tiene DIEZ AÑOS de antigüedad.

Cuando un dispositivo dice que es compatible con un formato debe leer correctamente cualquier archivo que cumpla la especificacion de ese formato. Y por lo que cuentas, la triste realidad es que no lee ni la especificacion de hace diez años.
Esto, en mi opinion, solo indica que el fabricante del dispositivo MIENTE descaradamente. Le otorga a su producto unas caracteristicas que no tiene como cualquiera puede comprobar en menos de una hora. Esto, señores, se llama ESTAFA.

Imaginate que te venden un tablet que navega por internet y dice soportar el HTML. Pero despues de una breve prueba te encuentras con que no soporta la etiqueta <SUP> o no es capaz de representar las imagenes en PNG. ¿Pensarias que es problema del generador de la pagina web? ¿O pensarias que el fabricante te esta tomando el pelo?


Y se que no estaras de acuerdo y por tanto voy a ponerte en ejemplo:
En http://www.snake.net/software/RTF/ puedes ver las especificacion del formato v1.3 (año 1994). Veras que hay un comando muy sencillos y que no se puede malinterpretar:
\qj Que indica que se represente el texto justificado.
\qc Que indica que se represente el texto centrado.
\ql Que indica texto alineado a la izquierda.

Curiosamente estos comando SIEMPRE han existido en RTF, incluso en su primera version. Ademas no tienen nada exoterico en su representacion. Si despues de pone \qj el texto no se justifica a mi me parece que tiene mas que ver con la incapacidad del programa lector que con lo arcano de la especificacion.

[silicon]

Y, si te parece, dejamos de discutir sobre el sexo de los angeles, pues no creo que nos lleven a nada util.

Aqui te dejo el primer RTF de prueba:
An__nimo_-_La_vida_del_lazarillo_de_Tormes.rtf - 281.2 Kb
Basicamente contiene:
- Parrafos.
- Cambios de tamaño de fuente
- Negritas
- Cursivas
- Margenes (los mismos para todo el documento)
- Sangria en primera linea.
- Todos los caracteres mayores de 127 codificados como UTF-16. No se usa codificacion abreviada.
- Una imagen PNG codificada en hexadecimal.
- Estilos, aunque deberian ser totalmente transparentes para lectores que no los soporten.
- Saltos de pagina
- Formato monoarchivo, sin usar carpeta para imagenes, sin compresiones raras, sin ningun byte que supere el ASCII 127, sin encabezados ni pies de paginas, sin fuentes embebidas y sin tabla de colores. Vamos, de lo mas estandar que se puede crear.
Si no le encuentras incompatibilidades podemos decir que ya tenemos solucion para mas de la mitad de los libros.

Os agradeceria que me realateis las incompatibilidades que encontreis.

[enrique7777]

Y, si te parece, dejamos de discutir sobre el sexo de los angeles, pues no creo que nos lleven a nada util.

Aqui te dejo el primer RTF de prueba:
An__nimo_-_La_vida_del_lazarillo_de_Tormes.rtf - 281.2 Kb
Basicamente contiene:
- Parrafos.
- Cambios de tamaño de fuente
- Negritas
- Cursivas
- Margenes (los mismos para todo el documento)
- Sangria en primera linea.
- Todos los caracteres mayores de 127 codificados como UTF-16. No se usa codificacion abreviada.
- Una imagen PNG codificada en hexadecimal.
- Estilos, aunque deberian ser totalmente transparentes para lectores que no los soporten.
- Saltos de pagina
- Formato monoarchivo, sin usar carpeta para imagenes, sin compresiones raras, sin ningun byte que supere el ASCII 127, sin encabezados ni pies de paginas, sin fuentes embebidas y sin tabla de colores. Vamos, de lo mas estandar que se puede crear.
Si no le encuentras incompatibilidades podemos decir que ya tenemos solucion para mas de la mitad de los libros.

Os agradeceria que me realateis las incompatibilidades que encontreis.

CoolReader 3.0.57-15 Debian 10/10
Saludos

Edito

cr3.1.0-14 Sony Prs T1 10/10

mas saludos


Edito de nuevo

Cool Reader 3.0.55.39_solsticio

Falla en UTF-16

y también con el Fbreader en papyre 6.1 con OpenInkpot

[Nem0]

---Con los COLORES no va a haber problemas (los dispositivos de solo B/n los ponen en negro y listo).
---Los estilos serán ignorados.
---Imagenes... o no las leen o, peor, bloquean la carga del archivo. Incluso los pocos que las leen, agotan enseguida la memoria (han de ser pocas imagenes). Curiosamente las BMP van mejor en Windows que la PNG, mientras que en otros dispositivos es al revés.
---Codificacion... No jugar con ella. Usense las ENTIDADES del lenguaje. ESO y media docena de comandos es lo unico que lo hace universal al RTF.
---Vigilar que las Fuentes vayan generalizadas (con /fswiss /fmodern y /froman en la fonttable). Lo digo porque el soft de programacion MODERNO de Microsoft (> visual estudio 2010) tiende a usar /fnil (es decir, dejar sin definir sus familias)
---Vigilar la Identacion. Lo digo porque el soft de programacion ANTIGUO tendía a equiparar sangría e identacion del la 1º linea... resultando un borde izquierdo continuo.

[Nem0]

Al seguir la especificaciones rtf-de-Microsoft (las que sean) ya puedes olvidarte de la universalidad. Lo unico que garantizan es que ese rtf será legible por el WORD OFFICE, puesto que ASI es como funciona internamente (el DOC lo usa como formato de almacenamiento, su motor de trabajo es ESE rtf). Por suerte, para los usuarios de distintas plataformas, ese tipo de RTFs no son del todo inútiles, pues el editor libre OPEN OFFICE ha asumido la filosofía de ser el clon del Word, y es él quien hace el verdadero servicio de exportar documentos entre plataformas interpretando esos rtf y permitiendo pasarlos a formatos locales. Pero el resto de software (incluido el de Microsoft) no está preparado para semejantes desarrollos, y mucho menos las plataformas poco potentes (eReaders, tabletas, moviles...).

* * *

Respecto a ese archivo-RTF, ojeando su código veo dos elementos de riesgo:
---usar estilos. (por experiencia ya sé que van a ser ignorados, pero no son peligrosos)
---usar las nuevas entidades unicode. (por su causa le doy un "paseo completo" a ese rtf, más que nada para comprobar si el OPEN OFFICE y el WORD-PAD aguantan bien esas entidades, pues son los programas que recomiendo en materia de exportación de RTFs)


__________________
LINUX\Mandriva
------------------[Open Office 3.2]
imagen: SI
alineamiento justificado: BIEN
identacion: BIEN
guion largo: BIEN
lineas vacias: PRESENTES
paginado: PRESENTE
salto cabeceras capitulo: NO

__________________
LINUX\Ubuntu
------------------[Open Office 3.2]
imagen: SI
alineamiento justificado: BIEN
identacion: BIEN
guion largo: BIEN
lineas vacias: PRESENTES
paginado: PRESENTE
salto cabecera capitulo: NO
(cabeceras INESTABLES)

__________________
LINUX\loculinux
------------------[Open Office 3.2]
imagen: SI
alineamiento justificado: BIEN
(incluso con guion virtual al borde)
identacion: BIEN
guion largo: BIEN
lineas vacias: PRESENTES
paginado: PRESENTE
salto/cabecera capitulo: NO

__________________
LINUX\GPU clasica
------------------[Open office 1.0]
imagen: SI
aliniemiento justificado: SI
(sin guion virtual)
identacion: BIEN
guion largo: NO (aparece "?")
lineas vacias: PRESENTES
paginacion: PRESENTE
salto cabecera capitulo: NO

__________________
WINDOWS 9x/ME
------------------[Word Pad]
imagen: NO
alineamiento justificado: NO
identacion: BIEN
guion largo: INESTABLE
(se deja ver la 1º vez, pero no editar)
lineas vacias: PRESENTES
paginacion: NO

__________________
WINDOWS XP
------------------[Word Pad]
Imagen: NO
alineacion justificada: NO
identacion: BIEN
guion largo: BIEN
lineas vacias: PRESENTES
paginacion: NO
------------------[Microsoft Word 2003]
Todo BIEN
------------------[Microsoft Word 2007]
Todo BIEN


* * *

___________
CONCLUSION:

En resumen, NO TIENE DEFECTOS SERIOS. Lo unico que le veo cuestionable es que se trate de un rtf "estandar", como el hecho por cualquier procesador PROFESIONAL... con sus mismas pegas, no es lo suficientemene "elemental", es el caso habitual para el que viene bien el consejo de "pasarlo por Word-Pad para simplificarlo" y que pueda entrar alli donde no entraba.
El resultado es este... http://www2.zshare.ma/kbgy9u1vnslk


_____
NOTA:
(un símil histórico)

En su día nadie llamó estafadores a los de Microsoft por que su navegador no siguiera todas las especificaciones del WWW-Consorcium. Los programadores de Webs fueron pragmaticos: en vez de guiarse por el W3C (y luego clamar al cielo por el inevitable fracaso) se limitaron a coger las etiquetas que tenían en común los navegadores de la época (Explorer, Netscape, Lynx y otras antiguallas) y confeccionar solo con ellas paginas-web válidas para todos.
Incluso hoy en día, los navegadores modernos tienen dos modos de funcionamiento: el "normal", con las últimas innovaciones en el lenguaje HTML; y el de "bajo mínimos" para ejecutar paginas viejas o cosas raras que se encuentren.

Sacando conclusiones de aquella situación... A quienes les interese hacer un RTF que pueda leer cualquier dispositivo, entoces ha de evitarse toda complejidad. Da igual que sea "legal", a nadie le importa si es fiel a las patentes de desarrollo de Mic. de Mac o de Java, al usuario lo que le importa es que funcione. No le puedes decir que es "culpa" de su lector, que no lee bien rtfs, por que te contesta "que de eso nada, que ya ha leido rtfs con él, y que lo que no va bien es el rtf que tú le das".
Y... ¿Hasta donde simplificar? --pues hasta quedar en planteamientos y prestaciones similares al BBCode; y además sin objetos: solo texto y sus efectos.


_____
NOTA:
(Sobre imagenes y otros objetos)
En mi opinion, las imagenes son prescindibles en el 99% de las NOVELAS... esa portada (y todas) podría haber ido perfectamente FUERA de la novela, lo que no afectaría en nada a su lectura. Donde sí pueden ser necesarias imagenes insertadas es en los manuales/tratados/ensayos y demás texto explicativo. Para ellos la opción universal es el HTML (pero las versiones clasicas, o evitando usar/abusar del CSS) o, si no, que usen PDF.


_____
NOTA:
(Sobre las CODIFICACIONES)

En principio, no hay que preocuparse NI por la codificacion en que se emitió el rtf NI por la codificación que use el receptor. El RTF es de los tiempos de comunicaciones a 7 bits... y por ello su TXT de base solo va a usar la parte baja de la-tabla-que-sea (es la parte segura/universal). Asi que, si no se da orden explícita de anular las ENTIDADES entonces todo va a ir bien a ese respecto (es una de las pocas cosas que funciona al 100%). Si algun eReader no lo lee, no es por culpa de eso (y tambien podeis ahorraros el trabajo de modificar la codificacion del propio eReader, pues no le va afecar en nada a un RTF normal), no es comparable al caso de los HTML y sus derivados modernos.

Ahora bien, a un RTF se le puede "forzar" a dos cosas:
---Obligarlo a NO usar entidades... la consecuencia es que si la codificacion del receptor no coincide con la del emisor entonces las LETRAS ESPAÑOLAS (eñes, acentos, ect) se verán mal. Pero el rtf sí que se ejecuta, no queda bloqueado por eso.
---Obligarlo a usar el NUEVO LOTE DE ENTIDADES UNICODE (que fue lo que se hizo en este rtf). Su peor resultado vendría a ser el mismo que el anterior (supongo, nunca lo he visto).

Y, otra cosa relacionada con esto: los rtf también aguantan BIEN el paso HACIA entornos verdaderamente UNICODE (caso del Java). Como en los demás casos, los problemas los provocan los objetos que se metan dentro del rtf, y no se deben a la diferencia de codificaciones.

[silicon]

Estupendo analisis del fichero. Quiero darte las gracias por anticipado.

Por tu mensaje deduzco que has analizado el codigo. Te habras dado cuenta de que no esta generado por ninguna dll u ocx de un lenguaje de programacion. Esta hecho "a pelo", lo cual permite decidir exactamente que es lo que se va a usar.

De tu analisis deduzco:
- Que el metodo de insertar y codificar las imagenes es el adecuado. Aparentemente en tus pruebas se muestras las imagenes con la excepcion del wordpad antiguo, que hasta donde conozco no soporta las imagenes (se las pongas como selas pongas). Aun en ese caso son ignoradas y no ocasionan problemas.
- El justificado tambien parece funcionar con la unica salvedad del worpad antiguo. Este editor no soporta justificado independientemente de como se codifique.
- El guion largo parece dar algun problema. Supongo que por que se trata de un caracter unicode que no tiene representacion en alguno sistemas. Puedo proponer un caracter alternativo en el caso de que el guion largo no se pueda mostrar. ¿El guion corto estaria bien?
- La paginacion no la defino en el RTF. Por tanto cada editor la mostrara como mas le convenga, si es capaz de mostrar alguna. Por tanto los resultados has obtenido son razonables. Creo que especificarla solo puede empeorar las cosas, pues diferentes dispositivo admiten diferente numero de caracteres por pagina.
- El salto de cabecera de capitulo parece lo pero. La mayoria de los sistemas parecen incapaces de entenderla.
La codifico como un salto de pagina forzado (comando \page). ¿Podrias enviarme una muestra de como lo hacen las open office?

[Nem0]

... El salto de cabecera de capitulo parece lo pero. La mayoria de los sistemas parecen incapaces de entenderla. La codifico como un salto de pagina forzado (comando \page). ¿Podrias enviarme una muestra de como lo hacen las open office?

Sobre la etiqueta \page también es la que usa OPEN OFFICE (la version Windows funciona por dentro igual que las otras), tanto en windows como en Linux. Si no funcionó bien creo que se debió a alguna mala interacion con los estilos. Me baso es esta comprobación:
http://www2.zshare.ma/rgszh4ok2k41
---caso-01: lo grabo en windows con O.Office (quien respeta los estilos) y lo llevo a Linux-ubunu... resultado (A) no funciona, y (B) es inestable (se deterirora aún más al grabar alli).
---caso-02: lo grabo en windows con el WordPad (lo que simplifica al minimo los estilos, y respeta la orden \page aunque la ignora al visualizar), y lo llevo a Linux... resultao (A) funciona, y (B) es estable (se mantiene aunque el archivo se edite/regrabe).

* * *
Más cosas...
---El guión largo no tiene remedio a nivel de código. Usa la entidad que quieras, cuando falla ya suele quedar un guión corto. Solo en casos muy raros salen caracteres extraños (y el usuario los puede reemplazar en masa), con lo que incluso ESO es preferible a la alternativa de que no salga nada (ya no tendría recuperación).
(Es decir, NO son un buen candidato a los condicionales \* pues funcionan en plan "esto o nada" y NO en plan "esto o sino aquello")
Pero también hay otros caracteres peligrosos:
---El punto-triple debe sustituirse por tres puntos (...), pues no tiene codificacion 8 bits y cuando falla no queda nada (bueno, algunas veces queda un guión corto).
---Prescindir de las variedades nuevas de comillas superiores y usar solo las normales (" ")
---También puede haber peligro en la codificación de las comillas anguladas (« »): Sé cierto que sus entidades clasicas SON seguras; pero, por otro lado, los formatos-TXT que provienen-de-unicode suelen perder esas comillas anguladas... Así pues, lo que no sé es si son seguras las entidades unicode de las angualadas (el libro de prueba no llevaba).
---Tambien son peligrosos los párrafos que llevan asociados un "lote especial de TABIQUES". Quien los maqueta nunca cae en la cuenta de que no todos los dispositivos tienen el mismo ancho de pantalla, o que no admiten bien la redifinición de posiciones de salto.

* * *

Trabajando sobre el código-rtf solo se puede "robustecer" un documento hasta cierto punto. El resto de medidas que se pueden tomar ya son a nivel de redacción de texto. Por ejemplo:
---será el usuario el que decida si correr el riesgo de usar el objeto "NOTA a pie de pagina", o bien (si está escarmentado) redactarla como "nota a pie de parrafo" (que no es más que un texto normal al que le ha diferenciado la letra, tamaño u otros efectos), o si es muy extensa redactarla como "nota a final de capítulo".
---será el usuario el que decida si para presentar unos pocos datos merece la pena recurrir a un objeto TABLA, o bien redactar una pseudo-tabla usando una fuente monospace (como la Curier).
---Con el guion largo, lo mismo. Si su eReader los va a cambiar por sencillos, entonces puede ordenar previamente un reeplazo masivo por un guion doble (--) o triple (---) dependiendo de lo compacta que sea la fuente que usa.
---Respecto a las cabeceras... la opción segura es ponerles por encima unas cuantas líneas vacías. No fiarse de los cambios en el interlineado, ni de los viejos controles (caracteres por debajo de 32) ni de los comandos. E incluso la propia línea vacía no es segura (cuando se exporta hacia formatos html), con lo cual nunca está demás añadir composiciones txt DECORATIVAS: yo siempre marco las pausas (* * *), y sobre-rayo los capítulos (__________).