... | ... | @@ -129,7 +129,14 @@ Since changes of the resolution change the values linearly, this table can be us |
|
|
</tbody>
|
|
|
</table>
|
|
|
|
|
|
So the best arragement depends on how much categories have to be depicted in the chart and which value resolution is desired.
|
|
|
So the best arragement depends on a number of different factors:
|
|
|
* amount of depicted bars
|
|
|
* existence of different datasets
|
|
|
* desired value resolution
|
|
|
|
|
|
Since the goal of this analysis is to create a general concept, it should be able to not only cope with simple bar charts (i.e. single dataset) but also with complex charts featuring a comparison of multiple datasets. As it will become clear in the next sections discussion, this will require the use of bar textures.
|
|
|
|
|
|
When comparing the results in the table above, the layout of horizontal bars on a portrait format seems to deliver a good general tradeoff between the possible amount of bars and the value resolution. Because of this, the implementation will create horizontally oriented bars. The page orientation is actually not crucial for the implementation because of the way the rendering system is designed. This means that the same algorithm can be used to draw the given chart on any format, as long as some properties minimum limits are not violated. Different formats will simply result in different amounts of depictable bars and in different value ranges regarding resolution.
|
|
|
|
|
|
### Complex bar charts
|
|
|
|
... | ... | |