Versión 1.0 - mayo de 2016

Líneas largas en ficheros de texto simple

Fin de línea en ficheros de texto simple

Conforme escribimos con una máquina de escribir el carro se desplaza hacia la izquierda hasta que se acaba la línea. Para continuar en la línea siguiente hay que hacer dos cosas: girar el tambor una línea y mover el carro hacia la derecha hasta el principio de la línea. Estos dos movimientos vienen en el código ASCII: LF (línea nueva, código decimal 10) y CR (retorno de carro, número decimal 13). En un archivo de texto se indica la línea nueva de diferente manera según el sistema operativo: en GNU/Linux y Mac OS X solo con el carácter LF, en Windows con los caracteres CRLF y en Mac antes del OS X solo con CR. Si alguna vez abres un fichero en Windows y te encuentras con una desagradable única línea muy larga pues ya sabes que has abierto un archivo de texto hecho en GNU/Linux (aunque los editores modernos suelen hacer la conversión automáticamente). Cuando se transfieren ficheros de texto por FTP el programa añade o quita los LF o CR necesarios para que el fichero se vea correctamente en el sistema operativo de destino. Incluso le modifica también la codificación de caracteres. Generalmente el programa de FTP hace esto automáticamente aunque se puede equivocar al detectar el tipo de fichero y por eso se puede indicar manualmente el tipo de transmisión. Si transmitimos ficheros de texto como binario no se realizarán dichas conversiones y si transmitimos ficheros binarios como texto estropearemos el fichero puesto que se le añadirán bytes y eso puede hacer que ese fichero quede corrupto y ya no sirva. Y los estándares de internet establecen que el fin de línea en un fichero de texto transmitido por la red sea CRLF por lo que un fichero transmitido entre dos sistemas Windows no precisaría conversión pero entre dos GNU/Linux sí, de LF a CRLF para transmitirlo y vuelta a LF en el ordenador de destino.

Si el texto comprendido entre dos saltos de línea no cabe en la ventana del editor de texto hay tres opciones:

1. Que el programa ajuste la longitud de la línea a la ventana y reorganice el texto (como puedes comprobar en esta página, haz la ventana más estrecha y lo comprobarás).
2. Que tengas que desplazarte hacia la derecha para leer lo que no se muestra en la pantalla porque se sale por la derecha como se ve en la siguiente línea:
   

   Este es un ejemplo de una línea bastante larga, tanto que se me acaban las palabras que escribir de ejemplo y tendré que empezar a escribir palabras sin sentido como coticón, barburillo, tendrencismo, etc. pero sobre todo lo que debes observar es lo incómodo que resulta leer esta línea salvo que por caso de extrema necesidad tenga que ser tan larga como al escribir una URL o un código que no se pueda partir en dos líneas.
   

3. Incluir saltos de línea manuales al final de la ventana.

Párrafos en Latex, Groff y procesadores de texto

En Latex, Groff, Texinfo, etc., los párrafos no se indican con un salto de línea sino con dos seguidos, esto es con una línea en blanco. Por tanto da igual si hacemos soft o hard wrap, a Latex le da igual. Es tan solo la preferencia que tengamos a la hora de leer el fichero fuente de Latex. Por tanto no hay relación entre salto de línea y párrafo.

En el codigo html tampoco hay relación entre salto de línea y párrafo, de hecho un párrafo es el texto comprendido entre las etiquetas <p>, el cual se puede ajustar dinámicamente al ancho de la ventana del navegador. Si queremos saltos duros tenemos que usar la etiqueta <br>.

En los procesadores de texto, como OpenOffice, el texto fluye por la ventana hasta que pulsemos la tecla Entrar o insertemos un salto de línea manual. Por tanto aquí sí hay relación directa entre salto de línea y párrafo.

Si tenemos un fichero de texto simple con ajuste duro y copiamos el texto a un procesador de texto el texto no se ajusta a la ventana por culpa de los saltos de línea. En ese caso es mejor usar el comando pandoc.

¿Por qué se usa muchas veces el ajuste duro en lo ficheros fuente de html, latex, etc.? Antiguamente mucho software no permitía el soft wrap y por tanto era imprescindible para leer bien las líneas en monitores de 80 caracteres de ancho pero incluso ahora las líneas cortas son muy útiles puesto que facilitan hacer cambios automáticos mediante sed. Es mucho más fácil trabajar con una línea de 70 caracteres que con una línea de 2000. Por otro lado el ajuste dinámico es muy útil para un trabajo directo por una persona puesto que aunque cambie el tamaño de la ventana el texto y los párrafos se leen perfectamente. Por tanto son maneras diferentes de trabajar, pero la primera es mucho más potente. Por ejemplo si gestionas la web de una empresa formada por 2000 ficheros html y esta empresa es absorbida por otra y por tanto se debe cambiar el nombre corporativo en todos los ficheros, con un guión de bash que use sed el cambio es trivial y mucho más fácil con líneas cortas que largas.

De igual manera en ficheros de configuración o en código fuente de programas de ordenador el ajuste dinámico no es deseable porque no sabes muy bien cuáles son saltos de línea duros o blandos y esto genera fallos difíciles de encontrar.

Conforme editamos un fichero fuente Latex o html los párrafos quedan bastante difíciles de leer a no ser que hagamos un pesado trabajo a mano cada vez que los modificamos. Sin embargo es más práctico no preocuparse por eso y al acabar formatearlo con fmt o tidy en el caso de los html (que también identa el código facilitando su lectura). El editor Kile, si está configurado para recortar las líneas, realiza este ajuste conforme escribimos o editamos.

Fin de línea y párrafos en mensajes de correo electrónico

En el correo electrónico el salto de línea se indica con CRLF tal como indica la RFC-822 original y sus sucesoras la RFC-2822 y RFC-5322. Además se indica que las líneas nunca pueden superar los 998 caracteres y que es deseable que no superen los 78 caracteres.

Al escribir un mensaje podemos hacer nosotros un ajuste estático manual o dejar que el editor de nuestro programa de correo haga automáticamente un ajuste dinámico o estático. Pero esto es solo lo que vemos al escribir. Cuando el mensaje se envíe, el programa de correo cortará todas las líneas por los 78 caracteres para cumplir con el estándar. Cuando los monitores solo mostraban 80 caracteres o incluso después con monitores más grandes y de mayor resolución el recortar las líneas a 78 caracteres no suponían un problema (sí era un problema si copiabas el mensaje y lo querías reutilizar en procesador de texto como hemos vista anteriormente). Pero ahora que hay pantallas pequeñas que no muestran 78 caracteres (como los teléfonos móviles) estos saltos duros generan escaleras muy incómodas de leer y en esos casos es más útil el ajuste dinámico.

  Este es un texto con líneas de 78 caracteres de ancho que se 
  ve perfectamente
  en una pantalla de ordenador por pequeña que sea pero que
  si se
  ve en la pantalla de un móvil se ve más o menos así, como una
  escalera bastante incómoda
  de leer e incluso de reutilizar el texto.

Para sacar partido al ajuste dinámico y seguir cumpliendo con el estándar de los 78 caracteres se usa el estándar RFC-3676 . Si el programa de correo cumple este estándar y lo tenemos configurado como formato flowed, los saltos de línea obligados a los 78 caracteres los codifica como un espacio seguido por CRLF (SPCRLF) mientras que los saltos duros incluidos por el usuario son cualquier carácter seguido de CRLF. De este modo el cliente de correo del receptor elimina los SPCRLF y hace un ajuste dinámico para adecuar el mensaje al tamaño de la ventana. Si tenemos configurado el formato como fixed los saltos cada 78 caracteres sí son saltos duros y el cliente receptor no puede reorganizar el texto.

También se puede usar el estándar RFC-2045 . En este caso los saltos suaves se indican con un signo igual justo antes del salto de línea. La función más importante de este estándar es enviar texto no ASCII (caracteres que no sean del inglés) o ficheros binarios usando solo 7 bits. El texto codificado con este estándar se llama codificación Quoted-Printable.

A mi particularmente me gusta leer los mensajes recibidos y mis redacciones con ancho fijo para no tener que ajustar el tamaño de la ventana (me gusta usar las ventanas maximizadas a tope) pero los envío como flowed para que el receptor haga lo que desee configurando su cliente (solo Thunderbird me permite configurar todo esto a mi gusto). Realmente la mayoría de las personas posiblemente lean los mensajes con línea largas en los anchísimos monitores actuales y preferiría mandarlos como fixed pero como mucha gente lee los correos en el móvil por eso prefiero enviarlo como flowed.

Con GPG (pero no con S/MIME) o enviando código fuente en el cuerpo del mensaje es mejor no usar ni flowed ni quoted printable para que los programas de correo no modifiquen absolutamente nada del mensaje (y lógicamente mantener las líneas a mano por debajo de 78 caracteres, porque automáticamente no sabemos lo que nos pondrá el editor del cliente de correo, por ejemplo Thunderbird introduce salto suave con espacio y CRLF).

Relacionado con lo anterior si queremos usar tildes en las cabeceras usamos encoded-words que vienen en el estándar RF2047.

Configuración de clientes de correo

Thunderbird 91.5.0. Están bastante escondidas y son bastante liosas pues generalmente están relacionadas. Se configuran en:
Editar > Preferencias > Avanzado > General > Editor de configuración

En esta versión los saltos suaves los envía como format flowed (espacio y CRLF), no como quoted-printable (igual y CRLF). Por tanto es difícil ver en el código fuente del mensaje si hay saltos suaves o no. Tampoco interpreta los saltos suaves codificados como quoted-printable, pero sí interpreta los caracteres noascii codificados como quoted-printable.

Para enviar los mensajes con diferentes codificaciones:
mail.strictly_mime
false: codifica con 8 bits. Puede enviar saltos suaves format flowed si mailnews.send_plaintext_flowed es true.
true: codifica con 7 bit. Si hay caracteres noascii no usa quoted-printable para codificarlos sino base64. Con esta codificación el texto no es legible por humanos y las líneas del texto codificado se cortan a 78 caracteres. Además el mensaje ocupa más espacio que con quoted-printable u 8 bit. Al decodificar, si hay saltos suaves de format flowed (espacio y CRLF) porque mailnews.send_plaintext_flowed es true el cliente puede interpretarlos.

Para enviar como format flowed o fixed:
mailnews.send_plaintext_flowed
true: format flowed (espacio y CRLF), permite reorganizar el texto al receptor.
false: fixed (no permite reorganizar el texto al receptor)

Para leer como format flowed (espacio y CRLF) o fixed:
mailnews.display.disable_format_flowed_support
true: fixed (no reorganiza el texto y se lee con ancho fijo)
false: flowed (reorganiza el texto a la anchura de la ventana).

Para redactar y que el ancho sea el de la ventana o que el editor incluya saltos de línea suaves (espacio y CRLF) a una anchura determinada:
mail.compose.wrap_to_window_width
true: la línea se ajusta a la anchura de la ventana (aunque puede ser necesario ajustar mailnews.wraplength a 0.
false: la línea se corta a una anchura determinada (controlada por mailnews.wraplength)
En ambos casos las líneas más largas de 78 se cortan. Si mailnews.send_plaintext_flowed es cierto la cabecera del mensaje incuirá el texto format=flowe y así, si el cliente está configurado para interpretar los saltos suaves lo hará. Si ponemos falso no pondrá dicho texto y el cliente no hará nada, aunque realmente los saltos suaves están ahí, no ha incluido saltos duros.

Ahora lo tengo configurado para no enviar format flowed (pone saltos blandos con espacio y CRLF pero no indica format=flowed en la cabecera, así que lo que yo veo en mi editor es lo que verá el receptor, o eso espero...) y no permito que interprete los saltos suaves, para ello:
mail.strictly false
mailnews.send_plaintext_flowed false
mailnews.display.disable_format_flowed_support true
mail.compose.wrap_to_window_width false
mailnews.wraplength 72
Si introduzco una línea si espacios, el editor no pone saltos suaves, y si supero los 998 caracteres Thunderbird automáticamente codifica el mensaje en base64 y corta las líneas codificadas a los 78 caracteres para cumplir con el estandar.

Para ver el código fuente de los mensajes pulsamos Ctrl+u

Más información:
http://kb.mozillazine.org/Mail_and_news_settings
http://kb.mozillazine.org/Plain_text_e-mail_-_Thunderbird#Flowed_format
http://kb.mozillazine.org/Mail_content_types#Plain_text

Gmail. Permite enviar como texto o como html. Envía las tildes como quoted-printable. El editor permite adaptar las líneas al tamaño de la ventana pero al enviar pone saltos duros a los 70 caracteres. Debido a las tildes codificadas mediante quoted-printable las líneas son más largas y entonces introduce saltos suaves a los 77 caracteres pero el mensaje le llega al receptor con saltos duros cada 70 caracteres.
Lee bien los mensajes quoted-printable con saltos suaves.
Lee bien los mensajes format flowed con saltos suaves.

Roundcube Webmail/0.5.3. Permite enviar como texto o como html. Envía las tildes como 8bit. El editor permite adaptar las líneas al tamaño de la ventana y envía como format flowed los saltos suaves.
Lee bien los mensajes quoted-printable con saltos suaves.
Lee bien los mensajes format flowed con saltos suaves.

Sylpheed 3.0.2. Para configurar la ventana de redacción y que no recorte las líneas automáticamente:
Configuración > Preferencias comunes > Componer > Editor

Sylpheed no reconoce el formato flowed por lo que los saltos suaves de un mensaje entrante se ven como duros.

Para redactar con codificación de 8bit o quoted-printable:
Configuración > Preferencias comunes > Enviar > Codificación

Con quoted-printable se pueden usar saltos suaves, pero si el mensaje no tiene tildes como no tiene falta de usar quoted no lo usa y por tanto no genera saltos suaves, solo líneas largas (Sylpheed no sigue la recomendación de los 78 caracteres. Incluso la obligación de que las líneas no sean mayores de 998 caracteres lo deja a la elección del usuario, aunque te informa de que si no recorta puedes perder información). Con 8bit tampoco crea saltos suaves e igual que antes envía líneas largas.

Para ver el código fuente, una vez seleccionado un mensaje pulsamos Ctrl+u. Si pulsamos Ctrl+h muestra las cabeceras. Si abrimos el mensaje estas teclas ya no funcionan y ahí que ir al menú Ver de la ventana del mensaje.

Mutt 1.5.20.

Su comportamiento depende del editor que usemos. En el fichero ~/.muttrc podemos activar o desactivar estas opciones:

set allow_8bit=yes   # permite enviar como 8 bits o como quoted-printable
set text_flowed=yes  # permite ajustar texto como flowed.

Si:

set allow_8bit=no 
#set text_flowed  

Si:

set allow_8bit=no 
set text_flowed  

Si:

set allow_8bit=yes
#set text_flowed

Si:

set allow_8bit=yes
set text_flowed

En los mensajes entrantes codificados quoted-printable muestra los saltos suaves con un "+" al comienzo de la siguiente pseuodolínea, lo cual es muy práctico porque permite diferenciar fácilmente los saltos duros de los suaves. También lo hace así si la línea es más larga que la ventana. Lo que no implementa es el format=flowed y simplemente muestra los mensajes recortados por los saltos duros.

Si pulsas la tecla "h" no muestra el codigo fuente sino todas las cabeceras. Para mostrar el código pulsa "|" y redirige el mensaje al comando less y ahí si lo deseas copia el texto, pero si no cabe en la pantalla es difícil seleccionar todo con el ratón. También se puede ver el código fuente pulsando la tecla "e" (de exportar) y se abre el mensaje en el editor por defecto y luego se puede guardar con otro nombre dónde deseemos.