Do you know if this only affects text objects, or does it affect other objects such as images and latex?

I only noticed with text, it came up because I was typing data into a PDF.

This may be caused by changing DPI scaling without restarting the application. Does this occur if you open Xournal++, load the file, and then export the PDF without changing DPI settings?

Edit: we should either warn users to restart or make a restart unnecessary.

I've repeated it now, using latest master

Same issue persists. I created this without any modifications of DPI: simply opened x++, drew two lines, added text so that it's on either side of the lines, and then exported to PDF.
spacking.zip

What I see in X++:

What I see in the PDF:

Interestingly enough, I can't reproduce this if I follow your steps.

But if I open the file you provided, I see the following in Xournal++:

Can you also insert an image and see if the problem persists? I want to make sure this issue is limited only to text before trying to figure it out. I suspect that system DPI scaling may be affecting Pango (which we use to render text).

Edit: here is a side-by-side comparison in Okular, with your PDF on the left and the one I generated locally on the right.

As you can see, the strokes are in the same location, but the text scaling is different.

See attached.

Image seems OK, text still odd. Confusingly, it worked OK the first time I tried it, then I rebooted and created a new file (which has original issue)
spacing_img.zip

Here's the time it worked OK, in case you can diagnose something from that:
GRID.zip

Same problem here:
Build 1.1.0 dev from 31.03.2020

Don't know why, but the I think the text changes his stretching/size and the drawing stays the same.

By the way: Thanks for this amazing free software!

I see the same behavior. (xournalpp built from GitHub master at 86aa7e5, Fedora 29, x86_64)

With a PDF background in xournalpp and added (and scaled) Text (in light blue):

and the exported PDF:

The bug is fixed in PR #2182.

Edit: The bug has not been fixed in the (now closed) PR #2182, because that would run into a Pango bug with empty lines.

Currently the way to get the least difference between xopp-file text spacing and exported pdf-file text spacing can be obtained by increasing the font size in small steps inside Xournal++ such that the line spacing remains exactly the same in the xopp-file (while the horizontal space it takes increases), but increases in the exported pdf.

For example Sans Regular 20, 20.1, 20.2, 20.3, 20.4 up to 20.47 are all perfectly aligned to the lines of the Ruled background in the xopp-file. In the export Sans Regular 20 has quite a bit smaller line spacing, whereas Sans Regular 20.47 is almost aligned to the lines. See here:

To reproduce:
lineSpacing_SansRegular_20-x.zip

I'm somewhat confused by this report. There is:

• the issue with horizontal spacing (width of spaces) being different onscreen vs. PDF
• the issue with line spacing being independent of font size up to a certain size onscreen (but correct in PDF, thus different)
  How are they related?
  (I do understand that the empty line issue is related to a possible fix for the line spacing.)

* (I do understand that the empty line issue is related to  a possible fix for the line spacing.)

The relation is as follows: The vertical line spacing is correct onscreen when using

pango_layout_set_line_spacing(layout, 1.0);

(which is only available in pango>=1.44). However using it would introduce a new bug where empty lines don't contribute to the text height.

About the horizontal spacing I'm not sure how that is related. That would have to be checked again with different pango versions.

* (I do understand that the empty line issue is related to  a possible fix for the line spacing.)

The relation is as follows: The vertical line spacing is correct onscreen when using

pango_layout_set_line_spacing(layout, 1.0);

(which is only available in pango>=1.44). However using it would introduce a new bug where empty lines don't contribute to the text height.

That's the part I understood... I even looked at the pango code and scratched my head, wondering how other programs use it to produce reliable text layout.

About the horizontal spacing I'm not sure how that is related. That would have to be checked again with different pango versions.

So it's not clear if it's related, but the "view on screen" codepath uses a different library from the "export to PDF" codepath, right? (Just trying to see if I can help with any release blockers.)

Both "view on screen" and "export to PDF" use Cairo for rendering and Pango for text layout. Moreover "export to PDF" uses Poppler to deal with PDF's.
By the way the Inkscape code doesn't use pango_layout_set_line_spacing. They somehow compute the text layout with different (and quite sophisticated) means.

So, the 20pt xopp in lineSpacing_SansRegular_20-x.zip has text which lines up with the paper ruling when viewed in xournalpp but shouldn't if I understand correctly; the PDF output has the correct smaller line spacing.
Interestingly, SVG comes out the same ways as PDF, whereas a PNG output looks like the xournalpp view.

At 20.47pt xournalpp view and PNG look exactly the same as at 20pt (in terms of line spacing), whereas SVG and PDF almost line up with the paper ruling now.

Somehow, some of these codepaths must involve setting the line spacing to the natural line spacing for the font whereas others use a default line spacing.

Also, onscreen, the line spacing "jumps" if you go from 19.99 to 20. I tend to think there is some hidden float to int and back at play...

Related issue: https://gitlab.freedesktop.org/cairo/cairo/-/issues/426 (referring to https://gitlab.gnome.org/GNOME/pango/-/issues/506)

Fixed by PR #2182.