Tuesday, July 30, 2013

Mid - term

And here it is, mid-term evaluation period is already open. And it seems like yesterday, we begin working on our projects. From last post, there explaining how the class text_render look, I was implementing it to existing code.

 Here is a final result , proof of concept latex interpreter. As you can see, it need to be upgraded.


Here's part of Octave code producing this plot.

graphics_toolkit('fltk');
x=0:0.1:10;
plot(x,sqrt(x));
title('Plot with LaTeX','fontsize',28);
ylabel('y=\sqrt(x)',interpreter','latex');

For now I will point only the main points that should be in next upgrade:
- it should have transparent background
- quality of image should be higher
- image should be smaller

   Transparent background 
Problem with current revision is that it use PPM format for transferring data to pixels member of any render class. It's handy, because Octave can directly open this file. Read image width and height, and then just read data stored in every pixel ( red, green and blue component ). But it has one big defect , alpha channel is missing. So there have to be another format or some kind of trick to get around this shortage of information.

   Antialiasing 
Current image is rendered form EPS file at 600 dpi. The idea is to render larger image and then scale it to fit original image at Octave plot. With this trick, rendered LaTeX image will be smoother. With better smooth there's better image quality. ( Note: Rendered image in plot presented here is rendered at 300 dpi to produce smaller image. )

   Image size
After placing image on plot is obvious that it's too big. It should be smaller to fit with other text on plot. As mentioned before we want smaller image then rendered, but with better smoothing so it will be pushed into smaller size to get this result.



Thursday, July 18, 2013

Implementation

Octave use freetype library to render text for OpenGL. Trough ft_render class, string is rendered depending on font size, color an other parameters.
Every text object has interpreter parameter, which is by default set to 'tex'. Although Octave has only limited set of tex functionality implemented. All this is going trough ft_render class, and as a result we have information about text in 8NDArray, which is then used by OpenGL for rendering of rasterized image.

When upgrading existing system, programmer have to save already existing functionality and add a new one. To add latex markup, there have to be class for it. And normally some dispatch mechanism on top, which can pick what type of render will be used. Solution to this problem came with abstract class and dispatch mechanism inside wrapper. So here is new class organisation.

text_render present top wrapper class, and inside it there is a dispatch mechanism pointing to one of three classes for text rendering. It also handles memory and use base_text_render class to create and destroy objects, with rep pointer.

base_text_render is abstract class used as parent class to text rendering classes. It has base virtual methods, named base methods on image presented above this text.

ft_render is existing class, using freetype to render text. It inherit base methods and has additional methods.  Additional methods computes bounding box, rotate image, change mode of rendering and get extent.

dummy_render class is empty. Is integrated to this concept because we can use latex if there are additional programs needed for this system. And renderer used by default is useless without installed freetype library. So to get around null rep pointer, this class will be picked and it will be just have some method to print error and help users install freetype or/and latex.

latex_render present implemented functions already developed in C. They are modified to use C++ libraries and to work as methods inside this class.
 - adapter method - put get input string and then create TEX file for further use.
 - render method - use Latex system and GhostScript as described in earlier post. As final result there is bitmap image. But OpenGL renderer needs 8NDArray, so this part is not finished.
 -  get_bbox method - open EPS file and read bounding box data, which is then transformed to true values

NOTE: Octave community use interesting concept for memory management. There are some abstract class and then wrapper on top. When someone create object it's not handled directly in further code but rep pointers are used. Here is one example liboctave/util/


...
class octave_mutex;
class
octave_base_mutex
{
public:
friend class octave_mutex; 
octave_base_mutex (void) : count (1) { } 
virtual ~octave_base_mutex (void) { } 
virtual void lock (void); 
virtual void unlock (void); 
virtual bool try_lock (void); 
private:
octave_refcount <int>; count;
};
class
OCTAVE_API
octave_mutex
{
public:
octave_mutex (void); 
octave_mutex (const octave_mutex&; m)
: rep (m.rep)
{
rep->count++;
}
~octave_mutex (void)
{
if (--rep->count == 0)
delete rep;
}
octave_mutex& operator = (const octave_mutex& m)
{
if (rep != m.rep)
{
if (--rep->count == 0)
delete rep;
rep = m.rep;
rep->count++;
}
return *this;
}
void lock (void)
{
rep->lock ();
} 
void unlock (void)
{
rep->unlock ();
}
bool try_lock (void)
{
return rep->try_lock ();
} 
protected:
octave_base_mutex *rep;
};
...

Wednesday, July 3, 2013

Form string to image

As you might notice, good part of my project presents converting string with LaTeX markup into bitmap image. As this can't be done directly form string we use some additional programs. Here is little sketch, focusing on how this part is working together. 
----------------------------------------------------------------------------------------------------------------------------------
string --> Adapter --> .tex --> LaTeX system --> .dvi --> dvips --> .eps --> Ghostscript --> .png                                                                                                      +--> bounding box                                     
----------------------------------------------------------------------------------------------------------------------------------

Adapter is transferring string with integrated markup to LaTeX file, with everything set for further use. File is predefined within code, Adapter just adds string into right place. Working further and additional testing will invoke changing of how exactly this code works but for now it's working great. 

LaTeX system isn't part of Octave. So it needs to be additionally installed on platform. It takes a file with structured markup code and convert it to device independent file format. 

dvips program can convert this file into encapsulated post script. It does this to get vector image and for boundary box (part of this file is line with coordinates of boundary box). 

Ghostscript is part of Octave installation. It takes previous file and convert it to bitmap image. We as user can control image quality with resolution. 

Bitmap image and boundary box will be used in next few steps for adding image to OpenGL buffer. This micro system is tested with all kinds of formula markup and for now everything is working okay. With every new step in development, there will be additional testing. There will be added code for controlling image quality, depending of size on plot and fontsize (LaTeX support only 10/11/12 point size of font directly). 

New timeline


When someone send application to GSoC, part of this application is proposed timeline. I wrote timeline proposal, thinking about how can this project be split into parts. Then I just arranged this parts according to their among dependence. Original timeline can be found here .

After intro task, I started working on main priority, adding LaTeX markup to Octave. This markup will be new functionality. When interpreter value of text box on some plot is set to "LaTeX", it should be rendered using LaTeX system and then added on plot trough OpenGL rendering. There is a need to redefine timeline. This need arose because different concept of project, than I've imagined. And because I spend sometime to intro task, that should ( it was expected ) be done during bounding period.

TIMELINE  << LaTeX markup project >>

Week 1 - (17.06 ÷ 23.06) - Preparation and intro task
This week was consumed for preparation. Preparation consisted
of reading the code. Installing all program necessary for development.
And work on intro task has started.

Week 2 - (24.06 ÷ 30.06) - Intro task and additional depencies
As it turned this intro task - adding lineheight property to text objects
on plots. After finishing this task, patch was made and added to patch
GNU Octave patch manager. Using additional programs parts of LaTeX
system and Ghostscript, markup code was successfully converter to
.eps file and then to .png file, manually.

Week 3 - (01.07 ÷ 03.07) - Adapter for LaTeX system
Adapter for transferring LaTeX markup is working. Additional code
that call dvips and Ghostscript is working too. It does this using system
function in C. Adapter and additional code are connected and tested
using this source for examples of formulas.

Week 4/5 - (08.07 ÷ 19.07) - Image quality and implementing code
Now when there is micro system for transferring markup and converting
markup code to bitmap image ready, it should be implemented directly into
Octave code. Questions are where and how exactly. Another thing to look after
is quality of bitmap images. Characters on image should be smooth, no matter
what size they are on final plot.

Week 6 - (22.07 ÷ 29.07) - Passing image to OpenGL and testing
Final image have to be placed to OpenGL buffer for further rendering. This will be done
modifying text::properties::update_text_extend and similar methods. After this part is
finished it should be tested and if needed upgrading code for better performance.

Mid - term evaluations (30.07 ÷ 01.08) 

Until mid - term there should be, as my mentor calls it proof-of-concept. After that it should be only upgraded. First thing is supporting LaTeX markup for printing formats. After that everything will be tested on Windows and OS X platforms. Every problem with other
platforms solved. And in end code should be configured. As example if there is something missing, we cant use LaTeX markup.