Vollkorn: una bien diseñada fuente tipográfica libre

Fuentes tipográficas bien diseñadas y completas que además de bellas sean legibles no es que existan tantas. Si además tienen que ser de licencia libre, pues ya nos quedan bien pocas. En estas páginas hemos hablado ya de las familias libertine, Source Pro y EB Garamond: hoy agregaremos a esta digna lista la fuente tipográfica Vollkorn, una magnífica familia de fuentes tipográficas disponible bajo licencia SIL Open Font License (OFL).

Diseñada por Friedrich Althausen, desde su aparición en el 2006 ha ido ganando características y al día de hoy ofrece cuatro «pesos», cada uno acompañado de su correspondiente versión en cursiva: regular, media, demi negrita, negrita.

Con soporte completo para «latin 3» y soporte parcial para cirílico, la fuente ofrece también varias características OpenType… si bien debo admitir que no todas funcionan completamente (al utilizar +FRAC, la única combinación que parece transformarse en fracción verdadera es 1/2). Eso sí, al menos las ligaduras tipográficas normales funcionan muy bien.

Ciertamente una fuente tipográfica para tener en cuenta.


PD: Para quien no ha captado la broma «oculta» en el nombre, pues «vollkorn» es un muy sabroso pan de harinas integrales típicamente alemán ;)

Deja un comentario

No está muerto quien pelea, pero ¿hay alguien peleando? El estado de AOO

NOTA: Hace ya varios meses que le estoy dando vueltas a este artículo, sin saber siquiera cómo comenzarlo. Un correo de mi gran amigo Mauricio, quien ha tomado las riendas del foro en español cuando yo me alejé, me dio el empujón que faltaba. Lo que sigue es una larga reflexión personal acerca de un tema complejo sobre el cual no tengo respuestas.


Sobre la pregunta del título, sí, hay alguien peleando, y no, no soy yo, al menos ya no. Pero vayamos por partes.

¿Debería importarme?

Por supuesto. Incluso si te has tatuado el logo de «the document foundation» sobre el pecho y no desperdicias oportunidad de hablar bien de LibO aún cuando nadie quiera oírte deberías darte cuenta de que a nadie le importan tus tatuajes o tu elocuencia: lo que la gente quiere es abrir sin problemas un archivo de hace cinco años y que ese archivo y el que crea ahora se abran sin problemas en diez años en cualquier programa corriendo en cualquier plataforma, quiere compartir archivos con otros, quiere mostrarse «profesional» aún cuando no lo sea. Pero esto solo es posible con un formato de archivos que sea un estándar abierto y a disposición de todos, un estándar que pueda ser interpretado por cualquier programa y que sea interpretado por muchos programas, no por uno solo. Si es con AOO, LibO, Calligra u otro engendro es algo que a nadie debería interesarle: toda la apuesta para mantener la libertad de nuestros documentos está en que el formato de archivos ODF sea fuerte y esa fuerza se logrará mantener solo si se tienen varias implementaciones válidas.

Un «vendor lock-in» de código abierto puede parecer mejor que uno cerrado, pero eso no quiere decir que sea completamente bueno. Lector, si eres de esos que desean la «muerte» de AOO deja por un momento de mirarte el ombligo y piensa en las consecuencias de que uno de los proyectos FOSS más famosos de la historia fracase. La diversidad no solo es buena, la diversidad es esencial: sin diversidad no hay evolución.

Un poco de historia

Rumores sobre la «muerte» del proyecto OpenOffice se suceden sin solución de continuidad desde que Oracle compró Sun en 2010, por lo que no son una novedad. Sobre la veracidad de estos rumores, pues la situación ha cambiado mucho (y muchas veces) en estos años: al principio eran fundados, luego, al pasar a la fundación Apache y por al menos un par de años, la actividad fue frenética hasta, quizás, la liberación de la versión 4.0 por lo que los rumores en esa época eran absurdas mentiras, ahora… entre de la liberación de AOO 4.0 y 4.1 algo sucedió y el proyecto comenzó a estancarse en forma cada vez más clara por lo que en estos momentos los rumores son fundados otra vez, casi tanto, si no más, que en el 2010.

La última oleada de artículos sobre la mala salud de AOO parte quizás de este análisis (en inglés):

Development activity in LibreOffice and OpenOffice

Este artículo fue seguido de otros que no citaré aquí (no es necesario), los cuales fueron a su vez traducidos no siempre en forma feliz y que por lo tanto tampoco citaré (no vale la pena).

Sobre el artículo original no hay mucho que pueda decirse: todos los datos son correctos. Es suficiente ver cómo la lista de correo de desarrollo pasó de más de 80 mensajes diarios (con picos de más de cien) en el 2012 para caer por debajo de la decena (con varios mínimos de uno) en el 2015… Sí, en febrero se dieron unos «picos» de unos cuarenta mensajes diarios, pero eso en realidad se debió a otro problema del cual hablaré más abajo.

¿Qué pasó?

Hace unos años dije:

Jürgen Schmidt se ofreció como «release manager» para coordinar las varias tareas previas a la liberación oficial […] pero si él por algún motivo decidiera no ofrecerse a esa tarea ningún problema: alguien más tomaría las riendas.

Pues bien, Jürgen dejó su cargo como release manager (RM) el dos de octubre pasado, hace más de siete meses y nadie parece interesado en reemplazarlo: sin RM una nueva versión es simplemente imposible y esa es una de las razones por las cuales AOO 4.1.2 (que debería traer binarios «firmados» para windows y OSX además de varias correcciones de error) se encuentra hoy más lejos de lo que parecía el año pasado.

Alguien que siga estas páginas podría preguntarse si esta situación que resulta hoy tan evidente no habrá comenzado mucho antes, o incluso si no será en parte responsable del «cansancio» que me llevó a abandonar el proyecto hace más de un año y medio. Ya sea que tengas estas inquietudes o no, estimado lector, la respuesta a ambas preguntas es sí.

No sería correcto que entrara en detalles ya que muchas de estas cosas se discutieron (y es que eran discusiones con nombre y apellido… ya se sabe, la cuestión de la privacy) en la lista de correo privada del proyecto, pero debo decir que se dieron en estos años varias situaciones que requerían una acción inmediata de la comisión directiva (el PMC) y que terminaron en… nada. Algunos de estos problemas eran, en mi opinión, graves, pero el proyecto como un todo no fue capaz de reaccionar.

Es decir, sé que un par de personas intentaron «mediar» en alguno de estos problemas, pero el proyecto como un todo parecía mantener una actitud del tipo «si no lo miramos, quizás se arregle solo», actitud que tuvo serias consecuencias como, por ejemplo, el que la wiki y los foros estuvieran con «mantenimiento mínimo» por más de un año (es suficiente explorar los reportes del proyecto a la fundación Apache donde pequeñas variantes de la frase «The OpenOffice custom infrastructure (wiki, forum) is still in a “minimal maintenance” mode» comienzan en octubre de 2013 y toman todo el 2014…).

Traté de hacer notar que esta excesiva pasividad era mala, pero no lo logré… o quizás sí, pero igual no se dieron respuestas. En un momento lancé una clara acusación a todo el equipo al decir «el proyecto se ha mostrado incapaz de reaccionar ante un problema real», ante lo cual obtuve solo una respuesta con un esperanzador «la próxima vez seremos capaces». Pues bien, unos meses más tarde esa «próxima vez» llegó y nuevamente no fue enfrentada por el grupo (sí por algunos individuos, pero eso no sirve), por lo que luego de meditarlo profundamente y no sin pena decidí retirarme.

La vida es complicada y no es posible hacer que todos sean felices: siempre que se toma una decisión alguien quedará fuera. Cuando el PMC decidió no decidir, yo me sentí fuera.

¿Culpables?

Todos (incluyéndome) y ninguno a la vez: Las relaciones humanas son complejas, para ser suaves, por lo que no es raro que se den problemas de todo tipo. Quizás el «apache way» con sus vagas reglas explícitas y sus rígidas reglas no escritas solo sea útil para grupos cerrados y no muy grandes de programadores y no funcione tan bien para comunidades de usuarios grandes y complejas como la heredada de OpenOffice. De hecho, por mucho tiempo (en gran medida aún hoy es así) el PMC no comprendió cómo funcionan los foros de la comunidad, llegando por momentos a reacciones absurdas.

Al menos un luchador

Tiempo después de mi partida (puedo decirlo porque él mismo lo hizo público varias veces) Jan Iversen, otro miembro del PMC renunció al mismo por motivos similares a los míos. Según sus propias palabras:

I resigned from the PMC in 2014 mainly because felt a strong disagreement with the rest of the PMC, about where we are, and how we give the project more momentum.

[Renuncié al PMC en 2014 principalmente porque sentí un fuerte desacuerdo con el resto del PMC sobre dónde estamos y cómo darle al proyecto más empuje.]

Pero hace unos meses Andrea Pescetti anunció su intención de «rotar» el cargo de chair del proyecto renunciando al mismo y llamando a elecciones para encontrar un sucesor. Luego de muchas dudas, idas y vueltas, Jan decidió presentarse y ganó… no sin dificultades: la elección tuvo que hacerse dos veces y fue el origen de esos breves «picos» de actividad en la lista de correo que mencioné antes.

Jan es una persona de un enorme empuje e infinita voluntad de hacer cosas, una persona por la cual siento un enorme respeto. ¿Será capaz de sacar el proyecto de este letargo? Pues no lo sé, la tarea es realmente monumental y no hay garantías.

Solo el tiempo dirá.

¿Y entonces?

Ni idea. Por lo pronto, lector, si usas AOO 4.1.1 pues que no va a dejar de funcionar de hoy para mañana: tal vez dentro de muchos años cuando las pocas librerías externas de las que depende cambien ya no será posible instalarlo, pero si ahora te sirve seguirá sirviéndote por mucho tiempo. Y si no usas AOO, pues ningún problema, sigue con lo que hoy te sirve: ya dije muchas veces que LibO es un gran proyecto perfectamente válido, que no tengo problemas con el proyecto en sí ni con su producto… solo con algunos de sus dirigentes, pero eso es otra historia…

Además, AOO todavía puede recuperarse. No será fácil, pero eso no quiere decir que sea imposible.

Debo admitir que la posibilidad de tener nuevamente solo un paquete de oficina libre «para dominarlos a todos» me preocupa y no porque el más firme candidato al cargo sea LibO: si solo quedara un AOO impetuoso y saludable también me preocuparía. Insisto en que la diversidad aquí es fundamental para darle fuerza al estándar ODF: si como parece AOO se dirige al olvido y Calligra nunca termina de despegar, tener solo un paquete de oficina usando por defecto ODF no va a ayudarnos.

Creo que la situación general de los paquetes de oficina libres es preocupante y, siendo una pieza clave del zoo de programas que nuestras computadoras necesitan hoy día, tiene el potencial de afectar la credibilidad del software libre como un todo.

En fin, que los próximos meses serán claves para el proyecto AOO. Esperemos que al menos Calligra Suite finalmente logre despegar y que programas como Abiword y gnumeric ganen importancia, dándole riqueza a este precario ecosistema de los programas de «productividad» libres.

,

3 comentarios

openSUSE Tumbleweed pasa a KDE Plasma 5.3, Applications 15.04.1

 openSUSE

 

 

 

 

Hace un mes comentábamos los planes de openSUSE Tumbleweed, la versión «rolling-release» de la distribución del camaleón, de pasar a Plasma 5 como escritorio por defecto. Pues bien, esto está sucediendo ahora mismo:

Tumbleweed moves to Plasma 5.3 and a new release of KDE Applications

Los servidores openQA están en estos momentos corriendo al máximo para tratar de bloquear todos los errores que sea posible.

Ya comentamos en su momento las novedades de Plasma 5.3 y de KDE Applications 15.04 (la versión 15.04.1, de corrección de errores, fue liberada hace unos días), por lo que lo más importante para comentar en este artículo es que quien tenga instalado Tumbleweed con el patrón KDE Applications verá cómo la próxima actualización arrastra todas las aplicaciones basadas en KDE Frameworks 5.

Quien tenga interés en instalar esta versión del camaleón puede consultar el Tumbleweed portal y más específicamente las instrucciones de instalación.

,

Deja un comentario

Disponible el cronograma para KDE Applications 15.08

Como comenta Albert Astals Cid (TSDgeos) en su blog, ya está disponible el cronograma para KDE Applications 15.08:

Schedules/Applications/15.08 Release Schedule

El esquema, más simple que en versiones anteriores, es el siguiente:

Miércoles 15 de julio «dependency freeze», es decir, ya no se pueden cambiar las dependencias de los paquetes

Miércoles 22 de julio se «congela todo» (solo correcciones de error) y se tiene la primer beta

Miércoles 5 de agosto el primer «release candidate»

Miércoles 12 de agosto se marca todo como listo

Miércoles 19 de agosto se libera KDE Applications 15.08

Ya iremos viendo qué novedades nos traerá esta nueva versión… ;)

Deja un comentario

Las fuentes tipográficas EB Garamond

En el último artículo he notado que, si bien las he utilizado como ejemplo en diversos artículos sobre LyX y el uso de propiedades OpenType (aquí, aquí y aquí), nunca dediqué un artículo a la familia de fuentes tipográficas que más me agrada: EB Garamond.

Liberada bajo la licencia SIL Open Fonts License (ofl), EB Garamond es un ambicioso proyecto que trata de llevar a la era digital y con una licencia libre los diseños de Claude Garamont de mediados del siglo 16.

Con un bello diseño que le confiere gran legibilidad, magníficas ligaduras tipográficas y varias características OpenType es una fuente ideal para la creación de libros que sean un placer no solo por su contenido, sino también por su forma

EBGaramond

La fuente (especialmente la «romana» que está más completa que la «itálica») tiene verdaderas versalitas, verdaderos sub y superíndices, distintas representaciones de los números (estilo antiguo y «normal», proporcionales y tabulares), ligaduras tipográficas, etcétera. Cubre abundantemente el alfabeto latino y griego (ambas con versiones en versalitas) además del cirílico.

Dijimos que el proyecto es ambicioso y muestra de esto es su objetivo de crear variantes para los diferentes «tamaños ópticos»: versiones de la fuente que se vean bien en los distintos tamaños. Por el momento se tiene la versión de base para tipografías de unos 12 puntos y una, especial por ejemplo para notas al pie de página, diseñada para 8 puntos. Y es que para lograr un aspecto siempre agradable los tamaños pequeños deberían mostrar líneas proporcionalmente más anchas, con mayores espacios en blanco y menos detalles, mientras que los tamaños grandes deberían ser más «livianos», con formas comprimidas en su espaciado y diseños más detallados.

Es importante notar lo siguiente:

  • Para aprovechar toda la belleza de esta fuente tipográfica es necesario el soporte OpenType completo. AOO no ofrece este soporte y LibO o Calligra Suite lo ofrecen solo en forma parcial por lo que la única forma de disfrutar de esta fuente (de hecho, la única forma de lograr que las variantes de 8 y 12 puntos se seleccionen automáticamente) es a través del uso se XeTeX o LuaTeX: en estas páginas hemos hablado bastante sobre el primero, en especial cuando se relaciona con LyX.
  • La fuente aún no está «completa»: carece por ejemplo de una versión en negrita, los caracteres griegos deben ser revisados, la versión en bastardilla es menos completa que la romana, etcétera.

Pero aún así, vale la pena.

La última versión puede siempre descargarse desde bitbucket.

1 comentario

Disponible KDE Frameworks 5.10.0

El viernes  fue anunciada la décima versión de KDE Frameworks, el conjunto de más de 60 librerías para desarrollo de aplicaciones que complementan Qt5 y forman la base tanto del escritorio KDE (Plasma) como de sus aplicaciones y de otros proyectos como LXQt, maui, etcétera.

Release of KDE Frameworks 5.10.0

En esta versión no hay nuevos «módulos», pero sí muchas correcciones de error y mejoras en los módulos existentes.

Además de las correcciones en módulos como KIO, KNotifications, etcétera, algunos como KGlobalAccel, KNewStuff, KWindowSystem, etcétera, han agregado nuevas clases, herramientas y macros que darán aún más poder a los desarrolladores que los utilicen.

Para quien no pueda esperar a que su distribución Linux favorita libere paquetes de esta versión (¡cuidado con el estrés! XD ) es posible descargar el código fuente y seguir las instrucciones para compilar todo en la siguiente página: KDE Frameworks 5.10.0 Info Page.

Deja un comentario

Letras capitales en LyX

Seguramente el lector habrá visto algo como lo que se muestra en la siguiente captura de pantalla:

Capitales1

Para hacer esto en LaTeX/LyX es necesario el paquete lettrine.

LyX ofrece soporte para este paquete desde su interfaz gráfica y en la sección 6.3 del manual que encontramos en el menú Ayuda → Objetos insertados se explica claramente una de las formas de utilizarlo… porque como veremos en este artículo existe otra forma, la cual resulta mucho más simple. Y es que lo que se cuenta en el manual nos ofrece toda la flexibilidad que queramos a la hora de elegir la forma de la letra capital cada vez que la necesitemos, ¿pero qué tal si queremos utilizar letras capitales varias veces (por ejemplo, en el primer párrafo de cada capítulo) y que siempre se vean igual? Hacerlo de la forma indicada en el manual de LyX se vuelve un tanto, digamos, incómodo

Para empezar y como siempre, debemos estar seguros de que el paquete que nos interesa esté instalado en nuestro LaTeX y de no ser así instalarlo y luego reconfigurar LyX para que lo reconozca. La documentación del paquete Lettrine en Linux se instala en

/usr/share/texmf/doc/latex/lettrine/lettrine.pdf
/usr/share/texmf/doc/latex/lettrine/demo.pdf

Ahora, en un documento LyX nos dirigimos a Documento → Configuración → Módulos y habilitamos el módulo Capitales, como se muestra en la siguiente captura de pantalla:

Capitales-habilitar

¡Clic en Aplicar, no Aceptar, que aún no hemos terminado con este menú! Y es que, como suele suceder en estos casos, debemos ir al Preámbulo LaTeX para agregar algo de código…

El documento a partir del cual creé el ejemplo de la primer captura de pantalla está configurado para utilizar XeTeX con la fuente EB Garamond como fuente de base y define un «alias» de la fuente EB Garamond Initials para utilizarla como letra capital.

NOTA IMPORTANTE: EB Garamond Initials no está aún completa, ¡le falta más de la mitad del alfabeto! Solo la he utilizado como ejemplo y porque ya la tenía instalada… Si el lector conoce una fuente tipográfica decorativa más completa y agradable solo tiene que hacer dos cosas: cambiar el nombre en la primer instrucción que sigue y dejar una nota con el nombre de esa fuente en los comentarios ;)

Esto es lo que he escrito en el preámbulo:

\newfontfamily{\Iniciales}[]{EB Garamond Initials}
\renewcommand{\LettrineFontHook}{\Iniciales}
\setcounter{DefaultLines}{4}
\renewcommand{\DefaultLraise}{0.35}

La primer instrucción define una nueva «familia de fuente», definición que es utilizada en la segunda instrucción para decir al paquete Lettrine cuál fuente queremos para las letras capitales. La tercer instrucción dice cuántas líneas debe ocupar la letra capital mientras que la cuarta «sube» la letra del valor indicado entre llaves para evitar que «choque» con el texto que le sigue. Esta última instrucción podría no ser necesaria dependiendo de la fuente tipográfica utilizada.

Hecho esto, cuando queremos insertar una nueva letra capital seleccionamos el primer carácter del párrafo en cuestión y hacemos clic derecho → Estilo de texto → Capital, como mostrado a continuación

Capitales2

que en la interfaz gráfica de LyX se ve así:

Capitales3

y en el documento compilado se ve como en la captura de pantalla que abre este artículo.

Y eso es todo por hoy. La documentación del paquete Lettrine es breve por lo que el lector no tendrá problemas en encontrar otras opciones para ajustar todo a sus preferencias en forma rápida y simple.

,

1 comentario

A %d blogueros les gusta esto: