Nueva línea

Newline insertada entre las palabras "Hola" y "mundo"

Nueva línea (frecuentemente llamado fin de línea, fin de línea (EOL), siguiente línea (NEL) o salto de línea) es un carácter de control o una secuencia de caracteres de control en especificaciones de codificación de caracteres como ASCII, EBCDIC, Unicode, etc. Este carácter, o una secuencia de caracteres, se utiliza para indicar el final de una línea de texto y el comienzo de una nueva.

Historia

A mediados de 1800, mucho antes de la llegada de los teletipos y las máquinas de teletipo, los operadores de código Morse o los telegrafistas inventaron y usaron los prosignos de código Morse para codificar el formato de texto de espacios en blanco en mensajes de texto escritos formales. En particular, el prosigno Morse BT (nemotécnico b reak text) representado por la concatenación de códigos Morse textuales literales "B" y "T" Los caracteres enviados sin el espaciado normal entre caracteres se utilizan en el código Morse para codificar e indicar una nueva línea o una nueva sección en un mensaje de texto formal.

Más tarde, en la era de las teleimpresoras modernas, se desarrollaron códigos de control de conjuntos de caracteres estandarizados para ayudar en el formato de texto de espacios en blanco. ASCII fue desarrollado simultáneamente por la Organización Internacional para la Estandarización (ISO) y la Asociación Estadounidense de Estándares (ASA), siendo esta última la organización predecesora del Instituto Nacional Estadounidense de Estándares (ANSI). Durante el período de 1963 a 1968, los borradores de normas ISO admitían el uso de CR+LF o LF solo como nueva línea, mientras que los borradores de ASA admitían solo CR+LF.

La secuencia CR+LF se usaba comúnmente en muchos de los primeros sistemas informáticos que habían adoptado máquinas de teletipo, generalmente un modelo de teletipo. 33 ASR: como un dispositivo de consola, porque esta secuencia era necesaria para colocar esas impresoras al comienzo de una nueva línea. La separación de nueva línea en dos funciones ocultó el hecho de que el cabezal de impresión no podía volver desde el extremo derecho hasta el comienzo de la siguiente línea a tiempo para imprimir el siguiente carácter. Cualquier carácter impreso después de un CR solía imprimirse como una mancha en el medio de la página mientras el cabezal de impresión todavía estaba moviendo el carro de vuelta a la primera posición. "La solución fue hacer que la nueva línea tuviera dos caracteres: CR para mover el carro a la columna uno, y LF para mueve el papel hacia arriba." De hecho, a menudo era necesario enviar caracteres adicionales, CR o NUL extraños, que se ignoran pero dan tiempo al cabezal de impresión para moverse al margen izquierdo. Muchas de las primeras pantallas de video también requerían múltiples tiempos de caracteres para desplazarse por la pantalla.

En dichos sistemas, las aplicaciones tenían que comunicarse directamente con la máquina de teletipo y seguir sus convenciones, ya que el concepto de controladores de dispositivos que ocultan dichos detalles de hardware de la aplicación aún no estaba bien desarrollado. Por lo tanto, el texto se compuso de forma rutinaria para satisfacer las necesidades de las máquinas de teletipo. La mayoría de los sistemas de minicomputadoras de DEC utilizaron esta convención. CP/M también lo usó para imprimir en los mismos terminales que usaban las minicomputadoras. A partir de ahí, MS-DOS (1981) adoptó CP/M's CR+LF para ser compatible, y esta convención fue heredada por el sistema operativo Windows posterior de Microsoft.

El sistema operativo Multics comenzó a desarrollarse en 1964 y usaba LF solo como su nueva línea. Multics usó un controlador de dispositivo para traducir este carácter a cualquier secuencia que necesitara una impresora (incluidos los caracteres de relleno adicionales), y el byte único era más conveniente para la programación. Lo que parece una opción más obvia, CR, no se usó, ya que CR proporcionó la función útil de sobreimprimir una línea con otra para crear efectos de negrita, subrayado y tachado. Quizás lo más importante es que el uso de LF solo como terminador de línea ya se había incorporado en los borradores del estándar ISO/IEC 646 final. Unix siguió la práctica de Multics, y más tarde los sistemas similares a Unix siguieron a Unix. Esto creó conflictos entre Windows y los sistemas operativos similares a Unix, por lo que los archivos compuestos en un sistema operativo no podían ser formateados o interpretados correctamente por otro sistema operativo (por ejemplo, un script de shell UNIX escrito en un editor de texto de Windows como el Bloc de notas).

Representación

Los conceptos de retorno de carro (CR) y salto de línea (LF) están estrechamente relacionados y pueden considerarse por separado o juntos. En los medios físicos de máquinas de escribir e impresoras, dos ejes de movimiento, "abajo" y "across", son necesarios para crear una nueva línea en la página. Aunque el diseño de una máquina (máquina de escribir o impresora) debe considerarlos por separado, la lógica abstracta del software puede combinarlos como un solo evento. Esta es la razón por la que una nueva línea en la codificación de caracteres se puede definir como CR y LF combinados en uno (comúnmente llamado CR+LF o CRLF).

Algunos conjuntos de caracteres proporcionan un código de carácter de nueva línea independiente. EBCDIC, por ejemplo, proporciona un código de carácter NL además de CR y LF códigos. Unicode, además de proporcionar los códigos de control ASCII CR y LF, también proporciona una "siguiente línea" (NEL) código de control, así como códigos de control para "separador de línea" y "separador de párrafo" marcadores

• Sistemas EBCDIC, principalmente sistemas de mainframe IBM, incluidos z/OS (OS/390) e IBM i (OS/400) NL (Nueva Línea, 0x15) como el personaje que combina las funciones de la línea de alimentación y el retorno del transporte. El carácter Unicode equivalente (0x85) se llama NEL (Siguiente Línea). EBCDIC también tiene caracteres de control llamados CR y LF, pero el valor numérico de LF ()0x25) difiere del utilizado por ASCII (0x0A). Además, algunas variantes de EBCDIC también utilizan NL pero asignar un código numérico diferente al personaje. Sin embargo, esos sistemas operativos utilizan un sistema de archivos basado en registros, que almacena archivos de texto como un registro por línea. En la mayoría de los formatos de archivo, no se almacenan terminadores de línea.
• Los sistemas operativos para la serie CDC 6000 definieron una nueva línea como dos o más caracteres de seis bits de valor cero al final de una palabra de 60 bits. Algunas configuraciones también definieron un carácter de valor cero como carácter de colon, con el resultado de que varios colones podrían interpretarse como una nueva línea dependiendo de la posición.
• RSX-11 y OpenVMS también utilizan un sistema de archivos basado en registros, que almacena archivos de texto como un registro por línea. En la mayoría de los formatos de archivo, no se almacenan terminadores de línea, pero la instalación de Servicios de Gestión de Registros puede agregar transparentemente un terminador a cada línea cuando se recupera por una aplicación. Los propios registros pueden contener los mismos caracteres de terminación de línea, que pueden considerarse una característica o una molestia dependiendo de la aplicación. RMS no sólo almacena registros, sino que también almacena metadatos sobre los separadores de registros en diferentes bits para que el archivo complique cuestiones aún más (ya que los archivos pueden tener registros de longitud fijos, registros que son prefijados por un conteo o registros que se terminan por un personaje específico). Los bits no son genéricos, así que mientras pueden especificar que CRLF o LF o incluso CR es el terminador de línea, no pueden sustituir otro código.
• Longitud de la línea fija fue utilizado por algunos sistemas operativos de mainframe temprano. En tal sistema, se asumió un extremo implícito de línea cada 72 o 80 caracteres, por ejemplo. No se ha almacenado ningún personaje de nueva línea. Si un archivo se importaba del mundo exterior, las líneas más cortas que la longitud de la línea tenían que ser acolchadas con espacios, mientras que las líneas más largas que la longitud de la línea tenían que ser truncadas. Esto imitaba el uso de tarjetas perforadas, en las que cada línea se almacenaba en una tarjeta separada, generalmente con 80 columnas en cada tarjeta, a menudo con números de secuencia en columnas 73–80. Muchos de estos sistemas agregaron un carácter de control de carros al comienzo del siguiente registro; esto podría indicar si el siguiente registro era una continuación de la línea iniciada por el registro anterior, o una nueva línea, o debería sobreimprimir la línea anterior (similar a una CR). A menudo esto era un personaje de impresión normal como # que por lo tanto no podría ser utilizado como el primer personaje en una línea. Algunas impresoras de línea temprana interpretaron estos caracteres directamente en los registros enviados a ellos.

Unicódigo

El estándar Unicode define una serie de caracteres que las aplicaciones conformes deberían reconocer como terminadores de línea:

LF: Línea Feed, U+000A

VT: Tab vertical, U+000B

FF: Forma Feed, U+000C

CR: Carriage Return, U+000D

CR+LF: CR ()U+000D) seguido por LF ()U+000A)

NEL: Next Line, U+0085

LS: Separador de línea, U+2028

PS: Párrafo Separador, U+2029

Esto puede parecer demasiado complicado en comparación con un enfoque como convertir todos los terminadores de línea en un solo carácter, por ejemplo, LF. Sin embargo, Unicode se diseñó para conservar toda la información al convertir un archivo de texto de cualquier codificación existente a Unicode y viceversa. Por lo tanto, Unicode debe contener caracteres incluidos en las codificaciones existentes.

Por ejemplo: NL es parte de EBCDIC, que usa código 0x15; normalmente se asigna a Unicode NEL, 0x85, que es un carácter de control en el conjunto de control C1. Como tal, está definido por ECMA 48 y reconocido por codificaciones que cumplen con ISO/IEC 2022 (que es equivalente a ECMA 35). El conjunto de control C1 también es compatible con ISO-8859-1. El enfoque adoptado en el estándar Unicode permite que la transformación de ida y vuelta conserve la información al mismo tiempo que permite que las aplicaciones reconozcan todos los tipos posibles de terminaciones de línea.

Reconocer y usar los códigos de nueva línea mayores que 0x7F (NEL, LS y PS) no se suele hacer. Son varios bytes en UTF-8, y el código para NEL se ha utilizado como puntos suspensivos (…) carácter en Windows-1252. Por ejemplo:

• ECMAScript acepta LS y PS como rupturas, pero considera U+0085 ()NELEl espacio blanco en lugar de una ruptura de línea.
• Windows 10 no trata ninguno de NEL, LS, o PS como rupturas de línea en su editor de texto predeterminado, Notepad.
• gedit, el editor de texto predeterminado del entorno de escritorio GNOME, trata LS y PS como novedad pero no NEL.
• JSON permite LS y PS caracteres dentro de cuerdas, mientras que ECMAScript antes de ES2019 los trató como nuevas líneas, y por lo tanto la sintaxis ilegal.
• YAML ya no los reconoce como especiales a partir de la versión 1.2, para ser compatible con JSON.

Tenga en cuenta que los caracteres especiales Unicode U+2424 (SYMBOL FOR NEWLINE, ␤), U+23CE (SÍMBOLO DE RETORNO, ⏎), U+240D (SÍMBOLO PARA RETORNO DE CARRO, ␍) y U +240A (SÍMBOLO PARA CAMBIO DE LÍNEA, ␊) son glifos destinados a presentar un carácter visible para el usuario al lector del documento y, por lo tanto, no se reconocen como una nueva línea.

En lenguajes de programación

Para facilitar la creación de programas portátiles, los lenguajes de programación proporcionan algunas abstracciones para manejar los diferentes tipos de secuencias de nueva línea que se usan en diferentes entornos.

El lenguaje de programación C proporciona las secuencias de escape 'n' (nueva línea) y 'r& #39; (retorno de carro). Sin embargo, no es necesario que estos sean equivalentes a los caracteres de control ASCII LF y CR. El estándar C solo garantiza dos cosas:

1. Cada una de estas secuencias de escape mapas a un número único definido por la implementación que se puede almacenar en un solo char valor.
2. Al escribir a un archivo, nodo de dispositivo, o socket/fifo en modo de texto, 'n ' se traduce transparentemente a la secuencia de nueva línea nativa utilizada por el sistema, que puede ser más largo que un carácter. Al leer en modo de texto, la secuencia de nueva línea nativa se traduce de nuevo a 'n '. In modo binario, no se realiza ninguna traducción, y la representación interna producida por 'n ' es la salida directamente.

En plataformas Unix, donde se originó C, la secuencia de nueva línea nativa es ASCII LF (0x0A), por lo que 'n' simplemente se definió como ese valor. Dado que la representación interna y externa son idénticas, la traducción realizada en modo texto no funciona, y Unix no tiene noción de modo texto o modo binario. Esto ha provocado que muchos programadores que desarrollaron su software en sistemas Unix simplemente ignoren la distinción por completo, lo que da como resultado un código que no es portátil para diferentes plataformas.

Es mejor evitar la función de biblioteca C fgets() en modo binario porque cualquier archivo que no esté escrito con la convención de nueva línea de Unix se leerá mal. Además, en el modo de texto, cualquier archivo que no esté escrito con la secuencia de nueva línea nativa del sistema (como un archivo creado en un sistema Unix y luego copiado en un sistema Windows) también se leerá incorrectamente.

Otro problema común es el uso de 'n' al comunicarse mediante un protocolo de Internet que exige el uso de ASCII CR+LF para líneas finales. Escribir 'n' en un flujo de modo de texto funciona correctamente en sistemas Windows, pero solo produce LF en Unix, y algo completamente diferente en sistemas más exóticos. Usar "rn" en modo binario es ligeramente mejor.

Muchos lenguajes, como C++, Perl y Haskell, brindan la misma interpretación de 'n' como C. C++ tiene una E/S alternativa modelo donde el manipulador std::endl se puede usar para generar una nueva línea (y vacía el búfer de transmisión).

Java, PHP y Python proporcionan la secuencia 'rn' (para ASCII CR>+LF). A diferencia de C, se garantiza que representan los valores U+000D y U+000A, respectivamente.

Las bibliotecas de E/S de Java no las traducen de forma transparente en secuencias de nueva línea dependientes de la plataforma en la entrada o la salida. En su lugar, proporcionan funciones para escribir una línea completa que agrega automáticamente la secuencia de nueva línea nativa y funciones para leer líneas que aceptan cualquiera de CR, LF , o CR+LF como terminador de línea (ver BufferedReader.readLine()). El método System.lineSeparator() se puede usar para recuperar el separador de línea subyacente.

Ejemplo:

 String eol = Sistema.lineSeparator(); String líneaColor = "Color: Rojo" + eol;

Python permite "Universal Newline Support" al abrir un archivo para lectura, al importar módulos y al ejecutar un archivo.

Algunos lenguajes han creado variables, constantes y subrutinas especiales para facilitar las líneas nuevas durante la ejecución del programa. En algunos lenguajes como PHP y Perl, se requieren comillas dobles para realizar la sustitución de escape para todas las secuencias de escape, incluidas 'n' y 'r'. En PHP, para evitar problemas de portabilidad, las secuencias de nueva línea deben emitirse utilizando la constante PHP_EOL.

Ejemplo en C#:

 cuerda eol = para el Medio Ambiente.NewLine; cuerda líneaColor = "Color: Rojo" + eol;  cuerda eol2 = "n"; cuerda líneaColor2 = "Color: Azul" + eol2;

Problemas con diferentes formatos de nueva línea

Un archivo de texto creado con gedit y visto con un editor de hex. Además de los objetos de texto, sólo hay marcadores EOL con el valor hexadecimal 0A.

Las diferentes convenciones de nueva línea hacen que los archivos de texto que se han transferido entre sistemas de diferentes tipos se muestren incorrectamente.

El texto en los archivos creados con programas que son comunes en los sistemas operativos Mac clásicos o similares a Unix, aparece como una sola línea larga en la mayoría de los programas comunes a MS-DOS y Microsoft Windows porque estos no muestran un solo salto de línea o un solo retorno de carro como un salto de línea.

Por el contrario, al ver un archivo que se origina en una computadora con Windows en un sistema similar a Unix, el CR adicional puede mostrarse como un segundo salto de línea, como ^M, o como <cr> al final de cada línea.

Además, es posible que los programas que no sean editores de texto no acepten un archivo, p. algún archivo de configuración, codificado usando la convención de nueva línea extranjera, como un archivo válido.

El problema puede ser difícil de detectar porque algunos programas manejan correctamente las líneas nuevas extranjeras mientras que otros no. Por ejemplo, un compilador puede fallar con oscuros errores de sintaxis aunque el archivo fuente parezca correcto cuando se muestra en la consola o en un editor. Los editores de texto modernos generalmente reconocen todos los tipos de líneas nuevas CR+LF y permiten a los usuarios convertir entre los diferentes estándares. Los navegadores web también suelen ser capaces de mostrar archivos de texto y sitios web que utilizan diferentes tipos de líneas nuevas.

Incluso si un programa es compatible con diferentes convenciones de nueva línea, estas características a menudo no están suficientemente etiquetadas, descritas o documentadas. Por lo general, se mostrará a los usuarios un menú o cuadro combinado que enumera diferentes convenciones de líneas nuevas sin indicar si la selección volverá a interpretar, convertir temporalmente o convertir permanentemente las líneas nuevas. Algunos programas se convertirán implícitamente al abrir, copiar, pegar o guardar, a menudo de manera inconsistente.

La mayoría de los protocolos de Internet textuales (incluidos HTTP, SMTP, FTP, IRC y muchos otros) exigen el uso de ASCII CR+LF ('rn', 0x0D 0x0A) en el nivel de protocolo, pero recomendamos que las aplicaciones tolerantes reconocen LF ('n', 0x0A ) también. A pesar del estándar dictado, muchas aplicaciones utilizan erróneamente la secuencia de escape de nueva línea de C 'n' (LF) en lugar de la combinación correcta de escape de retorno de carro y secuencias de escape de nueva línea 'rn' (CR +LF) (ver la sección Newline en lenguajes de programación arriba). Este uso accidental de secuencias de escape incorrectas genera problemas al intentar comunicarse con sistemas que se adhieren a la interpretación más estricta de los estándares en lugar de la interpretación tolerante sugerida. Uno de esos sistemas intolerantes es el agente de transferencia de correo qmail que se niega activamente a aceptar mensajes de sistemas que envían LF en lugar del CR+LF.

El formato de mensaje de Internet estándar para los estados de correo electrónico: "CR y LF solo DEBEN ocurrir juntos como CRLF; NO DEBEN aparecer de forma independiente en el cuerpo".

El Protocolo de transferencia de archivos puede convertir automáticamente líneas nuevas en archivos que se transfieren entre sistemas con diferentes representaciones de líneas nuevas cuando la transferencia se realiza en "modo ASCII". Sin embargo, la transferencia de archivos binarios en este modo generalmente tiene resultados desastrosos: cualquier ocurrencia de la secuencia de bytes de nueva línea, que no tiene semántica de terminador de línea en este contexto, pero es solo parte de una secuencia normal de bytes, se traducirá a cualquier representación de nueva línea. utiliza el otro sistema, corrompiendo efectivamente el archivo. Los clientes FTP a menudo emplean algunas heurísticas (por ejemplo, inspección de extensiones de nombre de archivo) para seleccionar automáticamente el modo binario o ASCII, pero al final depende de los usuarios asegurarse de que sus archivos se transfieran en el modo correcto. Si hay alguna duda sobre el modo correcto, se debe usar el modo binario, ya que FTP no alterará ningún archivo, aunque es posible que se muestren incorrectamente.

Conversión entre formatos de nueva línea

Los editores de texto a menudo se usan para convertir un archivo de texto entre diferentes formatos de nueva línea; la mayoría de los editores modernos pueden leer y escribir archivos usando al menos las diferentes convenciones ASCII CR/LF.

Por ejemplo, el editor Vim puede hacer que un archivo sea compatible con el editor de texto del Bloc de notas de Windows. dentro de vim

:set fileformat=dos
:wq

Los editores pueden no ser adecuados para convertir archivos más grandes o para la conversión masiva de muchos archivos. Para archivos más grandes (en Windows NT/2000/XP), a menudo se usa el siguiente comando:

D:TYPE unix_file Silencio FIND/V " ■ dos_file

Los programas de propósito especial para convertir archivos entre diferentes convenciones de nueva línea incluyen unix2dos y dos2unix, mac2unix y unix2mac, mac2dos y dos2mac, y flip. El comando tr está disponible en prácticamente todos los sistemas similares a Unix y se puede usar para realizar operaciones de reemplazo arbitrarias en caracteres individuales. Un archivo de texto DOS/Windows se puede convertir a formato Unix simplemente eliminando todos los caracteres ASCII CR con

$ tr -d 'r' inputfile ■ fichero de salida

o, si el texto tiene solo CR saltos de línea, convirtiendo todos los CR saltos de línea a LF con

'r' 'n' inputfile ■ fichero de salida

A veces se realizan las mismas tareas con awk, sed o en Perl si la plataforma tiene un intérprete de Perl:

$ awk '{sub("$","rn"); printf(%s",$0); ' inputfile ■ fichero de salida # UNIX to DOS (adding CRs on Linux and BSD based OS that have not GNU extensions)$ awk '{gsub("r","); print;} ' inputfile ■ fichero de salida # DOS a UNIX (removiendo CRs en Linux y sistema operativo basado en BSD que no tienen extensiones GNU)$ sed -e 's/$/r/ ' inputfile ■ fichero de salida # UNIX to DOS (adding CRs on Linux based OS that use GNU extensions)$ sed -e 's/r$// ' inputfile ■ fichero de salida # DOS a UNIX (removiendo CRs en sistema operativo basado en Linux que usan extensiones GNU)$ perl -pe 's/r? inputfile ■ fichero de salida # Convertir to DOS$ perl -pe 's/r? inputfile ■ fichero de salida # Convertir to UNIX$ perl -pe 's/r? ' inputfile ■ fichero de salida # Convertir to old Mac

El comando archivo puede identificar el tipo de finales de línea:

 $ archivo myfile.txt
 myfile.txt: ASCII texto en inglés, con terminadores de línea CRLF

El comando Unix egrep (grep extendido) se puede usar para imprimir nombres de archivo de archivos Unix o DOS (suponiendo que solo sean archivos de estilo Unix y DOS, no archivos de estilo Mac OS clásico):

$ egrep -L ' ' myfile.txt # show UNIX style file (LF terminated)$ egrep -L ' ' myfile.txt # show DOS style file (CRLF terminated)

Otras herramientas permiten al usuario visualizar los caracteres EOL:

$ Od -a myfile.txt
$ gato -e myfile.txt
$ gato -v myfile.txt
$ hexdump -c myfile.txt

Interpretación

Dos formas de ver las líneas nuevas, ambas coherentes entre sí, son que las líneas nuevas separan líneas o que terminan líneas. Si una nueva línea se considera un separador, no habrá nueva línea después de la última línea de un archivo. Algunos programas tienen problemas para procesar la última línea de un archivo si no termina con una nueva línea. Por otro lado, los programas que esperan que se use una nueva línea como separador interpretarán una nueva línea final como el comienzo de una nueva línea (vacía). Por el contrario, si una nueva línea se considera un terminador, se espera que todas las líneas de texto, incluida la última, terminen con una nueva línea. Si la secuencia de caracteres final en un archivo de texto no es una nueva línea, la línea final del archivo se puede considerar como una línea de texto incorrecta o incompleta, o se puede considerar que el archivo está truncado incorrectamente.

En el texto destinado principalmente a ser leído por personas que usan software que implementa la función de ajuste de línea, normalmente solo se necesita almacenar un carácter de nueva línea si se requiere un salto de línea, independientemente de si la siguiente palabra cabe en la misma línea, como como entre párrafos y en listas verticales. Por lo tanto, en la lógica del procesamiento de textos y la mayoría de los editores de texto, la nueva línea se usa como un salto de párrafo y se conoce como "retorno duro", en contraste con "suave devoluciones" que se crean dinámicamente para implementar el ajuste de palabras y se pueden cambiar con cada instancia de visualización. En muchas aplicaciones, un carácter de control separado llamado "salto de línea manual" existe para forzar saltos de línea dentro de un solo párrafo. El glifo del carácter de control para un retorno forzado suele ser un pilcrow (¶), y para el salto de línea manual suele ser una flecha de retorno de carro (↵).

Saltos de línea inversos y parciales

RI, (U+008D CAMBIO DE LÍNEA INVERSO, ISO/IEC 6429 8D, decimal 141) se utiliza para mover la posición de impresión una línea hacia atrás (haciendo retroceder el papel)., o moviendo el cursor de la pantalla una línea hacia arriba) para que se puedan imprimir otros caracteres sobre el texto existente. Esto se puede hacer para hacerlos más audaces, o para agregar subrayados, tachados u otros caracteres como signos diacríticos.

Del mismo modo, PLD (U+008B LÍNEA PARCIAL HACIA ADELANTE, decimal 139) y PLU (U+008C LÍNEA PARCIAL HACIA ATRÁS, decimal 140) se puede utilizar para avanzar o retroceder la posición de impresión del texto en una fracción del espacio entre líneas verticales (normalmente, la mitad). Estos se pueden usar en combinación para subíndices (avanzando y luego invirtiendo) y superíndices (invirtiendo y luego avanzando), y también pueden ser útiles para imprimir signos diacríticos.