[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Friedrich Beckmann
Subject: PSPP-BUG: [bug #45192] gtk3 / osx - histogram routine has problems when rendering text.
Date: Sat, 06 Jun 2015 19:00:54 +0000
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/600.6.3 (KHTML, like Gecko) Version/7.1.6 Safari/537.85.15

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

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

The problem seems to have been caused by a bug in the decimal_to_string
This change fixes the problem for histograms (by avoiding that function
however I am concerned that decimal_to_string remains buggy, and this function
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
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
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
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
1.2e+10 for scientific format.  I think a lot of pspp users will be
with this.  Can we change it to return a pango format string with proper

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


Reply to this item at:


  Nachricht gesendet von/durch Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]