Created attachment 191999 [details] special character selector I tried using the special character drop down selector. It applies the correct character, but uses another font. When I tried to add a character in a document that uses Liberation Sans, it used Tahoma (of its own free will for that character only). I have a screen shot that shows some characters appear to be duplicated. Thanks, Tracey
The characters available per font vary. So if Liberation Sans does not include a character, some other font is picked. Can you tell us which character you were inserting? At least 'Ā' is shown in Liberation Sans. Arch Linux 64-bit, X11 Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 1b83ebf42c535528b73baac2407b347f19070d07 CPU threads: 8; OS: Linux 6.7; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 25 January 2024
NO, I can not. However, now that I am over the initial scare, in the near future I will test all the characters. I selected all and changed it all to Liberation Sans so I don't know why it chose another font. Please stand by :-) Thanks, Tracey I just started using v24
Let's set to "need info" for now then. Please also see related reports bug 155957 and bug 139359.
Dear Tracey, 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 INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/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 MassPing-NeedInfo-Ping
Dear Tracey, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA 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 our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp
I have encountered the same problem. Steps to reproduce: 1. Create a new document in Writer. 2. Click on the Insert Special Character icon and then on Other Characters, which displays the full table of available characters. Pick one and click on Insert. 3. Make sure the character has been inserted in the current font (should be Liberation Serif). 4. Create a new presentation in Impress. 5. Click in a text area (or make a new one) and check which font it uses (should be Liberation Sans). 6. Click on the Insert Special Character icon, and select the character you inserted in Writer. Select it directly from the recently used characters displayed in the panel (where it should be listed first), not from the full table. 7. Select the inserted character (e.g. by pressing Shift+Left) to observe its font. Actual result: The character has been inserted in Liberation Serif. Expected result: The character should be inserted in the current font, which is Liberation Sans. Basically, I propose this change: Special characters should be inserted using the current font rather than a previous one (except when the character is not available in the current font). Version: 24.2.7.2 (X86_64) / LibreOffice Community Build ID: 420(Build:2) CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: cs-CZ Ubuntu package version: 4:24.2.7-0ubuntu0.24.04.1~bpo22.04.1 Calc: threaded
(In reply to Jan Lachnitt from comment #6) > I have encountered the same problem. Steps to reproduce: > > 1. Create a new document in Writer. > > 2. Click on the Insert Special Character icon and then on Other Characters, > which displays the full table of available characters. Pick one and click on > Insert. > > 3. Make sure the character has been inserted in the current font (should be > Liberation Serif). > > 4. Create a new presentation in Impress. > > 5. Click in a text area (or make a new one) and check which font it uses > (should be Liberation Sans). > > 6. Click on the Insert Special Character icon, and select the character you > inserted in Writer. Select it directly from the recently used characters > displayed in the panel (where it should be listed first), not from the full > table. > > 7. Select the inserted character (e.g. by pressing Shift+Left) to observe > its font. > > Actual result: The character has been inserted in Liberation Serif. > > Expected result: The character should be inserted in the current font, which > is Liberation Sans. > > Basically, I propose this change: Special characters should be inserted > using the current font rather than a previous one (except when the character > is not available in the current font). And in this particular case, have you verified that the character (which one, please?) is indeed included in Liberation Sans?
Yes, e.g. −±¼
Ok, reading bug 155957 and bug 159572, this is an intentional decision. Jan wants the previous behaviour, but it could lead to confusing situations.
(In reply to Buovjaga from comment #9) > Ok, reading bug 155957 and bug 159572, this is an intentional decision. Jan > wants the previous behaviour, but it could lead to confusing situations. Thank you for the references. I see that the original font must be preserved if the character is in a private use area. But otherwise I would use the present font, to prevent unwanted and unnecessary (and ugly) font mixing.
(In reply to Jan Lachnitt from comment #10) > (In reply to Buovjaga from comment #9) > > Ok, reading bug 155957 and bug 159572, this is an intentional decision. Jan > > wants the previous behaviour, but it could lead to confusing situations. > > Thank you for the references. > > I see that the original font must be preserved if the character is in a > private use area. But otherwise I would use the present font, to prevent > unwanted and unnecessary (and ugly) font mixing. Ok, so you are asking for more complex logic in the code. Let's ask what the UX team thinks. I wonder how expensive performance-wise such a scanning operation would be. There can be lots of glyphs in a font...
(In reply to Buovjaga from comment #11) > Ok, so you are asking for more complex logic in the code. Let's ask what the > UX team thinks. I wonder how expensive performance-wise such a scanning > operation would be. There can be lots of glyphs in a font... I understand that this will add complexity. However, the Private Use Areas are specified relatively simply: https://en.wikipedia.org/wiki/Private_Use_Areas .
Sounds easy: use the current font if the symbol exists. But what if the font "abuses" a unicode character to draw something completely different? For example https://www.azfonts.net/fonts/wingding-review/normal-107375
(In reply to Heiko Tietze from comment #13) > Sounds easy: use the current font if the symbol exists. But what if the font > "abuses" a unicode character to draw something completely different? For > example https://www.azfonts.net/fonts/wingding-review/normal-107375 I see the problem, but I think LO should rather be adapted for standards than for fonts that break them. Alternatively, you can add a switch to LO settings, thus letting the user choose.
(In reply to Jan Lachnitt from comment #14) > (In reply to Heiko Tietze from comment #13) > > Sounds easy: use the current font if the symbol exists. But what if the font > > "abuses" a unicode character to draw something completely different? For > > example https://www.azfonts.net/fonts/wingding-review/normal-107375 > > I see the problem, but I think LO should rather be adapted for standards > than for fonts that break them. > > Alternatively, you can add a switch to LO settings, thus letting the user > choose. Any font substantially structured with PUA glyphs is breaking Unicode standard, it makes programs unstable. LibreOffice gains little in trying to interpret glyphs specified in PUA, while requiring too much non-standard font handling to do so. Need only look at the PUA mapping of StarSymbol/OpenSymbol spread across the code base to see why this is not appealing. And why fonts, e.g. Type1, bitmap, even symbol (those are special case and get mapped) are not appealing to support. So no, non-standards PUA glyphs are not welcome. And there is no up side to attempting to handle them when os/DE font fallback methods kick in. IMHO => NAB and => WF
(In reply to V Stuart Foote from comment #15) > Any font substantially structured with PUA glyphs is breaking Unicode > standard, it makes programs unstable. LibreOffice gains little in trying to > interpret glyphs specified in PUA, while requiring too much non-standard > font handling to do so. > > Need only look at the PUA mapping of StarSymbol/OpenSymbol spread across the > code base to see why this is not appealing. And why fonts, e.g. Type1, > bitmap, even symbol (those are special case and get mapped) are not > appealing to support. > > So no, non-standards PUA glyphs are not welcome. And there is no up side to > attempting to handle them when os/DE font fallback methods kick in. > > IMHO => NAB and => WF I'm sorry, but I don't understand your reasoning (and don't know what WF means). I can give my reasoning. For example, ɑ (alpha) or ± (plus-minus) are well-defined Unicode symbols, which, I believe, are available in all common fonts. When inserting them, there is no reason to preserve the font from which they were inserted previously. So, I'm proposing this change: When a symbol is inserted using the popup (with popular and recently used symbols), the current font should be used, except if the character is in a PUA or if it's not available in the current font. Maybe the present behavior is not precisely a bug, as it was intended. We may then call this a feature request.
I have noticed that this bug (or feature request) is essentially a duplicate of bug 155274. Should we mark this as a duplicate and move the discussion to 155274?
(In reply to Jan Lachnitt from comment #17) > I have noticed that this bug (or feature request) is essentially a duplicate > of bug 155274. Should we mark this as a duplicate and move the discussion to > 155274? Maybe I was wrong--this bug report is about the popup, and the other is primarily about the full dialog. The dialog offers the current font by default, whereas the popup uses the font from which the character was originally selected. But the basic idea is the same: Direct formatting should be avoided whenever it's not necessary.
We discussed the topic in the design meeting. The use case is valid, actually both, and sometimes you want to remember a glyph for a certain font, for example when picking special symbols, and sometimes you want to insert glyphs that are available in most fonts and direct formatting is not needed. Some ideas come in mind: a) have a global option, b) do some smart comparison and use the current font if the glyph code pointer and the name match the stored item (and perhaps showing an infobar if the stored glyph is not available for the current font), c) introduce another command that allows the user to either store with the font "Add to favorites with font" or to remember just the unicode pointer per "Add to favorites" (or with different labels). Moving this to the duplicate ticket though. *** This bug has been marked as a duplicate of bug 155274 ***