about contibuting to octave

[Ben Abbott]

On Mar 3, 2009, at 2:22 AM, xianghang liu wrote:

> On Tue, Mar 3, 2009 at 2:13 PM, Ben Abbott <bpabbott at mac.com> wrote:
> - Show quoted text -
>
> On Mar 3, 2009, at 12:44 AM, Shai Ayal wrote:
>
> On Tue, Mar 3, 2009 at 7:17 AM, xianghang liu  
> <xianghangliu at gmail.com> wrote:
> Yes, I think I am interested in this. Would you please tell me how  
> to start
> and give me more details about this?
> Thanks.
>
> Xianghang
> On Tue, Mar 3, 2009 at 12:33 PM, Shai Ayal <shaiay at gmail.com> wrote:
>
> On Tue, Mar 3, 2009 at 4:36 AM, xianghang liu <xianghangliu at gmail.com>
> wrote:
> Hi,
> I am a C++ developer very interested in Octave and would like to
> contribute.
> I have had a look at projects listed at
> http://www.gnu.org/software/octave/projects.html. I would like to
> contribute
> numerical  and IO related projects in the list. Would you please  
> show me
> a
> more current copy of this?
> Hi,
>
> I'm not sure it's what you meant by IO related, but the graphics
> system is really in need of a c++ developer. We need someone to
> implement text objects.
> If this interests you, I'm sure Michael and I could help you start out
>
> Shai
>
>
> Great!
> I'll give you a very brief overview with which you can start, and just
> ask question as you go. It's also better if you ask on the maintainers
> list (or at least cc the list) instead of me directly for 3 reasons:
> 1. someone else might be able to answer better/before me
> 2. someone else will be able to correct me!
> 3. we will have a record of the discussion and changes that everyone  
> can see.
>
> Also, please use bottom posting as it is much easier to read later
>
> The graphics system in octave is made of two parts -
> 1. core graphics, which includes all the parts that are independent of
> the actual graphics implementation and underlaying OS (i.e. the object
> hierarchy,  setting/getting properties and more). Core graphics is
> implemented in the (very large) files:
> graphics.h.in, graphics.cc. graphics.h.in is converted to graphics.h
> by the script genprops.awk. all of these files are in the src
> directory
> 2. backends - these are in charge of the actual rendering and deal
> with the underlaying graphics system. Currently we have 2 backends,
> the gnuplot backend and the fltk backend which uses the
> opengl-renderer.
>
> The text object is very complex (probably why it is left undone) in
> that it is a core graphics object, but also has dependencies on the
> backend: As Ben noted, the text object has an "extent" property which
> should hold the text bounding box. This is dependent on the text and
> font properties. Only the backend knows the font properties, so this
> has to communicated from the backend to the core-graphics system. We
> need to decide how to do this and implement.
> Also there is the whole issue of simple TeX rendering for text.
>
> Shai
>
> Shai,
>
> Regarding the comment "Only the backend knows the font properties",  
> are font properties independent of the backend?
>
> Ben
>
> Thanks for your descriptions. I have get some rough understanding  
> about what we want to do.
> As far as I know, there is a properity called 'Extent' in Matlab  
> text object, which is the range of the text objects and is read- 
> only. I think we would like to implement something similar. To do  
> this we need to add a read-only property 'extent' to class text  
> definded in graphics.h. But this property is only known to backends  
> so we need to communication from the backends to the frontend. Any  
> mistakes?
> And would please tell me in which files backend of the graphics  
> system implemented?
>
> Thanks.
> Xianghang

The fltk backend is primarily in src/fltk_backend.cc

The gnuplot backend is primarily written as m-files. They are in  
scripts/plot (there is a lot of other files having nothing to do with  
gnuplot, in particular, there as well).

Regarding the text object's "extent"s, I've been under the assumption  
that this could/would be handled independent of the backend, and that  
all backends would rely upon a unified solution for calculating the  
extents of a text object.

Am I off in my expectation? ... if so, if anyone has a thought on how  
the extents for the gnuplot backend might be determined, please advise.

Ben