Possibility to assign specific colors to gantt-chart jobs based on the standard palette

Question

When displaying a gantt chart, the colors of the jobs come from the standard 16 color palette as far as I can see.

For example, when I have a gantt chart defined on pGanttChartJobStart(iJob, iSku, iLine) and pGanttChartJobDuration(iJob, iSku,iLine) and in the gantt chart the iLine is corresponding to the resources and the combination (iSku, iJob) are corresponding to the jobs.

If I understand it correctly, AIMMS will take the coloring from the first component in the Jobs section, which is exactly what I want (i.e. every job for a given sku always has the same color, namely the ‘sku’ color)

However, sometimes, this results in two jobs that are consecutive on one line, but have colors that are quit close to eachother.

I know I can easily create my own annotations and define my own colors for that with CSS, but then I will have lost the connection to the standard aimms palette. Do you know if it is possible to define custom annotations and in the CSS for those annotations indicate you want to use a specific value of the Mod16Ord..?

Or would the best be to just copy the aimms palette as it currently is and work with custom annotations, giving the end-user the possibility to manually select colors for the different skus in case these end-up consecutively on one line?

Edo Nijmeijer · Accepted Answer

The standard 16-color data palette was created to try and make sure that consecutive colors (annotation-Mod16Ord1 to annotation-Mod16Ord16) are contrasting enough to be distinguishable when placed next to each other.

However, if the chart’s data leads to non-consecutive colors being applied, then it sort of comes down to ‘luck’.
I always struggle to explain how the choices for Ord1-16 are made, but I think you have a grasp on that already. As long as you can make it go through the annotations in order, you have the best chances of getting usable colors.

The part I do know more about, is how the colors for the actual annotations are ‘constructed’. Let me show it for ‘Ord1’:

.annotation-Mod16Ord1 {
  --palette-shift-h: 0;
  --palette-shift-s: 1;
  --palette-shift-l: 1.6;
  background: hsla(calc(var(--color_data-palette-16_1-h) + var(--palette-shift-h, 0)) calc(var(--color_data-palette-16_1-s) * var(--palette-shift-s, 0)) calc(var(--color_data-palette-16_1-l) * var(--palette-shift-l, 1))/100%);
  fill: hsla(calc(var(--color_data-palette-16_1-h) + var(--palette-shift-h, 0)) calc(var(--color_data-palette-16_1-s) * var(--palette-shift-s, 0)) calc(var(--color_data-palette-16_1-l) * var(--palette-shift-l, 1))/100%);
  stroke: hsla(calc(var(--color_data-palette-16_1-h) + var(--palette-shift-h, 0)) calc(var(--color_data-palette-16_1-s) * var(--palette-shift-s, 0)) calc(var(--color_data-palette-16_1-l) * var(--palette-shift-l, 1))/100%);
}

All annotations use ‘variables’ (custom css properties) to define a color in the HSL color space. Plus some manipulation of those values (‘shifts’). Applied to background, fill and stroke to make it work with both html and svg elements.

Ord1 uses --color_data_palette-16_1-h -s and -l

Other ordinals look like we use odd numbers only, but there is a slightly different pattern to it. Irrelevant to this explanation here.

The point is that you could of course provide your own hue, saturation and lightness values for each annotation by having something like this in your custom stylesheets:

.annotation-Mod16Ord1 {
  --color_data-palette-16_1-h: 108;
  --color_data-palette-16_1-s: 55%;
  --color_data-palette-16_1-l: 49%;
}

And that should make Ord1 go from the normal purplish color to a green one.

It would still use the ‘shift’ on top of that too, though, so simple redefining HSL only will not get you those exact colors. For that, you’d need to redefine the shifts to be neutral too:

.annotation-Mod16Ord1 {
  --palette-shift-h: 0;
  --palette-shift-s: 1;
  --palette-shift-l: 1;
  --color_data-palette-16_1-h: 108;
  --color_data-palette-16_1-s: 55%;
  --color_data-palette-16_1-l: 49%;
}

You could also use something similar in the css definition of an annotation you set yourself. It would ‘combine’ with the regular annotation to get the same effect.

Since the color definitions are based on these calculations from separate parts, you cannot really ‘use’ the same color directly anywhere else. You can copy the setup shown in the first code block (the hsl values are always available), but the ‘shifts’ are locked into the annotation definitions though.

Redefining a new palette for data coloring is not a simple task, especially if it would need to work across all data being displayed with it. We faced the same problem. You’ve experienced how it can go ‘not as intended’ for yourself.

Which brings us back to your solution: if you can manage your data to ‘cause' consecutive annotation ordinals (from the standard palette) to be used, then this is your best bet to have clear charts.

gdiepen · Answer

I did see that creating my own palette is going to be a huge undertaking and not a path I really want go down.

Currently, have two solutions:

The mentioned solution that uses a full subset of the skus set that uses a custom ordering that the user can influence.
Duplicate the existing color palette hardcoded in a custom CSS file and by means of using annotations, allow the user to select a color for each of the skus. For this solution, I have not yet worked out the way of creating a table with the skus on the rows and a dropdown-select (with each row in the dropdown be a color-rectangle) for each sku-row allowing the user to select a color.

For now, my first solution is sufficient

Reply

Sign up

Login to the community

Scanning file for viruses.

This file cannot be downloaded