He pasado muchos, muchos días luchando con problemas de espacios en scripts del sudeste asiático. NUNCA he visto un entorno de publicación en el que los espacios de ancho fijo, como THIN SPACE \u2009 o EM SPACE \u2003, produzcan una salida correcta cuando se usan entre palabras o frases. Aquí hay algunos problemas específicos que he observado:
Mientras que un SPACE normal \u0020 desaparecerá al final de una línea cuando la palabra anterior llegue hasta el margen, un espacio de ancho fijo requerirá suficiente espacio para aparecer en la línea antes del margen derecho, o el ancho del espacio arrastrará la palabra anterior a la siguiente línea, o el espacio de ancho fijo se pasará a la siguiente línea solo, indentando efectivamente la siguiente línea de texto. Los algoritmos de salto de línea priorizan el salto en un SPACE por encima de los espacios de ancho fijo, produciendo párrafos feos con medias líneas de texto. Un espacio de ancho fijo no se puede estirar ni encoger para lograr márgenes justificados por completo o párrafos equilibrados. Solo un carácter SPACE normal funciona para estas cosas. Un espacio de ancho fijo puede aparecer de manera extraña cuando el usuario copia y pega desde una aplicación a un mensajero, etc. Los teclados de teléfono no pueden escribir un espacio de ancho fijo, por lo que una búsqueda de varias palabras en una aplicación de teléfono fallará. La solución que he encontrado es usar caracteres SPACE normales \u0020 para espacios estrechos y anchos. En PTXprint uso SPACE+ZWSP+SPACE para obtener un espacio doble (o triple) en los saltos de frase. En SAB uso dos o tres caracteres de espacio, con un estilo que contiene CSS white-space: pre-wrap; para evitar que el motor HTML colapse múltiples espacios en un solo espacio. En PTXprint, SAB o Indesign, puedo aplicar estilos personalizados al espacio para hacerlo más ancho o más estrecho.
Usar espacios de ancho fijo dentro de Paratext funciona más o menos bien, aunque el inventario de puntuación se confunde. Sin embargo, mi preferencia es evitar usar espacios de ancho fijo en Paratext también, porque son difíciles de ver. Es mejor usar un carácter visible (por ejemplo, una coma en los saltos de frase) y luego cambiar el carácter a un espacio más ancho o más estrecho en el momento de la publicación.
Como indicó mnjames, SAB es casi tan flexible como PTXprint cuando se trata de implementar reglas de cambio, por lo que deberías poder obtener una salida perfecta en cualquiera de los dos programas, si tienes una fuente que funcione.
I've spent many, many days wrestling with space issues in Southeast Asian scripts. I have NEVER seen a publishing environment in which fixed width spaces such as THIN SPACE \u2009 or EM SPACE \u2003 produce correct output when used between words or phrases. Here are a few specific problems I have observed:
Whereas a normal SPACE \u0020 will disappear at the end of a line when the preceding word reaches all the way to the margin, a fixed width space will either require sufficient space to appear on the line before the right margin, or the width of the space will pull the preceding word down to the next line, or the fixed width space will wrap to the next line alone, effectively indenting the next line of text. Line break algorithms prioritize breaking at a SPACE higher than at fixed width spaces, producing ugly paragraphs with half-lines of text. A fixed width space cannot be stretched or shrunk in order to achieve fully justified margins or nicely balanced paragraphs. Only a normal SPACE character works for these things. A fixed width space may appear strangely when the user copy-pastes from an app into a messenger, etc. Phone keyboards can't type a fixed width space so a multi-word search in a phone app will fail. The solution that I have found is to use normal SPACE \u0020 characters for both narrow and wide spaces. In PTXprint I use SPACE+ZWSP+SPACE to get a double (or triple) space at phrase breaks. In SAB I use two or three space characters, with a style containing CSS white-space: pre-wrap; to prevent the HTML engine from collapsing multiple spaces into a single space. In either PTXprint, SAB, or Indesign I can apply custom styles to the space to make it either wider or narrower.
Using fixed-width spaces within Paratext works mostly OK, though the punctuation inventory gets confused. My preference, however, is to avoid using fixed-width spaces in Paratext too because they're difficult to see. It's better to use a visible character (e.g. a comma at phrase breaks) and then change the character to a wider or narrower space at publication time.
As mnjames indicated, SAB is almost as flexible as PTXprint when it comes to implementing change rules, so you should be able to get perfect output in either program, if you have a working font.
Traducción automática desde English Mostrar original
