Re: color names in Math
On 29/10/2014 Regina Henschel wrote: ... https://issues.apache.org/ooo/show_bug.cgi?id=118191 You are right in that older documents will now have a light color where they had a dark color before. But now not only 8 but all 16 basic html colors will be supported, so the user can change the color name to teal if he really wants the dark color. However older OpenOffice versions don't know teal and will show a ?. If the solution were obvious, I would not have brought it to the list. Thanks for the very detailed explanation. This is surely material for the next Release Notes. I didn't have time to follow this when you were working on it, so please forgive me if I missed some details. So (limiting this to Math for the moment) we will get 16 color choices instead of 8, but some colors in older documents will now be rendered differently due to the fact that we were writing colors in the file by name, but we weren't respecting the name attributions in MathML (so we used to write red for denoting a color that MathML did not call red). I agree with your proposals on how to handle the broken color mapping. Is it feasible to switch to writing the RGB values to the file instead of color names? Would this ensure less equivocal compatibility with the standards and other suites? Would colors written this way be properly remapped to their names when reopening the file? If I read correctly, you said that this is what Calc does, and it looks much less error-prone. older OpenOffice versions don't know teal and will show a ?. This is important for the Release notes too. And would it be the same if we write the color as RGB? Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: color names in Math
Hi Andrea, Andrea Pescetti schrieb: On 29/10/2014 Regina Henschel wrote: ... https://issues.apache.org/ooo/show_bug.cgi?id=118191 You are right in that older documents will now have a light color where they had a dark color before. But now not only 8 but all 16 basic html colors will be supported, so the user can change the color name to teal if he really wants the dark color. However older OpenOffice versions don't know teal and will show a ?. If the solution were obvious, I would not have brought it to the list. Thanks for the very detailed explanation. This is surely material for the next Release Notes. I didn't have time to follow this when you were working on it, so please forgive me if I missed some details. So (limiting this to Math for the moment) we will get 16 color choices instead of 8 yes , but some colors in older documents will now be rendered differently due to the fact that we were writing colors in the file by name, but we weren't respecting the name attributions in MathML (so we used to write red for denoting a color that MathML did not call red). ODF specification simple says The math:math element serves as a container for content defined by the MathML 2.0 standard. To keep the old StarMath syntax the annotation element of MathML is used. So when saving a formula OpenOffice writes MathML code, which is needed for ODF and in addition it writes an annotation element to preserve its own StarMath code. When reading a file and such annotation element exists, then it is used and MathML is ignored. When such annotation element does not exist, then the MathML code is used. OpenOffice has written red to StarMath code in the annotation element and #ff to the MathML part. That is the correct mapping. But in rendering, OpenOffice has not shown the color #ff but the color #80. I agree with your proposals on how to handle the broken color mapping. Is it feasible to switch to writing the RGB values to the file instead of color names? I have looked at it, for to be able to use the #rgb and #rrggbb notations, which are allowed in MathML. My idea was to allow such notations in StarMath too. But that is a larger task and has a lot of problems. For example the current implementation of the StarMath parser handles all content as tokens, but does not keep the context of the tokens. So the hash # is turned to a token TPOUND. And for #00ff00 the next token would be TNUMBER, but for #ff the next token would be TIDENT (=identifier). As # is used as delimiter in matrix and stack, the context is needed to handle # different, when it follows a color command. In the import filter for MathML it is no problem. There the token for color has the complete value #00ff00 (for example) as token value and it would be possible to write the correct color value into the node of the model. Would this ensure less equivocal compatibility with the standards and other suites? Writing #rrggbb values in StarMath would make it unambiguous. I hesitate to start in that direction. It needs an own discussion (new thread) about the future of StarMath. Perhaps we should go in the same direction as with the old binary formats and drop it totally. MathML is much richer than the existing StarMath language. To be able to really use MathML 2.0, the StarMath language would have to be extended and who will do that? I have not even found a specification of the language. Would colors written this way be properly remapped to their names when reopening the file? The mapping is already done in case the annotation is missing, the value #ff is mapped to StarMath red, but red has been rendered as #80. If I read correctly, you said that this is what Calc does, and it looks much less error-prone. The color names do not exist in ODF file format, but file format uses #rrggbb values directly. So there is no problem with definitions made in Format Cell Numbers. The problem in Calc is, that it is possible to use a format code as string in the function TEXT and so the color names can be used indirectly. From some strange code, which translates between German and English color names, I guess that color names were perhaps used in StarOffice binary formats. older OpenOffice versions don't know teal and will show a ?. This is important for the Release notes too. And would it be the same if we write the color as RGB? Yes, #rrggbb notation would result in ? too. The StarMath parser in older versions is not able to parse #rrggbb notation in StarMath code. Kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: color names in Math
Fascinating. So there is basically an interoperability bug between the Starmath code and the MathML RGB coding. Notes below. -Original Message- From: Regina Henschel [mailto:rb.hensc...@t-online.de] Sent: Saturday, November 8, 2014 05:20 To: dev@openoffice.apache.org Subject: Re: color names in Math Hi Andrea, Andrea Pescetti schrieb: On 29/10/2014 Regina Henschel wrote: [ ... ] OpenOffice has written red to StarMath code in the annotation element and #ff to the MathML part. That is the correct mapping. But in rendering, OpenOffice has not shown the color #ff but the color #80. I agree with your proposals on how to handle the broken color mapping. Is it feasible to switch to writing the RGB values to the file instead of color names? I have looked at it, for to be able to use the #rgb and #rrggbb notations, which are allowed in MathML. My idea was to allow such notations in StarMath too. But that is a larger task and has a lot of problems. For example the current implementation of the StarMath parser handles all content as tokens, but does not keep the context of the tokens. So the hash # is turned to a token TPOUND. And for #00ff00 the next token would be TNUMBER, but for #ff the next token would be TIDENT (=identifier). As # is used as delimiter in matrix and stack, the context is needed to handle # different, when it follows a color command. In the import filter for MathML it is no problem. There the token for color has the complete value #00ff00 (for example) as token value and it would be possible to write the correct color value into the node of the model. Would this ensure less equivocal compatibility with the standards and other suites? orcnote It seems using #RGB codings is the reliable way to interchange since it does not depend on discrepancies in the names given to the codes. It even avoids internationalization issues. /orcnote Writing #rrggbb values in StarMath would make it unambiguous. I hesitate to start in that direction. It needs an own discussion (new thread) about the future of StarMath. Perhaps we should go in the same direction as with the old binary formats and drop it totally. MathML is much richer than the existing StarMath language. To be able to really use MathML 2.0, the StarMath language would have to be extended and who will do that? I have not even found a specification of the language. orcnote It strikes me that the way to deal with the red disparity is to have #80 written in the MathML where Starmath red is intend and to not include the StarMath code. On re-imput to OpenOffice, or to the StarMath, the name can then be properly re-derived from the #RGB. So StarMath red is not broken, interop with the correct color happens. Except for the problem below. /orcnote Would colors written this way be properly remapped to their names when reopening the file? The mapping is already done in case the annotation is missing, the value #ff is mapped to StarMath red, but red has been rendered as #80. orcnote This mapping #ff to StarMath red is definitely a bug. Does StarMath have no color-name equivalent for #ff? Does it have similar problems for the other primaries, #00ff00 and #ff? If the problem is that StarMath has limited color choices, there is a significant problem having that interfere with interop of ODF documents having MathML. /orcnote If I read correctly, you said that this is what Calc does, and it looks much less error-prone. The color names do not exist in ODF file format, but file format uses #rrggbb values directly. So there is no problem with definitions made in Format Cell Numbers. The problem in Calc is, that it is possible to use a format code as string in the function TEXT and so the color names can be used indirectly. orcnote In the OpenFormula specification of ODF 1.2, the TEXT function format code is left as implementation-defined. That raises two obligations it seems to me: 1. Implementation-Defined means the OpenOffice definition must be published in some easily-found form that others can consult for testing, verification, and determination of interoperability cases. Assuming that the TextFormatCode text value cannot be taken from a cell reference, there is no internationalization problem, since Calc can translate other-language expressions to a single code, if desired. If a cell-carried or formula-derived text value is (ever) allowed, support for names here becomes more difficult. (Note: This is not about what OpenOffice Calc shows to users or allows to be entered, but what is actually conveyed in the file. Ideally, there is some harmony though.) 2. It also means that the definition by other implementations of OpenFormula need to be considered. The obvious ones that come to mind are the Excel support for ODF OpenFormula, the support
Re: color names in Math
I should not write answers on the fly. I apologize, I have to correct some parts. Regina Henschel schrieb: OpenOffice has written red to StarMath code in the annotation element and #ff to the MathML part. That is the correct mapping. But in rendering, OpenOffice has not shown the color #ff but the color #80. Not the #rrggbb values are written to MathML but the color names. But those color names have a specified meaning in MathML. OpenOffice uses for StarMath - MathML white - white black - black yellow - yellow green - green red - red [different rendering in OpenOffice and MathML] blue - blue [different rendering in OpenOffice and MathML] cyan - aqua [different rendering in OpenOffice and MathML] magenta - fuchsia [different rendering in OpenOffice and MathML] The mapping is already done in case the annotation is missing, the value #ff is mapped to StarMath red, but red has been rendered as #80. Wrong :( #rrggbb values are not imported but only the color names, using mapping above. Only Calc uses #rrggbb values. Kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: color names in Math
Regina, Thanks for the detailed analysis. This is definitely a very messy situation. Notes below. -Original Message- From: Regina Henschel [mailto:rb.hensc...@t-online.de] Sent: Saturday, November 8, 2014 12:32 To: dev@openoffice.apache.org Subject: Re: color names in Math Hi Dennis, some corrections :( Read my other mail too. Dennis E. Hamilton schrieb: Fascinating. So there is basically an interoperability bug between the Starmath code and the MathML RGB coding. Yes. [..] orcnote In the OpenFormula specification of ODF 1.2, the TEXT function format code is left as implementation-defined. That raises two obligations it seems to me: 1. Implementation-Defined means the OpenOffice definition must be published in some easily-found form that others can consult for testing, verification, and determination of interoperability cases. The only reference I know is the in-build help. orcnote I could only find two examples under TEXT function. I tried some of the formats under Number Format Codes and I could not make a TEXT with Format work at all, using AOO 4.1.1 on Windows 8.1 x64. /orcnote Assuming that the TextFormatCode text value cannot be taken from a cell reference A reference to a cell is possible. orcnote Oh, I read the ODF 1.2 Part 2 6.20.23 incorrectly. So it is Format Code and it is any expression that produces a text value. So yes, References are possible. OK, then rewriting between the user and the document format is not useful, since these can be from the values in other cells. So that also means any international variations have to all be accepted by an OpenFormula consumer with the same implementation-defined FormatCode cases. /orcnote [ ... ] 2. It also means that the definition by other implementations of OpenFormula need to be considered. The obvious ones that come to mind are the Excel support for ODF OpenFormula, the support in Gnumerics, and of course LibreOffice. All of these implementations are expected to publish their definitions for TextFormatCode values, and some cooperation would be valuable in this context. /orcnote That might be better discussed in the ODF TC. Perhaps the OASIS Wiki would be a good place to collect such information - with the constantly recurring question, who will do it? orcnote Only Members of the ODF TC can create content on the OASIS Wiki for the ODF TC. Also, I think only members can create JIRA issues. They are readable in public, but not writable by anyone but the TC. /orcnote [ ... ] - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
