[LabPlot2] [Bug 389855] Numbers and axes don't line up

[Alexander Semke]

https://bugs.kde.org/show_bug.cgi?id=389855

Alexander Semke  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #16 from Alexander Semke  ---
(In reply to Matthew Trescott from comment #15)
> Yes, this bug can be closed.
Thanks.

> And I apologize for not doing sufficient
> research to see that LabPlot actually supports the workflow I'd expect. 
Don't worry. We fixed an issue here and we had a helpful discussion on the
general usability. I hope you'll give LabPlot another try and will be
continuing using it in future :-) Please report any kind of bugs in LabPlot and
wishes in bugzilla here. For more general discussions on new features it's
maybe better to use the kde-edu mailing list. Thank you once more.

-- 
You are receiving this mail because:
You are watching all bug changes.

[LabPlot2] [Bug 389855] Numbers and axes don't line up

[Matthew Trescott]

https://bugs.kde.org/show_bug.cgi?id=389855

--- Comment #15 from Matthew Trescott  ---
Yes, this bug can be closed. And I apologize for not doing sufficient research
to see that LabPlot actually supports the workflow I'd expect. I would just
suggest that the default tick type be "Increment" rather than "number". Feel
free to email me at matthewtrescott  gmail  com if you'd
like. Thanks for your patience and understanding about this rather subjective
topic of UI.

-- 
You are receiving this mail because:
You are watching all bug changes.

[LabPlot2] [Bug 389855] Numbers and axes don't line up

[Alexander Semke]

https://bugs.kde.org/show_bug.cgi?id=389855

--- Comment #14 from Alexander Semke  ---
(In reply to Matthew Trescott from comment #13)
> I recorded a screen capture of an example with two Y axes in Logger Pro.
> It's on my Google Drive because of the size limit on Bugzilla:
> https://drive.google.com/open?id=1jf8bl6CPxstT6VC_s_8_lmiDEhW9bcHX
Thanks for the video. The behavior you've shown here is also the behavior that
is documented in my links posted above for Origin, Mathematica and Matlab. We
actually didn't support this workflow in LabPlot yet at all. When posting those
links I didn't realize they were referring to something different. In you video
and in the links above it's about plotting different data sets of two different
scales in the same plot - the second scale is set by the properties of the
second axis. I meant actually the ability to add an _arbitrary_ number of axis,
like in the example with Gri
http://www.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/037/3743/3743f4.jpg
. Anyway, this feature (two different scales in one plot) is something that we
should add soon, too.


> I think there's another angle though: the user who needs advanced features
> will be smart enough (for lack of a better phrase) to find and enable them.
> The user who does not need them may simply be overwhelmed and give up if
> advanced formatting features are enabled by default. I can see that LabPlot
> has smart features, but it just hasn't yet learned to be smart on the user's
> behalf. ;)
It's not only about using advanced features it's also about having different
workflows. A user who needs an application with abilities to modify every
single details of a plot and to produce a PDF-export to be embedded into the
latex file for the next publication has totally different perspective and
demands on us than a user who just wants to quickly plot some external data.
With stated with the first perspective and adding now features to support also
the other perspective. And yes, I agree, we need to find out how to make the
usage of the application for different users comfortable.


> 
> I think that two design choices mentioned here are kinda related.
> 
> - The plot scales down to fit the data, rather than the worksheet expanding
> to fit it. 
This is the default behavior in LabPlot. The plot we create has on default the
data range set to "auto" and the axes added to the plot ("box plot" with 4
axes, etc.) have also "Auto fit" option set to "on". With this settings all the
data is shown, also automatically on new data changes - the plot adjusts to the
new ranges. The only think that caused here a bit confusion and that is
different compared to other tools is the difference between the worksheet view
having fixed size (e.g. 15cm x 15cm) or having and infinite size  (i.e. the
view fills out the whole available window space). The latter can be achieved by
using "view size" for the worksheet size and can be saved as default settings
if the user needs this kind of behavior all the time.


> This is understandable, since with massive numbers it would be
> unrealistic to grow the worksheet to fit the data. (But then it causes ticks
> to have non-whole-number labels). However, with panning and zooming, it
> would not be so surprising if the user wished to pan and zoom to various
> parts of the graph on his own. In this case, having the plot constantly
> autoscale while adding data points could be undesirable, so maybe
> autoscaling should by default only.
As mentioned above, this is the default behavior - the default plot auto
adjusts to the data. With zooming and panning the user can navigate into a
certain region in the data. The user can also switch off the auto-mode and set
the ranges to fixed values manually - this is actually the more frequent use
case for people working on the plots for publications. For panning we have the
buttons in the plot toolbar at the moment (shift left X, etc.). Panning with
the mouse is being implemented now. I added the first code already for this
recently. It works already but needs to be finalized yet.


> - The number of ticks is fixed. Here, I think, is the problem. The user
> shouldn't have to guess-and-check how many ticks are needed. It should be
> possible for LabPlot, by default, to find a value equal to or higher than
> the maximum value on a given axis that is a whole-number multiple of some
> reasonable tick increment. (The tick increment would be based on the size of
> the plot on the screen.) Of course, advanced users might want to adjust the
> distance between ticks manually, but I think even that would be very much
> preferable to changing the _number_ of ticks.
> 
> The above method describes roughly what Logger Pro does, although if LabPlot
> supported manually setting the tick increment it would actually have another
> feature that Logger Pro does not.
In LabPlot you can set the number of ticks for every axis separately. You can
* either 

[LabPlot2] [Bug 389855] Numbers and axes don't line up

[Matthew Trescott]

https://bugs.kde.org/show_bug.cgi?id=389855

--- Comment #13 from Matthew Trescott  ---
(In reply to Alexander Semke from comment #10)
> (In reply to Matthew Trescott from comment #9)
> > Fair enough, but that's still really unintuitive behavior.
> Agree. But this is still more intuitive than in most other programs that
> support multiple axes. You mentioned LoggerPro as an example for a software
> with good UX. What is the workflow in this program to create plots like on
> the screenshots in the following links?
> https://reference.wolfram.com/language/howto/
> GeneratePlotsWithTwoVerticalScales.html
> https://www.originlab.com/doc/Origin-Help/MultiY-Graph
> http://www.linuxjournal.com/article/3743?page=0,2
> https://de.mathworks.com/help/matlab/creating_plots/graph-with-multiple-x-
> axes-and-y-axes.html?s_tid=gn_loc_drop

I recorded a screen capture of an example with two Y axes in Logger Pro. It's
on my Google Drive because of the size limit on Bugzilla:
https://drive.google.com/open?id=1jf8bl6CPxstT6VC_s_8_lmiDEhW9bcHX

True, it's less flexible than LabPlot, but notice how trivial it is to use.
Before today I didn't even know that Logger Pro supported two y-axes, and that
recording was only my second try. 

> It looks like a piece of paper because every worksheet has a fixed size on
> default. What you're referring here to are, I think, not the _ranges_ of the
> data shown in the plot but the _size_ of plot and/or worksheet. I'm
> attaching two screenshots making the difference clear. Both plots show the
> same amount of data in the same data ranges, namely x=[0,20] and y=[-1,1],
> for f(x)=sin(x) with x \in (0,20). In the plot shown in
> worksheet_fixed_size.png the size of the worksheet is fixed (10cm x 10cm)
> and the plot adjusts its size (layout is active with some values for top,
> bottom, left and right margins). On the second screenshot
> worksheet_view_size.png the same function is plotted but now with worksheet
> adjusting it's size to the view size. To get this simply select "view size"
> for the size in the worksheet properties. If you resize the sub-window
> (change the size or maximize the sub-window), the worksheet and the plots on
> it will adjust the sizes accordingly. You can also set all the layout
> margins to 0 if you need more space for the plot(s) and also play around
> with the plot area paddings in the plot properties. You can even show the
> data in the presenter mode if you want to further get rid of menu bar and
> toolbars (main menu bar -> Worksheet -> show in presenter mode). Once you
> have your desired settings for the worksheet and plot (sizes, etc.) you can
> save them as default values (template buttons at the bottom of the
> properties dock widgets for different objects) - every newly created object
> will be then created with these properties.
> 
> 
> 
> > So basically, please make the plot more freeform until _after_ the user is
> > done analyzing. The average user will, I think, expect the number of ticks
> > to grow with the number of data points added. The average user will also
> > probably want to inspect the graph by panning and zooming before making a
> > printable version.
> We have quite a lot for zooming already. Panning will come soon. But of
> course, we're not done yet. Still a lot can be improved and added. Number of
> ticks is tricky and very many users won't expect the number of ticks to grow
> with the number of data - if I plot couple of values in the x-range 1-10 I
> want to have maybe the ticks for 1, 2, ...10, but if I plot 100k points in
> the range 1-10^6, I don't want to have million of ticks.
> 
> > Finally, _please_ keep in mind that the average user
> > expects things to Just Work. Thanks for all your help.
> Agree. The problem here is that there is no global "average" user. Depending
> on the actual workflows, tasks and scenarios, different users have different
> demands on this kind of software and we need to keep all of them in mind
> when implementing features and going for certain "default values".

I think there's another angle though: the user who needs advanced features will
be smart enough (for lack of a better phrase) to find and enable them. The user
who does not need them may simply be overwhelmed and give up if advanced
formatting features are enabled by default. I can see that LabPlot has smart
features, but it just hasn't yet learned to be smart on the user's behalf. ;)

I think that two design choices mentioned here are kinda related.

- The plot scales down to fit the data, rather than the worksheet expanding to
fit it. This is understandable, since with massive numbers it would be
unrealistic to grow the worksheet to fit the data. (But then it causes ticks to
have non-whole-number labels). However, with panning and zooming, it would not
be so surprising if the user wished to pan and zoom to various parts of the
graph on his own. In this case, having the plot constantly autoscale while
adding 

[LabPlot2] [Bug 389855] Numbers and axes don't line up

[Alexander Semke]

https://bugs.kde.org/show_bug.cgi?id=389855

--- Comment #11 from Alexander Semke  ---
Created attachment 110364
  --> https://bugs.kde.org/attachment.cgi?id=110364=edit
views size

-- 
You are receiving this mail because:
You are watching all bug changes.

[LabPlot2] [Bug 389855] Numbers and axes don't line up

[Alexander Semke]

https://bugs.kde.org/show_bug.cgi?id=389855

--- Comment #12 from Alexander Semke  ---
Created attachment 110365
  --> https://bugs.kde.org/attachment.cgi?id=110365=edit
fixed size

-- 
You are receiving this mail because:
You are watching all bug changes.

[LabPlot2] [Bug 389855] Numbers and axes don't line up

[Alexander Semke]

https://bugs.kde.org/show_bug.cgi?id=389855

--- Comment #10 from Alexander Semke  ---
(In reply to Matthew Trescott from comment #9)
> Fair enough, but that's still really unintuitive behavior.
Agree. But this is still more intuitive than in most other programs that
support multiple axes. You mentioned LoggerPro as an example for a software
with good UX. What is the workflow in this program to create plots like on the
screenshots in the following links?
https://reference.wolfram.com/language/howto/GeneratePlotsWithTwoVerticalScales.html
https://www.originlab.com/doc/Origin-Help/MultiY-Graph
http://www.linuxjournal.com/article/3743?page=0,2
https://de.mathworks.com/help/matlab/creating_plots/graph-with-multiple-x-axes-and-y-axes.html?s_tid=gn_loc_drop


> I'm not convinced that working with live data is really a focus because the
> XY plot looks like a piece of paper. I seriously think that if you gave up
> on making the XY plot have fixed range values, you would be able to avoid
> simplify this.
> Here's my envisionment of the workflow:
> 
> 1. The user enters data into a Spreadsheet.
> 2. The user creates an XY plot which by default is an infinite,
> linearly-scaled plane, then tells LabPlot to plot the data from the
> spreadsheet. The user is able to pan, zoom, edit points, and group-select
> points to analyze. Axes would have infinite ranges and number of ticks as
> well, and automatically decrease tick size when zooming in.
> 3. The user decides to make the data more readable, so he or she disables
> infinite ranges for the axes (which would also make the number of ticks
> constant), applies a theme to the graph, etc.
It looks like a piece of paper because every worksheet has a fixed size on
default. What you're referring here to are, I think, not the _ranges_ of the
data shown in the plot but the _size_ of plot and/or worksheet. I'm attaching
two screenshots making the difference clear. Both plots show the same amount of
data in the same data ranges, namely x=[0,20] and y=[-1,1], for f(x)=sin(x)
with x \in (0,20). In the plot shown in worksheet_fixed_size.png the size of
the worksheet is fixed (10cm x 10cm) and the plot adjusts its size (layout is
active with some values for top, bottom, left and right margins). On the second
screenshot worksheet_view_size.png the same function is plotted but now with
worksheet adjusting it's size to the view size. To get this simply select "view
size" for the size in the worksheet properties. If you resize the sub-window
(change the size or maximize the sub-window), the worksheet and the plots on it
will adjust the sizes accordingly. You can also set all the layout margins to 0
if you need more space for the plot(s) and also play around with the plot area
paddings in the plot properties. You can even show the data in the presenter
mode if you want to further get rid of menu bar and toolbars (main menu bar ->
Worksheet -> show in presenter mode). Once you have your desired settings for
the worksheet and plot (sizes, etc.) you can save them as default values
(template buttons at the bottom of the properties dock widgets for different
objects) - every newly created object will be then created with these
properties.



> So basically, please make the plot more freeform until _after_ the user is
> done analyzing. The average user will, I think, expect the number of ticks
> to grow with the number of data points added. The average user will also
> probably want to inspect the graph by panning and zooming before making a
> printable version.
We have quite a lot for zooming already. Panning will come soon. But of course,
we're not done yet. Still a lot can be improved and added. Number of ticks is
tricky and very many users won't expect the number of ticks to grow with the
number of data - if I plot couple of values in the x-range 1-10 I want to have
maybe the ticks for 1, 2, ...10, but if I plot 100k points in the range 1-10^6,
I don't want to have million of ticks.

> Finally, _please_ keep in mind that the average user
> expects things to Just Work. Thanks for all your help.
Agree. The problem here is that there is no global "average" user. Depending on
the actual workflows, tasks and scenarios, different users have different
demands on this kind of software and we need to keep all of them in mind when
implementing features and going for certain "default values".

-- 
You are receiving this mail because:
You are watching all bug changes.

[LabPlot2] [Bug 389855] Numbers and axes don't line up

[Matthew Trescott]

https://bugs.kde.org/show_bug.cgi?id=389855

--- Comment #9 from Matthew Trescott  ---
(In reply to Alexander Semke from comment #8)
> Ok. I see the reason for the confusion. What you actually want to change are
> the ranges of the plot and not the start and the end values of the axes. For
> this, select the plot and modify the ranges.
> 
> In LabPlot the user can define/have multiple axes. So, you first define the
> ranges of the data to be plotted (or keep it to "auto")  and then start
> adding axes. On default, we create axes with "auto fit" which automatically
> adjust to the plot ranges. But the user can add in addition new axes which
> cover only a certain region with different formatting (labels, number of
> ticks, scaling, etc.). Though being very flexible, this concept is hard to
> grasp for people who have worked with applications only that do not support
> an arbitrary number of axes. So, simply change the plot ranges and you
> should get a behavior you're familiar with.

Fair enough, but that's still really unintuitive behavior. 

> > My impression is that
> > the current design is meant to be used for developing printed reports, so in
> > order to maintain that functionality I suggest relegating it to some sort of
> > "export to print" wizard or something.
> Producing results that are ready to be exported and used in publications is
> one of the main emphasis of the application, yes. The export is done via the
> export dialog. But we also support other workflows like working with live
> data, analysis of imported data (ascii, binary, HDF5, netCDF, FITS), working
> with different computer algebra systems, etc. You can check the recent
> couple of blogs and the release announcements (2.1, 2.2, 2.3 and 2.4
> releases) on our homepage to get some ideas about the feature set of the
> application - https://labplot.kde.org/ .

I'm not convinced that working with live data is really a focus because the XY
plot looks like a piece of paper. I seriously think that if you gave up on
making the XY plot have fixed range values, you would be able to avoid simplify
this. Here's my envisionment of the workflow:

1. The user enters data into a Spreadsheet.
2. The user creates an XY plot which by default is an infinite, linearly-scaled
plane, then tells LabPlot to plot the data from the spreadsheet. The user is
able to pan, zoom, edit points, and group-select points to analyze. Axes would
have infinite ranges and number of ticks as well, and automatically decrease
tick size when zooming in.
3. The user decides to make the data more readable, so he or she disables
infinite ranges for the axes (which would also make the number of ticks
constant), applies a theme to the graph, etc.

So basically, please make the plot more freeform until _after_ the user is done
analyzing. The average user will, I think, expect the number of ticks to grow
with the number of data points added. The average user will also probably want
to inspect the graph by panning and zooming before making a printable version.
Finally, _please_ keep in mind that the average user expects things to Just
Work. Thanks for all your help.

-- 
You are receiving this mail because:
You are watching all bug changes.

[LabPlot2] [Bug 389855] Numbers and axes don't line up

[Alexander Semke]

https://bugs.kde.org/show_bug.cgi?id=389855

--- Comment #8 from Alexander Semke  ---
(In reply to Matthew Trescott from comment #6)
> Yes. The problems start when I try to make a plot with ranges x=[0,2] and
> y=[0,2]. At first, the lowest tick is 1.2 on both axes. When hovering over
> the axes and using the mouse wheel, I can scale down the axes so that I can
> see all the ticks from 0 to 2, but then the axes become disconnected. I'll
> attach a video that I think explains this better.
Ok. I see the reason for the confusion. What you actually want to change are
the ranges of the plot and not the start and the end values of the axes. For
this, select the plot and modify the ranges.

In LabPlot the user can define/have multiple axes. So, you first define the
ranges of the data to be plotted (or keep it to "auto")  and then start adding
axes. On default, we create axes with "auto fit" which automatically adjust to
the plot ranges. But the user can add in addition new axes which cover only a
certain region with different formatting (labels, number of ticks, scaling,
etc.). Though being very flexible, this concept is hard to grasp for people who
have worked with applications only that do not support an arbitrary number of
axes. So, simply change the plot ranges and you should get a behavior you're
familiar with.


> > Quick-and-easy but still powerful is definitely our goal. We're open for any
> > suggestions.
> 
> In that case, my suggestion is that the plot be an infinite plane that can
> be panned by (for example) holding down the Ctrl key and
> clicking-and-dragging with the middle mouse button.
Panning is on the TODO-list already. We'll add this feature soon. At the moment
we have the different buttons in the plot toolbar for the navigation in the
data only.

> My impression is that
> the current design is meant to be used for developing printed reports, so in
> order to maintain that functionality I suggest relegating it to some sort of
> "export to print" wizard or something.
Producing results that are ready to be exported and used in publications is one
of the main emphasis of the application, yes. The export is done via the export
dialog. But we also support other workflows like working with live data,
analysis of imported data (ascii, binary, HDF5, netCDF, FITS), working with
different computer algebra systems, etc. You can check the recent couple of
blogs and the release announcements (2.1, 2.2, 2.3 and 2.4 releases) on our
homepage to get some ideas about the feature set of the application -
https://labplot.kde.org/ .

The blog
http://krajszgsoc.blogspot.de/2017/07/live-data-features-alive-in-labplot.html
shows some features for plotting of live data.

-- 
You are receiving this mail because:
You are watching all bug changes.

[LabPlot2] [Bug 389855] Numbers and axes don't line up

[Matthew Trescott]

https://bugs.kde.org/show_bug.cgi?id=389855

--- Comment #7 from Matthew Trescott  ---
Created attachment 110362
  --> https://bugs.kde.org/attachment.cgi?id=110362=edit
Video of problem

-- 
You are receiving this mail because:
You are watching all bug changes.

[LabPlot2] [Bug 389855] Numbers and axes don't line up

[Matthew Trescott]

https://bugs.kde.org/show_bug.cgi?id=389855

--- Comment #6 from Matthew Trescott  ---
(In reply to Alexander Semke from comment #5)
> With the new code, if you create a spreadsheet and add some data like 
> 1 1
> 2 2
> and create a plot (context menu in spreadsheet -> plot data -> new plot in a
> new worksheet) you should get a plot with ranges x=[1,2] and y=[1,2]. Is
> this the case for you?

Yes. The problems start when I try to make a plot with ranges x=[0,2] and
y=[0,2]. At first, the lowest tick is 1.2 on both axes. When hovering over the
axes and using the mouse wheel, I can scale down the axes so that I can see all
the ticks from 0 to 2, but then the axes become disconnected. I'll attach a
video that I think explains this better.

> Quick-and-easy but still powerful is definitely our goal. We're open for any
> suggestions.

In that case, my suggestion is that the plot be an infinite plane that can be
panned by (for example) holding down the Ctrl key and clicking-and-dragging
with the middle mouse button. My impression is that the current design is meant
to be used for developing printed reports, so in order to maintain that
functionality I suggest relegating it to some sort of "export to print" wizard
or something.

-- 
You are receiving this mail because:
You are watching all bug changes.

[LabPlot2] [Bug 389855] Numbers and axes don't line up

[Alexander Semke]

https://bugs.kde.org/show_bug.cgi?id=389855

--- Comment #5 from Alexander Semke  ---
(In reply to Matthew Trescott from comment #4)
> I started over with a fresh project file after a git pull and ./compile and
> this is still not fixed, 
With the new code, if you create a spreadsheet and add some data like 
1 1
2 2
and create a plot (context menu in spreadsheet -> plot data -> new plot in a
new worksheet) you should get a plot with ranges x=[1,2] and y=[1,2]. Is this
the case for you?

>but I'm not sure I feel like continuing with this
> bug because it seems that quick-and-easy is not the target use-case. 
Quick-and-easy but still powerful is definitely our goal. We're open for any
suggestions.

> If it's
> any help, I'm comparing LabPlot to Vernier LoggerPro, and LoggerPro (which
> is a commercial product and not even open-source) is currently doing a much
> better job of following the KDE mantra of "simple by default, powerful when
> needed" than LabPlot. Maybe for inspiration you'd like to spin up an Ubuntu
> 14.04 VM and try out Vernier's discontinued Linux version:
> https://www.vernier.com/downloads/logger-pro-linux/

> I wish you the best of luck because I'd really like to see LabPlot be
> successful, but right now I don't see it going in that direction.
There are many different use-cases that need to be covered and it is not always
easy to find an interface fulfilling the different wishes. We consider _all_
user reports (bugs and feature requests). Anything that would help to bring
LabPlot into the right direction, here right meaning suitable for different
scenarios, is welcome.

-- 
You are receiving this mail because:
You are watching all bug changes.

[LabPlot2] [Bug 389855] Numbers and axes don't line up

[Matthew Trescott]

https://bugs.kde.org/show_bug.cgi?id=389855

Matthew Trescott  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|FIXED   |---

--- Comment #4 from Matthew Trescott  ---
I started over with a fresh project file after a git pull and ./compile and
this is still not fixed, but I'm not sure I feel like continuing with this bug
because it seems that quick-and-easy is not the target use-case. If it's any
help, I'm comparing LabPlot to Vernier LoggerPro, and LoggerPro (which is a
commercial product and not even open-source) is currently doing a much better
job of following the KDE mantra of "simple by default, powerful when needed"
than LabPlot. Maybe for inspiration you'd like to spin up an Ubuntu 14.04 VM
and try out Vernier's discontinued Linux version:
https://www.vernier.com/downloads/logger-pro-linux/

I wish you the best of luck because I'd really like to see LabPlot be
successful, but right now I don't see it going in that direction.

-- 
You are receiving this mail because:
You are watching all bug changes.

[LabPlot2] [Bug 389855] Numbers and axes don't line up

[Alexander Semke]

https://bugs.kde.org/show_bug.cgi?id=389855

--- Comment #3 from Alexander Semke  ---
(In reply to Matthew Trescott from comment #0)
> * The Cartesian Plot skips number 3 on X axis and 4 on the Y axis
> * The graph makes the Y axis start at 1 instead of zero.
> * The plotted points don't line up with the numbers on the axes on either
> axis.
The problem here is because of the offset we add for the plot ranges. When
plotting bigger data sets it is sometimes useful if you don't plot the data set
exactly up to the plot boundaries but leave some space in between. In your
example the plot range for x was not from 0 to 6 but from -0.3 to 6.3. I
removed this offset now since it can lead to confusing results as you
demonstrated with this example. 

The second problem here is that we show 6 axis ticks on default and set the
precision to 0. So, we don't show in this case any decimals - again, this logic
is useful when plotting bigger data sets with big ranges. We need to come up
here with a better logic so the initial plot is already quite good.

To fix your plot in the attached project, compile the current code, open the
project and click on the auto scale button in the toolbar - the ranges will be
set to 0-6 for x and to 1-7 for y. Change the number of ticks for the x-axis to
7 to obtain the desired result. In addition you can also change the precision
of the tick labels to 1 if it's required.

-- 
You are receiving this mail because:
You are watching all bug changes.

[LabPlot2] [Bug 389855] Numbers and axes don't line up

[Alexander Semke]

https://bugs.kde.org/show_bug.cgi?id=389855

Alexander Semke  changed:

   What|Removed |Added

   Version Fixed In||2.5
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
  Latest Commit||https://commits.kde.org/lab
   ||plot/624658f46d443e979b15ae
   ||139068cbf5b8ba9026

--- Comment #2 from Alexander Semke  ---
Git commit 624658f46d443e979b15ae139068cbf5b8ba9026 by Alexander Semke.
Committed on 04/02/2018 at 18:11.
Pushed by asemke into branch 'master'.

Set the auto scale offset for plot ranges to 0 since it can lead to confusing
results.
We'll re-enable this offset once we have an option for this in the UI.
FIXED-IN: 2.5

M  +2-3src/backend/worksheet/plots/cartesian/CartesianPlot.cpp

https://commits.kde.org/labplot/624658f46d443e979b15ae139068cbf5b8ba9026

-- 
You are receiving this mail because:
You are watching all bug changes.

[LabPlot2] [Bug 389855] Numbers and axes don't line up

[Matthew Trescott]

https://bugs.kde.org/show_bug.cgi?id=389855

--- Comment #1 from Matthew Trescott  ---
Created attachment 110326
  --> https://bugs.kde.org/attachment.cgi?id=110326=edit
Project file exhibiting the problem

-- 
You are receiving this mail because:
You are watching all bug changes.