Margins change between desktop and mobile

It was at least three times.

With great patience.

:)

Sorry, you are mistaken.  While the Header pane is open, the ¶ is visible and hence is still there. 

Without going back through all of the now 5 pages of this thread, I do not remember how many times I drew your attention to influence that the setting for the distance of the header\footer from the edge of the page can have on a document when opened on another device.  You ignored that until Charles also piped up with telling you to set it to 0 after I had provided him with a detailed explanation of the influence that setting could have.

Doug and others,

For those who are interested, I was very curious. I also did a quick diff analysis of the documents that made this work (the original document with header distance set to zero and the resulting document once it was opened in Android).

You're the specialists in Word, so you might want to see this. First, a diif on the directories held in the DOCX bundles:

The desktop version is on the left and the resulting Android creation is on the right. There are plenty of files created in Android which were not there before.

Obviously, although I am happy with the visual outcome of following Charles's request, there is still a structural change to the docx once opened in Android. I took a quick peek inside one and the result can be seen below:

Doing a diff of the respective document.xml files, there were 4 differences in total:

1 and 2 at the top of the file:

I don't know what these are but they seem to be intialising resource ids. You'll know more than me.

Difference 3, in the middle:

This was within the document that I had typed (body of the file, shall we say). Not a huge problem, it was some text in French that I had accepted or ignored (can't remember) on desktop but we can see here that on Android it wasn't fully accepted.

And now for the last diff, at the end of the file:

As I say, this is really at the end of the xml file. On the left there is nothing, and on the right there is a bunch of elements (probably a good word now). It appears to me that on the left, the desktop-created document, there are no headers or footers but on the right, the Android-created document.xml file, a footer and a header have been inserted.

Doug, as a Word specialist MVP, can you tell me if this is what I think it is, or what is it?

Since the good news, I have thought of further investigating the difference between the two documents.

Therefore, I've unzipped the docx files involved to look under the hood and there is immediately a glaring difference just by looking at the content of the bundles.

In the case of the original desktop document (document x), this is the content of the word folder within the docx file:

And in the case of the document y, the one resulting simply from opening document x in Word for Android (this is the bad result, not the result where I had set header distance to 0), the folder looks as follows:

I find this to be rather enlightening and not an indicator of simple margin conflicts. Something definitely happens to a document when you open it on Android.

Charles, thanks for the reminder. With all this, which I have found to be confusing, I had forgotten to do that test.

It works - there is no header inserted.

For info: When I went to change that setting it was at 12.7mm (same as the margins).

It hadn't caused a problem on PC but was causing a problem on Android. I still can't understand why Word for Android inserts a header (_yes it does_) to compensate for a margin conflict, but it does. I remain convinced that Microsoft should be aware of this as a probable issue for the developer pipeline.

This morning I was wondering whether there is a conflict between the desktop and mobile normal.dotm files even though that still wouldn't explain the insertion of a header. Now we know it's the margin/header space conflict which causes this to happen. I don't know the internal working of OOXML, but obviously Word for Android handles the conflict in a particular way while the desktop version of Word 2016 either considers that there is no problem or ignores it.

I maintain that, because Microsoft is pushing its marketing along advanced collaboration (see the latest changes in Word 2016), this will be an issue for other users in the future if it is not dealt with. As I said, I don't find any great need for this sort of collaboration (although maybe my next role will call for it, heaven forbid).

Good on you, Charles, for reminding me to do that test!