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
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.
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.
Created attachment 100633 [details] How it renders in Windows XP
Created attachment 100634 [details] How it renders in Linux Mint
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.
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.
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.
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.
(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?
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team This NEEDINFO message was generated on: 2015-07-18
(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.
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
See bug 57999 comment 23.
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INVALID due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of FDO Message generated on: 2015-09-03
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.