Re: units conversion (was: about contibuting to octave)

[Shai Ayal]

On Fri, Mar 13, 2009 at 9:57 PM, John Swensen <address@hidden> wrote:
>
> On Mar 12, 2009, at 7:11 AM, Ben Abbott wrote:
>
>>
>> On Mar 12, 2009, at 6:13 PM, Michael Goffioul wrote:
>>
>>> There exist already some code to convert from different "units".
>>> See for instance the convert_position function in graphics.cc used
>>> to convert position rectangles between various possible "units".
>>>
>>> Some extension is needed to be able to handle single point instead
>>> of rectangle and also to support data "units". However, the axes object
>>> provides an easy access to the current transformation matrix, so it
>>> shouldn't be that hard.  ... (snip)
>>
>> Regarding units conversion, should we write a single function that handles
>> this job for all objects with a "units" property?
>>
>> If we do that, it appears to me that we only need to write a single
>> listener to handle to handle the conversion for all objects with "units"
>> properties.
>>
>> Actually, given how addlistener works, it should be possible to write a
>> singled listener for everything (at least to have a single function name
>> whose actions depends on the object "type" and the property changed).
>>
>> For example, if the listener function is called "update_property", and
>> takes the following inputs ...
>>
>>        update_property (h, dummy_arg, property_that_changed,
>> old_property_value)
>>
>> The listeners for conversion of an object's units would be ...
>>
>>        addlistener (h, "units", address@hidden, "units", get (gca,
>> "units")})
>>
>> The listener function would then have access to the new and old units as
>> well as the old value.
>>
>> The listener for objects with a "rotation" property ...
>>
>>        addlistener (h, "rotation", address@hidden, "rotation"})
>>
>> In this case the old value isn't needed.
>>
>> The same approach can be used for objects with the "position" property.
>>
>>        addlistener (h, "position", address@hidden, "position"})
>>
>> One advantage of a unified listener is that it is easy to disable
>> recursion. For example, changing "units" changes the "position" property,
>> but need not trigger a new rendering.
>>
>> I think this approach can handle all cases and sets a consistent standard
>> that would make maintenance easier.
>>
>> I'm thinking about this from the perspective of m-file implementation.
>> However, as several properties are read-only, this would need to be
>> implemented in c++. So, I may be off base in my approach.
>>
>> Comments?
>>
>> Ben
>>
>>
>
> I apologize for getting into this conversation kindof late in the ballgame,
> but want to clarify a few things.  I have included a bit of code I wrote a
> while back to render latex strings to a GDKPixbuf using the poppler library
> (we can also use a GDK/GTK free portion of poppler called libSplash, but the
> GDK solution was easier since there were a lot of examples).  When I first
> wrote this, I was trying to render it in the OpenGL backend, but was having
> issues with sizes.  Are you saying that the handle graphics system now
> implements properties that tell how big this pixel buffer/OpenGL texture
> should be?
>

Your code, if I understand correctly, uses pdfLaTeX to render the
string. While this seems the ultimate solution (pdfLaTeX is a very
good LaTeX renderer), it poses a bit of a problem in the context of
the whole octave/backend paradigm:
1 If we put this code in the backend, than octave cannot compute text extents.
2 If we put this code in octave, than we have rendering in octave --
i.e. octave will produce bitmaps

maybe we should just go with the second choice and let octave produce
bitmaps for text objects with renderer=LaTeX

Another choice could be to split the text renderer from the general
renderer, so we would have 2 types of backends: a graphics backend and
a text backend, where the text backend would produce extents for
octave and bitmaps for the graphics backend

Shai