> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/latex/es/articulos-en-profundidad/07-an-introduction-to-luatex-part-1-what-is-it-and-what-makes-it-so-different.md).

# Introducción a LuaTeX (Parte 1): ¿Qué es y qué lo hace tan diferente?

LuaTeX es un *conjunto de herramientas*—contiene sofisticadas herramientas y componentes de software con los que puedes construir (maquetar) una amplia gama de documentos. El subtítulo de este artículo también plantea dos preguntas sobre LuaTeX: ¿qué es y qué lo hace tan diferente? La respuesta a “¿Qué es?” puede parecer obvia: “¡Es un motor de composición tipográfica TeX!” En efecto lo es, pero una visión más amplia, y a la que se suscribe este autor, es que LuaTeX es un sistema extremadamente versátil basado en TeX para *construcción de documentos e ingeniería*.

### Explicar LuaTeX: ¿por dónde empezar?

El objetivo de este primer artículo sobre LuaTeX es ofrecer un contexto para comprender lo que proporciona este motor TeX y por qué/cómo su diseño permite a los usuarios construir/diseñar/crear una amplia gama de soluciones a problemas complejos de composición y diseño tipográfico —quizá también ofreciendo cierto grado de “preparación para el futuro” a medida que los usuarios necesitan cada vez más software basado en TeX capaz de adaptarse al ecosistema técnico en constante cambio. En opinión de este autor, enumerar y describir sus funciones/capacidades no es necesariamente el mejor lugar para comenzar a desarrollar una comprensión de las capacidades y el potencial de LuaTeX. Ese enfoque no será particularmente útil para lectores que no estén familiarizados con otros motores TeX y para quienes las comparaciones basadas en funciones difícilmente resultarán especialmente significativas.

A riesgo de agotar la paciencia del lector (“¡Vaya al grano!”), adoptaré un enfoque más “holístico”, con la esperanza de proporcionar antecedentes útiles, pero a costa de algo de lectura adicional —y de adentrarnos en algunos temas de programación para ayudar a la comprensión. En [Parte 2](/latex/es/articulos-en-profundidad/09-an-introduction-to-luatex-part-2-understanding-directlua.md) exploramos el uso de `\directlua` pero, por ahora, tratamos de sentar las bases para comprender LuaTeX.

Este artículo refleja en gran medida el “recorrido” personal del autor al desarrollar una comprensión y apreciación de LuaTeX: que, conociendo primero algo sobre la filosofía detrás del desarrollo de LuaTeX, y viéndolo como un contenedor de herramientas de software, apreciarás mejor los amplios dominios de soluciones que este asombroso software abre.

## LuaTeX: ¡No solo para la academia o las matemáticas!

La gran cantidad de funciones y capacidades incorporadas en LuaTeX no solo proporcionan una composición tipográfica de calidad excepcional mediante LaTeX tradicional, sino que también ofrecen un enorme margen para desarrollar soluciones a medida, no basadas en LaTeX, para problemas complejos de producción e ingeniería de documentos. LuaTeX incorpora el potente lenguaje de scripting Lua, lo que significa, por ejemplo, que puedes usar Lua para cargar “plugins” (bibliotecas externas de software) en LuaTeX; esto permite además altos niveles de automatización, integración en sistemas de software o flujos de trabajo existentes y el aprovechamiento de software especializado para el procesamiento de datos, texto o gráficos.

Históricamente, TeX se ha asociado con la autoría/publicación académica, especialmente en matemáticas, pero LuaTeX, en particular, tiene un potencial significativo de aplicación en muchos otros ámbitos, incluida la producción comercial de documentos PDF. Un ejemplo de ello es [speedata publisher](https://speedata.github.io/publisher/) que usa LuaTeX puramente como motor de generación de PDF dentro de su flujo de trabajo basado en XML: no utiliza LaTeX en absoluto. De hecho, speedata publisher contiene prácticamente ningún código TeX: le pregunté a [Patrick Gundlach](https://twitter.com/patrickgundlach), desarrollador de speedata publisher, quien confirmó que, en total, utiliza alrededor de tres líneas de código TeX. Sus potentes capacidades de composición están diseñadas e implementadas en código Lua, utilizando la API Lua de LuaTeX (un tema que tratamos más adelante en este artículo).

## Una breve historia personal: cómo descubrí LuaTeX por primera vez

Descubrí LuaTeX por primera vez a finales de 2009/principios de 2010, cuando aún estaba en fase beta media (versión 0.50). En aquel momento buscaba software basado en TeX para maquetar las notas manuscritas resultantes de mis esfuerzos por aprender algo de árabe. Las búsquedas en Google revelaron una colección de videos de la conferencia TUG 2009 ([ahora en YouTube](https://www.youtube.com/playlist?list=PL2D4DD50DC9C0BA0E)) que incluía demostraciones de composición tipográfica árabe de altísima calidad (mediante el paquete [ConTeXt](http://wiki.contextgarden.net/Main_Page)). Esos videos también incluyen una charla titulada [El proyecto LuaTeX: a mitad de camino hacia la versión 1](https://youtu.be/AKv4po9PGW0).

El motor TeX que se usaba para producir esa exquisita composición árabe era algo llamado “LuaTeX”. En ese momento trabajaba en edición científica (física), pero aunque era plenamente consciente de TeX/LaTeX, no había oído hablar de LuaTeX: me intrigó y quise aprender más sobre este nuevo motor TeX. Como LuaTeX aún estaba en fase beta de desarrollo y evolucionaba rápidamente, quería estar al día con las últimas actualizaciones, así que la mejor opción (para mí) fue la ruta del hágalo usted mismo de construir (compilar) el ejecutable de LuaTeX a partir de su código fuente. Además del programa ejecutable LuaTeX, también necesitas una “instalación de TeX” para proporcionar el entorno en el que ejecutar LuaTeX (por ejemplo, texmf.cnf, paquetes de macros, fuentes, etc.). En lugar de descargar e instalar la enorme [TeX Live](https://www.tug.org/texlive/) distribución, opté por crear una instalación de TeX totalmente mínima y personalizada con la que explorar LuaTeX (un ejercicio “interesante” que [documenté en mi blog personal](http://www.readytext.co.uk/?cat=30)). Cada nueva versión de LuaTeX va acompañada de su Manual de referencia (por ejemplo, para[la versión 1.0.4](https://www.tug.org/svn/texlive/tags/texlive-2017.1/Master/texmf-dist/doc/luatex/base/luatex.pdf?revision=44591\&view=co)) que documenta las funciones y capacidades más recientes del software. Sin embargo, es un *manual de referencia* y (necesariamente) bastante escaso en explicaciones adecuadas para el principiante que desea comenzar con este increíble motor TeX: se asume cierto grado de familiaridad con conceptos TeX de bajo nivel. Dado que descubrí LuaTeX en una etapa relativamente temprana de su desarrollo, el buen material introductorio era, en aquel momento, relativamente difícil de encontrar, así que hizo falta algo de exploración, experimentación (y algo de frustración...) antes de que las piezas empezaran a encajar. No hace falta decir que mis estudios de árabe se detuvieron bruscamente cuando quedé fascinado por este asombroso software y, finalmente, pasé a escribir [plugins de LuaTeX para la composición tipográfica del árabe](http://www.readytext.co.uk/?p=3143) ¡en su lugar!

Mi propio “recorrido con LuaTeX” fue ciertamente muy no lineal, pero, en el camino, me brindó la oportunidad de aprender sobre (Lua)TeX (y las instalaciones de TeX) “desde cero”: mi blog alberga una colección ecléctica de [artículos](http://www.readytext.co.uk/?cat=3) basados en diversos temas que exploré y trabajé durante ese tiempo. Ojalá este artículo haga un uso apropiado de ese tiempo y experiencia, ayudando a otros a interesarse por comenzar a explorar las capacidades de LuaTeX. LuaTeX continúa desarrollándose y, en el momento de escribir esto, ha alcanzado la versión 1.0.4, publicada con TeX Live 2017. Los desarrolladores son muy activos y cualquier error descubierto suele corregirse poco después de ser informado, por ejemplo, a través de la [lista de correo dev-luatex](https://mailman.ntg.nl/mailman/listinfo/dev-luatex) o mediante el [rastreador de errores de LuaTeX en línea](http://tracker.luatex.org/my_view_page.php). Mucho antes de alcanzar la versión 1.0, LuaTeX ya era apto para producción, aunque, por supuesto, había que aceptar que las funciones evolucionaban continuamente y, en ocasiones, los cambios podían romper el código TeX existente. Hoy en día, por supuesto, LuaTeX está soportado por las plataformas Overleaf y ShareLaTeX (como LuaLaTeX).

## TeX en un mundo cambiante: nuevas tecnologías y flujos de trabajo

Está claro que los motores TeX no operan en un mundo tecnológicamente estático y, ocasionalmente, surgen innovaciones que son candidatas inmediatas y obvias para su inclusión en los motores TeX: una de esas innovaciones son las fuentes variables OpenType, que comentamos brevemente a continuación. Aunque no cabe duda de que el software de composición tipográfica basado en TeX es extraordinariamente versátil, los motores TeX operan ahora en un ecosistema de software muy diverso y en rápida evolución; nuevos flujos de trabajo acentúan la necesidad de integración y la flexibilidad para implementar una amplia gama de soluciones de documentos/composición, de las cuales TeX puede ser solo un componente.

TeX no solo tiene que seguir siendo relevante para sus usuarios actuales, sino también atraer a nuevos, permitiendo soluciones de creación de contenido que sigan siendo útiles para las generaciones entrantes: personas que quizá no deseen usar TeX como una herramienta autónoma, sino, tal vez, como parte de un flujo de trabajo global mediante plataformas colaborativas en línea como Overleaf.

Incluso una breve ojeada a [tex.stackexchange](https://tex.stackexchange.com/) demuestra la enorme variedad de documentos y soluciones que se están produciendo e implementando con software basado en TeX, a menudo mostrando una increíble inventiva a medida que las personas encuentran cada vez más casos de uso y tipos de contenido que desean generar. Además, la necesidad de flujos de trabajo que puedan procesar contenido/marcado basado en TeX para producir salidas no PDF (y no DVI) nunca ha sido mayor, como MathML/XML y HTML. Por ejemplo, “convertir” TeX en el [JATS XML](https://jats.nlm.nih.gov/) formato (durante mucho tiempo usado en la publicación de revistas académicas), pero también, más recientemente, el auge de epub usado en la publicación de libros electrónicos.

### Tecnología de fuentes variables: los tiempos están cambiando

El 14 de septiembre de 2016, Microsoft, [Google](https://opensource.googleblog.com/2016/09/introducing-opentype-font-variations.html), [Adobe](https://blog.typekit.com/2016/09/14/variable-fonts-a-new-kind-of-font-for-flexible-design/) y Apple anunciaron una nueva tecnología de fuentes: [fuentes variables OpenType](https://medium.com/@tiro/https-medium-com-tiro-introducing-opentype-variable-fonts-12ba6cd2369). No exploraremos esta tecnología con ningún detalle, pero basta decir que expertos en fuentes muy respetados como [Thomas Phinney](https://twitter.com/ThomasPhinney) y [John Hudson](https://twitter.com/TiroTypeworks) han observado ([en Twitter](https://twitter.com/ThomasPhinney/status/917087509342851072)) que la tecnología de fuentes variables se está adoptando mucho más rápido que muchas innovaciones tipográficas anteriores, muy probablemente impulsada por las necesidades de los diseñadores web que requieren diseños adaptativos que se ajusten a la miríada de diferentes tamaños/resoluciones de pantalla presentes en los dispositivos móviles.

Claramente, las fuentes variables OpenType son un desarrollo interesante y emocionante en las tecnologías tipográficas, del cual sin duda los usuarios de TeX podrían beneficiarse; de hecho, esta cuestión inevitablemente se ha [planteado en tex.stackexchange](https://tex.stackexchange.com/questions/355104/tex-luatex-xetex-fontspec-support-for-opentype-variable-fonts) con el soporte de LuaTeX discutido en la lista de correo de LuaTeX [lista de correo](https://www.tug.org/pipermail/luatex/2016-September/006204.html).

Vale la pena señalar de paso que la tecnología tipográfica basada en la creación “paramétrica” de fuentes no es una idea completamente nueva: METAFONT de Knuth y las tecnologías Multiple Master de Adobe son, en cierto modo, progenitores tempranos, aunque los detalles de implementación sean bastante diferentes.

### Fuentes variables: ¿cuándo las queremos? —¡ahora!

Cualquier estándar/especificación de tecnología nueva y útil necesita tiempo para integrarse en su ecosistema objetivo de desarrolladores e implementadores, incluido tiempo para aclarar cualquier ambigüedad o interpretación de las formulaciones dentro de la propia especificación. Los desarrolladores tienen que leer y comprender la documentación y convertirla en software real que funcione, lo que aquí incluye crear las fuentes y tecnologías para usarlas: navegadores compatibles y motores de composición tipográfica. Los desarrolladores de TeX claramente necesitarán acceso a fuentes variables de alta calidad que puedan usarse como “referencias” fiables para implementar (programar) el soporte para tecnologías de fuentes variables.

Implementar cualquier nueva tecnología dentro de TeX, como las fuentes variables, plantea la *posible* necesidad de modificar los internos de los motores TeX; por supuesto, la necesidad de hacerlo depende de la naturaleza de esa tecnología y, crucialmente, de qué aspecto del comportamiento de TeX se está sometiendo a cambio. No siempre es necesario modificar los propios motores TeX, quizá solo requiera cambios en el software de apoyo/complementario, incluidos los “componentes” (bibliotecas de código de terceros) usados dentro de esos programas. Internamente, los motores TeX son *diabólicamente* complejos: desarrollar una comprensión del código fuente de TeX suficiente para realizar modificaciones fiables requiere una experiencia considerable y altamente especializada (de la que hay una oferta muy limitada). También es esencial que cualquier modificación no afecte negativamente la estabilidad/compatibilidad a largo plazo de los motores TeX, algo vital para la comunidad TeX y para quienes procesan posteriormente los archivos (La)TeX de un autor, sobre todo los editores académicos y los servicios basados en la nube como Overleaf y ShareLaTeX.

Es probable que muchos usuarios de TeX estén interesados en aprovechar las fuentes variables; por ejemplo, para implementar nuevas posibilidades de diseño o encontrar soluciones a problemas complicados de composición. Así que, en cierto sentido, hay un dilema: usuarios de TeX que desean acceso a una nueva tecnología pero cuya implementación depende de un recurso muy limitado: el número de desarrolladores cualificados y capaces de hacerlo realidad. Modificar los internos de TeX es difícil y, en general, conviene evitarlo siempre que sea posible, así que ¿hay otra manera de abordar la adición de (ciertas clases de) nuevas funciones/capacidades a TeX? ¡Sí! Y LuaTeX ha tomado ese camino.

#### Experimentos iniciales: fuentes variables OpenType y LuaTeX

El diseño de LuaTeX ha permitido experimentar rápidamente con la tecnología de fuentes variables. Ya, a abril de 2017, el formato TeX ConTeXt, que usa LuaTeX, tenía una [versión beta](https://mailman.ntg.nl/pipermail/ntg-context/2017/088343.html) que implementaba fuentes variables OpenType. Esto fue posible porque el soporte tipográfico de ConTeXt está construido en código Lua (y ConTeXt tiene su propio cargador de fuentes escrito en Lua).

## LuaTeX: antecedentes e historia

LuaTeX es, en términos de TeX, “el recién llegado”, a pesar de haber estado en desarrollo activo durante más de 10 años. El sitio web de LuaTeX [documenta](http://www.luatex.org/roadmap.html) que LuaTeX comenzó en 2005 con (creo) un desarrollo activo y sostenido que empezó en 2006. Debido a su complejidad inherente, y al esmero de quienes lo construyeron, LuaTeX realmente necesitó 10 años de desarrollo para alcanzar la versión 1.0, que fue [anunciada por sus desarrolladores](https://mailman.ntg.nl/pipermail/dev-luatex/2016-September/005882.html) (Hans Hagen, Hartmut Henkel, Taco Hoekwater, Luigi Scarso) el 27 de septiembre de 2016.

Dentro de ese anuncio de lanzamiento hay una declaración importante de principio:

> “Nuestro objetivo principal es proporcionar una variante de TeX que permita extensiones del usuario sin necesidad de adaptar el funcionamiento interno.”

Esta formulación encapsula a la perfección la filosofía detrás del desarrollo de LuaTeX y apunta a una vía mediante la cual el software basado en TeX puede abordar los desafíos que ya hemos mencionado: adoptar nuevas tecnologías y seguir siendo relevante para nuevas generaciones de usuarios.

Ahora es el momento de abordar la segunda pregunta contenida en el subtítulo de este artículo: “qué lo hace tan diferente”. Al explorar el significado de “...permite extensiones del usuario sin necesidad de adaptar el funcionamiento interno” podemos comprender mejor la esencia de lo que LuaTeX “aporta a la mesa”.

## LuaTeX: abriendo la “caja negra” de TeX

El programa TeX original de Knuth es el ancestro común de todos los motores TeX modernos en uso hoy, y LuaTeX es, en efecto, el paso evolutivo más reciente: derivado del programa pdfTeX, pero con la adición de algunos potentes componentes de software que aportan mucha funcionalidad extra. Cuando Knuth escribió la versión original del software TeX también proporcionó el lenguaje TeX como una forma de controlar y programar su comportamiento de composición: se pusieron a disposición de los usuarios y desarrolladores de paquetes de macros TeX unos 320 comandos de bajo nivel (primitivas). Esos comandos ofrecían distintos grados de control o influencia sobre ciertos aspectos del comportamiento tipográfico de TeX, pero gran parte de la funcionalidad interna de TeX, los algoritmos, los procesos de toma de decisiones, los datos y las estructuras de datos estaban ocultos para el usuario. Es discutible que el programa TeX de Knuth no fuera una “caja negra” total, pero ciertamente era un tono muy oscuro de gris; admitidamente, el código fuente estaba disponible, pero para la gran mayoría de las personas eso también es una caja negra incomprensible.

Nos referimos a los procesos internos de TeX como algo así como una “caja negra”; sin embargo, LuaTeX abre sus internos basados en TeX para brindar a usuarios/desarrolladores un acceso mucho mayor, y control, a muchos de los procesos antes ocultos que ocurren en lo profundo del motor TeX. LuaTeX también añade muchas nuevas primitivas que proporcionan control sobre las nuevas funciones.

### LuaTeX: derivado de pdfTeX pero no usa el código de pdfTeX

Para ser precisos, es importante señalar que aunque describimos LuaTeX como derivado de pdfTeX, LuaTeX no utiliza directamente el código original del programa pdfTeX. Uno de los desarrolladores de LuaTeX (Taco Hoekwater) emprendió la tarea verdaderamente *hercúlea* de reescribir el núcleo del motor TeX de LuaTeX en código C limpio y moderno (CWEB).

#### Nota histórica

En parte debido a la antigüedad del código fuente original de TeX de Knuth —del que derivan sus descendientes modernos—, modificarlo para adaptar o crear nuevos motores de composición basados en TeX es un proceso complejo y enrevesado. Parte de ese proceso requiere la conversión de código Pascal a código C, lo cual no está exento de una [cierta complejidad](http://www.readytext.co.uk/?p=2529). El código C resultante generado automáticamente es extraordinariamente prolijo y muy difícil de leer o comprender. Está claro que tener el código de LuaTeX completamente reescrito evita por completo el proceso de conversión de Pascal a C.

## Los bloques de construcción de LuaTeX

En la introducción hicimos referencia a LuaTeX como un “conjunto de herramientas” y lo describimos como “sistema de construcción e ingeniería de documentos”. Hemos visto que en el anuncio de LuaTeX 1.0 sus desarrolladores afirmaron:

> “Nuestro objetivo principal es proporcionar una variante de TeX que permita extensiones del usuario sin necesidad de adaptar el funcionamiento interno.”

Ahora es el momento de unir estos hilos e ideas para centrarnos en los detalles de lo que todo esto *realmente significa* en la práctica.

### El rompecabezas de LuaTeX

Si miraras “bajo el capó” verías que el software LuaTeX, es decir, el programa ejecutable real, está construido a partir de una colección de componentes de software que se combinan para proporcionar la funcionalidad global de LuaTeX. Por supuesto, esto no es nada nuevo y la mayoría del software se construye así. Sin embargo, lo que hace a LuaTeX diferente de otros motores TeX es que estos componentes se combinan de tal manera que se da a los usuarios un acceso mucho mayor a muchos aspectos de la funcionalidad interna de TeX: los algoritmos de composición, los procesos de toma de decisiones, los datos y las estructuras de datos de TeX. Esta apertura de los internos de TeX permite a los usuarios construir nuevas soluciones tipográficas sin necesidad de modificar el propio motor TeX.

### El Lua de LuaTeX: una clave para la “caja negra”

Lua es un lenguaje de scripting muy potente, pero fácil de aprender, que [se originó en Brasil](https://www.lua.org/about.html)—fue creado en 1993 y sigue desarrollándose activamente. Una de las fortalezas de Lua es su uso como lenguaje de programación para “unir” componentes de software dispares, permitiéndote usarlos mediante un lenguaje de scripting simple pero versátil. Lua desempeña un papel central al abrir el funcionamiento interno del motor TeX de LuaTeX, pero para entender mejor cómo se logra esto, conviene hacer una pequeña digresión para discutir muy brevemente dos conceptos de programación:

* Interfaz de programación de aplicaciones (API);
* vinculación de lenguaje de programación.

Siéntete libre de omitir esta sección si te sientes cómodo con esos conceptos. Ninguno de los dos temas se tratará con detalle: no pretendemos un rigor técnico estricto, sino proporcionar solo el trasfondo suficiente para conocer estos conceptos: su significado y relevancia para LuaTeX.

### Interfaz de programación de aplicaciones (API)

Imagina que eres un programador que ha escrito algo de código que otros usuarios (otros programadores) podrían encontrar útil, pero tu código es complejo y no quieres que los usuarios de tu código tengan que preocuparse por esos detalles de bajo nivel. Ten en cuenta que esos programadores/desarrolladores trabajan con el mismo lenguaje de programación que tú usaste para escribir tu código. Además, supongamos que tienes planes de reescribir algunas partes de tu código, por ejemplo, para hacerlo más rápido, requerir menos memoria, etc. Los usuarios existentes de tu código no deberían tener que preocuparse por eso: cualquier cambio que planees hacer no debería romper sus programas. Entonces, ¿cuál es la solución?

La respuesta está en algo llamado API: una *interfaz de programación de aplicaciones*. En lugar de exigir a los usuarios (otros programadores) que accedan a los detalles de bajo nivel de tu código —que podrían cambiar—, proporcionas un conjunto específico de *funciones* que otros programadores pueden usar. Esas funciones son una *interfaz* a tu código, a través de la cual otros desarrolladores pueden construir *aplicaciones* sin necesidad de conocer íntimamente el funcionamiento interno de tu programa. En cierto modo, puedes pensar en esto como una capa adicional que rodea tu código y “aísla” a los usuarios de los detalles confusos de bajo nivel.

Siempre que no cambies esas funciones (la interfaz), eres libre de modificar y actualizar los detalles de nivel inferior de tu software sin afectar (romper) el trabajo de quienes confían en tu código para construir sus aplicaciones: de ahí el término Interfaz de programación de aplicaciones.

#### APIs: una analogía con los paquetes LaTeX

Cuando usas comandos proporcionados por un paquete LaTeX, puedes pensar en los comandos del paquete como una forma de API. Como usuario, no necesariamente te preocupan las maravillas de TeX y LaTeX detrás de esos comandos (es decir, en el código del paquete): todo lo que quieres es hacer uso de la funcionalidad que proporcionan.

### Vinculación de lenguaje de programación

Hemos visto que los programadores que escriben/publican un cuerpo de código útil (llamado una *biblioteca*) pueden proporcionar una llamada Interfaz de programación de aplicaciones (un conjunto de funciones) mediante la cual otros programadores, usando el *mismo* lenguaje de programación, pueden hacer uso de esa biblioteca (colección de código). Esto está bien cuando ambas partes (desarrollador de la biblioteca y sus usuarios) usan el *mismo* lenguaje de programación, pero ¿qué pasa si programadores que usan un *diferente* lenguaje de programación también quieren hacer uso de esa biblioteca? Por ejemplo, podrías escribir scripts usando el lenguaje Lua pero querer hacer uso de una biblioteca escrita en, por ejemplo, lenguajes de programación como C/C++. De alguna manera, los dos lenguajes de programación diferentes (Lua y C/C++) necesitan la capacidad de “comunicarse” entre sí. Una solución a este problema es la llamada [vinculación de lenguajes](https://en.wikipedia.org/wiki/Language_binding).

Examinar los detalles técnicos de la vinculación de lenguajes está fuera del alcance de este artículo, así que daremos un resumen conciso de los principios generales. En esencia, al añadir una “capa” adicional adecuada de código a la biblioteca original, esta puede “comunicarse” con otro lenguaje de programación (como Lua): esa capa de código se llama una *vinculación*. Permite que los dos lenguajes interoperen a través de una API mediante la cual los programadores del segundo lenguaje (como Lua) pueden acceder a las funciones/servicios proporcionados por la biblioteca.

![Diagrama esquemático que muestra el concepto de una vinculación de lenguaje.](/files/a196ec1ef95f93d8785e23b1cd419da0380b0e6a)

**Figura 1**: Diagrama esquemático que muestra el concepto de una vinculación de lenguaje: permite que un programa escrito en Lua use una biblioteca externa escrita en otro lenguaje de programación. Es mediante el uso de vinculaciones de Lua que los componentes internos de LuaTeX, y por tanto gran parte de la funcionalidad tipográfica interna de LuaTeX, se ponen a disposición de los usuarios para desarrollar soluciones a problemas complejos de composición tipográfica.

## LuaTeX: dos opciones de programación: TeX y Lua

Esencialmente, LuaTeX es un motor TeX que admite dos lenguajes de programación: el lenguaje tradicional basado en TeX y el lenguaje de scripting Lua. Por supuesto, puedes usar ambos lenguajes en el mismo documento TeX o, si lo prefieres, seguir componiendo tipográficamente por la vía de solo TeX: por ejemplo, mediante el paquete de macros LaTeX (LuaLaTeX). TeX (o LaTeX) no es un lenguaje de programación fácil de usar o aprender, y relativamente pocas personas han dominado realmente las muchas idiosincrasias de TeX: los conceptos de [tokens](https://www.overleaf.com/blog/522-what-is-a-tex-token) y expansión son bastante ajenos a las expectativas y experiencias de la mayoría de las personas respecto a un lenguaje de programación.

La adición de Lua abre la posibilidad de usar la composición tipográfica basada en TeX mediante un lenguaje de programación mucho más accesible y convencional: como se señaló al comienzo de este artículo, utilizando la API de Lua puedes realizar [una composición tipográfica sofisticada sin prácticamente ningún código TeX](http://wiki.luatex.org/index.php/TeX_without_TeX).

### LuaTeX añade muchas nuevas primitivas

Cada motor TeX proporciona cientos de los llamados comandos primitivos: los bloques de construcción fundamentales del lenguaje basado en TeX que admite cada motor de composición tipográfica individual. La versión original de TeX lanzada por Donald Knuth proporcionaba aproximadamente 320 comandos, pero los motores TeX más nuevos (pdfTeX, XeTeX y LuaTeX) han añadido cada uno muchas nuevas primitivas para proporcionar a los usuarios acceso a las funciones y funcionalidades adicionales de cada motor. El considerable número de nuevas primitivas de LuaTeX está documentado en su [Manual de referencia](https://www.tug.org/svn/texlive/tags/texlive-2017.1/Master/texmf-dist/doc/luatex/base/luatex.pdf?revision=44591\&view=co).

Entre las muchas nuevas primitivas introducidas por LuaTeX hay una llamada `\directlua{...}` que es la puerta de entrada al uso del código Lua: acceder a los internos del motor LuaTeX para crear herramientas y soluciones de composición tipográfica sofisticadas.

### \directlua{...}: La puerta de entrada a la programación Lua

Como se ha comentado, el lenguaje de scripting Lua puede verse como una “capa” a través de la cual es posible acceder al motor de composición tipográfica basado en TeX de LuaTeX y a la funcionalidad proporcionada por muchos de los componentes a partir de los cuales está construido LuaTeX. El lenguaje Lua también es el mecanismo que permite la extensibilidad de LuaTeX, gracias a la capacidad de Lua para cargar bibliotecas externas especializadas de software/código.

Colectivamente, la interfaz Lua (conjunto de funciones basadas en Lua) proporcionada por LuaTeX se denomina su *API de Lua*: es el “enlace de comunicación” entre el motor/componentes internos de LuaTeX y el documento del usuario.

### Un ejemplo sencillo de \directlua{...}

Las siguientes *extremadamente simple* ejemplo ni siquiera empieza a rascar la superficie de la punta del iceberg de posibilidades. Sin embargo, sirve para demostrar la idea básica de la interacción entre la “forma TeX” y la “forma Lua” de acceder a los parámetros de TeX.

Observa que:

* `\hsize` es una primitiva de TeX (comando) que establece el valor de un parámetro interno que determina el ancho de las líneas compuestas; por ejemplo, normalmente se lo fija a un valor adecuado dentro de un `\vbox{...}`. `\hsize` es solo uno de *muchas* parámetros de TeX a los que puedes acceder y/o modificar mediante código Lua.
* Acceder a los parámetros de TeX es solo un *pequeño* aspecto de la API Lua de LuaTeX: ¡hay muchísimo más!

```latex

\documentclass{article}
\begin{document}
\let\\\relax % redefine el significado de \\ para evitar problemas de expansión
Aquí está el valor actual de {\ttfamily\string\hsize} (vía \LaTeX):
\the\hsize\par
\directlua{
% Obtener el valor actual de \hsize usando la API de Lua
local hs=tex.hsize
% Usa una función de la API de Lua para imprimir algo
% Código LaTeX y el valor de \hsize
tex.print("Aquí está el valor de {\\ttfamily\\string\\hsize}
informado desde código Lua (en puntos escalados): ")
tex.print(hs.."\\par")
% Establecer un nuevo valor para \hsize usando la API de Lua
tex.hsize="400pt" % o usa tex.hsize=400*65536 (en puntos escalados)
}%
% Después de que \directlua haya terminado, pídele a LaTeX
% que nos diga el nuevo valor de \hsize
Aquí está el valor de {\ttfamily\string\hsize} informado
por \LaTeX{} después de que {\tt\string\directlua} haya terminado:
\the\hsize\par
\end{document}
```

Aquí hay una imagen que muestra el resultado de la composición tipográfica de LaTeX por LuaTeX (arriba):

![Resultados de ejecutar LuaTeX](/files/f19f30f5ad48341b8a470e67825c69db3cab889c)

Observa que el “truco” de TeX de `\let\\\relax` es evitar problemas causados por la “expansión” del código Lua en LuaTeX: un tema que señalamos brevemente a continuación.

### Uso del código Lua

Hay dos opciones principales para usar código Lua en tus documentos TeX/LaTeX:

1. **En línea**: Escribir código Lua directamente dentro de tu `.tex` documento (como en el ejemplo anterior);
2. **Externo**: Almacenar el código Lua en archivos de código `.lua` externos y usar las facilidades de Lua para cargarlos y ejecutarlos.

La opción (1) es la más adecuada para fragmentos más cortos de código Lua. La opción (2) se usa para programas más grandes o bibliotecas de código Lua. Tiene una ventaja clara: puedes evitar problemas complicados que implican los llamados `\catcode` valores de TeX `\catcode`  (que pueden ser “bastante frustrantes”). La razón de estos

Por supuesto, hay paquetes LaTeX para ayudar a usar código Lua en tus archivos .tex; por ejemplo, puedes usar el [paquete luacode](https://ctan.org/pkg/luacode?lang=en).

## Resumen e introducción de la Parte 2 de este artículo

Los componentes de software con los que está construido LuaTeX, junto con el lenguaje de scripting Lua integrado, proporcionan una poderosa combinación para construir soluciones capaces de resolver una amplia gama de problemas complejos de composición tipográfica, y para diseñar flujos de trabajo de producción de documentos que pueden beneficiarse de una estrecha integración con un motor de composición tipográfica basado en TeX. En [Parte 2 de este artículo](/latex/es/articulos-en-profundidad/09-an-introduction-to-luatex-part-2-understanding-directlua.md) analizamos en profundidad el comando más potente que proporciona LuaTeX: `\directlua`.

¡Hasta entonces, feliz uso de LuaTeX!

## Agradecimientos

El autor está sumamente agradecido a [Luigi Scarso](https://twitter.com/luigi_scarso), uno de los desarrolladores de LuaTeX, por tomarse el tiempo de leer un borrador de este artículo y hacer una serie de comentarios y sugerencias muy útiles. Cualquier error de hecho u omisión que permanezca es, por supuesto, responsabilidad del autor. Además, me gustaría agradecer a [Patrick Gundlach](https://twitter.com/patrickgundlach), desarrollador de [speedata publisher](https://speedata.github.io/publisher/), por su tiempo para responder a mis preguntas.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://overleaf-pro.ayaka.space/latex/es/articulos-en-profundidad/07-an-introduction-to-luatex-part-1-what-is-it-and-what-makes-it-so-different.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.