Здравствуйте,
Я только что провёл небольшой тест, добавив эту строку в файл:
\f + \fk test one \ft - Hmm\f* \f + \fk test two\ft - no space\f*
И я не могу воспроизвести проблему, которую вы описываете, когда дело доходит до уровня XeTeX (часть, которая превращает USFM в PDF), так что проблема не там.
Остаются некоторые возможные причины:
- PTXprint (python-код) удаляет пробел
- У вас есть строка в файле
changes.txt, которая удаляет пробел.
- Вы используете специальный символ, который ведёт себя не как обычный пробел или обычная буква (и поэтому мой ASCII-дефис не протестировал вещи должным образом).
Если вы хотите копнуть глубже, вы можете посмотреть в каталоге local/ptxprint/[project-name] (у вас слэши могут быть в обратном порядке) там, где находятся ваши файлы USFM. Там вы найдёте много вещей, включая переписанный файл USFM, который подаётся в задание XeTeX. Затем вы можете посмотреть на них, чтобы проверить, есть ли там ваш пробел, между ключевым словом и \ft. Если он есть, то, по моему предположению, это (3), и я бы прогнал эту строку текста через инструмент, который сообщает мне unicode-значения для каждого символа.
p.s. Я только что прогнал вышеуказанную тестовую строку через весь процесс PTXprint (в этом конкретном тестовом прогоне сноски были явно разбиты на абзацы):

Так что, ЕСЛИ вы используете простой U+002D HYPHEN-MINUS с обычными пробелами, то вариант (1) выше маловероятен.
Надеюсь, это поможет вам найти причину проблемы. Если нет, вы можете создать архив (см. вкладку помощи внутри PTXprint) и отправить его по электронной почте на адрес, указанный там, (со ссылкой на эту тему).
Дэвид
Hi,
I’ve just done a little test, adding this line to a file:
\f + \fk test one \ft - Hmm\f* \f + \fk test two\ft - no space\f*
And I can’t make the first one to behave as you are reporting once you get to the XeTeX level (the part that turns USFM into PDF), so it’s not a problem there.
There are some possibilities remaining:
- PTXprint (python code) is removing the space
- You have a line in
changes.txt file which is removing the space.
- You are using a special character which does not behave as a normal space or a normal letter (and so my ASCII minus did not test things properly).
If you want to dig a bit deeper, you could look in the local/ptxprint/[project-name] directory (your slashes may be the other way) under where your USFM files are. In there you’ll find lots of things including the re-written USFM file(s) that is/are fed to the XeTeX job. You could then look at them to check to see if your space is still there, between the keyword and \ft. If it is, then my guess is (3), and I’d be feeding that line of text to something that tells me unicode values for each character.
ps. I’ve just put the above test line through the whole PTXprint process (this particular test run clearly paragraphed the footnotes):

So, IF you are using a simple U+002D HYPHEN-MINUS, with normal spaces, then (1) above is unlikely.
I hope this helps you track down the issue. If not, then you can create an archive (see the help tab within PTXprint) and submit it by email to the address listed there, (referencing this topic).
David