Gustavo Sverzut Barbieri wrote:
> Hi,
>
> Just identified that
>
> part {
> name: "text";
> type: TEXT;
> description {
> state: "default" 0.0;
> rel2 {
> relative: 0.0 1.0;
> offset: 118 -1;
> }
> text {
> font: "Vera Sans:style=Bold";
> size: 20;
> text: "Some text";
> }
> }
>
> will cause Edje to mis calculate and return an empty string as result.
> Increasing or decreasing it by one pixel in width will make it "work"
> again, so it's a bit tricky to found in real world applications (but
> we did).
>
> But trickier than finding this is to get the logic of
> _edje_text_fit_x()... maybe someone else is more familiar with it and
> can provide some insight? If not then I'll dig into it later.
> BTW, why these kind of constructions are not provided by Evas?
> Evas should provide these high level utilities, like how many of some
> given text will fit in given width, height or both (these last 2 in in
> case of textblock). Also, since adding ellipses are a common case, we
> could add it as well. Maybe we could also use this to speed up these
> calcs, since calling all those Evas functions from inside Edje can be
> a bit a hit in performance :-/
I hit a similar problem a while ago, and tried to fix it. The problem
was that when you use shadows etc. the size evas reports for the string
isn't the same size that evas uses for the resulting evas object. This
might be a similar thing.
I agree, more of the logic should be moved to evas as it isn't to easy
to grok what object size a text string will result in.
Sebastian
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
