sillsdev / ptx2pdf

XeTeX based macro package for typesetting USFM formatted (Paratext output) scripture files
21 stars 7 forks source link

Seems to be a line spacing bug when footnotes are found inside words of Jesus #910

Closed davidc86 closed 6 months ago

davidc86 commented 10 months ago

The PT file has this: image

The footnote is: image

The output file looks like this: image

If I move the footnote to the end of the verse, it shifts the spacing down. I don't see any reason for this in the SFM files. (There are no codes in the footnote that call for a "large font" or "large line spacing".)

Any ideas. I know I have used this structure many times before and have never noticed this odd spacing before.

davidc86 commented 10 months ago

Here it shows up in another place:

image

FYI, if I move the footnote caller to the end of the verse, PTXprint scrunches up the Section Heading too close to the end of the verse.

NOTE: This oddity does NOT affect normal text:

image

It seems to be triggered if surrounded or near the Words of Jesus markers.

But here it did not mess up:

image

Maybe the Words of Jesus were not multiple lines?

NOPE, that's not it either:

image

Also notice that the footnote itself is pretty complex, so simple/complex footnotes are also not the issue:

image

Weird.

davidg-sil commented 10 months ago

To help me track it down, can you tell me which version you're seeing this in? Thanks! That sort of thing should show up in our test files, which I've just updated the standards for, so urm... eek!

davidg-sil commented 10 months ago

I realise that you didn't get consistent results, but I'm not able to reproduce it in my test files, so I'm thinking that we'll need you to send in an archive.

One question I have..., no, two! 1) PTXprint, the USFM standard and PT itself (all apart from the basic checks) is happy for you to not end/restart the \wj character style around the footnote. can you see what happens to the note in 9:22 if you don't \wj* \f + ....\f* \wj, but just stick the note in? 2) Might it be the \fq doing something? If (1) doesn't solve anything, what about taking out the \fq ... fq*?

davidc86 commented 10 months ago

Removing the \wj from around the footnote make the footnote caller red. I'd rather it not be considered part of the quote. The weird thing about this is that we use this exact structure all over the NT. In Matthew alone it is used a lot, but only in chapter 9 is there this weird spacing. In fact, in ch 9 it is used maybe 3 times and only 2 of them have the weird spacing.

The archive for Matthew is 38MB. Not sure where to drop such a big file (sending only part of it might not have whatever it is that is triggering the spacing issue).

davidg-sil commented 9 months ago

Probably too big for email, I'm not sure. There are things like wetransfer.com and transfernow.com, but most of the time big archives get transferred to us by emailing a link to a file on a google drive (to the support email).

markpenny commented 8 months ago

@davidg-sil The archive is now in the usual place and named: SLU-PublikasiSelaru-MatthewPTXprintArchive.zip

davidg-sil commented 8 months ago

OK... Based on my testing, it looks like the issue is not the \wj at all, but the combination of the previous page having space for the line, but not the line + the footnote., so it gets put back, and the praragraph breaking tries again.
Something is going wrong in the 'putting it back' process.
Probably because the font has a high ascent, (Bigger than the line spacing) and you are not running with XeTeXuseglyphmetrics=1. @mhosken will moan at me if I tell you to turn that on, because it sometimes causes other issues, and in your case, it is certainly moving the footnotes' baseline up and down, and that's affecting where the pagebreak is on page 4....

I know I spent a few days getting this working properly in the diglot code a year or 2 ago, so I'll try and work out if I can reuse the diglot 'join stuff back together' code, or if I need to examine that code and reapply it for this circumstance.

davidc86 commented 6 months ago

Looks like this works fine in v2.4.7, thanks!