On Fri, May 11, 2012 at 8:53 AM, Michael Stahl <mst...@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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
