On Sun, 16 Feb 2025 at 17:36, Pavel Sanda <sa...@lyx.org> wrote: > On Tue, Feb 11, 2025 at 04:48:10PM +0100, Pavel Sanda wrote: > > Ok, I got some time to actually look in the mysterious dis/appearance of > newlines > > in our .lyx fileformat and this is my current understanding: > > > > The superfluous newline is coming from the beginning of > Font::lyxWriteChanges > > where it's uncoditionally written to ostream output. > > > > Now, Font::lyxWriteChanges is called from Paragraph::write only when > > font1(inherit_font, bparams.language) != (getFontSettings(bparams, i)). > > > > When pasting footnote in CT mode in point 4 above, fonts in this > condition > > suddenly differ for the verbatim environment (but in completely different > > part of the document - perhaps CT pasting changes something in > bparams.language?). > > > > Now although these two fonts differ, no condition of specific members of > fonts > > in lyxWriteChanges is actually true and so the result is just "\n" > automatically > > written out. > > > > > > One option how to fix is attached. Essentially output "\n" iff at least > one condition > > returns something in lyxWriteChanges. The bit I am little unsure is > whether it's safe > > to use ostringstream for any encoding of characters. But I see it being > used in > > other parts of bufferparams, so hopefully ok. > > > > UG changes in bunch of places when saving with this patch, I did not > check > > whether our load machinery is robust against superfluous newlines. > > > > I am spent for today, but if more eyes can double check, that would be > good. > > This is now in 2a6f911bf3cf. Pavel
I just tested the latest version of LyX compared to what 2.4 used to do on the user guide on Windows. Simply resaving with 2.4.3 adds a lot of empty newlines; this behaviour totally disappeared with the current version of LyX (well, rather, 18f5e0e8). So, your fix does work!
-- lyx-devel mailing list lyx-devel@lists.lyx.org https://lists.lyx.org/mailman/listinfo/lyx-devel
