Bonjour,
Je viens de faire un petit test en ajoutant cette ligne à un fichier :
\f + \fk test one \ft - Hmm\f* \f + \fk test two\ft - no space\f*
Et je n’arrive pas à reproduire le comportement que vous décrivez une fois arrivé au niveau XeTeX (la partie qui transforme l’USFM en PDF), donc ce n’est pas un problème là-bas.
Il reste quelques possibilités :
- PTXprint (code python) supprime l’espace
- Vous avez une ligne dans le fichier
changes.txt qui supprime l’espace.
- Vous utilisez un caractère spécial qui ne se comporte pas comme un espace normal ou une lettre normale (et donc mon tiret ASCII n’a pas testé les choses correctement).
Si vous voulez creuser un peu plus, vous pouvez regarder dans le répertoire local/ptxprint/[project-name] (vos barres obliques peuvent être inversées) sous l’endroit où se trouvent vos fichiers USFM. Vous y trouverez beaucoup de choses, y compris le(s) fichier(s) USFM réécrit(s) qui est/sont transmis au travail XeTeX. Vous pouvez alors les examiner pour vérifier si votre espace est toujours présent, entre le mot-clé et \ft. Si c’est le cas, alors mon hypothèse est (3), et je passerais cette ligne de texte à quelque chose qui me donne les valeurs unicode de chaque caractère.
ps. Je viens de passer la ligne de test ci-dessus dans tout le processus PTXprint (ce test particulier a clairement mis les notes de bas de page en paragraphe) :

Donc, SI vous utilisez un simple U+002D HYPHEN-MINUS, avec des espaces normaux, alors (1) ci-dessus est peu probable.
J’espère que cela vous aidera à trouver le problème. Sinon, vous pouvez créer une archive (voir l’onglet d’aide dans PTXprint) et la soumettre par e-mail à l’adresse indiquée là-bas, (en référence à ce sujet).
David
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
Traduit automatiquement depuis English