Now using LO 7.0.3.1 and I also just checked the updated help file on this and find the problem appears to be a "FEATURE" by someone. In the help file on compatibility I found this note on the compatibility of conversion from MS Word. Since none of my documents were ever MS Word, only .ODT created in LO, I didn't think to check MS Word conversion issues before:

https://help.libreoffice.org/7.0/en-US/text/shared/optionen/01041000.html?DbPAR=SHARED#bm_id3577990

Start quote

Specifies compatibility settings for text documents. These options help in fine-tuning LibreOffice when importing Microsoft Word documents.

Open a text document, choose Tools - Options - LibreOffice Writer - Compatibility.

Some of the settings defined here are only valid for the current document and must be defined separately for each document.

Use printer metrics for document formatting

Specifies that printer metrics are applied for printing and also for formatting the display on the screen. If this box is not checked, a printer independent layout will be used for screen display and printing.

If you set this option for the current document and then save the document, for example, in an older binary format, this option will not be saved. If you later open the file from the older format, this option will be set by default.

end quote

It seems this automatic reset of the setting happens to ALL documents not just old MS Word ones that are converted.

Can you include or advise a way to disable this setting and have it STAY disabled for the document so it will NOT reset as a default action?

I confirm this behaviour with doxc-files, but not with odt-files. If I'm right, you only use odt-files. The setting remains after reopening the document. And as the dialog says, it is only for the current document in use and it is not a general setting

Version: 7.1.0.0.beta1 (x64)
Build ID: 828a45a14a0b954e0e539f5a9a10ca31c81d8f53
CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: threaded

(In reply to Dieter from comment #2)
> I confirm this behaviour with doxc-files, but not with odt-files. If I'm
> right, you only use odt-files. The setting remains after reopening the
> document. And as the dialog says, it is only for the current document in use
> and it is not a general setting
> 
> Version: 7.1.0.0.beta1 (x64)
> Build ID: 828a45a14a0b954e0e539f5a9a10ca31c81d8f53
> CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL:
> win
> Locale: de-DE (de_DE); UI: en-GB
> Calc: threaded

I've used only Libre Office since it split from Open Office and I used OO for several years before that. I've not used MS Word for over twenty years. For over a decade I've been using Zorin Linux as my OS.

While I usually use a layout document I created 5 years ago and saved as .ODT, I just created a new document by opening LO Writer, select new document, typed some text. Checked the Libre Writer Compatibility setting mentioned, and saw it was unchecked. I left it that way. Saved the new file, then opened it up again. When I looked at the Libre Writer Compatibility the top option had a check mark showing the software had set that itself. I unchecked the box, applied the change, saved it, told the system to save the unchecked option as the Default, closed the file, and reopened it to find the box checked again. thus the system keeps resetting that check box.

This issue happens with EVERY .ODT file I have. I've not looked at any other files as I don't use them enough to be worried if it's an issue there or not. But I do use the finished .ODT files to create PDF copies for printing, E-pub copies, and HTML copies for web pages.

Now, in general, I wouldn't mind what the settings are. However, that one check box causes the whole document to repaginate in an odd way. The result is weird widows and orphans. I uncheck the box and the pages go back to how they should be and I can type away. But once saved and opened again I have to uncheck that box before I can do anything with the file.

As a temporary work around to save doing that all of the time I've made changes to the file page settings. To get the pages back looking like they should without that setting I have to decrease the inside age margins by 0.25 cm, reduce the top and bottom page margins by 0.25 cm, reduce the header area by 0.25 cm, and reduce the space above the H1 heading by 0.50 cm. That fixes about 95% of the issue and the page displays very close to what it did before, but even then there are times I have to make a few changes to eliminate one or two words that have been wrapped onto a new line by themselves. 

BTW, 0.25 is about the height of a line of text in the 10 pt Palatino Linotype I use. Thus this one compatibility setting is making a change to the available text space on each page that's equivalent to over 4 lines of text per page with my font - that a heck of a change to the page being displayed.

I wish I knew why it's not happening to you. I'll have to see if it's happening in LO 7.1 when it gets to RC stage.

I did some further tests, because I had the idea, that it might depend on the template you use. But I couldn't reproducd.

Does it also happen in Safe Mode (Help => Restart in SafeMode)?
=> NEEDINFO

(In reply to Dieter from comment #4)
> I did some further tests, because I had the idea, that it might depend on
> the template you use. But I couldn't reproducd.
> 
> Does it also happen in Safe Mode (Help => Restart in SafeMode)?
> => NEEDINFO

1. OK, I opened a file, unchecked the setting and saved the file, then I restarted in Safe Mode, and the setting was unchecked. I closed the file, reopened the file, the setting was checked, then restarted in Safe Mode and the setting was unchecked. - Weird.

2. I then chose another file, opened it, the setting is checked, made no changes but restarted in Safe Mode, opened the file, changed the setting, saved the file, closed. Reopened, the setting is checked, restarted in Safe Mode and the setting is unchecked. - weird.

repeated the same experiments with one of the older file and got the same results as above.

There is a difference between the normal mode and the safe mode. However, the application of the setting to the normal mode is the issue. In the normal mode the file contents is repaginated to be wrong while in the safe mode it's the way it should be.

(In reply to Ernest Bywater from comment #5)
> (In reply to Dieter from comment #4)
> There is a difference between the normal mode and the safe mode. However,
> the application of the setting to the normal mode is the issue. In the
> normal mode the file contents is repaginated to be wrong while in the safe
> mode it's the way it should be.

If it doesn't happen in SafeMode there seems to be a problem with your user profile and a reset of your profile would probably solve the problem. For more informations see: https://wiki.documentfoundation.org/UserProfile

=> RESOLVED NOTABUG (feel free to change it back to UNCONFIRMED if the problem persists with a new profile)

(In reply to Dieter from comment #6)
> (In reply to Ernest Bywater from comment #5)
> > (In reply to Dieter from comment #4)
> > There is a difference between the normal mode and the safe mode. However,
> > the application of the setting to the normal mode is the issue. In the
> > normal mode the file contents is repaginated to be wrong while in the safe
> > mode it's the way it should be.
> 
> If it doesn't happen in SafeMode there seems to be a problem with your user
> profile and a reset of your profile would probably solve the problem. For
> more informations see: https://wiki.documentfoundation.org/UserProfile
> 
> => RESOLVED NOTABUG (feel free to change it back to UNCONFIRMED if the
> problem persists with a new profile)

That appears to have stopped the issue, but it does leave me with about 3 hours of work resetting every damn setting in the software, AGAIN. It would be a lot easier to just point at a single configuration setting that nuking everything.

Please insert a Primal Scream of your choice here. Also leave the issue shown as RESOLVED - However, I still think there is a very minor bug in the software somewhere.

I had reset the User Profile as Dieter asked, and the problem went away. I did wonder how the file got corrupted by the software itself, but left that alone. Since then I have spent a loooong time resetting my personal setting as to page dimension, document colours, toolbars, styles, and just about everything to do with the way LO displays for me. However, this time I stopped every now and then to check if all was working well. I had most of the setting in when the problem arose again - yep, it came back. I undid the last set of changes and it went away again. I then started making those changes one at a time, saving, and checking the operation. I finally found one setting that all by itself caused the problem to occur again or go away. It would seem that if you disable this one setting LO automatically activated the other setting that's the problem. This is not an issue I've noticed prior to LO 7, but it is a part of the personalised setting changes I've had since LO 4.

The setting found from the Menu choices - Tools - Options - Load / Save - General

If you uncheck the box:  Load user-specific settings with the document

You have a checked box at: LibreOffice Writer - Compatibility - Use printer metrics for document formatting

......

If you check the box:  Load user-specific settings with the document

You have an unchecked box at: LibreOffice Writer - Compatibility - Use printer metrics for document formatting

.....

It matters not how many times you save the, these two settings are linked and the second will be checked if the first is unchecked.

Problem solution is NOT intuitive and it IS unexpected, but it is to simply check the box for:

Tools - Options - Load / Save - General - Load user-specific settings with the document

(In reply to Ernest Bywater from comment #8)
> Please insert a Primal Scream of your choice here.
The default to "on" when user settings are not loaded with the document has been true since at least 5.2.

I am getting very confused by looking at this. mbUseVirtualDevice seems to be the opposite of UsePtrMetrics (which defaults to false) - and yet UseVirtualDevice seems to be the variable tied to "Use printer metrics for document formatting".

(In reply to Justin L from comment #9)
> (In reply to Ernest Bywater from comment #8)
> > Please insert a Primal Scream of your choice here.
> The default to "on" when user settings are not loaded with the document has
> been true since at least 5.2.
> 
> I am getting very confused by looking at this. mbUseVirtualDevice seems to
> be the opposite of UsePtrMetrics (which defaults to false) - and yet
> UseVirtualDevice seems to be the variable tied to "Use printer metrics for
> document formatting".

If it confuses you who can look at such things, just imagine how it confuses us poor users who can't get that deep into the code.

I don't know when the code change occurred, I can only comment on what I observe of when it affected me and what I learn by checking things out. I only noticed the issue after I had to reload my OS due to a change of motherboard, and when I loaded LO 7 I had to rebuild all of my personal settings. It is possible that one of the settings changed from the default ones when I reloaded the software was done different his time, but I don't know for sure.

Why the 2 settings mentioned in 19 Dec 2020 post are interacting the way they are is beyond me. It is something I suggest the developers try to work out as it may have other unexpected effects elsewhere that haven't yet been noticed or reported. I have found a way to get around the problem that concerned me, as I noted in that post, so I'm happy to be able to get on with my story writing and leave the head scratching to more knowledgeable persons like yourself.

It looks like this was introduced here:
commit cfc7cdca3424aacdc2a7d5fbf4b845e3e2ff4e6f
Author: Vladimir Glazounov <vg@openoffice.org>
Date:   Tue Apr 1 09:11:33 2003 +0000
    2003/03/21 20:23:22 dvo 1.62.102.4: #105712# load PrinterIndependentLayout
    2003/03/21 17:42:11 fme 1.62.102.3: #105712# Printer independent formatting - Notify OLE objects on printer change even if virtual device is used for formatting
    2003/03/15 10:45:51 fme 1.62.102.2: #105712# Feature - Printer independent formatting
    2003/03/06 14:48:34 dvo 1.62.102.1: #105712# load DeviceIndependentLayout document setting (save is automatic)

(In reply to Justin L from comment #11)
> It looks like this was introduced here:
> commit cfc7cdca3424aacdc2a7d5fbf4b845e3e2ff4e6f
> Author: Vladimir Glazounov <vg@openoffice.org>
> Date:   Tue Apr 1 09:11:33 2003 +0000
>     2003/03/21 20:23:22 dvo 1.62.102.4: #105712# load
> PrinterIndependentLayout
>     2003/03/21 17:42:11 fme 1.62.102.3: #105712# Printer independent
> formatting - Notify OLE objects on printer change even if virtual device is
> used for formatting
>     2003/03/15 10:45:51 fme 1.62.102.2: #105712# Feature - Printer
> independent formatting
>     2003/03/06 14:48:34 dvo 1.62.102.1: #105712# load
> DeviceIndependentLayout document setting (save is automatic)

............

That's interesting and it makes me wonder why I've not really noticed it until recently. The only reason I can think is it's only in the last couple of years I've not had a printer attached to the system and had no printer settings set up within the system or any of the software I use on it.

I'm trying to wrap my head around what the purpose of disabling "Load user-specific settings with the document" is. There are lots of settings that are saved in the document. Disabling "Load user-specific settings with the document" tells LO to ignore the subset of settings that can be specified by the user - i.e. those found in Writer - Compatibility. So instead of using the document's version of what compatibility options should be used, we use the program defaults (which can be adjusted by the user).

So why would anyone change that setting?  One possibility could be mass conversions - where you want to change the document settings to match some user-specified settings. But other than that, I am coming up blank.

The key problem exposed in this bug report is that when the document settings are read, it needs to apply a default value in case the document doesn't contain that setting. That is a natural part of supporting older documents. They will be missing settings that didn't exist when they were created. So if a setting is missing, that indicates that an OLD behaviour needs to be applied.

Well, in this case, we are specifically telling the program to IGNORE the user-controllable settings in the document. And since we are ignoring them, obviously they are not set. And so that means they are getting the old behaviour settings. But instead of giving them old behaviours, they should just use the user-specified behaviours.

The Writer - Compatibility settings therefore have two roles - and perhaps that hasn't been entirely clear to programmers over the years.
1.) The primary purpose is probably to allow the user to assign new defaults to documents they are creating - new documents. My guess is that this would be beneficial to create new documents that work with older versions of LibreOffice, or MS Word - aiding in a long corporate rollout for example.
2.) The second purpose is to force certain compat settings when loading old documents (via turning off Load User settings from document).
3.) A third role could be seen as giving a UI way to adjust the compatibility settings of a single document (but that is where we would run into these kinds of problems, because it can mean more than just that).

I still might not have a correct understanding of any of this, but that is what I am getting from reading the code.

I have some proposed patches at https://gerrit.libreoffice.org/q/LoadUserSettings

(In reply to Justin L from comment #13)
> I'm trying to wrap my head around what the purpose of disabling "Load
> user-specific settings with the document" is. There are lots of settings
> that are saved in the document. Disabling "Load user-specific settings with
> the document" tells LO to ignore the subset of settings that can be
> specified by the user - i.e. those found in Writer - Compatibility. So
> instead of using the document's version of what compatibility options should
> be used, we use the program defaults (which can be adjusted by the user).
> 
> So why would anyone change that setting?  One possibility could be mass
> conversions - where you want to change the document settings to match some
> user-specified settings. But other than that, I am coming up blank.
> 
> The key problem exposed in this bug report is that when the document
> settings are read, it needs to apply a default value in case the document
> doesn't contain that setting. That is a natural part of supporting older
> documents. They will be missing settings that didn't exist when they were
> created. So if a setting is missing, that indicates that an OLD behaviour
> needs to be applied.
> 
> Well, in this case, we are specifically telling the program to IGNORE the
> user-controllable settings in the document. And since we are ignoring them,
> obviously they are not set. And so that means they are getting the old
> behaviour settings. But instead of giving them old behaviours, they should
> just use the user-specified behaviours.
> 
> The Writer - Compatibility settings therefore have two roles - and perhaps
> that hasn't been entirely clear to programmers over the years.
> 1.) The primary purpose is probably to allow the user to assign new defaults
> to documents they are creating - new documents. My guess is that this would
> be beneficial to create new documents that work with older versions of
> LibreOffice, or MS Word - aiding in a long corporate rollout for example.
> 2.) The second purpose is to force certain compat settings when loading old
> documents (via turning off Load User settings from document).
> 3.) A third role could be seen as giving a UI way to adjust the
> compatibility settings of a single document (but that is where we would run
> into these kinds of problems, because it can mean more than just that).
> 
> I still might not have a correct understanding of any of this, but that is
> what I am getting from reading the code.
> 
> I have some proposed patches at
> https://gerrit.libreoffice.org/q/LoadUserSettings

Justin,

I write stories which are for publication in electronic formats. With the e-pub version they'll have settings set by the e-pub reader software while with the html version they'll have settings by the browser  well, that's what's hoped for. There is absolutely no need for me to have page margins and similar settings for those finished products. However, past experience has shown that sometimes the loaded default settings within LO has caused problems with the reader's software. Years ago I found out, by trial and error, that by disabling that setting the conflicts didn't occur. Thus I got into the habit of doing that as a default personalised setting.

In the last few weeks, due to playing around working on this issue as reported I've found that is no longer a problem due to the changes in the software in the last few years.

However, it still raises a question for me - If I have no printer attached and I have no intention of every printing the document via a standard printer process, why the heck do I need to have printer settings in the document as a compulsory or default aspect? Surely I should be able to just set what I want for margins and and that's it.

BTW: I do find the system is extremely annoying when I ask it so save a file and it wants confirmation I want to have the margins set outside of the printer capable margins. If I've not got a printer attached which is LO asking me about printer margins? It has to be pulling something from a default setting somewhere to have that conflict arise within it.

Anyway, I've functional work around that only gives the the occasional annoying Printer Margins error report, so I'm happy to get on with my work. But I do keep an eye on this in case I can help with any questions about what's going on.

Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/b8d9334b9d4cc03a9b7d1e570a35e0ac6ca42338

tdf#138544 sw LoadUserSettings: default PrinterIndependentLayout

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/a1d6701105456248f6ff39766a6699f26a8f3d60

tdf#138544 sw LoadUserSettings: default DoNotJustifyLinesWithManualBreak

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

In my opinion, disabling user-specific options should *not* apply to compatibility options stored in the document. It should *only* be applicable to things like view position, or configured printer. There may be valid cases when *those* should be not loaded; but compatibility options are just part of document, defining its look. Discarding them is as if we avoid loading styles (those are also user-specific, right?).

(In reply to Mike Kaganski from comment #17)
> In my opinion, disabling user-specific options should *not* apply to
> compatibility options stored in the document. It should *only* be applicable
> to things like view position, or configured printer. There may be valid
> cases when *those* should be not loaded; but compatibility options are just
> part of document, defining its look. Discarding them is as if we avoid
> loading styles (those are also user-specific, right?).

I agree with the points Mike makes about the user defined settings shouldn't be automatically overridden by the software. However, while I'm not sure where this issue has gone or is likely to go now, I do want to list two thoughts that have arisen while investigating this issue since I first reported it.

1. Other format compatibility issues and options should only ever come into effect or be applied to a documents whenever it is being imported from or exported to another format. Thus deciding on and setting them should be part of the import and export display or save process and never part of the normal open and save of the default format process.

This means that only the existing post import or export settings need be saved in the converted file and there is no need include the compatibility process options as the new saved file is compliant with the format it's been converted to. Thus there is no need to keep the pre-conversion settings and the conversion instructions.

2. All of the settings for the document should be accessible in some way for the user to set them as they wish. There should be no automatically applied setting for a document which the user doesn't have a way of setting to suit themselves. Then they should be saved with the document.

This point is due to there being some sort of default printer margin settings hidden somewhere within the software. I have no printer attached to my system, I have no printer configuration setting on my system, nor do I have any printer settings within LO Writer other than those within the Page styles for Paper Format and margins. Yet when I set a margin to be 0.25 cm and apply it I get a message stating this is outside the print range. I've no idea where that is coming from and if allowed to set itself the hidden default it sets it to 0.64 cm.
...............

On another issue, while I'd love to be involved in checking things out using the daily builds or alpha versions I've learned, the hard way, I'm not technically competent enough do that without messing up the version of LO I use each day, so now I wait until there's a new release to update and work with it.

Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/dd7825765f83d09d132d1e6138b27cb03564aae8

tdf#138544 sw LoadUserSettings: default SubtractFlysAnchoredAtFlys

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/8466fae95acff67b25272170b49deb47146d2971

tdf#138544 sw LoadUserSettings: default EmptyDbFieldHidesPara

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/e72a6a73cbcb91d6125170efd422fe0b8760e377

tdf#138544 sw LoadUserSettings: default ConsiderTextWrapOnObjPos

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

I had better stop here or else I will get myself into big trouble. I'm starting to doubt whether I should keep patches 2-5. Maybe they should be reverted.

It seems like this idea of "don't load user settings from the document" is probably ONLY an ODT thing? So it doesn't apply to DOCX files or even ODS.

Probably the best thing to do would be to hide that setting from the UI since its usefulness and we-know-what-it-is-supposed-to-do seems rather dubious at the moment.

(In reply to Mike Kaganski from comment #17)
> In my opinion, disabling user-specific options should *not* apply to
> compatibility options stored in the document.

This should be fairly easy to do for individual settings. Just remove them from aExcludeWhenNotLoadingUserSettings.

(In reply to Justin L from comment #22)
> I had better stop here or else I will get myself into big trouble. I'm
> starting to doubt whether I should keep patches 2-5. Maybe they should be
> reverted.
> 
> It seems like this idea of "don't load user settings from the document" is
> probably ONLY an ODT thing? So it doesn't apply to DOCX files or even ODS.
> 
> Probably the best thing to do would be to hide that setting from the UI
> since its usefulness and we-know-what-it-is-supposed-to-do seems rather
> dubious at the moment.
> 
> (In reply to Mike Kaganski from comment #17)
> > In my opinion, disabling user-specific options should *not* apply to
> > compatibility options stored in the document.
> 
> This should be fairly easy to do for individual settings. Just remove them
> from aExcludeWhenNotLoadingUserSettings.

G'day Justin,

This is talk of the patches is well past my understanding of what is and isn't being suggested or done. However, there's a couple of things that I think should be looked at and kept in mind.

1. The problem arose because LO Writer was making an automatic adjustment for a specific situation for compatibility when importing documents. BUT it was applying that adjustment to ALL documents when being saved in any format and not just to that specific importation event. 

The compatibility applications should only be done at the point of importation and conversion, and never applied outside of that situation.

1.a. A key aspect of the problem is the compatibility settings are being automatically applied to documents that didn't need to be made compatible as they were already .odt files. There's no need or reason for this, but it's happening and throwing out the usual user settings by doing so.

2. User applied settings should be applied and saved with the document at all times. They should never be replaced or changed by any automatic processes. If the user is trying to apply a setting that doesn't work, that should be handled with an error message at the time they apply the setting, and NEVER done as an automatic process later after the system appears to accept the setting.

You understand what the patches are doing, I don't, but please keep these points in mind with regards to what the patches are and are not doing.

(In reply to Justin L from comment #22)
> I'm starting to doubt whether I should keep patches 2-5.
> Maybe they should be reverted.

I intended to do revert these, but as I tried to write the commit comment, I couldn't justify the revert. It still seems like the right thing to do.

"tdf#138544 sw LoadUserSettings: default DoNotJustifyLinesWithManualBreak"
commit a1d6701105456248f6ff39766a6699f26a8f3d60 is the most complicated one. It affects some non-user-settable attributes. However, those are all based-on/controlled-by the user-settable "ConsiderTextWrapOnObjPos", which ends up being a very bad choice as the identifier of bDocumentPriorSO8. But in any case, I think the patches as they currently stand are the best way to handle the current state of affairs.

I once again reviewed the list of aExcludeWhenNotLoadingUserSettings,
and it seems like I have handled them all consistently. So I consider my job
here to be done.

I started a discussion document on compatibility settings at
https://wiki.documentfoundation.org/Documentation/CompatibilityFlags