GSoC 2019 Project [ Rubyplot ] discussion

[RUBYPLOT-GSOC][DAILY][7 June] Implementing different types of markers

Planned progress
Adding different types of markers


  • Had a weekly meeting with @v0dro to give updates and discussed some design decisions
  • Implemented a hash with lambdas for different types of markers
  • removed return from scale_figure and unscale_figure
  • added modify_draw function which modifies a draw object (or an array of draw objects) when required only for executing a block i.e. the object is modified and then after execution of the blog, the object is returned to its original state.
  • Scaling, rotation and translation is allowed in modify_draw


  • Implementing hash with lambdas is better than making a big method but the hash will still be very big and is the best option considering the number of different types of markers (around 35)(other options are creating helper functions or creating a module )
  • Shifting set_background_gradient is to be done
  • modify_draw function will be a little tough to understand for new developers but is a good design decision considering scalability.


  • Completing the blogs
  • Implementing different types of markers

[RUBYPLOT-GSOC][DAILY][8 June] Implementing different types of markers (Too much geometry)

Planned progress
Adding different types of markers


  • Added the marker types plus, dot, diagonal_cross, solid_circle, traingle_down, solid_traingle_down, traingle_up, solid_traingle_up, square, solid_square, bowtie, solid_bowtie, hglass, solid_hglass, diamond, solid_diamond, solid_tri_right, solid_tri_left, hollow_plus, solid_plus, vline, hline, omark


  • The hash for marker types is too big but is important.
  • The remaining marker types involve too much coordinate geometry, I have asked for suggestions in the ImageMagick discourse. If nothing else is possible I will implement it using geometry (by plotting multiple lines by giving points as inputs calculated relative to x and y coordinate of the marker)
  • Remaining marker types are star, solid_star, asterisk, tri_up_down, pentagon, hexagon, heptagon, octagon, star_4, star_5, star_6, star_7, star_8.


  • Completing the blogs
  • Implementing the remaining marker types
  • Checking area plot

[RUBYPLOT-GSOC][DAILY][9 June] The Area Plot

Planned progress
Checking the area plot


  • Corrected the draw_polygon function
  • Found a major bug in area plot frontend and found a way to correct it
  • Did a minor correction in draw_text -> not draw anything when the text is not given
  • Improved the blogs
  • Checked multiple subplots for Magick backend and they’re working (tested through a 2x2 grid with all the plots being scatter plots) (I have not tested rspec tests as they have candle-stick plots which have not yet been checked for Magick backend)


The bugs

  • Area plot bug: The data should not be sorted and the data given should be the y coordinates and the x coordinates should be 0 to data.size, I corrected this in this commit, link:
  • Although I corrected the bug, the delta for the area plot test is around 4500 and hence the test is not being passed Magick backend, it passes for GR backend. The plot for the test looks correct but the test is not passed. Here are the images for Magick and GR backend for an area plot for the data [25, 36, 86, 39, 25, 31, 79, 88] (corresponding to the rspec test):



The plots before the correction were (for data and test same as above):



  • The GR backend does not implement opacity
  • If texts are not given to draw_text function in GR backend then garbage value is printed (I fixed this magick backend by adding a simple condition that execute the code in the draw_text function only when text is given i.e. added

unless text.empty?


  • In scatter plot, the marker_fill_color has no default value and it gives an error if it is not set.
  • Should the square in the legend box describing the colour of the data have a border?(preferably black) as if I set the fill colour to white, the square is not visible as the background in Magick backend is white
  • While plotting multiple subplots, if a subplots is below another subplot then the x axis title of the upper subplot and title of the lower subplot overlap
  • Does x_axis.rb need

require_relative ‘base’

as it already inherits the base?

  • The constructor of x_axis.rb is

def initialize axes

and that of y_axis.rb is

def initialize(*)

and their parent class has

def initialize axes

So, I think that the syntax for y_axis should be changed to avoid confusion

  • The default title for X axis and Y axis is no text, would ‘X axis’ and ‘Y axis’ as the title by default be better?
  • in GR backend, in scatter plot the markers are drawn behind the X and Y axes, should it be in front of the axes? (If yes, can it be done?)

In decreasing priority:

  • Complete the blogs
  • Check bar plot
  • Submitting a proposal for Rubyconf Colombia
  • Correct area plot
  • Implement different types of markers
  • Implement ticks
  • shift set_background_gradient to backend
  • Other small bugs/improvements

Good job so far. Can you get all your work to a mergeable state so that I can merge your PR into master by the time you go on leave to get your visa? That way we will have a good way to gauge progress w.r.t the rest of the library when I work on the GR part and help us sync our work better.

I’ll start reviewing your already open PR so that you can make changes accordingly. Also, I need to see your blog ASAP. Its been delayed already.

Here’s replies to the problems you pointed out:

Area plot bug: The data should not be sorted

Works. Shouldn’t have sorted it in the first place.

Although I corrected the bug, the delta for the area plot test is around 4500

I suspect its because of the opacity that the comparison between the pixels goes wrong. Might there be a way around it?

GR backend does not implement opacity

I’ve opened an issue on this and will tackle the issue soon.

I’ve pushed a change:

This happens in GR or Magick?

The require statement loads the file that contains the Base class which Axes inherits from.

Will fix. Thanks.

Hmmm works. That would be a good addition. Can you open an issue for this so that I can implement in the GR backend as well?


I’m sure whether it can done. Maybe can try plotting the axes after plotting the elements within the plot. Anyway the need for this will be mitigated if we take 5% extra distance on each of the axes.

Thanks! I will be leaving for the Intel summit on 13th (and will be unavailable till 16th), I haven’t got the appointment date for my visa yet as I have not applied for it due to some delayed paperwork (I will let you know the dates as soon as I get it)

The PR is mergeable you can review it and merge it (the only temporary change is set_background_gradient function which I will look into later)

I tested it right now and it is not because of the opacity, infact setting the opacity to 1 increases the delata to around 16k


Happens in Magick for sure, will test in GR


I will make this change in the frontend

Yes, the 5% distance will correct this bug

[RUBYPLOT-GSOC][DAILY][10 June] The Blogs

Planned progress
Checking bar plot


  • Optimized draw_rectangle function
  • Passed the test for bar plot
  • added default X-axis title and Y-axis title
  • Improved the blogs


  • The legend box is missing in the bar plot
  • The blog is very big and will take one more day to complete


  • Complete the remaining work
  • Complete the blogs
  • Check bubble plot

[RUBYPLOT-GSOC][DAILY][11 June] The Blog

Planned progress
Check bubble plot



  • I have already explained all the functions which I implemented in The scatter plot example blog, I will make a separate blog and explain the functions again so that my progress is shown.
  • Various test in the bar plot, area plot and bubble plot fail because of the delta being too much but the plots look fine. The deltas are highly dependent on the colour used in the plots and some tests pass for light colours like yellow or white but fail for dark colours like green or black. @v0dro any idea why this might be happening? and any suggestions to improve this?
  • Should bubbles in bubble plot have a little less opacity so that if bubbles overlap, the visibility is more?
  • If no label is given to the plot then the GR backend draws incorrect text (It should draw nothing). Maybe this will fix if the condition of the empty string given is solved as discussed previously.


  • Checking the candle-stick plot
  • Writing the next blog
  • Completing the remaining work

[RUBYPLOT-GSOC][DAILY][12 June] Resuming plots

Planned progress
Check candle stick plot


  • Added draw_lines function (which currently uses ployline and is not using draw_line function)
  • Passed the tests for candle-stick plot
  • Currently the plots for the simple candle stick test for both backends:




  • I will write the next blog specifically for my contributions by next week
  • draw_lines function will be changed so that it is dependent on draw_line as ployline function will create problems if used for more than 2 points

Checking histogram (from 17th July)

I have been invited to an Intel summit held at Bangalore as I am an Intel student ambassador. I will be attending the summit from 13th-16th June and will resume the work from 17th June.
Sorry for the unavailability.

I like the details in your blog post. However in its current form its quite difficult to read because you’re diving directly into very deep technical details.

Can you add an ‘introduction’ paragraph that will serve as an overall introduction to the entire blog post? You can a table contents too and refer to that in your introduction. Something on the lines of ‘I have written so and so features and you can find this detail here and that detail there’. Like the introductory chapter of a reference book.

Can’t really say. Maybe we can try reading the images using some library that is not Magick?


That’s a bug and should be fixed.

@AlishDipani how’s your progress regarding the X and Y ticks?

Here’s some more feedback regarding the blog post:

As an example, in the Setting Output Device part of the post, you’ve a detailed explanation of the function of each within the method init_output_device. But what is missing here is the ‘purpose’ of each line. I can see that you’re creating three Magick::Draw objects. But WHY create three objects? What were the underlying design decisions that lead to creation of three objects instead of just one? These things are much more interesting to someone reading your post to get a technical overview. They also serve as guidelines later when a developer is wondering about the purpose of the code.

Another example is that we do not use the MATLAB notation for creating subplots (which is used by matplotlib). Would be great if you can write the reasons for that too.

Also explain why you do the text rotation in Magick the way you do.
Please make such updates to your post before moving on to the next one.

Yes, I’ll look into it.

Is opacity 0.7 fine?
Also, to do this we will have to use the draw_circle function instead of draw_markers as it does not support opacity.

I was unavailable and could not work on this, I will look into this soon

I will make these changes soon (surely by Saturday)