Prev: How to have access to all tcl procs and vars in a given interpreter
Next: Question about ttk_checkbutton widget
From: Alexandre Ferrieux on 7 May 2010 13:28
On May 7, 7:07 pm, Jeff Godfrey <jeff_godf...(a)pobox.com> wrote:
> On 5/7/2010 11:54 AM, Alexandre Ferrieux wrote:
>
> > On May 7, 6:22 pm, Jeff Godfrey<jeff_godf...(a)pobox.com>  wrote:
> >> Thanks for any input.
>
> > Off the top of my head, utterly untested: what about, instead of [.c
> > find withtag current], using (a loop of) [.c closest $x $y 0
> > $previous] ? The idea of $previous is that it allows you to go beyond
> > the closest (which most likely is the current).
>
> > Moreover, you can use this only when the 'current' tag yields a text
> > item, so the perf hit should be reasonable.
>
> Alex,
>
> I looked into using [.c closest] before posting, and though I haven't
> tried it, I didn't see a way to make it useful.
>
> According to the docs, when multiple matches are within the halo range,
> it returns the topmost item.  From there, I can step through the other
> matches (which I think is what you're suggesting), though I don't really
> know which one the User is after.  Well, I do, they want the one they're
> *visually* closest to, but I don't see a way to get that info using
> "closest".  I suppose I could take the list of matches and go about
> determining the closest one myself (from my DB data), but that seems messy.
>
> Am I missing something in your suggestion?

Sorry, my description was sketchy. I meant:

(1) generate an invisible (filled and bordered with the canvas' bg)
rectangle (or polygon for rotated text) of the proper size for each of
your text items. Put it way behind everything else so that its opacity
doesn't have any visual effect (opacity is necessary for proximity
operators to work in the middle). If the text is supposed to have an
opaque background, put the clipped rect/poly just behind. Keep an
external mapping by id from the rect to the text.

(2) iterate over the [closest], to find the first non-text item.

(3a) if it is a clipped rect, use the map and return the
corresponding text item

(3b) otherwise, just return that item

Now I realize that additional checks are due to decide whether it is
"close enough". Granted. Sigh...

-Alex
From: Jeff Godfrey on 7 May 2010 14:00
On 5/7/2010 12:28 PM, Alexandre Ferrieux wrote:

> Sorry, my description was sketchy. I meant:
>
> (1) generate an invisible (filled and bordered with the canvas' bg)
> rectangle (or polygon for rotated text) of the proper size for each of
> your text items.


Alex,

Thanks for the further explanation - this makes sense now, though...

Guh. More geometry to manage. Currently, as the view is scaled for
zooming, I manually resize the (named) fonts to approximately what they
should be based on the current zoom scale. I say approximately, as the
font dimensions must be provided as INT values, which definitely leaves
room for error at certain scales. I'd be concerned that unless I
manually manage the size of the proxy rectangles, the error would lead
to the visible text not matching the size of its proxy. If that's the
case, there's yet another iterative pass I'd need to make after each
scale change...

Originally, instead of using actual text, I manually rendered each
character (just using lines). This had some major advantages, as the
rotation and scaling of the pseudo-text just happened naturally, along
with the rest of the canvas items. The reason I'm trying to get away
from it (and use *real* text), is that it added quite a bit of
additional geometry to the canvas when viewing text-heavy data sets.
Since I'm already pushing the limits there, less geometry is better.

While I'm reasonably happy with my current real text implementation
(with regard to rotation, scaling, and visibility), it does have a few
drawbacks, with this selection thing just being the latest one.

I may need to rethink whether using real text is the right direction
after all, or whether I should go back to rendering it on my own via
line segments

Anyway, thanks for what sounds like a viable work-around for the current
issue. Unfortunately, the use of real text in this app seems to be
littered with work-arounds, all of which are quickly adding up.

Jeff



From: Donald Arseneau on 7 May 2010 16:26
On May 7, 10:16 am, Jeff Godfrey <jeff_godf...(a)pobox.com> wrote:
> I'm familiar with the info provided by [font metrics].  In fact, I'm
> currently using it to a limited extent in order to calculate the proper
> offsets to go from a sw anchor to a w anchor (as noted previously).  You
> mention that I could make adjustments if necessary, though I don't know
> what I can adjust that'll impact the current issue.  That is, I can tell
> how much extra space is included above and below a font, but what can I
> do about it that would improve the canvas selection issue?

I don't think you can clip the bounding box of the text itself, but
you could use the information to construct the proper sized rectangle
(polygon) to be used for "closest" detection (as per above).

I don't expect this is useful, but I'll mention it anyway: you can
make an image out of any text and use that to detect where the "ink"
is.

Donald Arseneau
From: Alexandre Ferrieux on 7 May 2010 17:06
On May 7, 10:26 pm, Donald Arseneau <a...(a)triumf.ca> wrote:
>
> I don't expect this is useful, but I'll mention it anyway: you can
> make an image out of any text and use that to detect where the "ink"
> is.

I'm interested; how do you do that ?

I know about the 'window' image format from the Img package, but
unfortunately it works only by grabbing the really displayed pixels,
not off-screen. So it must fit on the screen, must not be obscured by
another toplevel, must not be in a window that's been moved beyond a
screen border, etc. I'd love to know a more robust offscreen rendering
technique.

-Alex
From: Arndt Roger Schneider on 8 May 2010 05:09
Alexandre Ferrieux schrieb:

>On May 7, 10:26 pm, Donald Arseneau <a...(a)triumf.ca> wrote:
>
>
>>I don't expect this is useful, but I'll mention it anyway: you can
>>make an image out of any text and use that to detect where the "ink"
>>is.
>>
>>
>
>I'm interested; how do you do that ?
>
>I know about the 'window' image format from the Img package, but
>unfortunately it works only by grabbing the really displayed pixels,
>not off-screen. So it must fit on the screen, must not be obscured by
>another toplevel, must not be in a window that's been moved beyond a
>screen border, etc. I'd love to know a more robust offscreen rendering
>technique.
>
>-Alex
>
>
1. surface from tkpath 0.3
2. pixane
3. ImageMagick


There is another complicated and wired way:
To create a xml-fo definition for the text segment,
send it through a fo-processor, like fop, generating
an svg and importing the svg into a canvas window...

it _would_ be possible to aproximate the resulting
svg path definition into a series of Tk canvas polygons.

The generated path definition is constituted by
cubic bezier segments (in reality most fonts use quadratic bezier
segements),
it's possible to render
such elements as polygons by using the anchor points of the
bezier segments with the smooth property.


Jeff: I've followed your numerous postings on Tk canvas.
The Tk canvas is not suiteable for what you try to achieve.

-roger




First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: How to have access to all tcl procs and vars in a given interpreter
Next: Question about ttk_checkbutton widget