Entering a ⬛ changing the font on that line.

For some reason, when I enter a :black_large_square: character in Libre Office, it changes the font of the next character, or of the whole line. I guess this is a bug report?

Version: 6.0.7.3
Build ID: 1:6.0.7-0ubuntu0.18.04.2

Character:

When selecting the font and the font all around it, the same font is indicated on the menu. Wherever I place this character, all the following characters become some sort of serif font, but it says they are still the non-serif font that I have selected.

  1. Set your font to Font Awesome
  2. Type “Testing 123” followed by a line break
  3. Type the character “:black_large_square:
  4. Type “Testing 123” after that character
  5. The two fonts will look different, select the second one and see that it is still “Font Awesome”

It happens with “Lohit Gujarati”, “Font Awesome”, “KacstBook”, “KacstOffice”, “Pothana2000”.

It does not happen with “Liberation Sans”, “Baskerville”, “Deja Vu Sans”, “Roboto”,

It appears to only mess things up when placed at the beginning of a sentence or some whitespace.

The font seems to remain broken after inserting the character throughout a document and then removing them all. Once they are all gone and you change the font size, the font will change style randomly at different sizes. Size 36, sans serif, size 40, serif, 48, serif, 54, back to sans serif???

All the more if you think this is a bug, provide more technical details: what is the black square (Unicode code U+???)? LO version? OS?

Read these guidelines and edit (DO NOT USE ANSWER) your question for additional information.

Can’t reproduce here (same LO, Fedora 28, KDE desktop). How do you type the code point? Do you paste it from some other document? In the latter case, you may eventually paste other unwanted charactersIf it comes from a Writer/Word document, you may also import some formatting with it.

<CTRL+SHIFT+U> 2b1b
I closed the program, opened a new document, repeated it, type the character by hand and was able to repeat the bug. Interestingly it only happens when it’s set to “Font Awesome” font. The font is consistent in any other Sans Serif font, or any other font at all.

Have followed your instructions, though I have no “Font Awesome”. I tested with Liberation Sans, Baskerville (a serif font) and Gill Sans. No change in font appearance.

The key point may be the way of entering the Unicode char. I used 2b1b, then selecting the string and Alt+X.

It happens with “Lohit Gujarati”, “Font Awesome”, “KacstBook”, “KacstOffice”, “Pothana2000”.

It does not happen with “Liberation Sans”, “Baskerville”, “Deja Vu Sans”, “Roboto”,

What are the particular properties of that font? Is it one of those OpenType font with selectable variants?

Where can I examine the properties?

Try with “Fontforge”. You can download it as a package.

Well font awesome appears to be an otf, but I’m not sure what I can learn in font forge. All the characters appeared to be blank.

Actually I apparently have three versions of FontAwesome installed, an OTF a WOFF and a TTF. So… I don’t know which one it’s using. All the other fonts that have the problem are all TTF, but all the other fonts that don’t have the problem are also TTF. So I don’t think it’s determined solely on the format.

I could temporarily get some kind of narrow version of Lohit Gujarati after the black square, but trying to pinpoint the case I can no longer reproduce the phenomenon. Very strange!

It’s the ghost in the machine!

The FontAwsome TTF fonts are also web fonts just like the WOFF fonts.
You should not have these installed on your desktop.
Having both the OTF and TTF versions installed is probably confusing your OS, and LO.
The fonts will probably both have the same internal names causing font cache corruption/errors.
Remove the web fonts and re-set your font cache.

Reproduced - I followed the steps above (steps ##1-5), and got the same result. After U+2B1B on the second line the font still indicates Font Awesome (I only have OTF installed), but display looks to me like Times New Roman (or something eerily similar). I’m on Ubuntu 18.04LTS with LibO Version: 6.2.2.2 / Build ID: 1:6.2.2-0ubuntu0.18.04.1~lo1.

If you can replicate this and provide an example document you should file a bug report.
Include the same document as Export to PDF.

That character does not exist in the fonts I checked: FontAwesome 5 Free Regular and Solid, KacstBook, KacstOffice, Pothana2000, Liberation Sans, Deja Vu Sans, Roboto, Noto Sans, Ubuntu, and Arial Unicode.
So LibreOffice is having to find this character in some font and do a replacement.

LibreOffice is looking for that character in other installed fonts.
On my system it found it in CormorantUpright-Light - an odd choice and a bit random.

In LibreOffice this replacement is annoyingly done with no indication/info to the user to see what has happened.
The only way to see the actual fonts being used is to Export to PDF and then examine the PDF Text Properties.
That is how I can see my replacement font is CormorantUpright-Light on that character.

You can also get an idea of what is happening by copying the characters from the PDF into a Unicode tool.
Such as: http://babelstone.co.uk/Unicode/whatisit.html
Then you may be able to see what hidden characters also are present.

You may want to use the Insert Special Characters dialog to pick that character from a font which actually has that character thereby avoiding LibreOffice doing the replacement (which could be the problem).
That may avoid the issue as a workaround.

.

Created a bug report here: https://bugs.documentfoundation.org/show_bug.cgi?id=131691

Entering a Unicode point +u 2b1b or LibreOffice’s own U+2b1b +x toggle will depend on os/DE provided method of finding a glyph to use when the paragraph font does not include coverage of the Unicode point selected. And having made that font change–the os/DE is responsible for returning control of the font to the program in use. If multiple characters are in the wrong font after font fallback that is not a LibreOffice issue, rather is os/DE. LibreOffice provides the Special Character dialog to make such selections, from fonts that specifically include the glyph for the codepoint.

Do you really think the font is changed? Please check the various drop-down menus in the toolbar to verify the font and font size remain the same.

It is likely that your black square symbol comes from a dingbats font. Dingbats font usually have a wider linespacing than “ordinary” font. When mixing characters from fonts with non equal properties, the largest property is used so that characters on current line do not “collide” with preceding line, thus creating a wider inter-line spacing, giving the illusion that font size was enlarged.

See: https://bugs.documentfoundation.org/show_bug.cgi?id=131691