Truly, a trivial bug. I am using a Graphite-enabled font, and when I go to Insert Special Characters the font isn't the one I am using, but Segoe UI. I haven't tried uninstalling that font yet, but I doubt it will work.
This also happens when a saved file contains a font not installed on the used system.
Hello Linus, *, I cannot confirm your bug with Version: 4.1.0.1 Build ID: 1b3956717a60d6ac35b133d7b0a0f5eb55e9155 under Debian Testing AMD64 ... :( Have you tested it with a newer version of LO than 3.6.2.2? Does it occur there as well? Which graphite font did you use? I have used Gentium Basic without any problem ... ;) Sorry for the inconvenience Thomas.
Created attachment 81825 [details] Example of the bug Charis SIL:1032=1 changes special characters dialog to UI font
The font I am using is Charis SIL Compact, and this bug is still present in LibreOffice 4.0.1.2 (the version I am using). Just to be clear: to reproduce, set a font to use a graphite feature and open the special characters dialog to find that the UI font is there instead.
Also, thank you for taking the time to test this. I got my Bugzilla account to report this bug, and it's finally getting noticed six months later.
Hello Linus, *, (In reply to comment #4) > The font I am using is Charis SIL Compact, and this bug is still present in > LibreOffice 4.0.1.2 (the version I am using). and you haven't tried a newer version of LO than 4.0.1.2 like 4.0.4.1 or 4.1.0.1 (RC)? Maybe it is fixed there ... ;) > Just to be clear: to reproduce, set a font to use a graphite feature Where (and how) have you set the font "to use a graphite feature"? Sorry for the inconvenience Thomas.
I won't get into the details, but download Charis SIL Compact (you can find it with you favourite search engine), switch to it as the typeface, and type in the font menu AFTER the font name "Charis SIL Compact": :1032=1. The font name should now read "Charis SIL Compact:1032=1".
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: *Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1 or later) https://www.libreoffice.org/download/ *If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior *If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT *Update the version field *Reply via email (please reply directly on the bug tracker) *Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-04-01
Created attachment 114532 [details] Still present 4.4.1 This bug is still reproducible on 4.4.1. Steps to reproduce: 1. Download and install a Graphite-enabled font 2. Activate a graphite feature in it 3. Insert → Special Character Expected behaviour: the font displayed in Special Character is the font currently being used. Actual behaviour: the font displayed in Special Character is the font used for the system user interface.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.5 or 5.1.2 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT - Update the version field - Reply via email (please reply directly on the bug tracker) - Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-04-16
This bug is still present on 5.1.3.2, Ubuntu 14.04. I'm too lazy to take a screenshot this time. Just please take a look at it.
bug 90269 is a duplicate of this bug https://bugs.documentfoundation.org/show_bug.cgi?id=90269 so closing the 90296 bug. This bug seems really easy to solve, can't it be an easyhack ?
*** Bug 90269 has been marked as a duplicate of this bug. ***
For this to be a easyHack, you need to fill in the keywords: skill<foo> difficulty<foo> topic<foo> As well as add a code pointer. This is normally done by a core developer, but since you have added "easyHack" then I assume you know that. Putting the bug on NEEDINFO until the above is resolved.
Changing status: NEEDINFO -> NEW Adding keyword 'needsDevEval' [ninjaedit]
I can confirm that this bug still exists in LO 5.3 on Windows. The bug is "trivial" in that the workaround is trivial. Normally the Special Characters dialog preselects the current font at the cursor location in the drop down list. However, when the document cursor is within a font with an enabled font feature, then the font at the cursor is NOT preselected, and Segoe UI is selected instead (on Windows 7). Explanation of font features: http://software.sil.org/charis/wp-content/uploads/sites/14/2015/11/CharisSIL-features5.000.pdf
Created attachment 140663 [details] Example with OpenType font This also happens with OpenType fonts. On the attached document there are two paragraph styles, style1 and style2, both using Libertinus Serif font, but the second paragraph style add the "onum" (old style numerals) OpenType tag. The result when you click on "insert special character" is shown on the screenshots: on the first paragraph (using style1 and hence "Libertinus Serif") the insert special character dialogue offers the right font, but on the second paragraph (using style2 and hence "Libertinus Serif:onum") offers a different font.
I tried the attachment document, "Example with OpenType font", SpecialCharTest.odt (3rd in the list). The Font Name drop-down is Libertinus Serif, and is Italic. I know this means the font is being substituted. If I go to Insert > Special Character. In 6.0.6.2, the Font drop-down was Bitstream Vera Sans. In 6.1.0.3, the Font drop-down is empty.
Special character dialog has been reworked completely. Chosen font is applied to what goes into the document.
(In reply to Heiko Tietze from comment #19) > Special character dialog has been reworked completely. Chosen font is > applied to what goes into the document. In which version? For me, it doesn't work with 7.0. Steps to reproduce: 1) Set your text in Libertinus Serif. 2) Select a couple of words and set the font as follows: Libertinus Serif:smcp Selected text turns into small caps. (You can use any other OpenType tag) 3) With the cursor inside that text, open the Insert Character dialog Result: the font box in the dialog is empty and a generic sans font is shown instead.
Yes confirming issue now affects both Graphite and OT font use on Windows alike. Removing the easyHack as no code pointers. Have not checked if Linux builds are likewise affected. Version: 7.1.0.0.alpha0+ (x64) Build ID: <buildversion> CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded 2020-08-15 TB77 daily for master buildid=4708fa80ac95f11bfbfd422bec52865a17b46fd9 Setting additional font feature (from Paragraph style or Character DF) is sufficient to confuse the Special Character Dialog. On launching the dialog an incorrect font populates the charmap, and any glyph selected is applied to document in that incorrect font. So, seems an issue in resolving font name with an appended smart font notation (either Harfbuzz or Graphite handling). @Tomaž -- is there a way to make use of your font/FeatureParser work on bug 58941 to at least pass a corrected/truncated font name to the charmap Special Character dialog? Or, the much more ambitious effort to render (and pick from) the charmap with the font feature(s) applied?
Well looks like that the special character dialog doesn't take into account the font features and actually when the font has features applied, it just can't find the font and sets an empty string. Truncating away the font features from the name could be a quick fix yes and FeatureParser should be able to do that, but to properly implement this, the special character dialog must take font features into account.
Proposed patch: https://gerrit.libreoffice.org/c/core/+/131953 However, it solves only the aspect of the missing font in the combobox.
Andreas Heinisch committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/7a2bd19355d78551f9ce253fca69d37881d1d1c1 tdf#56363 - Search font family without the font feature after the colon It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Andreas Heinisch committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e38374b15be9ea4ced36a9b5954de1dc18ba2943 tdf#56363 - UI test fails if the selected font is not present It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.