Created attachment 60383 [details] Incorrect alignment of characters from Catalog When the numerator or the denominator of the fraction contains only characters from the Catalog, then the alignment is incorrect, for example: %pi over {%xi %xi} If you add a character is not from the Catalog, then the alignment is correct: {2 %pi} over {4 %xi %xi} or so: {{}%pi} over {{}%xi %xi} See the attached picture of how it looks to me. MS Windows 7 Home Premium 32bit Russian
confirmed on linux LibO 3.5.4.2
Created attachment 82403 [details] rendering with OpenSymbol (bad) and Liberation Sans (good) I think this is a bug with the OpenSymbol font, rather than a but iwth LibreOffice. When I change the symbol catalog to use Liberation Sans to render my %alpha instead of OpenSymbol, the problem goes away. Attached image illustrates the point.
note, this bug is still present in LibreOffice 4.0.4.2 on Ubuntu 12.04 (from LibreOffice PPA).
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (4.4.1 or later) https://www.libreoffice.org/download/ *If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior *If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-04-18
This bug is still present in LO 5.0.1.2 (under MS Windows 7).
Tested in LO 3.3.0.4, it's the same there so I set as inherited from OOo
IIUC the "catalog" of Greek characters gets calculated based on the font assigned to FONTNAME_MATH. Any substitute font (e.g. Asana Math, STIX, Cambria Math-- or a general Unicode font Symbola, Nota, Code2000) used would be similarly affected in populating the catalog of objects. Actions in comment 2 are not really changing the glyph metric of the default calculation--rather they are substituting a glyph --with new metrics-- for a value in the catalog. Believe correcting this requires attention to rules of how the nodes are assembled into formulas.
Created attachment 131566 [details] clip of Math module showing nodes with OVER elements with and without spacers @Takeshi, Khaled, * Notice that positioning of nodes composed with Greek symbols and the "over" element get odd spacing to the constructed over bar. Inserting a "`" spacer and braces with the greek symbol corrects the base line for the symbol--but seems like it is always needed, both for above and below the "over" bar. Adding the spacer corrects the construction of the node--so wouldn't we be able to adjust the logic for the nodes to apply the spacer without having to insert it and enclosing in braces? To me this seems to have nothing to do with the font metrics as folks suggest, rather it is just the source controlling construction of the nodes. Use this nonsense formula to see the effect of using spacers (regardless of font substitution, OpenSymbol default or Styx or Asana etc.): {`%pi} over {`%xi %xi} + 1 over {`%pi} + {`%xi} over a + 1 over {`%chi} newline {%pi} over {%xi %xi} + 1 over {%pi} + {%xi} over a + 1 over {%chi}
I don't understand why others are concluding here that the problem is with the rendering engine... as my earlier-attached example image ('rendering with OpenSymbol and Liberation Sans') shows, everything works fine if the OpenSymbol font is replaced with Liberation Sans in the Symbol Catalog (this must be done manually, one symbol at a time, using the GUI). If that is not a problem with the OpenSymbol font itself, then where else could the problem be?
Created attachment 133592 [details] 1/alpha + 1/(alpha+1) alignment problem Additional image added for further clarify the way that the problem disappears when choosing Liberation Serif font.
(In reply to john from comment #9) > I don't understand why others are concluding here that the problem is with > the rendering engine... as my earlier-attached example image ('rendering > with OpenSymbol and Liberation Sans') shows, everything works fine if the > OpenSymbol font is replaced with Liberation Sans in the Symbol Catalog (this > must be done manually, one symbol at a time, using the GUI). > > If that is not a problem with the OpenSymbol font itself, then where else > could the problem be? Well you are sort of right. Adjusting OpenSymbol typo/hhea metrics may be needed. Issue here is the way the fonts are sized/scaled for the SmBinVerNode [1][2], as the nodes are being calculated, and when the OpenSymbol glyphs are _mixed_ with Liberation Serif in a subnode the Denominator spacing (nDenomDist) picks up the spacing for Liberation Serif--the OpenSymbol only subnode gets a different spacing. That OpenSymbol only nodes are assigned an unhelpful Height metric can be demonstrated by modifying the Format -> Fonts: Numbers font to use the OpenSymbol glyphs. The "1 over %alpha + 1 over {%alpha + 1}" sample formula will then be calculated with OpenSymbol only Numerator spacing (nNumDist) and Denomenator spacing (nDenomDist) and collapses the spacing to the over bar. Alternatively, modify the iGreek %ialpha "α" and assign it Liberation Serif (so to match default Numbers format) and the formula gets matching spacing for all the nodes. @Takeshi, Khaled, Mike -- is the answer to chase the font metrics for errant fonts (notably OpenSymbol that we control, but others like Asana and STIX get assigned ugly spacing) or can we improve the logic for the node spacing to set minimum distances and handle mixed font composition of a node? =-ref-= [1] http://opengrok.libreoffice.org/xref/core/starmath/inc/node.hxx?#739 [2] http://opengrok.libreoffice.org/xref/core/starmath/source/node.cxx?#818
** Please read this message in its entirety before responding ** 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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I still see the bug (using the formula in Comment 8) with the latest release: Version: 6.0.4.2 (x64) Build ID: 9b0d9b32d5dcda91d2f1a96dc04c645c450872bf CPU threads: 8; OS: Windows 6.1; UI render: default; Locale: en-CA (en_CA); Calc: group
Dear Aleksandr, 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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I still see the bug in version 6.2.4.2 (x64).
This is a bug and not a bug. The % conserves the box size of the char, witch can of course be minor than other chars. In 7.1 sould be corrected using the char command (stills in devellopment).
*** Bug 81684 has been marked as a duplicate of this bug. ***
Created attachment 167539 [details] unmatched nDenomDist and nNumDist in formula LO master/7.2.0 glitch continues, from using font metric alone in composing node distance for over, and root controls