Superscript displayed differently in Writer and MS Word

English
#1

Regardless of whether I create a document in Writer or Word / docx or odt, the position of the superscript character is different in Writer than in Word.

You can see the difference in the following screenshot. The first two are from one document using the default superscript (created in Writer, then opened in Word).
The last two images are also one document, but the superscript position was set manually (3pt set in Word. Then opened in Writer).

drawing3
drawing31456×1275 219 KB

I only can attach one file. So to reproduce it, just create a document like in the screenshot. Font used is Calibri, Font Size: 11

Tested with Word of Office 2010 and Microsoft 365 Version 2406

Version: 24.2.3.2 (X86_64) / LibreOffice Community
Build ID: 433d9c2ded56988e8a90e6b2e771ee4e6a5ab2ba
CPU threads: 14; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-US
Calc: threaded

#2

Rendering is different in both suites, OK. What is your question? Achieving same look in both? You didn’t attach any file; please provide one.

Be aware that these suites are based on different formatting standards. Cross-opening a document inevitably requires conversion/translation. This brings inaccuracies during the process.

Note that the controls are totally different: Writer computes relative position and size while Word raises by an absolute distance and changes size by a constant “delta”. This is probably the cause of the divergence. Testing requires both suites and I have no Word available.

Also, the way you apply superscript in Writer may affect the result: whether you use a character style or direct formatting. If both are mixed, result is often “surprising”.

#3

The goal is to have the same result in both Writer and Word. Why this came up is that a document was created in Word. When opened in Writer it was clear directly that the document in Writer was longer. I then found out that the higher superscript numbers lead to a higher line height.

Even if the superscript position is stored in relative values, i would expect the calculation to have the same result as the corresponding absolute value in docx.

I compared odt and docx to see what is actually stored in the files. For absolute superscript vales, in odt it is the percent value, for docx the absolute value. And just “super” or “superscript” when simply clicking on superscript:

simple superscript - odt
<style:style style:name=“T1” style:family=“text”>
<style:text-properties style:text-position=“super 58%”/>
</style:style>

simple superscript - saved as docx
<w:r>
<w:rPr>
<w:vertAlign w:val=“superscript”/>
</w:rPr>
<w:t>1</w:t>
</w:r>

custom position - odt
<style:style style:name=“T2” style:family=“text”>
<style:text-properties style:text-position=“27% 100%”/>
</style:style>

custom position - saved as docx (val 6 = 3 pt)
<w:r>
<w:rPr>
<w:position w:val=“6”/>
</w:rPr>
<w:t>1</w:t>
</w:r>

Sample files:
sample.docx (6.0 KB)
sample.odt (11.3 KB)

#4

Was the .docx created with Word and the .odt with Writer? Or have you created on file in one of the applications and saved under two formats?

#5

For the attached files, those were created in Writer. I tested both ways however (doesn’t make a difference regarding the issue - meaning the same docx xml was generated also in Word - e.g. <w:position w:val=“6”/> for custom position).

When odt is saved in Word for 3pt superscript then this is saved: <style:text-properties style:text-position=“27.2% 100%”/>
So it is 27,2% in odt, when choosing 3pt in Word. It is 3pt in docx when chosing 27% in Writer.
The difference in the UI is the same regardless of that difference. The position of the superscript text is displayed differently in Word an Writer regardless of whether it is stored as odt or docx.

#6

Do you consider the situation normal? Isn’t there a sense that this might be an interoperability bug?

#7

It looks like some kind of bug to me. I would be surprised if simple formatting like superscript is not clearly defined in standards like OpenXML (docx) and OpenDocument (odt).

#8

Heh, you are optimist.

OOXML standard defines the “superscript value” as clearly as:

This setting shall raise the text in this run above the baseline and change it to a smaller size, if a smaller size is available.

[ECMA-376 Part 1, 22.9.2.17 ST_VerticalAlignRun (Vertical Positioning Location)]

But this is an interoperability bug nevertheless, because the idea when importing/exporting OOXML is to match what Word does.

#9

It might be that Word is the outlier with respect to position. It seems that LibreOffice follows Adobe’s positioning of superscripts, see Software Support in Subscript and superscript - Wikipedia

#10

I guess Mike’s question will lead to:

you should enter your bug directly into Bugzilla

Cited from here:
https://wiki.documentfoundation.org/Ask/Guide_-_How_to_use_the_Ask_site/en

#11

Thanks for the link. Even though the default values are different, that wouldn’t explain the difference when setting an custom position for the superscript character.

#12

Why not? Two different programs that interpret their methodology from different standards and use different methods of achieving it. As @Wanderer pointed out, MS Word seems to be the outlier in their interpretation/implementation.

If you really need this kind of exactness between programs perhaps you’ll have more luck using a font that supports superscript/subscript characters. I don’t have any experience with this but presumably it will be consistent in relation to other characters.

#13

I understand your point when comes to default position of superscript characters (which is where Word is an outlier). When I set a superscript position of 4 pt for example, I don’t see much room for interpretation for how high the character should be.
I just tested different fonts and it seems indeed to make a difference. The difference is still there, but with Arial or Cambria for example it is a bit less.

#14

What I meant by this is instead of using LibreOffice or Word to handle the superscript, use a font that has superscript characters encoded within it. You’d probably want to setup autocorrect to handle them for you to save having to type unicode characters but the formatting should be consistent across software.

#15

I assume you mean the Unicode Block ‘Superscripts and Subscripts’. I tested with Gentium Plus, which according to fileformat.info has 100% support for that Unicode Block.
Here are the results:

test-with-gentium-plus
test-with-gentium-plus851×239 9.63 KB

top: Default superscript (simply clicked the symbol in the toolbar)
bottom: Custom Position 3Pt
Document format: docx

#16

Do you mean you requested superscript for the symbols in the Super/Sub-scripts block? The point of having such a block is to use them raw (as is) because they are already in a position “compatible” with the font.

If you applied superscript style to Superscripts symbols, you have redundant cumulative effect. What is the result with “as is” glyphs (no superscript applied)?

1 Like
#17

You didn’t use the superscript characters in the font. You used MS Word and LibreOffice’s implementation of superscript which resizes and positions the NORMAL “1” character as per the specifications linked earlier in this conversation. This is an ease of use thing rather than preserving typographic consistency across software.

See the following example that uses the superscript “1” contained within the font (Unicode 00B9).

Google Gentium Pro font Superscript MS Word vs LibreOffice Writer 20240712
Google Gentium Pro font Superscript MS Word vs LibreOffice Writer 202407121237×610 73.3 KB

#18

ah, thanks a lot. The position is the same now. I forgot to use the actual unicode characters :man_facepalming:

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.