PSPP-BUG: [bug #45192] gtk3 / osx - histogram routine has problems when rendering text.

[Friedrich Beckmann]

Update of bug #45192 (project pspp):

                Category: Compilation/Portability => GTK3                   
                  Status:                   Fixed => In Progress            
             Open/Closed:                  Closed => Open                   

    _______________________________________________________

Follow-up Comment #5:

Am 02.06.2015 um 13:49 schrieb John Darrington
<address@hidden>:

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?   

yes, I am looking for a replacement of the decimal_xxx functions. I think they
are
used in the xr_scale tick generation today.


  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.

When doing the scale tick, I can look into that also. 

There is the problem left, that the x-axis ticks will overwrite the axis
label. In an 
ideal world, the axis label would have another position depending size of the
tick 
names. But the chart rectangle is already drawn at xr_init time, so we cannot

escape further down...

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.


I can try that. I have not looked into the pango format. 

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?45192>

_______________________________________________
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/