是的，我同意 Matthew_Lee 的觀點，認為這是一個重要問題，尤其是在法語世界。在我的分析中，我有幾點想提及，但我會嘗試在這篇文章底部進行總結（TLDR）。
一些線上研究顯示了一些有趣的現象，這些並非真正「離題」：
還有一些幽默的失敗案例（顯然他們使用的是普通空格——在這種情況下導致了斷行）：
這正是我們想要避免的情況——標點符號與其相關文本脫節。因此，如果我們要使用某種空格字符來分隔標點符號，我們必須始終使用某種不換行空格（non-breaking space）。
主要的兩個選項是全形不換行空格（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 通常為 0.2em（即一個 em 的五分之一）。普通空格或 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 之前，還有一點補充。在最近的排版工作中，我們實際上使用了 0.1em（即一個 em 的十分之一）作為標點符號周圍的空格，即小於 NNBSP。以下是我們使用的標點符號定義：
\catcode`\:=\active \def:{\unskip\kern0.1em\char`\:{}} % colon
注意：這是在 XeTeX 中完成的，但也可以通過 PTXprint 實現。我認為你希望在 Advanced 工具選項卡中可用的 ptxprint-mods.tex 配置文件中定義它。這會在標點符號周圍提供相當小的空格，如下面的樣本所示：
image752×102 11.5 KB
但團隊認為，對於法語中標點符號周圍所需的空間，這個空間已經足夠。（當然，法國人可能不同意，但這不是他們的語言！）
結論（TLDR）：這對 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 空格修復，但也提供了一些規避它的方法。此外，還需要想出一種方法來處理所有使用波浪號作為不換行空格的舊項目，也許只需進行一次轉換，將它們全部轉換為 NBSP，一旦 Paratext 能正確處理它。
總之，這是一些更多的思考素材……
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…
