是的,我同意 Matthew_Lee 的观点,认为这是一个重要问题,尤其是在法语世界。在我的分析中,我想提到一些事情,但我会尝试在本帖底部进行总结(太长不看版)。
一些在线研究显示了一些有趣的事情,这些并不完全是“题外话”:

还有一些幽默的失败案例(显然他们当时使用的是普通空格——在这种情况下导致了断行):

这正是我们要避免的——标点符号与其关联文本脱节。因此,如果我们打算使用某种空格字符来分隔标点符号,我们必须始终使用某种不换行空格。
主要的两个选项是全角不换行空格(NBSP, U+00A0)或窄不换行空格(NNBSP, U+202F),其定义可以在 Unicode 标准中找到,分别在 https://unicode.org/charts/PDF/U0090.pdf 和 https://unicode.org/charts/PDF/U2000.pdf:


如您所见,NNBSP 的定义指出其宽度通常等于细空格(thin space),而在同一图表中,细空格被定义为:

因此,NNBSP 通常是一个 em 的五分之一(0.2em)。普通空格或 NBSP 有多大?这些度量取决于字体,但使用 Charis SIL 字体进行的粗略计算表明,空格和 NBSP 字符约为 0.34em。NNBSP 约为 0.22em。这是一个显著的差异,如果您在标点符号周围使用 NBSP(或者作为临时措施使用普通空格,其缺点是会在行末断行),我认识的排版师会说那个空格太大了。使用 NNBSP 会有显著帮助,并且可以通过修改 PrintDraftChanges.txt 中的以下行在 PTXprint 中相对容易地实现:
' *:' > '\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 字符。例如,在这个项目中,团队的做法不一致,在问号和冒号周围使用(普通)空格,但在引号(guillemets)周围不使用:

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 之前,还有一点。在最近的排版工作中,我们实际上使用了十分之一 em(0.1em)作为标点符号周围的空格,即比 NNBSP 更小。以下是我们使用的标点符号定义:
\catcode`\:=\active \def:{\unskip\kern0.1em\char`\:{}} % colon
注意:这是在 XeTeX 中完成的,但使用 PTXprint 也可以做到。我认为您希望在 Advanced 工具选项卡上可用的 ptxprint-mods.tex 配置文件中定义它。这提供了标点符号周围相当最小的空格,如本示例所示:

image752×102 11.5 KB
但团队认为,对于法语所要求的标点符号周围的空格需求来说,这个空间已经足够了。(当然,法国人可能不同意,但这不是他们的语言!)
结论(太长不看版):这对 Paratext 意味着什么?
如果团队在文本中使用普通空格来分隔标点符号,那么有时在 Paratext 的屏幕上显示不正确(即标点符号未正确附着于其文本,如上所示),这虽然令人分心,但并非世界末日。在这种情况下,责任在于排版师或应用程序构建者适当更改这些普通空格。不幸的是,如果这是放入 DBL 的形式(极有可能),那么像 YouVersion 这样的应用程序将会出现问题,因为它们出了名地不能正确处理这些空格。
鉴于我在排版项目中看到的这种趋势——使用越来越小的不换行空格来分隔标点符号(先是 0.2em 的 NNBSP,然后使用 PTXprint 手动排版为 0.1em),我几乎总是建议团队在 Paratext 中不在标点符号周围输入任何空格,然后信任排版或应用程序构建过程在那些标点符号周围做正确的事情。这意味着当文本放入 DBL 时,YouVersion 不会出现悬挂标点符号的问题。(它也不会在标点符号周围有空格,但在我看来这是一个较小的问题。)
因此,按照这个具体的行动计划,Paratext 不需要任何更改。如果您想要,正如 Matthew_Lee 建议的那样,一种显示 NNBSP 或 NBSP 字符的方法,我认为那是一个好主意,但我们的键盘也需要一种输入这些字符的方法(它们并不总是具备),并且 Paratext 需要知道不要干扰这些字符。(并且标点符号清单需要显示与这些空格的所有组合,以确保它们被一致使用,例如始终使用 NNBSP。)
这篇帖子与其说是提出解决方案,不如说是提供更多背景和信息。我真的不喜欢 Paratext 中现在这种波浪号 / NBSP 的工作方式,并同意它应该改变。Paratext 似乎应该假设它应按字面意思处理文本中的每个字符,无论是波浪号、NBSP 还是 NNBSP。并且一种(微妙地)查看它们的方式将会很好。两个或更多空格是否应该自动合并(回应 @anon942452)?也许如果它们是相同的字符?这仍然允许自动的 Paratext 空格修复,但也提供了一些绕过它的方法。此外,还需要想出一种方法来处理所有使用波浪号作为不换行空格的遗留项目,也许只是一个转换,一旦 Paratext 正确处理了这一点,就将它们全部转换为 NBSP。
总之,这是更多值得思考的内容……
Yes, I agree with Matthew_Lee that this is an important issue, especially in the French-speaking world.There are a number of things I want to mention in my analysis, but I will try to summarize (TLDR) at the bottom of this post.
A little online research shows some interesting things, which are not really “beside the point”:

And some humorous failures (where they obviously were using a normal space - that broke in this case):

That’s exactly what we want to avoid - bits of punctuation not connected to its associated text. So if we are going to use a some sort of space character to set off punctuation, we must ALWAYS use a non-breaking space of some sort.
The main two options are the full No-Break Space (NBSP, U+00A0), or the Narrow No-Break Space (NNBSP, U+202F), whose definitions can be found in the Unicode standard, at https://unicode.org/charts/PDF/U0090.pdf and https://unicode.org/charts/PDF/U2000.pdf, respectively:


As you can see, the definition of the NNBSP says it is typically the width of a thin space, which is defined in that same chart as :

So a NNBSP would typically be a fifth of an em (0.2em). How big is a normal space or a NBSP? These metrics are font-dependent, but a rough calculation with the Charis SIL font shows that the space and NBSP characters are about 0.34em. The NNBSP is about 0.22em. This is a significant difference, and if you use a NBSP (or as a temporary measure a regular space, which has the disadvantage of breaking across lines) around punctuation, the typesetters I know will say that that space is too large. Using the NNBSP helps significantly, and can be done fairly easily in PTXprint with changes like the following lines in 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
This puts a NNBSP before or after (as necessary) the punctuation, and also removes any spaces that are there (if any). That means that whether or not the team puts in spaces, they will be normalized to NNBSP characters. E.g. in this project the team is inconsistent and uses (regular) spaces around question marks and colons, but not around quote marks (guillemets):

image945×67 35 KB
Note that you can see that these are just regular spaces if you adjust the zoom and/or pane size just right, as they will allow a break across a line, like this:

image755×114 48.8 KB
But the changes above should be able to handle both those cases OK, and insert the NNBSP for the typesetting.
In a similar way, you would want to put change rules in your SAB projects, to make sure that your Scripture apps handle the spaces properly. Check out this post for sample rules: https://community.scripture.software.sil.org/t/suggestions-for-changes-gallery/590/3.
Note that the rules in this post do not handle the space or no-space as elegantly as the rules above, but you can adjust them with tricks like the " *" used above.
And one further point before we get to Paratext… In recent typesetting jobs we have actually used one tenth of an em (0.1em) as space around the punctuation, i.e. smaller than NNBSP. Here is the punctuation definition we used:
\catcode`\:=\active \def:{\unskip\kern0.1em\char`\:{}} % colon
Note: this was done in XeTeX, but the same could be done with PTXprint. I believe you would want it defined in the ptxprint-mods.tex configuration file available on the Advanced tool tab. This gives a fairly minimal space around the punctuation, as seen in this sample:

image752×102 11.5 KB
But the teams have felt that that is sufficient space to meet their felt need of space around the punctuation that is required in French. (Of course, the French may disagree, but it’s not their language!)
Conclusion (TLDR): So what does this mean for Paratext?
If the team uses regular spaces in the text to offset their punctuation, then sometimes it will appear incorrectly on their screen in Paratext (i.e. with punctuation not properly attached to its text, as shown above), which is distracting but not the end of the world. In this case, the onus is on the typesetter or app builder to change those regular spaces appropriately. Unfortunately, if this is the form that is put into the DBL (highly likely), then apps like YouVersion are going to have problems, because they notoriously DON’T handle those spaces appropriately.
Given this tendency to smaller and smaller no-break spaces to set off the punctuation (first the NNBSP at 0.2em, then manually typesetting at 0.1em with PTXprint) that I’ve seen in my typesetting projects, I almost always recommend that teams put NO spaces around their punctuation in Paratext, and then just trust the typesetting or app building to do the right thing around those punctuation marks. This means that when the text is put into the DBL, YouVersion is not going to have any hanging puctuation. (It won’t have spaces around the punctuation either, but that is a lesser problem IMHO.)
So with this specific plan of action, no changes are required in Paratext. If you wanted, as Matthew_Lee suggested, a way to show NNBSP or NBSP characters, I think that would be a good idea, but our keyboards would also need a way to type those characters (which they don’t always), and Paratext would need to know not to mess with those characters. (And punctuation inventories would need to show all of the combinations with those spaces, to make sure that they were being used consistently, e.g. always with a NNBSP.)
This post isn’t so much proposing solutions as providing more background and information. I really don’t like the way this tilde / NBSP stuff works in Paratext now, and agree that it should change. It seems like Paratext should assume that it should take every character in the text at face value, whether it is a tilde, NBSP or NNBSP. And a way to see them (subtly) would be nice. Should two or more spaces be automatically combined (responding to @anon942452)? Maybe if they are identical characters? That would still allow the automated Paratext spacing fix, but also provide some options for getting around it. And one would also need to come up with a way to deal with all of the legacy projects that have tildes for non-breaking spaces, maybe just a conversion, to convert them all to NBSP, once that’s handled properly in Paratext.
Anyway, some more food for thought…