computing chart labels

[John Darrington]

Regarding Fritz's change:

commit d5f9f3dea48e19a139827e9876385e0fa660cf38
Author: Friedrich Beckmann <address@hidden>
Date:   Mon Jun 1 00:20:01 2015 +0200

    histogram tick drawing - added format generation for optimum tick drawing
    Fixes bug #45192 which showed up in the gtk3 branch on MacOS.


Firstly, thanks very much for fixing this problem.


    It replaces the decimal_xxx computations with a routine that computes a
    formatting string and a scale factor for a given axis range and number of
    bins.

The problem seems to have been caused by a bug in the decimal_to_string 
function.
This change fixes the problem for histograms (by avoiding that function 
altogether)
however I am concerned that decimal_to_string remains buggy, and this function 
is
used elsewhere.

Would it be possible to use the same approach to avoid the decimal arithmetic 
functions altogether?   

    In addition the width of the rendered labels is compared with the width
    of the bins in the display such that the labels will automatically
    switch between horizontal and 45 degree display.

I think there is an existing bug report about clashing labels in other charts.
We should do the same there to avoid this.


Also, I see that the new function, chart_get_ticks_format returns a format like 
1.2e+10 for scientific format.  I think a lot of pspp users will be unsatisfied 
with this.  Can we change it to return a pango format string with proper 
superscripts.



-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.

signature.asc
Description: Digital signature