Cosas Interesantes

miércoles, 30 de junio de 2010

El PAPYRE 6.S ALEX, lo mejor de ambos mundos en “Navegación Dual” (Duet Navigation)

¿Qué es el PAPYRE 6.S ALEX? logo[1]
El PAPYRE 6.S ALEX es el branding que GRAMMATA utilizará para su distribución del SPRING ALEX DS-10. En la pasada feria CES 2010 (de la cual publicamos alguna noticia en este BLOG) fue uno de los diseños de e-reader que recibió premios de la crítica como diseño más innovador.
La innovación se centra básicamente en su form factor con display dual, con una pantalla de tinta electrónica EPD de 6” que se complementa con una pantalla LCD de 3,5”. Es un diseño original, pero no único ya que Nook y algún otro lo comparten. (SPRING ha emprendido una demanda de propiedad intelectual contra Barnes&Noble).
Así pues el dispositivo es un ebook pegado a un pad mobile. Pero la gracia es que no está meramente pegado, sino que ambas mitades del dispositivo trabajan en colaboración, de forma integrada. Mediante un botón físico SYNC/UNSYNC podemos hacer que ambas pantallas trabajen conjuntamente o no. Parece magia potagia.
Esta tecnología se llama “Duet Navigation
¿Cómo se consigue la magia del PAPYRE 6.S ALEX?
El dispositivo arranca y carga un sistema operativo ANDROID v1.6 en la pantalla LCD y aparece el escritorio con los iconos de las aplicaciones existentes. Mientras en la pantalla EPD se ha cargado un contenido estático, un “salvapantallas” que puede ser un logo o un práctico croquis del dispositivo con sus componentes. Y ya estamos listos para trabajar.

Empezaremos curioseando la pantalla LCD que manejaremos con los dedos, de forma sencilla. No es el multitouch sofisticado del iPhone, pero funciona eficientemente. La única tecla física que necesitaremos usar mientras operemos la mitad LCD, es la tecla de retroceso o ESC, para retroceder un paso o salir de la aplicación en curso. El tacto de las teclas físicas es de calidad, en armonía con el acabado general de la máquina.

La navegación Dual o Duet Navigation
El funcionamiento no puede ser más sencillo. Cuando estemos en una aplicación de lectura, el modo por defecto será SYNC (en sincronía) mostrando ambas pantallas de forma cooperativa la aplicación. O sea, el texto en la EPD y las opciones de contexto (tamaño de fuente, marcadores, TOC, librería, etc.…) en la LCD. Para avanzar por el texto usaremos las teclas físicas DCHA/IZDA.
Pero si queremos mostrar el texto en la pantalla LCD, deberemos pulsar UNSYNC. El texto entonces podrá avanzar con las teclas físicas o con los dedos en la pantalla LCD. Una pulsación SYNC volverá a mostrar el menú en la pantalla LCD.

Pero la cosa se pone más interesante cuando utilizamos una aplicación “no dual por defecto” como el navegador. Empezaremos la sesión en la pantalla LCD. El navegador es el estándar del sistema operativo ANDROID DONUT que nos permite desplazarnos con movimientos de dedo. Una pulsación larga, invocará los controles de ZOOM (VOLVER a 1x, AUMENTO, DISMINUCIÓN). Al pulsar sobre una caja de texto aparecerá el teclado virtual, de manejo sencillo y eficiente, sin las virguerías de sensibilidad al contexto propias del iPhone, pero adecuado y más que cómodo en el uso. El único fallo que le encuentro al navegador es la imposibilidad de teclear directamente en la barra de URL, que es de sólo lectura (o yo nunca he sido capaz de teclear directamente en ella.) La visualización de las páginas es muy buena.
Pues bien, hasta ahora sólo he visto la web en la pantalla LCD. Un toque de SYNC y la pantalla EPD mostrará la web en pantalla grande con un retardo mínimo y buena calidad de visión. Incluso en páginas con contenidos dinámicos, tales cómo gráficos GIF con animaciones, la pantalla EPD visualiza con toda fidelidad la web y en tamaño “grande”. Mientras, abajo, en el LCD tendremos una visión más “zoom” de la página apropiada para ver el detalle; y además lógicamente en color. Un simple gesto de los dedos, y se presenta un visión completa de la página en LCD, para realizar movimientos largos (desde el principio al final de una página larga, por ejemplo); un toque y vuelves a la visión “focalizada”

Y si pensáis hacer turismo…
Este es un POST viajero ya que lo lanzo desde Florencia, Italia, preciosa ciudad donde estamos pasando unos cortos días de vacaciones. No es que tuviera previsto actualizar el BLOG durante el viaje, pero el Hotel Davanzati me lo ha puesto muy fácil.
Además de 2 cuentas de acceso al Wi-Fi libre del hotel, la habitación dispone de un portátil laptop DELL con Windows Vista; 2 TVs de pantalla plana cada una equipada con su AZBOX con contenidos de estreno, audio, video y

satélite gratis total; y de postre una PLAYSTATION 2 para la que puedes pedir juegos en la recepción. No he visto un despliegue tecnológico tal en ningún hotel 5 estrellas superlujo de los que he estado. Puedes incluso ver las fotos de tu propia cámara, la conexión es sencillisima. Y repito, los contenidos (peliculas de estreno, por ejemplo) gratuitos.

Además la habitación es amplia, confortable, el aire acondicionado funciona como un cañón y todo está nuevecito. El cuarto de baño incluye una ducha independiente, amplia y cómoda. Y un sofá convertible en una cama de verdad; no de las que se deja uno la espalda como suele ser habitual.
Por una vez, el TripAdvisor ha acertado de pleno. Se ve que es un negocio familiar regentado con mucho gusto, imaginación y atención al detalle.
El hotel está situado en el mismísimo centro, a 5 minutos de TODO lo que hay que ver en la ciudad histórico-artística.
Todos los días de 18:30 a 19:30 hay “Hora feliz" con espumosos y snacks gratis para deleite de los guiris residentes. Si tenéis previsto venir por estos lares (preciosa ciudad) es una opción muy recomendable y no es nada caro. Comparado con los precios de Madrid resulta hasta barato.
Una buena recomendación si pensáis venir para acá.

domingo, 27 de junio de 2010

Las buenas prácticas de LARdT (BBPP LARdT 1.0) para crear un libro electrónico ePUB decente. (Cap. 01)

A veces un ebook te puede volver loco

Todos los que disfrutamos con la lectura; y además lo hacemos en electrónico de vez en cuando, sufrimos una decepción cuando después de descargar ese título que nos apetecía leer resulta que es casi ilegible debido a que su calidad como libro electrónico es infumable. Por eso, con el tiempo, he ido desarrollando un conjunto de buenas prácticas que me permiten generar los libros electrónicos en ePUB con una calidad razonable.
Dentro del proceso de generación/conversión de libros electrónicos en ePUB, la mayoría de lo que comentaremos en esta serie de POSTs son ítems de sentido común, otros muchos temas estarán muy determinados por el conjunto de herramientas que utilizo y pueden perder validez en otros escenarios diferentes; y seguro que gran parte de mis recomendaciones son mejorables. Pero en cualquier caso, creo que pueden resultar prácticas para todo el que tenga interés en la calidad de su biblioteca digital. Así pues, vamos a empezar a explicar que son las buenas prácticas de LARdT para crear un libro electrónico ePUB decente (en adelante, BBPP LARdT 1.0).
Podéis estar seguros de que los títulos de la BIBLIOTECA de “Mi PAPYRE 6.1 Reader para ebooks” están confeccionados siguiendo en lo posible, el conjunto de BBPP LARdT 1.0

El Primer Mandamiento: siempre en formato ePUB
Los PDFs son estupendos y yo los utilizo para un montón de cosas, el FB2 es practico, poseedor de una arquitectura sencilla pero flexible y potente al mismo tiempo; y sobre todo tiene herramientas que permiten tanto la generación (BOOK DESIGNER) como la lectura (COOLREADER) de libros electrónicos de gran calidad. Pero el ‘único formato libre, soportado por la industria como estándar para el libro electrónico es el ePUB. Por eso, para ser un buen ebook tendrá que ser ePUB. En el conjunto de estándares y procedimientos recogidos en las BBPP LARdT 1.0, ebook y ePUB son prácticamente sinónimos.



Más presupuestos previos y metodología
Siempre partimos de un escenario en el que tenemos un texto en un formato digital cualquiera distinto de ePUB y lo convertimos, mejorándolo en el proceso. Para describir este procedimiento vamos a modelizar la realidad distinguiendo 3 FASES, (aunque podríamos haber elegido cualquier otro número):

Pre–proceso: tareas previas o preparatorias a la conversión al formato ePUB
Procesamiento o Prensa ePUB: al final de esta fase debemos disponer de nuestro texto como libro digital ePUB correctamente formado.
Pos–proceso: tareas finales y ajustes a realizar sobre el libro digital en formato ePUB para alcanzar el nivel de calidad deseado.

Aunque hablaremos de cada fase con más detalle, baste para este primer capitulo comentar que el grueso o la importancia del trabajo se ha ido desplazando desde la primera a la tercera fase. A día de hoy, y como normal general intento minimizar la necesidad de  realizar  trabajos de preprensa.

Pronto seguiremos comentado con mayor detalle las buenas prácticas de LARdT para crear un libro electrónico en ePUB decente o BBPP LARdT 1.0.

Continuamos con el Cap. 02 de las BBPP LARdT 1.0

viernes, 25 de junio de 2010

Todo lo que siempre quiso saber sobre el formato ePUB de sus ebooks y nunca se atrevió a preguntar (Cap. 03)

LOGO Oficial ePUB

Estábamos explicando el detalle de lo que hay dentro

de un ePUB en el

Capítulo 02

de la serie. Un archivo ePUB viene a ser algo parecido a esto:

ePUB File:.    
│ mimetype

├───META-INF
│ container.xml

└───OEBPS
content.opf
│ toc.ncx

├───Images
│ img0001.jpeg
│ img0002.jpeg
│ …...
│ img0007.png

├───Styles
│ style001.css

└───Text
content001.xhtml
content002.xhtml
content003.xhtml
...
content026.xhtml
content027.xhtml
content028.xhtml



PAPYRE STREET




Y habíamos terminado de describir que es y para que vale el archivo “content.opf”.


Así pues, retomamos la explicación sobre:



La estructura y contenido de un fichero ePUB

Nos habiamos quedado a punto de comentar CLICK para IMAGEel archivo
- toc.ncx: que como indica su nombre controla la tabla de contenidos (índice) del libro. Controla lo que se muestra en el panel izquierdo (generalmente) de los programas de lectura (CALIBRE, LUCIFOX, ADE, etc…)



image
 
El uid debe coincidir con el registrado en “content.opf”.
doctitle: lo contenido por esta etiqueta aparecerá como título del libro en el programa de lectura, aunque no coincida con lo registrado en los metadatos de “content.opf”.
La etiqueta navpoint marca el listado de capítulos, siendo el nombre del capítulo, el texto adjunto y el src (source) el archivo vinculado que incluye el contenido de ese capítulo.
El atributo “playOrder” de la etiqueta navpoint indica el orden de lectura que ese capítulo supone en el hilo narrativo del libro.

Curiosamente, según las especificaciones el “id” de un capítulo puede ser cualquiera cosa, pero evidentemente será mucho más fácil darle el mismo “id” (identificador único) que ya usamos para el archivo que contiene el capítulo en el fichero “content.opf” (ver Capítulo 02) para evitar liarse.
Además, algún programa de lectura es posible que no muestre correctamente el índice o TOC del libro; o simplemente se vuelva loco si los “id”s no coinciden en los 2 archivos (toc.ncx y content.opf)

También es de Perogrullo pero los valores de playorder tienen que estar en orden. (Un ítem con playorder 1 siempre deberá estar antes que el ítem con el playorder 2)
Tampoco son aconsejables los “huecos” en el playorder, generan errores de aplicación durante la lectura.

- styles.css: puedes usar una hoja de estilo CSS para formatear la presentación de estilo de tu libro.

  Pero el archivo debe estar listado en el manifiesto de “content.opf” o no funcionará. 
CLICK para IMAGEN 

 

- archivos xhtml: son el texto del libro, el contenido; y deben ser documentos XML 1.1. Puedes tener tantos archivos como capítulos (o más) o tener el libro entero en 1 sólo archivo con marcadores que indiquen la separación de los capítulos. Evidentemente, es mejor que coincida con la división en capítulos.

CLICK para IMAGEN y básicamente, esto es lo más importante que hay que saber sobre en archivo ePUB.
Parece más complicado de lo que es en realidad.

Y recordad, niños, esto es CERCA image1 y esto es LEJOS image31
jueves, 24 de junio de 2010

Todo lo que siempre quiso saber sobre el formato ePUB de sus ebooks y nunca se atrevió a preguntar (Cap. 02)

LOGO Oficial ePUB La estructura y contenido de un fichero ePUB
En Todo lo que siempre quiso saber sobre el formato ePUB (Cap. 01) empezabamos a analizar en detalle el contenido de un archivo ePUB. Veamos la estructura en detalle:

ePUB File:.    
│ mimetype

├───META-INF
│ container.xml

└───OEBPS
content.opf
│ toc.ncx

├───Images
│ img0001.jpeg
│ img0002.jpeg
│ …...
│ img0007.png

├───Styles
│ style001.css

└───Text
content001.xhtml
content002.xhtml
content003.xhtml
...
content026.xhtml
content027.xhtml
content028.xhtml

     




He cogido un libro cualquiera y lo he destripado. Y Coco nos va a ir contando que es PAPYRE STREETcada cosa: 
Por cierto, los nombres de los archivos distinguen entre mayusculas y minusculas, asi que ojito. 
el archivo mimetype





Es un archivo de texto que como su propio nombre indica declara explicitamente que el archivo es un ePUB y no otra cosa. Dentro Coco profesorcontiene SIEMPRE una única frase:



"application/epub+zip"






que sirve para que el sistema operativo no se confunda y crea que es otra cosa en lugar de un archivo ePUB (por ejemplo un archivo ZIP). Para que funcione, este archivo tiene que estar situado el primero de la lista (físicamente, dentro del contenedor) y además sin comprimir, para que pueda ser leído por el sistema operativo o la aplicación de lectura sin dificultades.









el directorio META-INF




Este directorio contiene el archivo “container.xml” que indica a la aplicación de lectura dónde se encuentra el texto del libro, indicando la ubicación del archivo “content.opf”. Este directorio es identico para cualquier libro ePUB.


CLICK para IMAGE 





 



directorio OEBPS


Como podeis ver es LA UBICACIÓN RECOMENDADA (no deja de ser curiosa esta relajación del estándar; las especificaciones de IDPF no obligan a que el libro esté aquí dentro pero hay lectores que no funcionan si no lo encuentran en este directorio) para el contenido del libro, incluyendo las imágenes en su directorio correspondiente.


Puedes ubicar el contenido del libro en otro sitio, siempre y cuando indiques en el archivo “container.xml” donde queda situado “content.opf”, que a su vez desarrolla el detalle de dónde están los componentes del libro.


Dentro de OEBPS tendremos:


             - Directorio images: con los archivos gráficos (portada, ilustraciones, …) del libro.




             - Content.opf: este archivo XML debe recoger una lista de todos los archivos incluidos en nuestro contenedor ePUB (y EL ORDEN en el que van); y muy importante, los metadatos (autor, género, …) 
Veamoslo en contexto:


CLICK para IMAGE 
Podría tener cualquier otro nombre, siempre y cuando esto se refleje en “container.xml”. De hecho, los ebooks procedentes de FEEDBOOKS, tienen como “firma” característica ciertas variantes sobre la estructura ePUB común. Una de estas diferencias es llamar al fichero que hace el papel de “content.opf”, “fb.opf






Los metadatos

Son esa información que sirve para distinguir entre un ePUB hecho con cariño y otro hecho “a lo que salga”; además de ofrecer información sobre el libro contenido en nuestro archivo ePUB. Y se encuentran DENTRO del fichero “container.xml”. Los que no pueden faltar son: 
dc:title – Título del libro


dc:language – Idioma del libro, según la codificación de la lista RFC 3066. dc:identifier – Código identificador único del archivo ePUB. Cada fichero ePUB tendrá uno distinto (distintos ePUBs sobre el mismo libro, distintos ids). Normamente es generado por el programa dónde cambiamos de formato nuestros ebooks; pero si generamos un ePUB desde cero, sería una buena práctica incluir el ISBN como parte del código.


Puede haber muchas clases de metadatos posibles; que recogen todo tipo de información sobre la obra literaria incluida en nuestro ePUB.






El manifiesto

Como vemos en la imagen, otro contenido típico del archivo “content.opf” es el manifest, que es una lista (sin orden estricto) de los archivos contenidos en el ePUB, con una declaración del tipo de archivo que es cada uno. (image, xhtml, text,…)


Además a cada archivo se le asigna un identificador que se utiliza en la sección “spine”.


CLICK para IMAGE 
La espina (“



spine”), es la parte del archivo dónde se establece el orden de lectura de los archivos que forman el contenido del libro y que venía listados desde el “manifest”.


No es necesario incluir TODOS los archivos en la espina; únicamente lo que se necesite para establecer un orden de lectura correcto. (por ejemplo, no se suele incluir los archivos de imagen).





Resumiendo, “container.xml” nos dice donde está “content.opf”; y en “content.opf” encontramos, la lista de TODOS los archivos que componen el libro (contenido: texto e imagen, formato: estilos CSS, estructura: TOC, etc…) en el manifiesto; y en la espina el ORDEN NECESARIO para una LECTURA CORRECTA del libro. Y de propina, los metadatos, que no tienen que ver con archivos, sino que son atributos (caracteristicas) de la entidad “libro”.





Y lo demás, lo vemos a ir dejando para el capítulo 3.





Y recordad, niños, esto es CERCA image1 y esto es LEJOS image31
miércoles, 23 de junio de 2010

Sudáfrica 2010: Ya es oficial, los del Tiki-Taka superan a Naranjito y ya sólo nos queda… Chile

Como uno ya va teniendo más años de lo que le gustaría y le quedan algunas neuronas recuerda que corría el año 1982; y la FIFA nos había colocado para que ganáramos nuestro mundial (otro mundial que íbamos a ganar) a Honduras como una de las peritas en dulce para que quedáramos primeros de grupo. Pues resulta que la perita se nos atragantó y sólo le pudimos empatar de penalti injusto. Pasamos como segundos de grupo, y quedamos emparejados con Alemania e Inglaterra, con el resultado consiguiente.
En este sentido, la generación del tiki-taka ya ha superado a los de Naranjito.
También ha quedado claro que Villa ha ocupado el lugar de Raúl con todos los honores. Está haciendo oposiciones a cáncer de la selección pero sin pasar previamente por la larga ejecutoria que desempeñó el anterior 7 de España. El primer gol, inverosímil obra maestra, es una cumbre de habilidad y chuponeo de muchos quilates. El detalle de empeñarse en tirar el penalti, desplazando a los compañeros especialistas designados, por el lucimiento personal del hat-trick; siendo estadísticamente un consumado fallador, es para nota. Esperemos que no nos quedemos fuera por el golaveraje.
Y ahora a por Chile. Los listos habían previsto que daba igual porque ya íbamos a estar clasificados y los chilenos pues a lo mejor también. Y resulta que es Chile quien llega al tercer partido con la clasificación de cara. Así que pueden esperar atrás, ordenaditos y tirarnos un viaje cuando convenga. Es decir, el típico partido que se nos puede atragantar. Más vale que el santo nos venga de cara porque a Chile no le vamos a hacer 25 oportunidades para marcar 2 goles. Y que a Villa le regalen un jabulani firmado y se olvide de tirar penaltis.
Esperemos también que Chile llegue clasificado y relajado.
Total, ya nos hemos ganado a pulso el cruce con BRASIL.

lunes, 21 de junio de 2010

Sudáfrica 2010: Cada uno a lo suyo, Chile gana y Suiza…

El partido ha terminado hace un rato; y visto lo visto, se hace INCOMPRENSIBLE que los del tiki-taka no le metieran 3 a Suiza. Lentos, rústicos, ultradefensivos y fiándolo todo a un despiste del contrario (2 que tuvo España en su partido, 1 le colaron aunque de carambola). Chile ya está clasificado y nosotros, de momento ZERO POINTS. Teníamos fe en llegar a las finales, pero han llegado antes de tiempo porque cada partido va a ser una final.
Y con respecto al otro día, yo debo haber visto otro partido distinto porque me parece que se fallaron ocasiones claras de gol, por EL AFAN DE PROTAGONISMO. Pudiendo pasar a 2 compañeros, ¿cómo se te ocurre tirarte un globo, Villa?

En 90 minutos, empieza la primera final de España. Esperemos que sea para bien, porque lo único que nos faltaba era volvernos a casa en la primera fase.


Misterio: De 100 partidos que jugáramos contra esta Suiza ganaríamos 98. ¿Por qué tiene que ocurrir la excepción estadística en la fase final del Mundial?
¿Por qué siempre nos pasa lo mismo? ¿Por qué reservamos las machadas para las fases clasificatorias?
Predicción: Además nos van a hacer una judiada (penalti injusto, gol en clamoroso fuera de juego, etc…)

A pesar de todo, todavía no estamos fuera, así que ánimo y suerte. (Y el país lo necesita.)

domingo, 20 de junio de 2010

Arreglando la conversión de un PDF en libro ePUB para Mi PAPYRE 6.1 reader ¡con muchas notas a pie de libro!

Para hacer la conversión del título “Corsarios de Levante” partimos de un PDF quePAPYRE STREET está protegido por lo que no ha sido posible realizar las tareas de pre-proceso (recortar pies y cabeceras, revisar el reflow, etc…) típicas para conseguir una conversión sin muchos problemas. Ha sido necesario por tanto depurar pies y cabeceras que aparecían mezclados en mitad del texto y otros errores típicos en estos casos de los que ya hemos hablado en este BLOG. Pero este libro se caracteriza además por incluir casi 100 notas a pie de libro (añadidas por el editor digital de la versión PDF, no por el autor original) que aclaran muchos de los términos marineros y militares del relato. Como mejoran bastante la experiencia de lectura me parecía necesario incluirlas en la versión ePUB.

Gestionando un montón de notas
notas en PDF
En el archivo PDF, las notas aparecen originalmente como se muestra en la foto, pero después de la conversión, como podéis comprobar aparecen simplemente como un número “pegado” a la palabra en cuestión. Un auténtico desastre multiplicado por cien.

Despues de convertir
Así que se impone utilizar RegEx para arreglar este entuerto.
Empezamos a buscar una expresión de búsqueda que nos encuentre todas las ocurrencias y nada más que las ocurrencias relacionadas con este error.
Necesitamos una expresión que encuentre palabras terminadas en un número y con un espacio o signo de puntuación a continuación. Desgraciadamente si no delimitamos cuantos números estamos buscando, la expresión nos encontrará también, cosas como nombres de estilo CSS (“calibre9”, por ejemplo). Así que lo partimos en 2 tandas, primero buscaremos 1 a 1 las palabras terminadas en un digito (las notas del 1 al 9), y reemplazaremos 1 a 1 excluyendo las otras cosas que podamos encontrar; y luego ya podremos de un sólo golpe reemplazar las notas del 10 al 95 ya que no se confunden con ninguna otra cosa.

La expresión de sustitución tendrá que incluir el código para convertir ese número en una nota dentro del texto. Así pues:

CLICK para CODEComo siempre, si pulsáis en la imagen accederéis al código. 
¡Ale-hop! y …
 Arreglado
es decir, donde antes ponía:

bajando la entena1.

ahora queda:

bajando la entena. <a title="[1]" href="#_ftn1" id="_ftnref1" name="_ftnref1"><span class="MsoPie">[1]</span></a>



Pero no hemos terminado ni mucho menos. Al final del libro nos quedan varias

Coco profesor

páginas con el texto aclaratorio de las notas (son 95) que tendremos que vincular a las notas situadas dentro del texto. El problema es que para cada nota, después de copiar-pegar el código tendríamos que realizar al menos 5 modificaciones (1 para cada vez que aparece el número de la nota); por lo que estamos hablando de casi ¡500 ediciones! No puede ser.
Nuestro amigo Coco, nos sugiere que hagamos algún invento que nos ahorre este trabajo tan tedioso.

CLICK para IMAGEN  
Lo primero va a ser copiar el texto de las notas a pie de libro en un archivo de texto plano TXT, de forma que cada nota ocupe una línea con su número de nota al inicio de la línea. Con un copiar-pegar y unos cuantos retornos de carro lo hacemos muy rápidamente:


Fichero de texto con las NOTAS
Y ahora vamos a crear un programita que mediante un bucle para los valores 1 a 95, lea la frase correspondiente con el texto de la nota, le añada el código necesario para convertirlo en una nota a pie de libro y escriba el resultado en otro archivo de texto.
 CLICK para CODE

Como siempre, si pulsáis en la imagen accederéis al código. 
Como soy un tío muy rarito el programa esta hecho en KIXTART, un dialecto BASIC interprete de MICROSOFT orientado al scripting para la gestión de sistemas pero convertirlo a algo más universal, como por ejemplo VISUAL BASIC es muy sencillo porque la sintaxis es muy similar.
Resumiendo:


Para n=1 a 95, leo el archivo con el texto de las notas frase a frase hasta que encuentro la línea con la nota número n; le quito el comienzo de la línea dónde está el número de la nota para dejar sólo el texto. A ese texto le añado delante el código necesario para que sea una nota a pie de libro, cuya parte variable es el número n de la nota. Escribo la frase resultante en otro archivo de texto, donde me quedaran al final 95 líneas, una para cada nota a pie de libro.
Este es el archivo DESTINO resultante:
CLICK para CODE Por último, solo queda hacer un copiar-pegar desde este archivo a nuestro e-book en ePUB y ¡Voilá!

CLICK para IMAGE

jueves, 17 de junio de 2010

Todo lo que siempre quiso saber sobre el formato ePUB de sus ebooks y nunca se atrevió a preguntar (Cap. 01)

LOGO Oficial de ePUB ¿Quien lo inventa?
La International Digital Publishing Forum es una alianza de empresas para establecer los estándares tecnológicos y comerciales de la publicación digital. Sus miembros acordaron la definición de ePUB como la extensión de archivo (o sea todo lo que se llame “.epub”) que llevaran los libros electrónicos.

¿Que debe cumplir?
Pero no vale cualquier libro electrónico. Debe cumplir las siguientes características:
- en formato XML


- con reflow, (la capacidad de reajustar automáticamente los componentes del texto cuando se produzcan cambios en el formato del documento: tipo/tamaño de letra, márgenes, ventana de presentación, etc… Es lo que hace que los libros electrónicos no tengan un número de páginas fijo, sino que tienen una paginación dinámica).
- libre, abierto y sin encriptar PAPYRE STREET
- y que cumple tres conjuntos abiertos de especificaciones:  la Open Publication Structure (OPS), Open Packaging Format (OPF) y Open Container Format (OCF). Estas especificaciones o estándares detallan lo que puede llevar dentro un ePUB, cómo debe estar organizado internamente y su modo de empaquetamiento (como fichero ZIP).
Dicho de otra forma, un fichero ePUB es un container (Contenedor), es decir una caja donde se guardan una serie de archivos (fundamentalmente en formato XHTML), cuyas características y contenidos están definidos y delimitados (mediante XML) y que se organizan y ordenan de una forma concreta (en una estructura de directorios definida). Y todo ello se empaqueta comprimiéndolo en formato ZIP.
Coco profesor del PAPYRE
Coco nos sugiere que hagamos la siguiente prueba:  Renombra un archivo “.ePUB” a “.ZIP”; y haz doble-click encima. El descompresor que tengas instalado en tu ordenador descomprimirá el archivo y te mostrará la estructura de directorios que incluye todos los archivos que forman parte de un ePUB.


¿Qué contiene un archivo ePub?

Si hacéis la prueba podréis comprobar que contiene una estructura como esta:

  
├───META-INF 
└───OEBPS
├───Images
├───Styles
└───Text




Esta estructura de directorios es fija y debe darse siempre. El detalle de lo que se encuentra en cada directorio, cómo debe estar formado y para que sirve será objeto del Cap 02: Todo lo que siempre quiso saber sobre ePUB.

Añadimos el buscador de libros dedicado de Kiermel a Mi PAPYRE 6.1 reader para libros electrónicos

Buscador de Libros Hemos añadido a la sección “Más libros, más libres” situada en la barra de widgets de la derecha de la página, un enlace al buscador de libros dedicado de Kiermel, que por cierto, es un asiduo lector y socio de la Biblioteca; y además ha tenido la amabilidad de colocar un enlace hacia este BLOG.
Es un desarrollo muy práctico (mi primera opción para buscar algún libro) que se centra en la búsqueda en sitios específicos de libros electrónicos y además tiene subconjuntos de búsquedas programados por pestañas (en formato PDF, ePUB, en Scribd, …).
Para comprobar lo cómodo y práctico que resulta sólo tenéis que pulsar en el icono de la pila de libros de la sección “Más libros, más libres

jueves, 10 de junio de 2010

Resolviendo dudas RegEx sencillas para mejorar los ePUB de Mi PAPYRE 6.1 reader

PAPYRE STREETKiermel nos envía la siguiente duda:





 Coco profesor
Coco va a explicarnos como hacerlo paso a paso.
Queremos encontrar, un rango de números. Pues bien:
0-9

y lo encerramos entre corchetes para indicar que es un rango de números. Pero ¿cuántos números puede haber juntos? Al menos habrá 1, pues eso lo indicamos con el metacarácter "+". Cuando queramos encontrar desde 1 a n ocurrencias de lo que estemos buscando, usaremos “+”; para encontrar de 0 a n ocurrencias lo indicaríamos con “*
[0-9+]

De momento, esto nos encontrará cualquier grupo de números de 1 o más cifras. Como es la expresión a mantener, la agrupamos encerrándola entre paréntesis. Así la expresión de búsqueda será:
<p class="title-p"><strong>([0-9+])</strong></p>

Y en la expresión de sustitución sólo tendremos que indicarle que queremos mantener sin reemplazar el PRIMER GRUPO (sólo hemos agrupado 1) de lo que encontramos en la expresión de búsqueda, y eso lo hacemos con "\1". Si tuviéramos 3 grupos y quisiéramos el tercer grupo, lo indicaríamos con "\3"
<h2>\1</h2>

Esperamos que nuestro amigo Kiermel lo haya entendido.

Y recordad, niños, ahora estoy CERCA image y ahora LEJOS image
miércoles, 9 de junio de 2010

Mi PAPYRE 6.1 reader y el nuevo PAPYRE 6.S ALEX, especificaciones frente a frente / Specs comparison PAPYRE 6.1 – new PAPYRE 6.S ALEX

image Desde que GRAMMATA anunció la próxima comercialización del nuevo e-reader PAPYRE 6.S ALEX se ha generado una expectación importante. Para atender a ese interés este BLOG va a dedicarle unos posts analizando el nuevo producto. Y lo primero es ver desde donde partimos. Por eso hemos preparado una tabla comparativa de las especificaciones entre los dos dispositivos.
Especificaciones frente a frente






El documento permite analizar de un golpe de vista las diferencias más relevantes. Podéis descargaros el documento, como siempre desde DESCARGASDOCUMENTOS DE REFERENCIA / TECH DOCS - Nº4

As far as GRAMMATA is going to sell the new PAPYRE 6.S ALEX very soon we have made a spreadsheet with a specifications comparison between the PAPYRE 6.1 and PAPYRE 6.S ALEX. You may dowload it, as usual, from DESCARGAS – DOCUMENTOS DE REFERENCIA / TECH DOCS - Nº4 

Arreglando con RegEx los guiones largos perdidos(EM DASH) en un ebook ePUB para Mi reader PAPYRE 6.1 (Cap. 02)

Coco profesorPAPYRE STREETCoco nos comenta que el otro día encontró algo extraño en un ebook ePUB con relación a los guiones largos. Resulta que al abrir el libro en ADE de Adobe los guiones largos aparecían como “?” (cierre interrogación). Evidentemente lo mismo pasaba en el lector ADE de mi PAPYRE. ¿Qué misterio es este?  

 

 



 

image

La cosa es aun más misteriosa porque, como podéis comprobar en las imágenes, el texto ePUB se ve perfectamente tanto en el browser incorporado de CALIBRE como el editor SIGIL


Pues es una cuestión de “buenas prácticas” a la hora de editar el libro. El asunto

está en que ADE es más

estrict

o

en el manejo del conjunto de caracteres permitidos

, y resulta que aunque parezca un guión largo (EM DASH), lo que tenemos en este libro es el carácter “barra” que no es admitido por ADE, PORQUE NO ES UNA ENTIDAD HTML 4.0.



Cómo Arreglarlo
 


Pues sustituyéndolo por un carácter que estemos seguros que ADE va a aceptar. La

Click para IMAGE

buena práctica

será utilizar siempre ENTIDADES HTML 4.0 cuyo listado podéis ver en la Wikipedia.
Así, sustituimos por el GUIÓN LARGO (EM DASH) y para estar seguros de no equivocarnos lo escribiremos en su notación HTML, es decir:

&mdash;
Es una práctica que os recomiendo para cuando utilicéis caracteres "especiales" y así no tendremos sorpresas. Efectivamente después de sustituir, ¡Voilá!, texto arreglado.


 

 



image



Y recordad, niños, ahora estoy CERCA image y ahora LEJOS image
© Cosas Interesantes