Version: 1.1.0_devel (using KDE 3.3.0, compiled sources) Compiler: gcc version 3.3.2 OS: SunOS (sun4u) release 5.8 In a very recent cvs version, I have the problem that x axis tick labels are drawn over the axis. I will create an attachment to illustrate it. As there is no way to specify label positions to fix it by hand, this is a bit annoying :-(
Created attachment 8681 [details] image showing the problem I don't know if it is linked, but it looks like the problem is worse when the X axis label is not drawn. Also notice that the Y axis ticklabels are OK.
On Wednesday 15 December 2004 10:58, Nicolas Brisset wrote: > 16:58 ------- Created an attachment (id=8681) > --> (http://bugs.kde.org/attachment.cgi?id=8681&action=view) > image showing the problem > > I don't know if it is linked, but it looks like the problem is worse when > the X axis label is not drawn. Also notice that the Y axis ticklabels are > OK. _______________________________________________ This is most likely related to my label changes. Strangely, I don't see this though. Can you please attach a .kst file that shows this? (without data, or with data from an ascii file that I can easily generate)
On Wednesday 15 December 2004 17:12, George Staikos wrote: > This is most likely related to my label changes. Strangely, I don't see > this though. Can you please attach a .kst file that shows this? (without > data, or with data from an ascii file that I can easily generate) I could try to find the right test case (I used a .cdf file for the image I attached to the bug report), but I doubt this is linked with your recent changes as the version I tried with is the kdeextragear-2-041214 cvs snapshot, and I believe your label changes were comitted later. I will try it from home where I can use cvs and let you know what the result is. Nicolas
Created attachment 8684 [details] Shows staggered x-labels Similar problem. Using datawizard read columns 1,2,3 from gyrodata.dat into three seperate plots in the same window. Repeat and then regrid into two columns. Zoom the top left plot on the x-axis to 0 -> 3.4. Notice that the x-labels are staggered.
On December 15, 2004 10:58 am, Nicolas Brisset wrote: > I don't know if it is linked, but it looks like the problem is worse when > the X axis label is not drawn. Also notice that the Y axis ticklabels are > OK. Actually, they are not. They are not centered vertically. Which is what is happenening w/ the X labels as well. Did someone change the vertical allignment of labels recently? (last few days)
Notice also that the TopLabels are floating too high.
On Wednesday 15 December 2004 13:51, Barth Netterfield wrote: > On December 15, 2004 10:58 am, Nicolas Brisset wrote: > > I don't know if it is linked, but it looks like the problem is worse when > > the X axis label is not drawn. Also notice that the Y axis ticklabels are > > OK. > > Actually, they are not. They are not centered vertically. Which is what > is happenening w/ the X labels as well. Did someone change the vertical > allignment of labels recently? (last few days) I changed the painting altogether, as I said earlier. I haven't seen this problem on any of my machines, but I guess it's probably related.
George, it would be good if you could descibe the differences in the parsing that you have made. You mentioned you have changed the way that ^ and _ behave. Are these changes going to be backwards compatible (i.e. if someone is already using ^/- are their labels going to change)?
On Wednesday 15 December 2004 14:59, Andrew Walker wrote: > ------- George, it would be good if you could descibe the differences in > the parsing that you have made. You mentioned you have changed the way that > ^ and _ behave. Are these changes going to be backwards compatible (i.e. if > someone is already using ^/- are their labels going to change)? The changes are backwards compatible to before the commits in May that changed the parsing, I think. However it's still broken. I didn't actually change anything in parsing except interpreting \t. I only really changed rendering. It was described in my commits quite clearly. ^ and _ would not always be drawn correctly, and would sometimes overlap text. It doesn't do that anymore. The new render code uses different KstPainter calls, that's about all. The new parser and renderer are going to be used instead, so consider kstlabel's parse+render code obsolete.
CVS commit by netterfield: BUG: 95211 After recent changes, the renderer was sometimes using the bounding box of "0123456789" for height, and sometimes using height = ascent + decent +1 for height... This uses the latter definition for all cases. So now, top alignment is with the top of the highest accent allowed in the font, and bottom alignment is with the lowest decender. This has additionally required some re-tweaking of kst2dplot label placement. Still more could be useful, but not tonight. M +16 -15 kst2dplot.cpp 1.330 M +23 -24 kstlabel.cpp 1.53