Bug 123536 - Unicode Superscript Characters Shown Incorrectly
Summary: Unicode Superscript Characters Shown Incorrectly
Status: RESOLVED NOTOURBUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.1.5.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-02-18 08:28 UTC by tomi.hasa
Modified: 2019-02-19 05:27 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Superscript characters in a new document (8.52 KB, application/vnd.oasis.opendocument.text)
2019-02-18 08:31 UTC, tomi.hasa
Details
screenshot (106.78 KB, image/png)
2019-02-18 15:27 UTC, tomi.hasa
Details
Sample document with paragraph font correctly assigned, superscript correct (35.08 KB, image/png)
2019-02-18 16:01 UTC, V Stuart Foote
Details
Same document but with font names mentioned (9.00 KB, application/vnd.oasis.opendocument.text)
2019-02-18 16:10 UTC, tomi.hasa
Details
Screenshot of my second version of the document with font names (123.48 KB, image/png)
2019-02-18 16:11 UTC, tomi.hasa
Details
sting of SUPERSCRIPT numbers various fonts on macOS (97.95 KB, image/png)
2019-02-18 18:40 UTC, V Stuart Foote
Details
Word version of the document (24.53 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2019-02-19 04:24 UTC, tomi.hasa
Details
Screenshot of the Word version of the document (200.86 KB, image/png)
2019-02-19 04:24 UTC, tomi.hasa
Details
Fixed version of the Word document with fonts (24.41 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2019-02-19 05:24 UTC, tomi.hasa
Details
Screenshot of the fixed version of the Word document (198.09 KB, image/png)
2019-02-19 05:25 UTC, tomi.hasa
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tomi.hasa 2019-02-18 08:28:41 UTC
Description:
I copy-pasted Unicode characters ¹ ² ³ ⁴ ⁵ ⁶ ⁷ ⁸ ⁹ ⁺ ⁻ to a new document in LibreOffice Writer and I noticed that the characters are not the same height and location compared to each other. The problem looks different with different fonts.

Steps to Reproduce:
1. Start LibreOffice Writer.
2. Create a new document.
3. Copy-paste Unicode superscript characters ¹ ² ³ ⁴ ⁵ ⁶ ⁷ ⁸ ⁹ ⁺ ⁻ to the document.

Actual Results:
Numbers 6 and 9 are in incorrect positions when using the default Liberation Serif font. With Arial and Times New Roman fonts numbers 1, 2 and 3 are in incorrect positions.

Expected Results:
All Unicode superscript characters should have the same size and position.


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Version: 6.1.5.2
Build ID: 90f8dcf33c87b3705e78202e3df5142b201bd805
CPU threads: 16; OS: Mac OS X 10.11.6; UI render: default; 
Locale: fi-FI (en.UTF-8); Calc: group threaded
Comment 1 tomi.hasa 2019-02-18 08:31:05 UTC
Created attachment 149362 [details]
Superscript characters in a new document

Example document with the problem.
Comment 2 V Stuart Foote 2019-02-18 14:44:26 UTC
Will depend on font having glyphs for all UCS codepoints. 

Select the string of superscript characters and change font from the 

Liberation Serif is missing U+2076 SUPERSCRIPT SIX and U+2079 SUPERSCRIPT NINE, so font fallback occurs.

Arial and Time New Roman are correct, where the fonts contain the full set of glyphs.
Comment 3 tomi.hasa 2019-02-18 15:27:46 UTC
Created attachment 149374 [details]
screenshot
Comment 4 tomi.hasa 2019-02-18 15:29:40 UTC
See the screenshot I just added. How do you interpret that?
Comment 5 V Stuart Foote 2019-02-18 16:01:04 UTC
Created attachment 149376 [details]
Sample document with paragraph font correctly assigned, superscript correct

(In reply to tomi.hasa from comment #4)
> See the screenshot I just added. How do you interpret that?

Incorrect font assignment to the paragraph? And, if I correct attachment 149362 [details] I get the expected handling of Arial and Times New Roman.
Comment 6 V Stuart Foote 2019-02-18 16:09:18 UTC
(In reply to V Stuart Foote from comment #5)
>... And, if I correct attachment

Sorry, too harsh. s/correct/modify

When I open the attachment--as is--it renders Superscript glyphs of both the Arial and the Times New Roman correctly. Just the Liberation Serif, with missing SIX and NINE glyphs uses a fallback.
Comment 7 tomi.hasa 2019-02-18 16:10:42 UTC
Created attachment 149377 [details]
Same document but with font names mentioned
Comment 8 tomi.hasa 2019-02-18 16:11:21 UTC
Created attachment 149378 [details]
Screenshot of my second version of the document with font names
Comment 9 tomi.hasa 2019-02-18 16:12:28 UTC
(In reply to V Stuart Foote from comment #6)
> (In reply to V Stuart Foote from comment #5)
> >... And, if I correct attachment
> 
> Sorry, too harsh. s/correct/modify
> 
> When I open the attachment--as is--it renders Superscript glyphs of both the
> Arial and the Times New Roman correctly. Just the Liberation Serif, with
> missing SIX and NINE glyphs uses a fallback.

My problem exists: I made a second version of the document with font names added. See my screenshot of the second version.
Comment 10 V Stuart Foote 2019-02-18 18:31:20 UTC
OK, so played with this on an macOS system (10.13.6 High Sierra).

It *is* a font fallback issue on macOS as well. 

Apples deployed Arial (v 5.01.2x), and Times New Roman (v 5.01.3x) do not include coverage of Unicode glyphs.

Both only cover SUPERSCRIPT ONE, TWO, THREE and both look to be receiving font fallback to system Lucinda Grande.

=> NOB.
Comment 11 V Stuart Foote 2019-02-18 18:40:03 UTC
Created attachment 149386 [details]
sting of SUPERSCRIPT numbers various fonts on macOS

this clip from 6.2.0 on macOS suggests fonts missing glyphs are getting font fallback from system font Lucinda Grande
Comment 12 V Stuart Foote 2019-02-19 01:57:39 UTC
@Khaled - are you in agreement here regards this being NOB? We've no control of OS font fallback for missing glyphs, right?
Comment 13 tomi.hasa 2019-02-19 04:24:09 UTC
Created attachment 149395 [details]
Word version of the document

Word version of the document is fine.
Comment 14 tomi.hasa 2019-02-19 04:24:49 UTC
Created attachment 149396 [details]
Screenshot of the Word version of the document
Comment 15 tomi.hasa 2019-02-19 04:27:02 UTC
(In reply to V Stuart Foote from comment #12)
> @Khaled - are you in agreement here regards this being NOB? We've no control
> of OS font fallback for missing glyphs, right?

Word version of the same copy-pasted text is fine. See the attachment and the screenshot I just added. I have Microsoft Office 2011's Word.
Comment 16 tomi.hasa 2019-02-19 04:28:59 UTC
(In reply to tomi.hasa from comment #15)
> (In reply to V Stuart Foote from comment #12)
> > @Khaled - are you in agreement here regards this being NOB? We've no control
> > of OS font fallback for missing glyphs, right?
> 
> Word version of the same copy-pasted text is fine. See the attachment and
> the screenshot I just added. I have Microsoft Office 2011's Word.

I opened the Word version of the document with LibreOffice and the Unicode characters look fine. Amazing!
Comment 17 tomi.hasa 2019-02-19 05:24:58 UTC
Created attachment 149397 [details]
Fixed version of the Word document with fonts
Comment 18 tomi.hasa 2019-02-19 05:25:29 UTC
Created attachment 149398 [details]
Screenshot of the fixed version of the Word document
Comment 19 tomi.hasa 2019-02-19 05:27:26 UTC
(In reply to tomi.hasa from comment #16)
> (In reply to tomi.hasa from comment #15)
> > (In reply to V Stuart Foote from comment #12)
> > > @Khaled - are you in agreement here regards this being NOB? We've no control
> > > of OS font fallback for missing glyphs, right?
> > 
> > Word version of the same copy-pasted text is fine. See the attachment and
> > the screenshot I just added. I have Microsoft Office 2011's Word.
> 
> I opened the Word version of the document with LibreOffice and the Unicode
> characters look fine. Amazing!

I forgot to change the fonts to the Word version of the document, so I uploaded a fixed version of the Word document and a screenshot also. Yep, seems like a font bug with OS X 10.11 (El Capitan).