In Solver dialog (menu Tools), the limiting conditions have Operator, which includes a normal "<=" for "less than or equal to", but has strange "=>" for "greater than or equal to", instead of widely accepted ">=".
Seen in: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 002ae41bb6088002ba3ed0188ac822fb823a23f9 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Weirdly enough, OOo 3.3 had >= but LO 6.0 had =>, so it must have been changed deliberately at some stage? We could even consider using characters like ≥ or ⩾ and ≤ or ⩽ Hossein, an easyhack ?
(In reply to Stéphane Guillou (stragu) from comment #1) > We could even consider using characters like ≥ or ⩾ and ≤ or ⩽ Just a note: when considering Unicode symbols, remember that the system font used for their rendering could not have it. Cue: bug 133089 caused by a fix to tdf#124471 (but PUA codepoints were used there, so might be moot).
(In reply to Stéphane Guillou (stragu) from comment #1) > Seen in: > > Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: 002ae41bb6088002ba3ed0188ac822fb823a23f9 > CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 > Locale: en-AU (en_AU.UTF-8); UI: en-US > Calc: threaded > > Weirdly enough, OOo 3.3 had >= but LO 6.0 had =>, so it must have been > changed deliberately at some stage? > > We could even consider using characters like ≥ or ⩾ and ≤ or ⩽ > > Hossein, an easyhack ? I think this is suitable for an EasyHack. Searching for a string from the UI leads to the below UI file, in which one can easily modify: $ git grep -l "Limiting Conditions" sc/uiconfig/scalc/ui/solverdlg.ui Using a text editor, the change in the UI file would be minimal. Please note that there are 4 instances of each of these characters in the UI file.
(In reply to Hossein from comment #3) > > Using a text editor, the change in the UI file would be minimal. Please note > that there are 4 instances of each of these characters in the UI file. Waiting for review. https://gerrit.libreoffice.org/c/core/+/151616
Bogdan B committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f6782ca20a5b0405beffdea4062a99cd043ffe9f tdf#155179 Replace in Solver "=>" with ">=" It will be available in 7.6.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.
In this case the Unicode character is not PUA and can be used with no problems, and the string could be made non-translatable as it’s not useful, and with that, the change can be backported.
Adolfo, it's correct if I would change instead of <items> <item translatable="yes" context="solverdlg|op3list"><=</item> <item translatable="yes" context="solverdlg|op3list">=</item> <item translatable="yes" context="solverdlg|op3list">>=</item> <item translatable="yes" context="solverdlg|op3list">Integer</item> <item translatable="yes" context="solverdlg|op3list">Binary</item> </items> to <items> <item translatable="no" context="solverdlg|op3list">U+2264</item> <item translatable="no" context="solverdlg|op3list">U+003D</item> <item translatable="no" context="solverdlg|op3list">U+2265</item> <item translatable="yes" context="solverdlg|op3list">Integer</item> <item translatable="yes" context="solverdlg|op3list">Binary</item> </items> It's ok to change also for "less than", "equal"? It's ok for all three to be nontranslatable?...
(In reply to Adolfo Jayme Barrientos from comment #6) Note that PUA is not the whole problem. Indeed, PUAs are no-go; but being in a defined Unicode set, even in BMP, doesn't automatically mean that a character is a good candidate for an UI element. Taking an extreme case, Unicode 15 adopted many new characters, and they are definitely not PUA; but using them in UI would mean that *likely* many fonts on users' systems would be unable to render these characters (yet). So even for "normal" Unicode characters in the UI, please always consider, how likely it is that a distro-default, or even user-defined, UI font misses this character, and so, a substitution would happen. Not saying that I believe that ≥ or ≤ are rare; I *have a feeling* that they should be safe - I just didn't see a consideration of what I mention here, so decided to write FTR.
Mike, the character *is* present in the Ubuntu fonts, in the Noto family, in Segoe UI (both Static and Variable) and SF. I have checked. You don’t have to be so wary of my recommendations. When I wrote https://wiki.documentfoundation.org/Design/Guidelines/UIWriting#Typography I *did* have that into consideration. I’m not naïve.
(In reply to BogdanB from comment #7) > Adolfo, it's correct if I would change instead of > > <items> > <item translatable="yes" context="solverdlg|op3list"><=</item> > <item translatable="yes" context="solverdlg|op3list">=</item> > <item translatable="yes" context="solverdlg|op3list">>=</item> > <item translatable="yes" context="solverdlg|op3list">Integer</item> > <item translatable="yes" context="solverdlg|op3list">Binary</item> > </items> > > to > > <items> > <item translatable="no" context="solverdlg|op3list">U+2264</item> > <item translatable="no" context="solverdlg|op3list">U+003D</item> > <item translatable="no" context="solverdlg|op3list">U+2265</item> > <item translatable="yes" context="solverdlg|op3list">Integer</item> > <item translatable="yes" context="solverdlg|op3list">Binary</item> > </items> > > It's ok to change also for "less than", "equal"? It's ok for all three to be > nontranslatable?... Obviously, “U+2264” is a no-go; you need to use the actual codepoint, not its U+ notation.
(In reply to Adolfo Jayme Barrientos from comment #10) > > Obviously, “U+2264” is a no-go; you need to use the actual codepoint, not > its U+ notation. A new patch is in gerrit, please take a look. https://gerrit.libreoffice.org/c/core/+/151623
Bogdan B committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/8107a65b17e5eaab41027cfd69ae227fb2e26ee8 tdf#155179 Improve Solver symbols It will be available in 7.6.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.
Thanks you Adolfo for the patch. I was blocked.
Verified fix with the latest changes on Windows and Linux: Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 074c62b4e47c1e595f08d90e3811a8baab102dd5 CPU threads: 12; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: CL threaded Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 3d6b0594267e42945a87bc98105a2e820d2229f6 CPU threads: 32; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-US (en_DE); UI: en-US Calc: threaded