Bug 95211

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