openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <dennis.hamil...@acm.org>
Subject RE: color names in Math
Date Sat, 08 Nov 2014 17:19:05 GMT
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.henschel@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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org


Mime
View raw message