Да, я согласен с Matthew_Lee в том, что это важный вопрос, особенно во франкоязычном мире. В моём анализе есть ряд моментов, которые я хотел бы упомянуть, но я постараюсь дать краткое резюме (TLDR) в конце этого поста.
Небольшой поиск в интернете показывает некоторые интересные вещи, которые не являются «отвлечением от темы»:
И некоторые забавные ошибки (где явно использовался обычный пробел, что в данном случае привело к разрыву строки):
Именно этого мы хотим избежать — ситуаций, когда знаки препинания не связаны с соответствующим текстом. Поэтому, если мы собираемся использовать какой-либо символ пробела для отделения знаков препинания, мы ВСЕГДА должны использовать неразрывный пробел какого-либо типа.
Два основных варианта — это полный неразрывный пробел (NBSP, U+00A0) или узкий неразрывный пробел (NNBSP, U+202F), определения которых можно найти в стандарте Unicode по адресам https://unicode.org/charts/PDF/U0090.pdf и https://unicode.org/charts/PDF/U2000.pdf соответственно:
Как вы можете видеть, в определении NNBSP указано, что он обычно имеет ширину тонкого пробела, который определён в той же таблице как :
Таким образом, NNBSP обычно составляет одну пятую эм-квадрата (0.2em). Какова ширина обычного пробела или NBSP? Эти метрики зависят от шрифта, но приблизительный расчёт с использованием шрифта Charis SIL показывает, что символы пробела и NBSP имеют ширину около 0.34em. NNBSP составляет около 0.22em. Это значительная разница, и если вы используете NBSP (или, как временную меру, обычный пробел, который имеет недостаток в виде разрыва между строками) вокруг знаков препинания, верстальщики, которых я знаю, скажут, что этот пробел слишком велик. Использование NNBSP значительно помогает, и это можно довольно легко сделать в PTXprint с помощью изменений, подобных следующим строкам в файле PrintDraftChanges.txt:
' *:' > '\u202f:' # Place non-breaking thin space before colon
'« *' > '«\u202f' # Place non-breaking thin space after opening guillemets
' *»' > '\u202f»' # Place non-breaking thin space before closing guillemets
'‹ *' > '‹\u202f' # Place non-breaking thin space after opening guillemets
' *›' > '\u202f›' # Place non-breaking thin space before closing guillemets
Это вставляет NNBSP перед или после (по необходимости) знаков препинания и также удаляет любые пробелы, которые там есть (если они есть). Это означает, что независимо от того, вставляет ли команда пробелы или нет, они будут нормализованы в символы NNBSP. Например, в этом проекте команда непоследовательна и использует (обычные) пробелы вокруг вопросительных знаков и двоеточий, но не вокруг кавычек (французских кавычек-«ёлочек»):
image945×67 35 KB
Обратите внимание, что вы можете увидеть, что это просто обычные пробелы, если правильно отрегулировать масштаб и/или размер панели, так как они позволяют разрыв между строками, как здесь:
image755×114 48.8 KB
Но изменения, описанные выше, должны уметь корректно обрабатывать оба этих случая и вставлять NNBSP для верстки.
Аналогичным образом, вы хотели бы добавить правила изменений в ваши проекты SAB, чтобы убедиться, что ваши библейские приложения правильно обрабатывают пробелы. Ознакомьтесь с этим постом, чтобы увидеть примеры правил: https://community.scripture.software.sil.org/t/suggestions-for-changes-gallery/590/3.
Обратите внимание, что правила в этом посте не так элегантно обрабатывают наличие или отсутствие пробела, как правила выше, но вы можете отрегулировать их с помощью трюков, таких как " *", использованных выше.
И ещё один момент, прежде чем мы перейдём к Paratext… В недавних работах по верстке мы на самом деле использовали одну десятую эм-квадрата (0.1em) в качестве пробела вокруг знаков препинания, то есть меньше, чем NNBSP. Вот определение знаков препинания, которое мы использовали:
\catcode`\:=\active \def:{\unskip\kern0.1em\char`\:{}} % colon
Примечание: это было сделано в XeTeX, но то же самое можно сделать с PTXprint. Я полагаю, что вы хотели бы определить это в файле конфигурации ptxprint-mods.tex, доступном на вкладке инструментов Advanced. Это даёт довольно минимальный пробел вокруг знаков препинания, как видно в этом образце:
image752×102 11.5 KB
Но команды считают, что этого пробела достаточно, чтобы удовлетворить их ощущаемую потребность в пробелах вокруг знаков препинания, которая требуется во французском языке. (Конечно, французы могут не согласиться, но это не их язык!)
Вывод (TLDR): Что это значит для Paratext?
Если команда использует обычные пробелы в тексте для отделения своих знаков препинания, то иногда это будет отображаться неправильно на их экране в Paratext (т.е. знаки препинания не будут правильно прикреплены к тексту, как показано выше), что отвлекает, но не является концом света. В этом случае ответственность лежит на верстальщике или создателе приложения, чтобы правильно изменить эти обычные пробелы. К сожалению, если именно в таком виде текст будет помещён в DBL (что очень вероятно), то такие приложения, как YouVersion, будут иметь проблемы, потому что они, как известно, НЕ обрабатывают эти пробелы должным образом.
Учитывая эту тенденцию к всё более и более мелким неразрывным пробелам для отделения знаков препинания (сначала NNBSP в 0.2em, а затем ручная верстка в 0.1em с помощью PTXprint), которую я наблюдал в своих проектах по верстке, я почти всегда рекомендую командам НЕ ставить пробелы вокруг знаков препинания в Paratext, а просто доверять верстке или созданию приложения сделать правильные вещи вокруг этих знаков препинания. Это означает, что когда текст будет помещён в DBL, у YouVersion не будет «висящих» знаков препинания. (У них также не будет пробелов вокруг знаков препинания, но, по моему мнению, это меньшая проблема.)
Таким образом, с этим конкретным планом действий изменения в Paratext не требуются. Если бы вы хотели, как предложил Matthew_Lee, способ отображать символы NNBSP или NBSP, я думаю, что это была бы хорошая идея, но нашим клавиатурам также потребовался бы способ вводить эти символы (чего они не всегда могут делать), и Paratext должен был бы знать, что не нужно вмешиваться в эти символы. (И инвентари знаков препинания должны были бы показывать все комбинации с этими пробелами, чтобы убедиться, что они используются последовательно, например, всегда с NNBSP.)
Этот пост предлагает не столько решения, сколько предоставляет больше контекста и информации. Мне действительно не нравится то, как сейчас работает эта штука с тильдой / NBSP в Paratext, и я согласен, что это должно измениться. Кажется, Paratext должен предполагать, что он должен принимать каждый символ в тексте буквально, будь то тильда, NBSP или NNBSP. И было бы хорошо иметь способ видеть их (незаметно). Должны ли два или более пробела автоматически объединяться (в ответ на @anon942452)? Может быть, если они являются идентичными символами? Это всё ещё позволило бы автоматическую коррекцию пробелов в Paratext, но также предоставило бы некоторые варианты для обхода этого. И также нужно было бы придумать способ справиться со всеми устаревшими проектами, в которых используются тильды для неразрывных пробелов, возможно, просто конвертация, чтобы преобразовать их все в NBSP, как только это будет правильно обработано в Paratext.
В любом случае, ещё немного пищи для размышлений…
