Neil Hodgson wrote:
Robert Roessler:
...
Possible approaches: besides using a mono-spaced font for line numbers
(or just not using line numbers), is it the case that the rendered
width of a numeric string in s particular font is just the sum of the
widths of its individual glyphs (plus possible inter-character
spacing), *irrespective* of their ordering?
This is a dangerous assumption and is worse now there are so many
tweaks for fonts: I've seen very different spacing from playing with
the GNOME font control panel. Any patch should be an option.
Digit widths are more variable on GTK+ than on Windows where many
fonts that are otherwise strongly proportional have equally wide
digits. Many italics fonts have '7' drawn outside the character box
but I haven't found any (yet) that change spacing because of kerning
on digit strings.
I did suggest that was a big "if"... I have no problems acknowledging
your clearly larger experience with this subject.
As for how much of this is exposed at the level of the Scintilla API,
there could either be an additional variant of the SCI_TEXTWIDTH call,
*or* SCI_TEXTWIDTH could just note that a given invocation is using
STYLE_LINENUMBER, and use the "alternate" implementation.
Why does this get exposed to the container? The value is supposed
to be the same as performing the costly version, so the API can just
use the current code. Its Scintilla internally that is doing the right
justified drawing.
Well, it only seemed fair that a feature like this be available, given
that doing the original width calculation to get a width for the line#
margin is where this started... recall my "we need a quick and dirty
way to compute the width of '_9999'"? :) On reflection, you are
certainly right, this is probably not the way to do it. :)
Robert Roessler
[EMAIL PROTECTED]
http://www.rftp.com
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
