In Formula editor's catalog it is impossible to change existing element's font face (combo list) without its name auto-switched to Unicode value and 'Modify' button grayed out.
So there's nothing to it but click 'Add'. There's now element with new name in catalog and no elelent with old name
So, to actually change font face AND keep element's name one has to re-change that new element, retyping the vanished element's name into the 'Symbol' field, then clicking 'Modify'.
A consequence of this behaviour is that until re-opening the document all formulas using element's name are rendered with old (incorrect) font face.
The scenario when this is especially relevant, at least in my case, is as follows:
1) One has an element in catalog, named THENAME
2) One wants to change something relatively minor in it, say, serifed font face to sans-serifed one.
3) One selects the element to change and clicks 'Edit', then selects the font face (other one than that's which is set already). Immediately two things may happen:
3.1) glyph's unicode position is reset, either if it's not available in the new face or, in some cases (Neo Euler->Asana Math), even if it IS available;
3.2) the name in the 'Symbol' field is reset to Ux.... pattern
4) Now one'd expect it'd be sufficient to set 'Symbol' back to what's edited now (THENAME). However, if the field is set so, the old definition gets activated again, in full (font face etc.).
Created attachment 90489 [details]
Screenshots of dialogs under v3304 and v4132.
There are some settings in the indicated facility that change in an manner that would seem unwanted. To be clear, this bug is reporting a problem relating to:
1. Edit a formula.
2. Tools > Catalog... (the Symbols dialog will display).
3. Click Edit... button (the Edit Symbols dialog will display).
4. Change Font from OpenSymbol to some other font e.g., Liberations Sans.
5. Fields other than just the Font are changed as a result e.g., Symbol and Subset.
Only the Font field is changed.
I have tested the above action under Ubuntu 10.04 x86_64 running:
- v220.127.116.11 OOO330m19 Build: 6
- v18.104.22.168 OOO340m1 Build: 602
- v22.214.171.124 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
- v126.96.36.199 Build ID: e183d5b
- v188.8.131.52 Build ID: 2e2573268451a50806fcd60ae2d9fe01dd0ce24
- v184.108.40.206 Build ID: 70feb7d99726f064edab4605a8ab840c50ec57a
In v220.127.116.11 the Subset is additionally modified (from "Basic Greek" to "Basic Latin"). This can be changed back again without any other effect. The value of Symbol remains unchanged ("ALPHA"). Modify button also remains active.
All versions listed from v18.104.22.168 through v22.214.171.124 not only change the Subset, but also the Symbol from "ALPHA" to "Ux0391" as described in the report. Any attempt to change this back to "ALPHA" (pull down list) results in the Font and Subset also being reset. It is possible to edit the Symbol string to something new (e.g., "foo") however according to comment #0 this deletes the "ALPHA" entry which then causes problems for other formula. This automatic changing of the Symbol would therefore seem problematic and may be a regression. The Modify button does remain active (unless the Symbol is reverted to "ALPHA").
(In response to comment #0)
> 'Modify' button grayed out.
I am not sure this is the behaviour I have witnessed, but there certainly appears to be a problem.
As per comment #2, confirmed. Status set to NEW. Version set to 3.4.6 release. Platform to All. Keyword regression added.
Thank you for looking into it :)
The workaround of sorts is to manually edit registrymodifications.xcu, adding the copy of some of the existing entries with name, set and codepoint changed.
By the way, styles (bold etc.) changes also seem to fail working. E.g., it seems I can't get bold outlines of 'CMU Sans Serif/Serif' series. Entry is selected, but normal style is rendered nevertheless.
still existing in 4.3.0 rc1
Migrating Whiteboard tags to Keywords: (bibisectRequest)
This can't be bibisected (it's before the bibisect package started being built). Removing keyword.
For me this dialog works as expected in LO 5.1 (tested with LO 126.96.36.199.0+ built at home under Ubuntu 15.10 x86-64).
The Symbol field shows the unicode of the selected in the grid. It allows you to choose another character by its name, switch to it in the grid and the shows its unicode. That is a very useful behavior.
For the other fields Symbol set and Subset, they shows the value for the selected symbol in the chosen font. If you change the font, these fields are changed accordingly. For example if you change OpenSymbol for "Standard Symbol L" the symbol set is still Greek but the subset becomes empty because this font does not have subset.
Please, could you test again.
Best regards. JBF
(In reply to Jean-Baptiste Faure from comment #8)
> For me this dialog works as expected in LO 5.1 (tested with LO 188.8.131.52.0+
> built at home under Ubuntu 15.10 x86-64).
If anything, the behaviour of the thing got worse -- more confusing. I'm looking at 184.108.40.206.0 built on slackware x86_64.
After I change the fontface for the symbol -- to the fontface with such code -- I get `U+xxxx` into the `name` field. If I choose 'modify' the old symbol is replaced with `U+xxxx`. If I re-enter the old name in the `name`, the subset and position are changed -- I didn't notice any system in this change.
So for me it's old plodding through the user modifications .xcu if I want to change something with no royal pain.
And I'm not even starting on how the catalog definitions are constrained to the system. I can't reuse the symbols on another machine, can't export or import.
Frankly, the whole module looks to me fit to be thrown out and rewritten with some sane assumptions in mind. Pity I'm not capable of doing this myself.
Closing as NotABug (see comment #8).
For other problems like import / export of the catalog, please file a separated enhancement request (bug report with importance set to enhancement).
Best regards. JBF
Some fix. Comment #8 misinforms. Well, whatever.