Passei muitos, muitos dias lutando com problemas de espaçamento em sistemas de escrita do sudeste asiático. NUNCA vi um ambiente de publicação em que espaços de largura fixa, como THIN SPACE \u2009 ou EM SPACE \u2003, produzissem uma saída correta quando usados entre palavras ou frases. Aqui estão alguns problemas específicos que observei:
- Enquanto um SPACE normal \u0020 desaparece no final de uma linha quando a palavra anterior chega até a margem, um espaço de largura fixa exigirá espaço suficiente para aparecer na linha antes da margem direita, ou a largura do espaço puxará a palavra anterior para a próxima linha, ou o espaço de largura fixa será quebrado para a próxima linha sozinho, indentando efetivamente a próxima linha de texto.
- Os algoritmos de quebra de linha priorizam a quebra em um SPACE acima de espaços de largura fixa, produzindo parágrafos feios com meias-linhas de texto.
- Um espaço de largura fixa não pode ser esticado ou encolhido para alcançar margens totalmente justificadas ou parágrafos bem equilibrados. Apenas um caractere SPACE normal funciona para essas coisas.
- Um espaço de largura fixa pode aparecer de forma estranha quando o usuário copia e cola de um aplicativo para um mensageiro, etc.
- Teclados de celular não conseguem digitar um espaço de largura fixa, então uma busca de múltiplas palavras em um aplicativo de celular falhará.
A solução que encontrei é usar caracteres SPACE normais \u0020 para espaços estreitos e largos. No PTXprint, uso SPACE+ZWSP+SPACE para obter um espaço duplo (ou triplo) nas quebras de frase. No SAB, uso dois ou três caracteres de espaço, com um estilo contendo CSS white-space: pre-wrap; para impedir que o mecanismo HTML colapse múltiplos espaços em um único espaço. Tanto no PTXprint, SAB ou Indesign, posso aplicar estilos personalizados ao espaço para torná-lo mais largo ou mais estreito.
O uso de espaços de largura fixa dentro do Paratext funciona mais ou menos bem, embora o inventário de pontuação fique confuso. Minha preferência, no entanto, é evitar o uso de espaços de largura fixa no Paratext também, porque são difíceis de ver. É melhor usar um caractere visível (por exemplo, uma vírgula nas quebras de frase) e, em seguida, alterar o caractere para um espaço mais largo ou mais estreito no momento da publicação.
Como mnjames indicou, o SAB é quase tão flexível quanto o PTXprint quando se trata de implementar regras de alteração, então você deve ser capaz de obter uma saída perfeita em qualquer um dos programas, se tiver uma fonte funcional.
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.
