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 #ff0000 to the MathML part. That is the correct mapping. But in rendering, OpenOffice has not shown the color #ff0000 but the color #800000. > > 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 #ff0000 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 #800000" 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 #ff0000 is mapped to StarMath "red", but "red" has been rendered as #800000. <orcnote> This mapping #ff0000" to StarMath "red" is definitely a bug. Does StarMath have no color-name equivalent for #ff0000?" Does it have similar problems for the other primaries, #00ff00 and #0000ff? 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 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> 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. <orcnote> What is the oldest OpenOffice.org version where the StarMath parser Can handle #RGB codings? </orcnote> Kind regards Regina <orcnote> Thanks for the meticulous analysis, Regina. I wonder if some of the disconnection here has to do with cases where the commitment to ODF as the primary format has been compromised. The inconsistencies are going to be a problem if there is to be greater ODF compliance and interoperability going forward, especially in those places where ODF has been made a preferred format. Those selections are not with concern for OpenOffice.org's StarOffice heritage but for the interoperability and substitutability assurances that is presumed for ODF compliance. </orcnote> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
