Informe de (no) avance, octubre

Este mes me han caído encima una serie de problemas que me quitaron tiempo libre. Si a esto se le suma el hecho de que la resolución de algunas cuestiones técnicas bastante complejas en el proyecto \text{L\kern-.1667em\lower.25em\hbox{Y}\kern-.125emX\@} han retrasado la liberación de la «RC1», pues que ya tenemos la excusa perfecta para que yo no haya hecho casi nada en el libro.

\text{L\kern-.1667em\lower.25em\hbox{Y}\kern-.125emX\@} 2.3.0 RC1 tendría que estar al caer en las próximas semanas, por lo que muy probablemente todo esté listo (nueva versión del programa y libro) antes del final de noviembre.

Creo.

Anuncios

1 comentario

Firefox 56 (y posteriores) en openSUSE Leap

Por motivos que no vienen a cuento en este artículo, Firefox ha cambiado muchas cosas en las últimas versiones por lo que ya no acepta ciertos plugins o extensiones que solía aceptar antes. Esto ha determinado que existan dos versiones del navegador, la 52-ESR (Extended Support Release) que mantiene algunas de las cosas antiguas y la nueva, que al momento de escribir estas líneas es la 56. Y openSUSE usa por defecto la versión ESR.

Hasta aquí todo bien. La versión ESR funciona perfectamente por lo que para la mayor parte de los usuarios es más que suficiente. Pero el otro día entrando en wordpress me encontré con este mensaje

Un tanto exagerado, lo sé, pero me entró la curiosidad de usar la última versión de Firefox. Todos dicen que es más rápida y tal…

Pues bien, abriendo YaST2 → Repositorios de software → Añadir → Especificar URL → etcétera solo hay que agregar el repositorio correspondiente a nuestra distribución dentro de los que se encuentran aquí

http://download.opensuse.org/repositories/mozilla/

Por ejemplo, para 42.2 sería

http://download.opensuse.org/repositories/mozilla/openSUSE_Leap_42.2/

Se aceptan todas las llaves, vamos a instalar y desinstalar programas para elegir tanto firefox como los paquetes que tengamos instalados con «mozilla» en el nombre, los cambiamos al nuevo repositorio, tratamos de actualizar… y aparecen conflictos con java-1_8_0-openjdk.

Las opciones que nos da YaST2 son:

  • Quedarnos con firefox 52
  • Instalar una versión anterior de java-1_8_0-openjdk y paquetes relacionados
  • «Romper» java-1_8_0-openjdk y paquetes relacionados

Luego de consultarlo con la comunidad decidí probar esta última opción, la cual resultó ser sumamente exagerada ya que todo parece funcionar correctamente.

NOTA: Unos días después de instalar Firefox 52 su repositorio se actualizó por lo que es posible que ahora ya no exista este error de dependencias.

Firefox 56 parece cargarse y funcionar mucho más rápidamente que las versiones anteriores, lo cual se agradece. Tiene un par de nuevas opciones que resultan interesantes. Por ejemplo al comenzar a escribir en la barra de direcciones no solo tenemos las clásicas sugerencias basadas en el historial: también aparecen algunos botones con los diferentes motores de búsqueda

Aunque quizás lo más llamativo sea la nueva herramienta para realizar capturas de pantalla de una página web: nos permite seleccionar un objeto de una página o una sección rectangular o lo que quedamos

Las capturas pueden ser descargadas o almacenadas en la red (si se tiene una cuenta en firefox). Ideal para quienes escriben guías de usuario.

¡Ha! Ahora hacer clic central en una página NO pega el contenido del portapapeles en la barra de direcciones. ¡Se han terminado los problemas que surgían cuando fallamos a centrar el enlace que queríamos abrir en una pestaña nueva! 😉

3 comentarios

Camino a LibO 6.0: las primeras versiones de desarrollo

En estos días me he tomado un momento para descargar la versión «archive» (nada de rpm o deb: el programa ya compilado y simplemente empaquetado en un tar.gz, listo para descomprimir y usar) de la versión de desarrollo de LibreOffice 6.0. He aquí algunas de las novedades que he encontrado.

Caracteres especiales

La herramienta para insertar caracteres especiales ha dado un salto de calidad realmente importante. El botón de insertar caracteres especiales se ha convertido ahora en un menú que ofrece no solo el abrir la herramienta de base, sino también una lista de los caracteres usados recientemente y otra de los «favoritos»

Por si esto fuera poco (que no lo es) al abrir el diálogo principal nos encontramos con una herramienta mucho más potente que no solo nos permite configurar los favoritos con un simple clic derecho: también nos da información valiosa del carácter a insertar y la posibilidad de buscar caracteres a través de sus nombres unicode (la caja «search» arriba a la izquierda)

Menús de personalización

La herramienta que se abre en Herramientas → Personalización ha sido completamente reescrita, organizando todos sus componentes y ofreciendo a su vez un campo de búsqueda que simplifica la configuración de menús y atajos de teclado

Barra de estilos

Aún no está disponible la caja con los estilos de carácter, pero ya tenemos algunas mejoras que vuelven a esta barra realmente útil. Por ejemplo, los botones de los estilos de carácter «saben» (y «lo comentan» iluminándose) cuál es el estilo de carácter aplicado al texto sobre el que se encuentra el cursor, por lo que el botón del estilo de carácter «predefinido» solo se señala cuando no hay un estilo de carácter aplicado al texto

Navegar por objetos

En la barra de búsqueda (Ctrl-F) se ha agregado un cómodo menú que permite seleccionar categorías de objetos para «saltar» rápidamente entre ellos

Seleccionando el ítem que nos interesa podemos saltar entre títulos, tablas, imágenes, secciones… lo que necesitemos, simplemente usando los dos botones de la derecha.

Algunos problemas

LibreOffice usa un sistema llamado VCL para «dibujar» su interfaz gráfica. Este sistema tiene algunos «plug-in» para conectarse con gtk2, gtk3 y KDE4. Este último plug-in parece tener un problema en la versión de desarrollo que he probado: no es posible insertar acentos. Seguramente esto se solucionará a tiempo para la versión final, pero mientras tanto es muy simple el iniciar LibreOffice con su interfaz gtk3 incluso en un sistema Plasma: abriendo un terminal virtual en la carpeta con el guión de inicio del programa podemos lanzar Writer con

SAL_USE_VCLPLUGIN=gtk3 ./swriter

Con la interfaz en gtk3 todo parece funcionar correctamente.

Conclusión

La versión 6.0 de LibreOffice está tomando buena forma, con características sumamente interesantes. La interfaz gtk3 ha avanzado mucho y, seleccionando el tema correcto, cuadra en un entorno plasma incluso mejor que la interfaz KDE4. Realmente LibreOffice 6.0 se viene con todo en regla para convertirse en una de las actualizaciones más interesantes de la historia del proyecto.

Para más información sobre las novedades: LibreOffice 6.0: Release Notes (en inglés y en fase de composición).

Deja un comentario

La trampa de los estándares

No pensamos demasiado en ellos, pero los formatos de archivo son una parte esencial de nuestra vida digital: en ellos guardamos imágenes, texto, bases de datos, confiamos en ellos para almacenar nuestra información importante, dependemos de ellos. Pero así como son una herramienta versátil y potente pueden también crear trampas difíciles de evitar.

Estas trampas pueden tomar varias formas. La más evidente es el infame «vendor lock-in»: un formato de archivo cuyo funcionamiento es secreto o está «protegido» por patentes en modo tal que solo pueda ser utilizado por un programa particular o, en el menor de los males, por «socios autorizados».

No creo que los lectores de este pingüino necesiten una lista de ejemplos de esta nefasta (al menos para el usuario) práctica.

Para luchar contra el «vendor lock-in» es que, en principio, nacen los estándares abiertos: contra los formatos cerrados que alguna vez utilizó MSOffice se creó el estándar ODF, para enfrentarse al ubicuo mp3 vorbis y compañía, etcétera.

La idea es que al ser un estándar abierto cualquiera puede implementar su uso y que por lo tanto un mismo archivo podrá ser abierto por cualquier programa en cualquier momento obteniendo siempre el mismo resultado.

La idea, digo.

Porque si bien es cierto que a veces esto se logra (png, PDF, vorbis, theora) la realidad es siempre más compleja.

Tomemos como ejemplo un archivo ODT creado en LibreOffice Writer en el que además de aplicar características OpenType avanzadas se tenga la fuente incrustada en el mismo.

Probemos ahora a abrir ese archivo en Apache OpenOffice o en Calligra Suite (en ambos se ve igual). ¿Resultado?

Y mejor no empezamos a hablar de los problemas que tiene Calligra Words para abrir documentos odt «normales»

Ahora bien, el formato ODF es un estándar ISO, ¿porqué tanta diferencia?, ¿no debería ser el resultado siempre el mismo?

Desafortunadamente no.

Pero antes de continuar debemos distinguir entre estándares «solo para almacenar y mostrar» y estándares «para ser manipulados». Ejemplo de estándar para «almacenar y mostrar» son los formatos de audio y vídeo o el magnífico PDF, mientras que para los formatos «a ser manipulados» tenemos el formato utilizado por LibreOffice y compañía, ODF. En este artículo estamos hablando mayormente de la segunda categoría, que nadie va a discutir la utilidad de un estándar como PDF. ¡Los PDF son magníficos! Solo no hay que tratar de modificarlos.

Veamos entonces el porqué un archivo «estándar para ser modificado» como el ODT puede fallar tanto.

Por una parte diferentes programas tienen distintos niveles de desarrollo por lo que el hecho de que algo esté definido en el estándar no implica que todos los «clientes» de ese estándar lo implementen. Por otro lado, y esto es aún más importante, los «estándares para ser modificados» no suelen ser las recetas rígidas exentas de ambigüedad que muchos creen: hasta donde comprendo el asunto ODF permite el uso de «extensiones» no definidas explícitamente en el estándar, extensiones que en realidad solo podrán ser utilizadas por una implementación particular que las reconozca… y LibreOffice hace uso de varias de esas extensiones, como incrustar fuentes, por ejemplo, o utilizar nombres extendidos para tener soporte OpenType.

¿Conclusión?, pues que ODF no resuelve el problema de la «interoperatividad». Y por si esto fuera poco agrega otro problema más sutil, pero no por eso menos grave. Veamos un ejemplo.

Writer ofrece la posibilidad de numerar las notas al pie de página «por capítulo». El problema es que define como «capítulo» solo títulos de nivel 1: si queremos agrupar nuestros capítulos en «partes» y nuestras notas al pie «por capítulo» tendremos problemas si tratamos de utilizar el nivel 1 para la parte y el 2 para el capítulo.

Existen «trucos» para superar este problema, es verdad, pero ninguno de ellos resulta perfecto. Por algo son trucos.

Ahora bien, ¿imaginas, lector, el motivo por el cual esta opción de usar «capítulos» que sean títulos de nivel 2 no está disponible en Writer? Sí, se debe al formato ODT: simplemente no lo permite.

Bug 112301 – Set outline level for chapters

(ver comentario 2)

LibreOffice ha sido capaz de aprovechar las ambigüedades de ODF para implementar características sumamente útiles y potentes como el soporte OpenType, el incrustar fuentes y vídeos en sus archivos, implementar firmas digitales y mucho más, pero al costo de perder interoperatividad con otros editores ODF. Y al mismo tiempo LibreOffice tiene las manos atadas a la hora de implementar características útiles cuando el estándar ODF decide ser explícito.

Es decir, por una parte la ambigüedad de ODF ha dado lugar a una especie de «vendor lock-in soft» donde documentos medianamente complejos creados en versiones recientes de LibreOffice no funcionan correctamente en otros editores ODF, mientras que por otra parte la rigidez del estándar hace difícil el ir más allá de lo que ya tenemos, bloqueando efectivamente el progreso del programa.

En el pasado fui un furioso defensor de ODF, pero ahora ya no estoy tan seguro de su utilidad. Y es que el objetivo de limitar el poder de los formatos de MSOffice lo ha cumplido solo parcialmente (sigue siendo más sencillo manipular un .doc que un .docx), crea la ilusión de una interoperatividad en realidad inalcanzable y por si esto fuera poco dificulta la implementación de nuevas características.

Ahora creo que cada programa que crea documentos «para ser manipulados» debería utilizar su propio formato de archivo y que ese formato de archivo solo necesita estar bien documentado, con documentación accesible a todos así cualquiera puede implementar filtros para importar y exportar a ese formato. Nada más. ¿Ser un «estándar»? Para esta categoría de programas ya no creo en los estándares. Uno de los motivos por los que LaTeX sigue funcionando a través de los años es que no se preocupa de lo que hacen los demás y tiene un formato de archivo que le sirve solo a él. Comprensible por todos, sí, pero exclusivo.

Los estándares han resultado ser un mito pernicioso, lleno de trampas. Y es que solo funcionan (cuando lo hacen) para tareas bien definidas como un formato de imagen, audio o vídeo o cuando el contenido que llevan no debe ser modificado, como en un PDF. Para tareas más complejas como documentos que combinan texto e imagen (y audio y vídeo) en una página bien definida y que deben ser manipulados (documentos de texto, planillas de cálculo) los estándares resultan ser poco más que un cuento de hadas: algo bonito, incluso deseable, pero completamente alejado de la realidad.

Y sí, HTML es una más que bienvenida excepción, pero tiene su truco. O más bien tres trucos.

Primer truco: HTML es un estándar que nació antes que los programas que actualmente lo implementan mientras que ODF nació a partir del formato ya en uso por OpenOffice.org y por lo tanto los otros programas que lo implementan se adaptaron a ese formato, no les es nativo.

Segundo truco: el visor de HTML (el navegador) está separado del editor de HTML mientras que para ODF ambas funciones coinciden en el mismo programa. Esto hace que HTML sea más parecido a los estándares «para almacenar y mostrar» (como el PDF, que sí funciona) que a los estándares «para ser modificados» (como el ODF, que como estamos viendo en este artículo puede resultar un tanto problemático).

Tercer truco: los desarrolladores web necesitan comprobar todo varias veces y en varios navegadores diferentes para hacer «ajustes finos» antes de poder publicar por lo que… en fin, que se entiende.

Finalmente comprendo el porqué la gente de Abiword usa un formato propio y solo da soporte para importar o exportar ODT: atarse a un estándar puede complicarte la vida.

Para completar la lista de dificultades podríamos hablar también del asunto de la proliferación de estándares… pero ese es otro problema que me permitiré dejar pasar.

,

3 comentarios

Walleye, una fuente con gracias de diseño original

Este artículo es parte de la serie Recomendando fuentes tipográficas


Hoy presento una fuente tipográfica que no es ni una recreación de otra más antigua ni un fork de un proyecto existente, sino un trabajo original diseñado desde cero por Chuck Masterson y ofrecido con licencia OFL:

Walleye

La fuente es multilingüe, dando soporte a Latín, griego politónico y cirílico. De hecho además de las numerosas características OpenType presentadas en las capturas de pantalla Walleye ofrece varias opciones especializadas para los diversos sistemas de escritura que soporta (pueden consultar este PDF para más información).

Una agradable fuente para texto que sin renunciar a influencias clásicas (contraste relativamente bajo y «en diagonal», serifas pequeñas) nos regala originalidad (terminaciones «en bandera», formas «abiertas»).

Deja un comentario

Pali, otra versión (más) de Palatino

Este artículo es parte de la serie Recomendando fuentes tipográficas


Diseñada por Hermann Zapf en 1949, Palatino  es una fuente de estilo antiguo que ha sido copiada y revisada numerosas veces. De hecho en estas páginas hablamos de una de sus versiones: TeX Gyre Pagella, la cual se basa a su vez en URW Palladio, la cual…

Entonces, ¿otra Palatino? Pues sí, y a mucha honra:

Respecto de otras versiones de Palatino, Pali ofrece una gran cantidad de características OpenType avanzadas además de otras diferencias:

Como puede verse en la última captura de pantalla Pali es por una parte más «compacta» que TeX Gyre Pagella, pero ofrece versalitas más «altas». Otra diferencia es el interlineado por defecto que en Pali es menor (12 puntos para una fuente de 10, contra los más de 13 de otras variantes).

Esta fuente es fruto del trabajo de un viejo conocido de estas páginas: Bhikkhu Pesala.

Es posible descargar esta fuente desde la página de su autor.

Deja un comentario

Informe de avance, septiembre

Ya sé que lo dije antes, pero ahora sí es verdad: el libro está prácticamente completo. Creo. Solo tengo que lograr trabajar un poco con la nueva versión 2.3 (cuando llegue: en los próximos días tendría que publicarse la «rc1») para corregir algunas capturas de pantalla y algunos párrafos.

2.3 llega con muchas habilidades nuevas. Una de ellas es la posibilidad de utilizar «comillas “anidadas” e “inteligentes”» automáticas, pero esto es algo con lo que tengo que experimentar un poco para describirlo correctamente y la verdad es que no he tenido tiempo ni siquiera de pensar a instalar la versión beta.

Ya he comenzado a modificar la página que albergará el proyecto. Como puede verse el índice general ha cambiado un tanto desde el primer reporte: no solo tenemos nuevas secciones, dos capítulos se han «fusionado».

El contenido ha crecido mucho más de lo que puede indicar el mayor número de páginas. En estos días he aprendido varios trucos interesantes, uno de los cuales puede verse en la captura de pantalla… Pista: está relacionado con el entorno «parte», más precisamente con la página que sigue al entorno parte…

Otra captura con un poco de código, listas, una figura, descripción de menús y teclas rápidas…

Esas cosas 🙂

Lo dicho, ya casi estamos.

4 comentarios

A %d blogueros les gusta esto: