https://bugs.documentfoundation.org/show_bug.cgi?id=159000
--- Comment #3 from Kati L. <[email protected]> --- (In reply to Mike Kaganski from comment #1) > (In reply to Kati L. from comment #0) > > Example: the double acute accent found in the menu is [U+02dd]. The correct, > > combining acute accent ought to be [U+030b]. The actual combining diacritics > > can't be found anywhere in the available selection in the Insert Special > > Characters menu window - but, when typing them in the text in their Unicode > > form followed by the combination key [alt+x], does bring out the correct > > combined characters (the vowel with the diacritic correctly above it) - in > > the used font, as a cherry on top. Therefore, they have to exist in the data > > of the font files, so who don't they show in the menu window? > > This is misconception. Your text has the font set to your choice. The > controls display it. But specific glyphs that you request might come from a > different - substitution - font. It appears that I wasn't still being meticulous enough, even if I thought that I'd been way too nitpicky. I'm aware of this fact. I just forgot to mention that, too, in my list of several other options. I attached a screencapture to demonstrate that certain combinations indeed do exist within the font, whereas other characters are substituted with the equivalents from another font. I believe I already described this feature here: " [This actually used to be an issue in the older versions of LO Writer (the one I had in use, about three years ago), as well as the reverted character appearing in the default application font, instead of the document default font or the selected font inside that text block. (As an anecdote, some of these strange reversions still appear in certain older drafts of my texts, retained in the PDF conversions made for the sake of easier proofreading, as a funny throwback.)]" The forced reversion / substitution no longer is an issue where the said characters actually exist within the font. Even in these cases (in the older versions of this software), they did, and the problem seemed to arise from having converted a document to .odt from .doc, or opening a document originally written in MSWord in LOWrite and saving it as .odt. Somehow, it didn't recognize the characters, even if the font remained the same in both formats and original softwares where the documents were written. But, like said, this no longer is an issue as long as the characters actually do exist in the used font. So, in the case of my complaints, the fonts do appear in the intended font, once I use the Unicode entering technique. They don't seem (falsely) to exist, within the entire set of characters in the Insert Special Character menu window. Will attach another screenshot of the said window. Sorry it doesn't appear as a picture in this thread, I reached the extent of my data skills at this time of the night, but was so frustrated by the misconception of my assumed misconception that I decided to return here and clarify the matter. Sorry. I'm an incurable geek, and I get needlessly annoyed when something that should be relatively effortless suddenly requires extensive work just in order to type in a single character. -- You are receiving this mail because: You are the assignee for the bug.
