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.
Notes below.
I snipped some in-between text to make it a bit shorter.
[..]
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.
Correction: OpenOffice writes "red" not #ff0000.
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>
I think so too. But that is difficult with the StarMath language.
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>
You are right. It was my error. OpenOffice writes "red".
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>
See above OpenOffice writes "red".
StarMath has no color-name equivalent for #ff0000.
The same error is in "blue". The StarMath blue is indead a "#000080".
StarMath has no color-name equivalent for #0000ff.
The primary #00ff00 is called "lime". StarMath has no color-name for it.
The StarMath "green" is a "#008000" and that is the same as the MathML
"green"
StarMath has the color-names "cyan" and "magenta", which do not exist in
MathML.
[..]
<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.
Assuming that the TextFormatCode text value cannot be taken from a
cell reference
A reference to a cell is possible.
, 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.)
As far as I see, the number format code is not written to file format,
in case it is used in a style. But all properties are transformed into
ODF attributes. For example the color [BLUE] in the number format code
in the UI becomes a fo:color="#0000ff" in the file.
There is no issue with color names in the TEXT function as I have tested
yet. The color in the format code is ignored in case of the TEXT
function. [I should be more careful and really test all.]
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?
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>
My error, see above and the other mail. StarMath parser can only handle
color names.
PowerPoint 2010 imports .odp with Math-objects which have the 16 color
names and those which have #rrggbb values as well.
OpenOffice has to be improved in the Math-module. But upholding StarMath
might not be the best solution.
Kind regards
Regina
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
