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 #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?
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
#ff0000 is mapped to StarMath "red", but "red" has been rendered as #800000.
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
