Bug 131977 - nodes for sm Attributes, e.g. hat, circle, are not aligned correctly with the nodes of variables which are in italic form by default--nodes for diacritics need to be positioned to match the variables
Summary: nodes for sm Attributes, e.g. hat, circle, are not aligned correctly with the...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Formula Editor (show other bugs)
Version:
(earliest affected)
6.4.2.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Formula-Editor Diacritics
  Show dependency tree / graph
 
Reported: 2020-04-08 06:31 UTC by Ville Aakko
Modified: 2024-05-24 14:08 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Attachments
Screenshot of the output from the formula editor with the given example (7.75 KB, image/png)
2020-04-08 06:32 UTC, Ville Aakko 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ville Aakko 2020-04-08 06:31:44 UTC 
Description:
Diacritic characters entered in formula editor are misaligned when used with small Greek characters. This is inconvenient since using diacritics with Greek characters is very common in many types of maths. 

Despite being cosmetic, I'll leave severity as normal, since producing correctly aligned math formulas is a major expected feature of the editor (and not doing that greatly lowers usability of the software).

Steps to Reproduce:
1. Enter for example following in the formula editor:
hat %theta  hat %omega newline
hat a hat %THETA hat a newline
circle %omega circle %theta newline
circle a newline


Actual Results:
 observe misaligned diacritic marks (hats and circles) on lines 1 and 3 of output (for comparison lines 2 and 4 contain charactes where alignement is correct)
3.

Expected Results:
All diacritics should be aligned correctly.


Reproducible: Always


User Profile Reset: No



Additional Info:
Versio: 6.4.2.2
Koontiversion tunnus: 6.4.2-2
CPU-säikeet: 8; Käyttöjärjestelmä: Linux 5.6; Käyttöliittymän piirtäminen: oletus; VCL: gtk3; 
Maa-asetus: fi-FI (fi_FI.UTF-8); Käyttöliittymän kieli: fi-FI
Calc: CL
Comment 1 Ville Aakko 2020-04-08 06:32:42 UTC 
Created attachment 159408 [details]
Screenshot of the output from the formula editor with the given example
Comment 2 V Stuart Foote 2020-04-09 01:36:38 UTC 
These are not individual sm nodes, rather, these are manifestation of poor font metrics with the projects OpenSymbol font.

Permanent fix requires ability to select different default font for the sm Math editor module--that is open as bug 101174

Meanwhile, you can work around if you do a font replacment, e.g. OpenSymbol -> Dejavu Sans (from Tools -> Options -> Fonts 'Apply replacement table') you will get better alignment and sizing for the combining diacritics.
Comment 3 Ville Aakko 2020-04-11 20:48:49 UTC 
Thanks for your reply.

I made a replacement table from Opensymbol -> Dejavu Sans, and that actually makes things even worse. Now diacritics are offset to the right for all characters (including greek and non-greek). Do you have any other font suggestions a user could try to get useful output? (preferentially something which is easily available, but not necessarily the same, in most Linux Distributions, Windows and OS X?)

Also, reading bug 101174 report as a user, it is not clear it should cover this issue. However, if it is supposed to cover this one, I believe this bug report can be closed as a duplicate in that case (or, perhaps a dependency between the bugs should be made?).

The goal (IMO) should be: LibreOffice math should handle diacritics correctly and output clean math formulas out of the box, or at least with minimal user intervention (in case the problem is unavailability of fonts with non-restrictive licensing which prevents bundling of a sensible font with LO). 

Using that font replacement table seems like a kludge, and I still can not get acceptable results with the help of it.
Comment 4 V Stuart Foote 2020-04-12 02:58:12 UTC 
(In reply to V Stuart Foote from comment #2)
> These are not individual sm nodes, rather, these are manifestation of poor
> font metrics with the projects OpenSymbol font.
> 

Actually, I was incorrect. The 'hat' and 'circle' are sm Attributes each in its own sm node, and using the non-combining values e.g. U+00e5 and U+02da --there are font metric issues still, but not with combining diacritics (what changing the font would otherwise resolve). 

Rather, issue is with sm variables that will render in italic, but the nodes for the non-combining diacritics for each of the sm Attributes do not. 

You can force centered alignment of the sm nodes by forcing the variable non italic--done with the 'nitalic' attribute:

nitalic hat %theta nitalic hat %omega newline
nitalic hat a nitalic hat %THETA nitalic hat a newline
nitalic circle %omega nitalic circle %theta newline
nitalic circle a newline
  
but you loose italic variables, which folks prefer.

=> NEW

bug 101174 is related, but this is a legitimate mishandling of nodes for sm Attributes.

And should folks wonder, we intentionally avoid using the Unicode combining diacritics as per bug 66276
Comment 5 QA Administrators 2023-10-31 03:13:32 UTC 
Dear Ville Aakko,

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 with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

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) from https://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: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug