[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new snapshot?
From: |
Ben Abbott |
Subject: |
Re: new snapshot? |
Date: |
Thu, 25 Feb 2010 15:14:43 -0500 |
On Thursday, February 25, 2010, at 02:33PM, "Shai Ayal" <address@hidden> wrote:
>On Thu, Feb 18, 2010 at 2:43 PM, Ben Abbott <address@hidden> wrote:
>>
>> On Feb 18, 2010, at 6:37 AM, Jaroslav Hajek wrote:
>>
>> > hi all,
>> >
>> > it's been 5 months and almost 700 changesets since 3.3.50. What about
>> > a new snapshot now?
>> > Regarding 3.4.0, I'd like to still try to address at least these two
>> > projects:
>> >
>> > 1. merge the MArray classes
>> > 2. legends in FLTK backend
>> >
>> > 1 is straightforward, just wants some code manipulation to do. 2 will
>> > probably be a more difficult task.
>> >
>> > Any other projects to be completed prior to 3.4.0?
>>
>> Regarding the legends, current the gnuplot backend uses gnuplot's legend
>> feature. For compatibility the legend should be constructed as an instance
>> of an axes object. What I'm leading up to is that I expect most of the work
>> will be agnostic to the backend, and should work with gnuplot as well.
>>
>> There are (were?) two missing features that I expect would make the job of
>> implementing a compatible legend easier.
>>
>> (1) Method to determine the "extent" property for text objects
>
>The extent property for text objects should be available even if the
>object has not been rendered yet, so we cannot rely on the backend
>setting this property auto-magically (the backend sees new objects for
>the first time only when they are rendered).
>
>What I've come up with is two ways to determine the extent property:
>1. add some a method to the backend class to get the extent of a text
>object from the backend (this has to be done independent of whether
>the text object has been rendered)
>2. add extent calculations into core octave (making octave depend on
>e.g. freetype)
>
>In both cases, I don't see how this can be done with gnuplot. Does
>anyone have any idea? Did I miss anything?
>
>Shai
For gnuplot, it may be sufficient to make some approximations/estimations
representing some common font(s). Most of the time errors in the length of a
text object may be covered up by appropriate justification of the object
{"left", "center", "right"}. There are some instances this approach will be
expected to produce visible errors. Two that are obvious to me are; (1)
legends, where the box/axes must matched to the length of the text labels, (2)
y-axis labels must be shifted left/right to make room for the ticklabels.
Coincidently, those two come to my mind because I often seen problems with how
they are rendered in Matlab.
In any event, regarding your #2 above, do I infer correctly that this approach
could be implemented independent of the backend? If so, since gnuplot depends
upon freetype as well, is there a reason why such an implementation would not
work for both gnuplot and fltk ... of course, gnuplot would have to be
restricted to using only freetype fonts.
Ben
- Re: new snapshot?, (continued)
- Re: new snapshot?, Michael D. Godfrey, 2010/02/26
- Re: new snapshot?, John W. Eaton, 2010/02/26
- Re: new snapshot?, Michael D. Godfrey, 2010/02/26
- Re: new snapshot?, Michael D. Godfrey, 2010/02/26
- Re: new snapshot?, Michael D. Godfrey, 2010/02/26
- Re: new snapshot?, David Bateman, 2010/02/28
- Re: new snapshot?, Michael D. Godfrey, 2010/02/28
Re: new snapshot?, Benjamin Lindner, 2010/02/18
R: new snapshot?, Marco Atzeri, 2010/02/26
Re: new snapshot?,
Ben Abbott <=