I spent two evenings formatting a group report, sent the .docx to the person merging our sections, and got three screenshots back. The English subtitle on the cover had wrapped onto a second line, a table that sat on page 3 was now on page 4, and there was half a page of blank space in the middle of the body. Same file, same Word, different laptop.
To find out what was actually moving, I built a stand-in document — A4, 7 pages, a 36-row table, three images, four footnotes, headers and footers, all of it made up — and converted it to a web page inside the browser so I could measure the real width and height of every element. I used ImgIng (https://imging.ai/) for that. It runs locally: I kept the network panel open through several rounds and there was not a single non-GET request, so nothing left my machine.
Two separate things turn out to be going on.
The first is font substitution. A Word file stores the name of a font, not the font itself. If the machine opening it has nothing registered under that name, the system quietly picks something that can display the characters and uses that instead. The name in the font box still reads the same, which is exactly why this is so hard to spot. And every typeface has its own widths and heights, so the moment the glyphs change, the space the same string occupies changes with them. On my sample, one line of English measured 411.9x33 px with the font missing and 575.3x81 px with it installed; a Chinese paragraph was 45.6% taller in one case than the other. A line that used to fit no longer fits, so it wraps. A page that used to hold everything no longer does, so content spills over. Every page number after that point is off.
The second one goes deeper. Rename a .docx to .zip and open it — there is no page in there. What you get is a set of XML files saying which font a paragraph uses, what size, what line spacing, where someone inserted a page break. It is a set of instructions, not a finished layout. Pagination happens when the file is opened, computed from the fonts, paper size and margins that exist on that machine at that moment. Getting a different result on a different computer is the expected behaviour, not a corrupted file. (Rename it back and it opens normally, so the round trip is safe to try.)
Once that clicked I changed how I hand documents over. If someone has to keep editing it, they get the .docx, and we agree up front to stick to fonts that ship with the operating system. If they only need to read it — the report going to a professor, the frozen version for the group, the material I send before a defence — I send something whose layout is already fixed and will not be recomputed on open. PDF is the obvious one. The other option I have been using is an offline read-only HTML file: my 7-page sample came out as a single 85,903-byte .html with the three images inlined as base64 and no external resources at all. The person receiving it needs no Office installed, and cannot edit it by accident.
I also turned JavaScript off in the desktop browser and opened it again. The body text was line-for-line identical to the version with scripts running, and I could still select and copy 3,178 characters out of it.
What I am not going to claim is that it looks exactly like Word. I never compared it against Word, because I do not have Word installed. On my sample the page count lined up with the explicit page breaks in the source and no body text went missing, but the WordArt title on the cover came out as a blank area, and the footer page numbers needed checking by hand. So whatever format you convert to, open it yourself once before you send it.
And when someone tells you your layout is broken on their side, the first question is not which version of Word they are running. It is what font name those characters show on their screen.
Top comments (0)