Prev: How to have access to all tcl procs and vars in a given interpreter
Next: Question about ttk_checkbutton widget
From: Jeff Godfrey on 7 May 2010 12:22
Continuing with my canvas viewer project...

I'm noticing a few oddities with large canvas text as it relates to
anchor positions and item selection using the "current" tag. The issues
are due to the fact that the internal "height" of a text string includes
not only the visible text itself, but also some blank space above and
below the characters (likely related to line spacing).

When using *large* fonts (when my app is "zoomed in"), this additional
space above and below the text item can be huge. This causes a number
of issues...

- Setting a "sw" anchor point for the text is wildly inaccurate, as it's
the sw corner of the bounding box, which includes the blank space. For
this reason, I've found it necessary to compensate all of my text
coordinates (which are naturally sw points) in order to use "-anchor w"
instead. This eliminates the offset error, though it's not entirely
trivial to do when using rotated fonts.

- I graphically highlight the "current" item as the mouse is dragged
over the canvas. Again, due to the unusually tall bounding box on large
fonts, I can be *visually* almost on top of, say, a line item, but the
"current" item can be a text string that's 40 pixels above or below the
mouse position. While I know what's going on, it just doesn't "feel"
right from a User perspective.

Is the line spacing info intended to be part of the font values when
doing things like the above? The issue is really fairly minor as long
as the fonts are small, but as they grow, it becomes quite difficult to
deal with.

Thanks for any input.

Jeff
From: Alexandre Ferrieux on 7 May 2010 12:54
On May 7, 6:22 pm, Jeff Godfrey <jeff_godf...(a)pobox.com> wrote:
> Continuing with my canvas viewer project...
>
> I'm noticing a few oddities with large canvas text as it relates to
> anchor positions and item selection using the "current" tag.  The issues
> are due to the fact that the internal "height" of a text string includes
> not only the visible text itself, but also some blank space above and
> below the characters (likely related to line spacing).
>
> When using *large* fonts (when my app is "zoomed in"), this additional
> space above and below the text item can be huge.  This causes a number
> of issues...
>
> - Setting a "sw" anchor point for the text is wildly inaccurate, as it's
> the sw corner of the bounding box, which includes the blank space.  For
> this reason, I've found it necessary to compensate all of my text
> coordinates (which are naturally sw points) in order to use "-anchor w"
> instead.  This eliminates the offset error, though it's not entirely
> trivial to do when using rotated fonts.
>
> - I graphically highlight the "current" item as the mouse is dragged
> over the canvas.  Again, due to the unusually tall bounding box on large
> fonts, I can be *visually* almost on top of, say, a line item, but the
> "current" item can be a text string that's 40 pixels above or below the
> mouse position.  While I know what's going on, it just doesn't "feel"
> right from a User perspective.
>
> Is the line spacing info intended to be part of the font values when
> doing things like the above?  The issue is really fairly minor as long
> as the fonts are small, but as they grow, it becomes quite difficult to
> deal with.
>
> 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
From: Aric Bills on 7 May 2010 12:59
On May 7, 10:22 am, Jeff Godfrey <jeff_godf...(a)pobox.com> wrote:
> Continuing with my canvas viewer project...
>
> I'm noticing a few oddities with large canvas text as it relates to
> anchor positions and item selection using the "current" tag.  The issues
> are due to the fact that the internal "height" of a text string includes
> not only the visible text itself, but also some blank space above and
> below the characters (likely related to line spacing).
>
> When using *large* fonts (when my app is "zoomed in"), this additional
> space above and below the text item can be huge.  This causes a number
> of issues...
>
> - Setting a "sw" anchor point for the text is wildly inaccurate, as it's
> the sw corner of the bounding box, which includes the blank space.  For
> this reason, I've found it necessary to compensate all of my text
> coordinates (which are naturally sw points) in order to use "-anchor w"
> instead.  This eliminates the offset error, though it's not entirely
> trivial to do when using rotated fonts.
>
> - I graphically highlight the "current" item as the mouse is dragged
> over the canvas.  Again, due to the unusually tall bounding box on large
> fonts, I can be *visually* almost on top of, say, a line item, but the
> "current" item can be a text string that's 40 pixels above or below the
> mouse position.  While I know what's going on, it just doesn't "feel"
> right from a User perspective.
>
> Is the line spacing info intended to be part of the font values when
> doing things like the above?  The issue is really fairly minor as long
> as the fonts are small, but as they grow, it becomes quite difficult to
> deal with.
>
> Thanks for any input.
>
> Jeff

Most fonts are designed to ask for enough space for ascenders (like
the top of the 'd') and descenders (like the bottom of the 'p'), plus
a small talus or internal leading, most of which is traditionally put
below the descenders. Many (most?) English words have no letters with
descenders, so it can appear that a font is asking for an unreasonable
amount of space below the letters. [font metrics] will give you
separate values for the ascent and descent of a font, so if you wanted
to go to the trouble, you could check for letters with descenders and
make adjustments if a string doesn't contain any.

Some fonts also contain a ridiculous amount of internal leading (many
fonts from SIL suffer this affliction). If you're using a font like
that, you might make some measurements and adjust things
proportionally, or you may just want to switch fonts. It's
unfortunate that we can't automate these things a bit more, but at
present we're quite limited in the amount of font introspection Tk can
perform. Unfortunately, at the moment I don't have the time or skills
to change that.
From: Jeff Godfrey on 7 May 2010 13:07
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?

Jeff

From: Jeff Godfrey on 7 May 2010 13:16
On 5/7/2010 11:59 AM, Aric Bills wrote:
> On May 7, 10:22 am, Jeff Godfrey<jeff_godf...(a)pobox.com> wrote:

>> Thanks for any input.

> [font metrics] will give you
> separate values for the ascent and descent of a font, so if you wanted
> to go to the trouble, you could check for letters with descenders and
> make adjustments if a string doesn't contain any.

Aric,

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?

> Unfortunately, at the moment I don't have the time or skills
> to change that.

Yeah, same here.

Thanks,

Jeff

 |  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