Deja-Vu Mono 10 underscores (still missing)

[Lex Trotman]

Hi Neil,

I am testing the upgrade of Geany to Scintilla 5 (5.1.1 ATM) and note that the underscores are still missing for the subject font.

On my system with a 27" QHD monitor the underscores show on 9 and 12 point but not on 10 and 11 point. 

I compared the Geany display to Eclipse and Gedit and the Geany/Scintilla lines definitely use less vertical space (Gedit and Eclipse are identical and show underscores). 

But underscores in Geany show at all tested sizes using the Hack font, although the lines still use the same vertical space as Deja-Vu.  This is why I have been blaming Deja-Vu not Scintilla.

But maybe a workaround is to copy how Gedit/Eclipse calculate the line height for the GTK backend in Scintilla if that makes underscores show reliably?  

It might use more vertical space than now, but at least it will not be using more space than other editors on the same system.

Cheers

Lex

[Lex Trotman]

On Fri, 3 Sept 2021 at 10:02, Lex Trotman <ele...@gmail.com> wrote:
>
> Hi Neil,
>
> I am testing the upgrade of Geany to Scintilla 5 (5.1.1 ATM) and note that the underscores are still missing for the subject font.
>
> On my system with a 27" QHD monitor the underscores show on 9 and 12 point but not on 10 and 11 point.
>
> I compared the Geany display to Eclipse and Gedit and the Geany/Scintilla lines definitely use less vertical space (Gedit and Eclipse are identical and show underscores).
>
> But underscores in Geany show at all tested sizes using the Hack font, although the lines still use the same vertical space as Deja-Vu. This is why I have been blaming Deja-Vu not Scintilla.
>
> But maybe a workaround is to copy how Gedit/Eclipse calculate the line height for the GTK backend in Scintilla if that makes underscores show reliably?

Forgot to mention, extradescent of 2 gives the same vertical height as
Gedit/Eclipse, but there have been reports to Geany that this is
insufficient to make underscores show fully on some systems.

>
> It might use more vertical space than now, but at least it will not be using more space than other editors on the same system.
>
> Cheers
> Lex
>

> --
> You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to scintilla-inter...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/scintilla-interest/3782b15a-9910-42ab-8431-e5c59c44b8f8n%40googlegroups.com.

[Neil Hodgson]

Lex Trotman:

> But maybe a workaround is to copy how Gedit/Eclipse calculate the line height for the GTK backend in Scintilla if that makes underscores show reliably?

It may be worth examining these applications to see what they are doing.

It would help to know what the floating-point ascent and descent are for the cases of interest on the systems where there are problems. That is, the results from pango_font_metrics_get_ascent and pango_font_metrics_get_descent. Maybe there are other calls that could be used on the specific ‘_’ character to see what its max y is. There are various ways to round the values to an integer line height as used by Scintilla. There could also be tweaks to the baseline (ybase) used to vertically position characters within the draw rectangle.

Neil

[Lex Trotman]

On Fri, 3 Sept 2021 at 12:37, 'Neil Hodgson' via scintilla-interest

<scintilla...@googlegroups.com> wrote:
>
> Lex Trotman:
>
> > But maybe a workaround is to copy how Gedit/Eclipse calculate the line height for the GTK backend in Scintilla if that makes underscores show reliably?
>
> It may be worth examining these applications to see what they are doing.

Noting that I am not a GTK/Pango expert, my lunchtime browsing of Gedit found:

1) gedit uses GTKsourceview
2) GTKSourceview seems to delegate rendering of the text to GTKtext,
haven't had time to look at that
3) but GTKSourceview renders the gutters itself (the line number
margins for eg) and I would expect that to need to use the same height
as GTKtextview or the numbers and the text won't align.
4) rendering the gutter text seems to use
pango_layout_get_pixel_size() for height with no adjustment
https://gitlab.gnome.org/GNOME/gtksourceview/-/blob/master/gtksourceview/gtksourcegutterrenderertext.c#L84
(AFAICT)

So it seems to delegate the whole problem to Pango to do the rounding for it.

Cheers
Lex

>
> It would help to know what the floating-point ascent and descent are for the cases of interest on the systems where there are problems. That is, the results from pango_font_metrics_get_ascent and pango_font_metrics_get_descent. Maybe there are other calls that could be used on the specific ‘_’ character to see what its max y is. There are various ways to round the values to an integer line height as used by Scintilla. There could also be tweaks to the baseline (ybase) used to vertically position characters within the draw rectangle.
>
> Neil
>

> --
> You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to scintilla-inter...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/scintilla-interest/D65DA5B1-B0D4-4B77-93B8-C9D03369D07C%40me.com.

[Lex Trotman]

On Fri, 3 Sept 2021 at 14:01, Lex Trotman <ele...@gmail.com> wrote:
>
> On Fri, 3 Sept 2021 at 12:37, 'Neil Hodgson' via scintilla-interest
> <scintilla...@googlegroups.com> wrote:
> >
> > Lex Trotman:
> >
> > > But maybe a workaround is to copy how Gedit/Eclipse calculate the line height for the GTK backend in Scintilla if that makes underscores show reliably?
> >
> > It may be worth examining these applications to see what they are doing.
>
> Noting that I am not a GTK/Pango expert, my lunchtime browsing of Gedit found:
>
> 1) gedit uses GTKsourceview
> 2) GTKSourceview seems to delegate rendering of the text to GTKtext,
> haven't had time to look at that
> 3) but GTKSourceview renders the gutters itself (the line number
> margins for eg) and I would expect that to need to use the same height
> as GTKtextview or the numbers and the text won't align.
> 4) rendering the gutter text seems to use
> pango_layout_get_pixel_size() for height with no adjustment
> https://gitlab.gnome.org/GNOME/gtksourceview/-/blob/master/gtksourceview/gtksourcegutterrenderertext.c#L84
> (AFAICT)
>
> So it seems to delegate the whole problem to Pango to do the rounding for it.

And Pango seems to calculate height by rounding starting pixels down
and ending pixels up to get a bounding box and then subtracting them
to get pixel height, which seems to concur with the observation that
Gedit heights are two pixels greater than Scintilla heights (on my
system with my screen and font size, YMMV).

[Lex Trotman]

On Fri, 3 Sept 2021 at 17:22, Lex Trotman <ele...@gmail.com> wrote:
>
> On Fri, 3 Sept 2021 at 14:01, Lex Trotman <ele...@gmail.com> wrote:
> >
> > On Fri, 3 Sept 2021 at 12:37, 'Neil Hodgson' via scintilla-interest
> > <scintilla...@googlegroups.com> wrote:
> > >
> > > Lex Trotman:
> > >
> > > > But maybe a workaround is to copy how Gedit/Eclipse calculate the line height for the GTK backend in Scintilla if that makes underscores show reliably?
> > >
> > > It may be worth examining these applications to see what they are doing.
> >
> > Noting that I am not a GTK/Pango expert, my lunchtime browsing of Gedit found:
> >
> > 1) gedit uses GTKsourceview
> > 2) GTKSourceview seems to delegate rendering of the text to GTKtext,
> > haven't had time to look at that
> > 3) but GTKSourceview renders the gutters itself (the line number
> > margins for eg) and I would expect that to need to use the same height
> > as GTKtextview or the numbers and the text won't align.
> > 4) rendering the gutter text seems to use
> > pango_layout_get_pixel_size() for height with no adjustment
> > https://gitlab.gnome.org/GNOME/gtksourceview/-/blob/master/gtksourceview/gtksourcegutterrenderertext.c#L84
> > (AFAICT)
> >
> > So it seems to delegate the whole problem to Pango to do the rounding for it.
>
> And Pango seems to calculate height by rounding starting pixels down
> and ending pixels up to get a bounding box and then subtracting them
> to get pixel height, which seems to concur with the observation that
> Gedit heights are two pixels greater than Scintilla heights (on my
> system with my screen and font size, YMMV).

And gtk_textview gets height from `pango_layout_get_pixel_extents()`.
The `pango_layout_get_pixel_size()` used by gtk_sourceview is just a
convenience wrapper around `...pixel_extents()` which uses the
`inclusive` return value from `pango_extents_to_pixels()` which does
the floor and ceiling as described above, see
https://github.com/GNOME/pango/blob/fde510ce427cbb32ce05a1c463bb1947d07bc878/pango/pango-utils.c#L1053

Cheers
Lex

PS Scintilla is a breeze to understand compared to GTK_textview :)

[Neil Hodgson]

Lex Trotman:

> 2) GTKSourceview seems to delegate rendering of the text to GTKtext,
> haven't had time to look at that
> 3) but GTKSourceview renders the gutters itself (the line number
> margins for eg) and I would expect that to need to use the same height
> as GTKtextview or the numbers and the text won't align.
> 4) rendering the gutter text seems to use
> pango_layout_get_pixel_size() for height with no adjustment
> https://gitlab.gnome.org/GNOME/gtksourceview/-/blob/master/gtksourceview/gtksourcegutterrenderertext.c#L84

That is working on a layout which contains some (styled) text to draw so will depend on the text and the fonts. The only caller gtk_source_gutter_renderer_text_snapshot_line is using the width and height to draw text in the gutter - it doesn’t appear to be pushing the height back into a data structure or caller.

gtk_source_gutter_renderer_text_measure looks more like something that can be called to find the height of a line.

I think GTKText can have different heights for different lines depending on the text and fonts but this may not be possible with GtkSourceView.

The gutter and text is more likely to synchronize using max(gutter_height, text_height) than just using the gutter_height. Gutters commonly contain line numbers and numbers are shorter than most text.

Neil

[Lex Trotman]

I tried applying std::floor and std::ceil instead of std::round in the
Ascent and Descent functions but it is still not the same as Gedit
height and Deja-Vu underscores do not show.

However whilst searching I came across this
https://docs.gtk.org/Pango/struct.FontMetrics.html which seems to
suggest that a Fonts suggested height may be bigger than ascent +
descent, so if Pango renders the text up to height and Scintilla
pastes that in the buffer ascent+descent apart there is a likelihood
that parts of the line above will be erased, which seems to be what is
happening.

Cheers
Lex

[Neil Hodgson]

Lex Trotman:

However whilst searching I came across this
https://docs.gtk.org/Pango/struct.FontMetrics.html which seems to
suggest that a Fonts suggested height may be bigger than ascent +
descent, so if Pango renders the text up to height and Scintilla
pastes that in the buffer ascent+descent apart there is a likelihood
that parts of the line above will be erased, which seems to be what is
happening.

   Ink may go outside the font’s size data but that should be fairly rare for ASCII including ‘_’ and, in the past, most text would fit OK. Emoji, stacked accents, and connectors used in Arabic and Indian text can go well outside which is when it is best to start sharing vertical space with multi-phase drawing or the lines will be too tall. Its also really hard to find the maximum values since they are often caused by the context of multiple characters together, not just finding the height of each possible character then finding the maximum.

  Scintilla used to measure a text string (ASCII letters, digits and punctuation or with some accented characters ÂÃÅÄ) to find the extents but that was #ifdefed out because of problems on GTK/Win32 then removed with Pango. This could be resurrected but the APIs used to find the upper and lower extents of the sample may have their own problems. There will always be a tension between making enough room for any possible character and not using too much space leading to fewer lines.

   The old code looked similar to this (simplified):

const char sizeString[] = "`~!@#$%^&*()-_=+\\|[]{};:\"\'<,>.?/1234567890"

                          "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";

XYPOSITION SurfaceImpl::Ascent(Font &font_) {

gint lbearing;

gint rbearing;

gint width;

gint ascent;

gint descent;

gdk_string_extents(PFont(font_)->pfont, sizeString,

  &lbearing, &rbearing, &width, &ascent, &descent);

return ascent;

}

   Neil

[Lex Trotman]

Hi Neil,

I had time to make the following change to SurfaceImpl::Height()

XYPOSITION SurfaceImpl::Height(const Font *font_) {
if (PFont(font_)->pfd) {
PangoFontMetrics *metrics = pango_context_get_metrics(pcontext,
PFont(font_)->pfd, pango_context_get_language(pcontext));
const XYPOSITION height = std::round(floatFromPangoUnits(
pango_font_metrics_get_descent(metrics)));
pango_font_metrics_unref(metrics);
if(height != 0)return height;
}
return Ascent(font_) + Descent(font_);
}

(copied almost verbatim from Ascent above)

and now the line heights are basically identical to Gedit and Eclipse
and underscores show for all tested point sizes with Deja-Vu.

The underscore is slightly fainter than for say Hack font, probably
the lower half of the anti-aliasing is still being cut off, but Gedit
is the same.

Not sure if the fallback to Ascent and Descent is needed, just that I
noted that the reference above stated font Height could be zero.

[Lex Trotman]

Sorry copy and paste error, obviously above is pango_font_metrics_get_height();

Cheers
Lex

[Neil Hodgson]

Lex Trotman:

>> XYPOSITION SurfaceImpl::Height(const Font *font_) {
>> if (PFont(font_)->pfd) {
>> PangoFontMetrics *metrics = pango_context_get_metrics(pcontext,
>> PFont(font_)->pfd, pango_context_get_language(pcontext));
>> const XYPOSITION height = std::round(floatFromPangoUnits(
>> pango_font_metrics_get_descent(metrics)));
>
> Sorry copy and paste error, obviously above is pango_font_metrics_get_height();

OK. That requires Pango 1.4.4 from July 2019.

https://blogs.gnome.org/mclasen/2019/07/27/more-text-rendering-updates/

Since there are older systems still supported, the call will need a PANGO_VERSION_CHECK with a fallback implementation.

https://www.manpagez.com/html/pango/pango-1.42.0/pango-Version-Checking.php#PANGO-VERSION-CHECK:CAPS

Looking up the call and Pango 1.4.4 showed some interesting items like this one mentioning “With DejaVu Mono, a character with underscore will not show the underscore”.

https://bkhome.org/news/202009/pango-version-144-is-a-disaster.html

Neil

[Lex Trotman]

On Thu, 9 Sept 2021 at 08:05, 'Neil Hodgson' via scintilla-interest

<scintilla...@googlegroups.com> wrote:
>
> Lex Trotman:
>
> >> XYPOSITION SurfaceImpl::Height(const Font *font_) {
> >> if (PFont(font_)->pfd) {
> >> PangoFontMetrics *metrics = pango_context_get_metrics(pcontext,
> >> PFont(font_)->pfd, pango_context_get_language(pcontext));
> >> const XYPOSITION height = std::round(floatFromPangoUnits(
> >> pango_font_metrics_get_descent(metrics)));
> >
> > Sorry copy and paste error, obviously above is pango_font_metrics_get_height();
>
> OK. That requires Pango 1.4.4 from July 2019.
>
> https://blogs.gnome.org/mclasen/2019/07/27/more-text-rendering-updates/
>
> Since there are older systems still supported, the call will need a PANGO_VERSION_CHECK with a fallback implementation.

Probably needs a runtime check too, the API has been 1.0.0 since 2002
so an app compiled with 1.44 could be installed on a system with 1.42
and the library .so.1.0 version will be found, so only the packaging
systems protect against it if the packager remembers.

Probably good to do the runtime check in the SurfaceImpl constructor
and set a boolean. Fallback of ascent + descent will be no worse than
now, and with a runtime check it will fix itself when the user system
is upgraded to pango 1.44 or newer.

>
> https://www.manpagez.com/html/pango/pango-1.42.0/pango-Version-Checking.php#PANGO-VERSION-CHECK:CAPS
>
> Looking up the call and Pango 1.4.4 showed some interesting items like this one mentioning “With DejaVu Mono, a character with underscore will not show the underscore”.
>
> https://bkhome.org/news/202009/pango-version-144-is-a-disaster.html

That is likely to be due to the older apps using ascent+descent since
height was not available until 1.44, as the post said apps need to be
changed to use the data the font provides. Maybe the line spacing
should have defaulted to 0.0 to use the old method (See Mattias' post
you linked) and changed apps would have to set 1.0 or whatever, but
backward compatibility wasn't GTK/Gnome/G* projects strong suit and
they got lots of hate over the years about it.

Cheers
Lex

>
> Neil
>
> --
> You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to scintilla-inter...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/scintilla-interest/49B7A35C-2870-444C-82FD-3572ADE42C78%40me.com.

[Neil Hodgson]

I’m not seeing any difference between ascent+descent and height on Fedora 34 with Pango 1.48.4 or Fedora 32 with Pango 1.44.7.

Excerpts from tracing:
DejaVu Sans Mono, 9 Ascent: 11.1387 Descent 2.83008 Height 13.9688 13.9688
DejaVu Sans, 9 Ascent: 11.1387 Descent 2.83008 Height 13.9688 13.9688
DejaVu Serif, 10 Ascent: 12.376 Descent 3.14453 Height 15.5205 15.5205
DejaVu Sans Mono, 10 Ascent: 12.376 Descent 3.14453 Height 15.5205 15.5205
DejaVu Sans, 10 Ascent: 12.376 Descent 3.14453 Height 15.5205 15.5205

The two values after ‘Height’ are from pango_font_metrics_get_height and pango_font_metrics_get_ascent + pango_font_metrics_get_descent.

Attached is a patch to print out metrics inside PlatGTK.cxx.

Replacing std::round with std::ceil in Ascent and Descent makes the underscore visible at the cost of extra space and fewer lines.

[Lex Trotman]

On Fri, 10 Sept 2021 at 17:12, 'Neil Hodgson' via scintilla-interest

<scintilla...@googlegroups.com> wrote:
>
> I’m not seeing any difference between ascent+descent and height on Fedora 34 with Pango 1.48.4 or Fedora 32 with Pango 1.44.7.
>
> Excerpts from tracing:
> DejaVu Sans Mono, 9 Ascent: 11.1387 Descent 2.83008 Height 13.9688 13.9688
> DejaVu Sans, 9 Ascent: 11.1387 Descent 2.83008 Height 13.9688 13.9688
> DejaVu Serif, 10 Ascent: 12.376 Descent 3.14453 Height 15.5205 15.5205
> DejaVu Sans Mono, 10 Ascent: 12.376 Descent 3.14453 Height 15.5205 15.5205
> DejaVu Sans, 10 Ascent: 12.376 Descent 3.14453 Height 15.5205 15.5205

The problem is these figures are all pre-rounding, I have added the
rounded versions to get:

DejaVu Sans Mono, 10 Ascent: 12.376 12 Descent 3.14453 3 Height
15.5205 15.5205 16 15

In particular the last two which are std::round(height) which is what
my patch was using to get the same height as Gedit and Eclipse and
std::round(ascent) + std::round(descent) which is what unmodified
Scintilla uses by adding Ascent() + Descent() since both of those are
rounded.

>
> The two values after ‘Height’ are from pango_font_metrics_get_height and pango_font_metrics_get_ascent + pango_font_metrics_get_descent.
>
> Attached is a patch to print out metrics inside PlatGTK.cxx.
>
> Replacing std::round with std::ceil in Ascent and Descent makes the underscore visible at the cost of extra space and fewer lines.

Yes, thats the point, it takes extra space to fit the underscore,
thats what Gedit and Eclipse do, as I said in the original message, "I

compared the Geany display to Eclipse and Gedit and the

Geany/Scintilla lines definitely use less vertical space".

While I had the printing I tried a few other fonts:

FreeMono, 10 Ascent: 10.666 11 Descent 2.66699 3 Height 13.333 13.333 13 14
Hack, 10 Ascent: 12.376 12 Descent 3.14453 3 Height 15.5205 15.5205 16 15
FreeSans, 10 Ascent: 10.666 11 Descent 2.66699 3 Height 14.666 13.333 15 14
Liberation Mono, 10 Ascent: 11.0996 11 Descent 4.00391 4 Height
15.1035 15.1035 15 15
MathJax_Typewriter, 10 Ascent: 9.25293 9 Descent 3.05371 3 Height
12.3066 12.3066 12 12
Nimbus Mono PS, 10 Ascent: 8.04004 8 Descent 5.29297 5 Height 16
13.333 16 13
Noto Mono, 10 Ascent: 12.3691 12 Descent 3.25488 3 Height 15.624
15.624 16 15

That is a wide range of values for what are ostensibly "10 point" fonts.

Also for varying point sizes plus I have annotated which ones have
visible underscores on standard Scintilla, ie
round(ascent)+round(descent):

DejaVu Sans Mono, 8 Ascent: 9.90137 10 Descent 2.51562 3 Height
12.417 12.417 12 13 yes
DejaVu Sans Mono, 9 Ascent: 11.1387 11 Descent 2.83008 3 Height
13.9688 13.9688 14 14 yes
DejaVu Sans Mono, 10 Ascent: 12.376 12 Descent 3.14453 3 Height
15.5205 15.5205 16 15 no
DejaVu Sans Mono, 11 Ascent: 13.6143 14 Descent 3.45898 3 Height
17.0732 17.0732 17 17 no
DejaVu Sans Mono, 12 Ascent: 14.8516 15 Descent 3.77344 4 Height
18.625 18.625 19 19 yes

That shows that the underscore issue may be more than just the plain
height since 11 point gives the same height value either way, but
doesn't show the underscores. Possibly Scintilla draws lower than the
font intended?

Cheers
Lex

>
> --
> You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to scintilla-inter...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/scintilla-interest/EA5F39EC-CED4-4897-A096-CCD2C0DABA74%40me.com.

>
>
> --
> You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to scintilla-inter...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/scintilla-interest/EA5F39EC-CED4-4897-A096-CCD2C0DABA74%40me.com.

[Neil Hodgson]

Lex Trotman:

In particular the last two which are std::round(height) which is what
my patch was using to get the same height as Gedit and Eclipse and
std::round(ascent) + std::round(descent) which is what unmodified
Scintilla uses by adding Ascent() + Descent() since both of those are
rounded.

   Setting line height to std::round(height) does not show the underscore.

   For DejaVu Sans Mono 10, rounding the floating point height of 15.5205 yields 16. No underscore.

   Applying std::ceil to both ascent and descent (12.376, 3.14453) produces (13, 4). Add that together to get 17 and the underscore becomes visible on the lowest pixel of the line.

   An alternative technique of using std::ceil(height) for the line height then placing the text within the line using the floating point ascent produced poor-looking text. Its possible that the fonts are hinted based on integral vertical positioning.

   Here is an image showing these techniques. The left is using a line height of 16 but with the floating point vertical position. The right is using a line height of 17 and integral vertical position.

https://www.scintilla.org/GTKHeightAscentDescent.png

   Running the trace code on an older version of Ubuntu showed this:

Pango 1.42.3 1.42.3

DejaVu Sans Mono, 10   Ascent: 13   Descent 4   Height 0 17

   The Pango behaviour before 1.44 appears to be to ceil the ascent and descent.

   Neil

[Lex Trotman]

On Sat, 11 Sept 2021 at 08:35, 'Neil Hodgson' via scintilla-interest

<scintilla...@googlegroups.com> wrote:
>
> Lex Trotman:
>
> In particular the last two which are std::round(height) which is what
> my patch was using to get the same height as Gedit and Eclipse and
> std::round(ascent) + std::round(descent) which is what unmodified
> Scintilla uses by adding Ascent() + Descent() since both of those are
> rounded.
>
>
> Setting line height to std::round(height) does not show the underscore.
>
> For DejaVu Sans Mono 10, rounding the floating point height of 15.5205 yields 16. No underscore.
>
> Applying std::ceil to both ascent and descent (12.376, 3.14453) produces (13, 4). Add that together to get 17 and the underscore becomes visible on the lowest pixel of the line.

Ok I changed both SurfaceImpl::Ascent() and Descent() to use std::ceil
instead of std::round and the same in the printed values, results

DejaVu Sans Mono, 9 Ascent: 11.1387 12 Descent 2.83008 3 Height
13.9688 13.9688 14 15 yes
DejaVu Sans Mono, 10 Ascent: 12.376 13 Descent 3.14453 4 Height
15.5205 15.5205 16 17 yes
DejaVu Sans Mono, 11 Ascent: 13.6143 14 Descent 3.45898 4 Height
17.0732 17.0732 18 18 yes

DejaVu Sans Mono, 12 Ascent: 14.8516 15 Descent 3.77344 4 Height
18.625 18.625 19 19 yes

Spacing and text quality looks fine and is identical to Gedit/Eclipse.

The DejaVu font definitely has the underscore lower than both Hack and
Noto, and it appears thinner, I suspect because the lower
anti-aliasing is being hidden by the next line, but as I said before
thats the case with Gedit too, so its no worse.

>
> An alternative technique of using std::ceil(height) for the line height then placing the text within the line using the floating point ascent produced poor-looking text. Its possible that the fonts are hinted based on integral vertical positioning.
>
> Here is an image showing these techniques. The left is using a line height of 16 but with the floating point vertical position. The right is using a line height of 17 and integral vertical position.
> https://www.scintilla.org/GTKHeightAscentDescent.png
>
> Running the trace code on an older version of Ubuntu showed this:
> Pango 1.42.3 1.42.3
> DejaVu Sans Mono, 10 Ascent: 13 Descent 4 Height 0 17
> The Pango behaviour before 1.44 appears to be to ceil the ascent and descent.

I don't have an older version to test with, but duplicating this as
above seems to get an acceptable result with 1.44 and hopefully will
be ok on older (and newer) Pango.

Using std::ceil in Ascent() and Descent() would seem to allow Geany to
keep shipping with default extradescent of 0 meaning short fonts (eg
freesans) remain sensibly spaced, adding two pixels by default (which
made DevaVu 10 show underscore) made the spacing look very large for
short fonts, and kind of defeated the point of using short fonts at
all.

Cheers
Lex

>
> Neil

>
> --
> You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to scintilla-inter...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/scintilla-interest/5E657222-C584-4E7F-8284-1A13729B50A0%40me.com.

[Neil Hodgson]

Lex Trotman:

> The DejaVu font definitely has the underscore lower than both Hack and

> Noto, and it appears thinner, …

The font configuration of the system can change the position of the underscore as shown in https://www.scintilla.org/GTKHintingMag.png . It may also be blurred between two pixels.

Hinting modes can be changed with the GNOME Tweaks application shown in https://www.scintilla.org/GTKHinting.png with corresponding displays as 3 screen captures. Full and Medium hinting displayed the same on this system. The metrics reported by GTK do not change despite the underscore moving.

There is also a Font Tweaks Tool application that can perform deeper changes to fonts.

> Using std::ceil in Ascent() and Descent() would seem to allow Geany to
> keep shipping with default extradescent of 0 meaning short fonts (eg
> freesans) remain sensibly spaced, adding two pixels by default (which
> made DevaVu 10 show underscore) made the spacing look very large for
> short fonts, and kind of defeated the point of using short fonts at
> all.

Using ceil for both ascent and descent appears the safest choice to show underscores and almost all tall accents in Roman-based languages. Extra ascent and descent may be needed for accent stacking languages, emoji and other cases.

Committed:
https://sourceforge.net/p/scintilla/code/ci/3369c500e30489925084279220d62525c87316ad/

Its possible to set extra ascent and descent to negative values and I made some additional changes to make this safer. Calculated ascent over all fonts must be >= 1 and descent >= 0 so line height >= 1. Users could choose negative values to stop extra spacing they do not want.

Negative extra space can make document maps show more lines by allowing lines to take 1 or 2 pixels: use a small font and set extra descent to -1 so descenders take no space.

Additional ascent and descent changes:
https://sourceforge.net/p/scintilla/code/ci/84228464bd202057f8afffecd0bd6a6d4e18318f/

Neil

[Lex Trotman]

> Using ceil for both ascent and descent appears the safest choice to show underscores and almost all tall accents in Roman-based languages. Extra ascent and descent may be needed for accent stacking languages, emoji and other cases.
>

I realised I had misunderstood the part of Pango used by Gedit, it
applies ceiling and floor to xy values, so it applies ceiling to the
upper value and floor to the lower one which is equivalent to this
applying ceiling to both ascent and descent. So this seems the right
thing to do.

> Committed:
> https://sourceforge.net/p/scintilla/code/ci/3369c500e30489925084279220d62525c87316ad/

Thanks for your help Neil

>
> Its possible to set extra ascent and descent to negative values and I made some additional changes to make this safer. Calculated ascent over all fonts must be >= 1 and descent >= 0 so line height >= 1. Users could choose negative values to stop extra spacing they do not want.
>
> Negative extra space can make document maps show more lines by allowing lines to take 1 or 2 pixels: use a small font and set extra descent to -1 so descenders take no space.
>
> Additional ascent and descent changes:
> https://sourceforge.net/p/scintilla/code/ci/84228464bd202057f8afffecd0bd6a6d4e18318f/

Interesting, I have made a note to check if our configuration file
allows negative numbers for the extra descent setting.

Cheers
Lex

>
> Neil
>
> --
> You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to scintilla-inter...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/scintilla-interest/A0E22630-38BD-4C79-B60B-DA452A745074%40me.com.