On Fri, May 11, 2012 at 8:53 AM, Michael Stahl <mstahl@redhat.com> wrote:
i wonder if that restriction is really necessary.
IMO it is. Imagine a case where the same color scale definition is
applied to non-contiguous regions, and you having to decide whether to
scale those regions as if they are unified, or treat them as
independent ranges (therefore independent scaling). Having that
restriction removes such ambiguity. And when dealing with file format
specification, removing ambiguity is almost always a good thing.
Also, I'm personally a bit reluctant to using the styles section for
this. Because it's also possible that the same scaling definition is
applied to, say, A1:A10, and A11:A20, but we need to treat them as
separate units. The current proposal would incorrectly merge these
two ranges into one, and would cause unintentional scaling effect or
unintentional grouping of scaled ranges.
My gut feeling (totally unscientific and may be illogical) tells me
that wedging this information into the style section may not be the
cleanest approach. I could, however, imagine we define these color
scales elsewhere, and reference them from the style section somehow,
either by name or by index. Or just totally leave it outside the
style section. Somehow I tend to think that this feature behaves more
like a database range, chart source range, or pivot table data source,
than conditional formatting. And based on how Markus is implementing
it so far even in the core, the color scale data is separated stored
than the conventional conditional formatting data.
of course i don't
know how Calc is implemented and whether there would be performance
advantages in doing so;
Not sure about performance advantage, but it would clear up the above
ambiguity issue, which would ease the implementation and keep the
implementation cleaner.
also i don't know if OOXML has such a
restrictions,
In OOXML color scales are defined per range, so in that sense yes.
but another problem: is it possible that users want to use the same
color scale on a bunch of cells, but otherwise style them differently?
This is probably the same concern I raised above. We need to keep two
separate but contiguous ranges with the same style as separate groups,
in case the user wants to change the style definition of one group
later.
if so i guess this could be dealt with via some kind of style
inheritance (which is already possible AFAIK), i.e. put the color scale
into a base style; or perhaps it would be better to have color scales as
top-level elements, and then reference them from styles (similar to e.g.
fonts), like so:
Hmm, I'm not in favor of this. To me this is making it more complex
than it needs to be. The feature itself doesn't have the concept of
inheritance relationship. I would hate to introduce such relationship
in the file format which leads to having to convert one model to
another during file save and load.
Just my 2-cents.
Kohei
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.