Download it now!
Bug 79643 - VIEWING: Non-ASCII characters fail to render in italics or equations
Summary: VIEWING: Non-ASCII characters fail to render in italics or equations
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.2.4.2 release
Hardware: Other Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: Fonts
  Show dependency treegraph
 
Reported: 2014-06-04 16:54 UTC by Paul Hsieh
Modified: 2016-11-03 14:42 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Just demonstrate the problem. (32.33 KB, application/vnd.oasis.opendocument.text)
2014-06-07 23:46 UTC, Paul Hsieh
Details
How it renders in Windows XP (83.08 KB, image/png)
2014-06-08 07:00 UTC, Yousuf Philips (jay) (retired)
Details
How it renders in Linux Mint (155.29 KB, image/png)
2014-06-08 07:00 UTC, Yousuf Philips (jay) (retired)
Details
The missing characters. (193.55 KB, image/jpeg)
2014-06-08 08:13 UTC, Paul Hsieh
Details
The results when exporting to pdf (93.33 KB, application/pdf)
2014-06-08 08:16 UTC, Paul Hsieh
Details
Here's notepad rendering everything correctly (200.90 KB, image/jpeg)
2014-06-08 08:36 UTC, Paul Hsieh
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Hsieh 2014-06-04 16:54:13 UTC
Problem description: Many non-ASCII Unicode characters (the therefore character, approximately equal character, implication arrow character) render as a non-displayable character when rendered in Times New Roman or when italicized.  (Arial, non-italicized can render these characters.)

Current behavior:
Draw the non-renderable box character

Expected behavior:
Draw the correct character as previous version of Open Office work, and how the current version works without italicization.
              
Operating System: Windows XP
Version: 4.2.4.2 release
Comment 1 Yousuf Philips (jay) (retired) 2014-06-06 19:03:23 UTC
Dear Paul,
If you would be so kind as to send us an example document with these 3 characters so that we can examine them.
Comment 2 Paul Hsieh 2014-06-07 23:46:15 UTC
Created attachment 100626 [details]
Just demonstrate the problem.

This is a file that demonstrates the problem.

It is just a writer file with the two characters: ≅ ∪

In the Arial font bold or not, it renders correctly.

In either Times New Roman or if the character is italicized then the character the "unrerable" square is shown rather than the desired, output.
Comment 3 Yousuf Philips (jay) (retired) 2014-06-08 07:00:16 UTC
Created attachment 100633 [details]
How it renders in Windows XP
Comment 4 Yousuf Philips (jay) (retired) 2014-06-08 07:00:31 UTC
Created attachment 100634 [details]
How it renders in Linux Mint
Comment 5 Yousuf Philips (jay) (retired) 2014-06-08 07:02:39 UTC
Unfortunately, i am not able to reproduce your font issue in either Linux Mint or Windows XP SP3. Is there any other information that you can provide so we can track down the issue? Please send in a screenshot so we can see how its looking for you.
Comment 6 Paul Hsieh 2014-06-08 08:13:35 UTC
Created attachment 100640 [details]
The missing characters.

This is what I see on the screen for the file source.  It's not just a rendering issue as I will show in the next attachment.
Comment 7 Paul Hsieh 2014-06-08 08:16:29 UTC
Created attachment 100641 [details]
The results when exporting to pdf

This is what I get from exporting this to a pdf.  So there is a genuine inability to render characters in some modes going on here.  I will re-iterate, an earlier OpenOffice (that I had to uninstall, in order to install the latest LibreOffice) does not have this problem at all.
Comment 8 Paul Hsieh 2014-06-08 08:36:45 UTC
Created attachment 100642 [details]
Here's notepad rendering everything correctly

Of course notepad can only use/display one font at a time, so I just went through all the iterations, and it made no difference; notepad could always render correctly.  This screen shot shows Times New Roman + italicization at the same time.
Comment 9 Yousuf Philips (jay) (retired) 2014-06-08 08:48:36 UTC
(In reply to comment #7)
> This is what I get from exporting this to a pdf.  So there is a genuine
> inability to render characters in some modes going on here.  I will
> re-iterate, an earlier OpenOffice (that I had to uninstall, in order to
> install the latest LibreOffice) does not have this problem at all.

yes it is understandable that if it rendered that way in LibreOffice, that it would print in the same way.

(In reply to comment #8)
> Of course notepad can only use/display one font at a time, so I just went
> through all the iterations, and it made no difference; notepad could always
> render correctly.  This screen shot shows Times New Roman + italicization at
> the same time.

Can you try testing this in any other word processors you may have like Wordpad, Kingsoft Writer, Microsoft Word?
Comment 10 QA Administrators 2015-07-18 17:36:26 UTC Comment hidden (obsolete)
Comment 11 Paul Hsieh 2015-07-18 22:30:23 UTC
(In reply to Yousuf (Jay) Philips from comment #9)
> (In reply to comment #7)
> > This is what I get from exporting this to a pdf.  So there is a genuine
> > inability to render characters in some modes going on here.  I will
> > re-iterate, an earlier OpenOffice (that I had to uninstall, in order to
> > install the latest LibreOffice) does not have this problem at all.
> 
> yes it is understandable that if it rendered that way in LibreOffice, that
> it would print in the same way.
> 
> (In reply to comment #8)
> > Of course notepad can only use/display one font at a time, so I just went
> > through all the iterations, and it made no difference; notepad could always
> > render correctly.  This screen shot shows Times New Roman + italicization at
> > the same time.
> 
> Can you try testing this in any other word processors you may have like
> Wordpad, Kingsoft Writer, Microsoft Word?

I don't have any of those installed except Wordpad.

Wordpad is much worse in that it cannot render U+0222A (∪) at all, unless I select the very particular font Code 2000.  Similarly, if I switch to Code 2000 in LibreOffice, it can render this character.  Wordpad renders U+02245 (≅) using a bizarre glyph that is a very poor approximation even when I give it Code 2000.

Notice the above line renders perfectly in Chrome, which, in my setup selects arial;sans-serif as the font.  When I cut and paste it into LibreOffice it is fine under those fonts.  Either switching to Times New Roman or Italicizing them breaks the two characters in question but selecting Code 2000 also works.

This is a problem for equations, however, where I don't know how to select the font for a specific character I put in there.  So I have actually no work around (i.e., just selecting Code 2000 for these single characters) for this.
Comment 12 Gordo 2015-07-29 13:04:42 UTC
Depending on what documents I have been viewing, I get different results when I open the attachment.  Sometimes all except the last are blocks.

The reason is that Times New Roman and Arial do not have theses glyphs.  Writer is using the closest matching style which might be SimSun and even that does not have all the styles so it is finding another closest matching style.  It may be that there has been changes to how Writer finds the closest match.

You can see this by doing the following:
1. New Text Document.
2. Special Character -> Font--Times New Roman -> Subset--Mathematical Operators.
Result:
No U+0222A or U+02245.
3. Change Font to SimSun and Subet to Mathematical Operators.
4. Select U+0222A and Insert.
5. Select the character and Format -> Character -> Font tab -> Style--Regular.
Result:
Between the language and the preview it will say, "The same font will be used on both your printer and your screen".
6. Change Style to Italic.
Result:
"This font style will be simulated or the closest matching style will be used."  It says the same for bold and bold italic.
7. With the Character dialogue still open, change Font to Times New Roman and Style to Regular.
Result:
"The same font will be used on both your printer and your screen".  That might be a separate bug.
8. Change Style to Bold.
Result:
Preview has a block character.  It could be that it is falling back to Simsun which does not have that style and it stops there.

Tahoma, DejaVu, OpenSymbol, Linux Libertine G, and others have the glyphs you require.  Just set that one character to the needed font.

In the formula, if you set the Custom Fonts to one that supports the glyphs then in the Command pane you can type "font serif {≅}" to force it to use the custom serif font.

Windows Vista 64
Version: 4.4.5.2
Build ID: a22f674fd25a3b6f45bdebf25400ed2adff0ff99
Comment 13 Gordo 2015-07-31 12:59:16 UTC
See bug 57999 comment 23.
Comment 14 QA Administrators 2015-09-04 03:01:42 UTC Comment hidden (obsolete)
Comment 15 V Stuart Foote 2016-11-02 21:23:31 UTC
Font fallback on Windows has been much improved for bug 71603 by

http://cgit.freedesktop.org/libreoffice/core/commit/?id=03bff1b6b953e4b7a54d2fb7bbf366bea7e959d9

http://cgit.freedesktop.org/libreoffice/core/commit/?id=5d39c2013374727b1c8f147b8b99d54402a7ff02

Please retest with a master > 20161102, or the 5.3.0beta1 when released.