Summary: | 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 | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Ville Aakko <ville.aakko> |
Component: | Formula Editor | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | NEW --- | ||
Severity: | normal | CC: | himajin100000, sadiarubab1982, shabbarsyed1999, vsfoote |
Priority: | medium | ||
Version: | 6.4.2.2 release | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 39750, 161236 | ||
Attachments: | Screenshot of the output from the formula editor with the given example |
Description
Ville Aakko
2020-04-08 06:31:44 UTC
Created attachment 159408 [details]
Screenshot of the output from the formula editor with the given example
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. 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. (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 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 |