Problemas de estandarización

Maquetar correctamente un libro electrónico, y más todavía si incluye imágenes, no es fácil y cuesta tiempo y dinero. Parte de esta complejidad viene de la nula estandarización que existe en el hardware de visualización. Esta falta de estándares se da, a su vez, por dos factores. Por un lado, el acelerado desarrollo técnico que origina nuevos equipos y mejores prestaciones cada poco tiempo y, en segundo lugar y sobre todo, por la voluntad comercial de las firmas competidoras de no crean estándares de modo que un usuario que haya comprado un dispositivo determinado quede prisionero de él y esté obligado a comprar los contenidos o las actualizaciones de esa firma. Estas guerras comerciales frenan sobremanera la creación de literatura digital e impide que la literatura digitalizada alcance la calidad de los libros impresos, algo que sería muy importante para poder subir el precio de los e-books y desarrollar la industria. Si no, como hasta ahora, el mayor valor del libro electrónico seguirá siendo su bajo precio, no la portabilidad o el aprovechamiento de las ventajas que lo digital proporciona. 
 

Los problemas más importantes que obstaculizan una maquetación correcta son: 

-       Diversidad de tamaños de pantalla

-       Diversas resoluciones de pantalla

-  El que, además, estas pantallas pueden estar en posición vertical u horizontal.

-   El diferente tamaño de texto y las diferentes fuentes que puede elegir el lector.

-    La incompatibilidad de plataformas que hacen que algo programado ser visto bien en un sistema, no lo sea en otro. O que se vea distinto, mal. Lenguajes incompatibles entre plataformas.

 

Tamaños de pantalla y orientación 

Los gráficos siguientes muestran la problemática del tamaño de la pantalla. Obsérvese la imponente diferencia de tamaño entre los monitores más habituales, teléfono, tableta y ordenador. 

Imaginemos un texto con un tipo de fuente fijo, un tamaño de letra fijo y unos márgenes fijos. Si los valores son fijos en valor absoluto y, por ejemplo, se ven bien en una gran pantalla de ordenador, cuando deseemos ver ese texto en una pequeña pantalla simplemente  “se saldrá” de la misma y habrá que añadir barras de deslizamiento (scroll). Algo que es muy engorroso. 
 

Nuestros ojos, nuestro cerebro, tienen unos estándares a la hora de leer. Hay una anchura de columna, un tamaño de texto, un tipo de página que nos parece naturalmente correcto. Otros parámetros nos cansan, no nos son naturales, del mismo modo que no podemos hacer teclas de un milímetro de lado para nuestros dedos o periódicos de 6 metros para poder manejarlos confortablemente. Hay unas escalas y unas formas “necesarias” para nosotros. Por ejemplo, una cómoda lectura exige que cada columna de texto tenga en torno a 10 u 11 palabras ( de 7 a 15 en el límite). Tener menos palabras requiere estar moviendo continuamente la posición y es muy cansado. Tener más hace también que la lectura sea complicada. ¿Pero cómo meter 15 palabras en una pantallita? Un texto fijo de este tipo, leído en un Smartphone sería muy desagradable de leer, debiendo moverlo continuamente de derecha a izquierda y de abajo a arriba, perdiendo rápidamente la ubicación propia y haciendo agotador leer un texto largo. Y puede ocurrir, incluso, que el dispositivo no permita estos desplazamientos (ni con pantalla táctil ni con barras de scroll)  por limitaciones de software, de hardware o de ambos. Y si, por el contrario, ponemos muy pocas palabras por línea (6 o 7), al leer ese texto en una gran pantalla veríamos sólo espacios en blanco.

 

Otra técnica sería escalar la página fija al tamaño de la pantalla pero también es inapropiada porque en monitores pequeños los textos quedarían tan diminutos que serían ilegibles (algo que, por ejemplo, suele pasar con los ficheros PDF en muchos lectores electrónicos). También podríamos utilizar porcentajes en vez de valores fijos (por ejemplo, fijar el margen derecho al  10% del ancho de pantalla) pero esto lleva al mismo problema de visualización que ocurre cuando se escala, porque esa técnica porcentual continúa intentando meter todo en una pantalla diminuta. 
 

Así pues, un texto fijo y una página fija no son útiles cuando hablamos de libros digitales. Es preciso permitir “fluir” el texto en función del tamaño de la fuente y del tamaño de la pantalla. Esto, ya de por sí, no es inmediato. Precisa programarse. Pero si, como ocurre, el lenguaje de programación varía de una plataforma a otra, el trabajo de los diseñadores comienza a ser muy complicado.  
 

Para enredar más el asunto, podemos tener imágenes. ¿Qué ocurre cuando estamos- mediante programa- haciendo fluir el texto? Las imágenes no pueden ser “fluidificadas”. ¿Dónde deben ir? ¿Dónde las ponemos? Más programación pero, además, condenada a un semi-fracaso porque hagamos lo que hagamos, la maquetación, el formato de página, habrá variado y el diseño final – para cada pantalla, cada texto y cada plataforma- será distinto, gustando más o menos y siendo, ante todo, impredecible.  

Asimismo, los tamaños pueden ser no escalables (relación 4:3 de algunas pantallas contra 16:9 de otras)

 

Resolución de pantalla 
 

Las resoluciones de pantalla van mejorando a medida que evoluciona la tecnología. De las originales bajos tamaños de 800 x 600 píxeles a los grandes monitores de hasta 3840x1080 píxeles va un gran trecho.  Igualmente ocurre con la densidad de píxeles, desde los más sencillos monitores de 72 ppp (píxeles por pulgada) hasta las nuevas pantallas de alta densidad de 220-260 ppp (que Apple promociona con el nombre comercial de “retina” publicitando que se acercan a la resolución del ojo humano, lo que no es cierto). Aún deben mejorar mucho más porque un ojo  – “nuestra retina”- es capaz de distinguir normalmente hasta 500-600 ppp (y se dice que incluso un ojo en buen estado de salud puede distinguir 2200 ppp). Llegando a estas últimas resoluciones, el ojo ya no sería capaz de distinguir los píxeles y se podría considerar que una pantalla tendría la misma calidad que el material impreso. Seguro que se logra en menos de tres años.  
 

Si las fuentes o las imágenes son vectoriales (es decir, se re-dibujan por medio de coordenadas en cada dispositivo), se verán estupendamente en una pantalla retina. Pero si no son vectoriales (y lo normal es que las fotografías no lo sean), se verán peor en una pantalla de alta resolución que en una de alta resolución porque, dependiendo del tamaño, no será posible mapear los puntos existentes en la foto con los disponibles en la pantalla y las líneas quedarán quebradas. Más complicaciones. Para resolverlo, habría que almacenar las imágenes a más resolución (ralentizando la transferencia o el manejo de páginas) o almacenar varias versiones de la misma imagen dependiendo del aparato en que la veamos. Algo nada racional. 
 

¿Y si hay Flash por medio? Pues tampoco lo veremos bien porque de momento Adobe no soporta las resoluciones “retina”. 

 

Fuentes
 

Las fuentes con serifa “serif” se leen mejor (aunque, en esto, hay mil gustos diferentes) pero con las pantallas de baja resolución los “serifs” se pierden, quedan mal dibujados con lo que el resultado final es malo. En tales caso, conviene cambiar de criterio y pasar  a fuentes “san serif”. Con las pantallas de alta resolución y las pantallas “retina”, conviene por el contrario seguir fieles a las fuentes “serif”.  ¿Programamos dos veces? ¿Qué tipo de compromiso tomamos? ¿Y si además cambia el tamaño de la fuente a voluntad del lector porque tiene presbicia y no ve bien? ¿Qué ocurre si el lector está leyendo un libro en un ordenador y continúa leyéndolo en su teléfono cuando va al trabajo en metro?  

Aunque se han creado fuentes con serifa especialmente estudiadas para poder ser visualizadas de modo correcto incluso a baja resolución, bien puede ocurrir que el usuario no tenga tal fuente instalada y/o no desee bajársela e instalarla. Más y más complicación programática. Más y más coste. 
 

También existen problemas con el interlineado que depende de la fuente elegida y su tamaño. ¿Siempre doble espacio? Seguramente, no es lo adecuado para una pantallita pequeña en donde perderíamos mucho espacio. ¿Siempre fijo? Tampoco, porque en unas pantallas se vería bien y en otras mal. 

 

 

Diseño adaptable
 

El Diseño adaptable, más conocido por su terminología inglesa, Responsive design (RD) o Responsive Web Design (RWD), se está desarrollando con la idea de ofrecer una experiencia de visualización óptima en cualquier pantalla, cualquier texto, cualquier web y cualquier tamaño de texto. La idea es buena y admirable. Llevarla a la práctica muy complicado y costoso.  
 

El RD debe permitir una buena visualización, agradable, legible, elegante, fácilmente navegable, a través de un gran número de dispositivos – teléfonos, e-books, tabletas, monitores- minimizando la necesidad de hacer zoom y de usar desplazamientos. Un texto o una página web diseñado con Responsive Design debe adaptar la maquetación al entorno, haciendo fluir el texto, cortando líneas donde proceda, adecuando los párrafos, colocando las imágenes en el lugar más propicio según el momento, etc. 
 

Se puede intuir fácilmente que programar todo esto no es baladí y requiere muchas horas. Pero es que, además, los diversos fabricantes se encargan de que las programaciones serán incompatibles. Muchos teléfonos no entienden javascript; Apple no permite usar el Flash de Adobe; el HTML y el HTML5 de Chrome son diferentes del de Microsoft; Android no se entiende con IOS; etc. etc. ¿Qué hacer? Pues sólo queda programar varias versiones para usarlas dependiendo del aparato o realizar programaciones únicas muy complicadas llenas de casos y ramificaciones posibles en función de qué detectemos como dispositivo (si el dispositivo se deja detectar, claro), lo que alarga el código y ralentiza las descargas y el funcionamiento.  
 

Posiblemente, la aproximación de más calidad hoy en día sería programar siempre en HTML y CSS – que quizá pueda verse en muchas plataformas- en vez de programar en formatos del tipo e-Pub o Mobi. Comienzan a existir herramientas (Modernizr, jQuery, and jQuery Mobile) que pretenden ser genéricas para realizar estas tareas de programación compleja pero, a mi entender, no son la solución porque la técnica evoluciona y las herramientas se van quedando desfasadas con rapidez. Para cuando una se implementa y tiene un volumen suficiente de literatura, ya ha cambiado el mundo.  
 

Programar en “forma web” tiene también sus limitaciones. Por ejemplo, HTML no permite aún justificar las líneas con lo que se pierde uno de los elementos característicos de una correcta maquetación (este blog, Biblumliteraria, está, por ejemplo, justificado). Tampoco HTML sabe “cuando cortar una palabra y dónde”, lo que complica más todavía la maquetación, apareciendo “ríos” en las columnas por no poder controlar los espacios entre palabras.  
 

¿La verdadera solución? Estandarizar, pero creo que no lo veremos en muchísimos años.