The FreeType Project - Bugs: bug #52165, blank line between characters...
You are not allowed to post comments on this tracker with your current authentication level.
bug #52165: blank line between characters (regression in 2.8)
Submitter: | Vincent Lefèvre <vinc17> | ||
Submitted: | Wed 04 Oct 2017 12:02:54 PM UTC | ||
Severity: | 3 - Normal | Item Group: | Incorrect behaviour |
Status: | Wont Fix | Privacy: | Public |
Assigned to: | wl | Open/Closed: | Closed |
Planned Release: | None |
Jump to the original submission
Thu 12 Oct 2017 04:01:24 PM UTC, comment #28: |
Alexei Podtelezhnikov <podtelez> |
Wed 11 Oct 2017 09:40:01 PM UTC, comment #27: This is actually a nice idea, thanks!
|
Werner LEMBERG <wl> |
Wed 11 Oct 2017 04:46:13 PM UTC, comment #26: Why? You made autohinter work for all kinds of scripts. The box drawing is just another script with a very defined unicode range. We can do whatever autohinting to fit our rounding convention. We can make a special blue zone for them too. Adjusting spacing for these glyphs is actually wrong on the other hand.
|
Alexei Podtelezhnikov <podtelez> |
Wed 11 Oct 2017 04:27:35 PM UTC, comment #25: No no no! If in auto-hinter mode, it's neither a bug in FreeType nor a bug in xterm (or rather, a bug in Xft) – it's simply not possible to know that those characters should be stacked perfectly![*] As mentioned earlier, the auto-hinter sometimes increases the vertical glyph dimension at small sizes to increase readability. [A possible solution would be to check the (hinted) dimensions of block characters and adjust the vertical spacing accordingly.]
|
Werner LEMBERG <wl> |
Wed 11 Oct 2017 01:52:08 PM UTC, comment #24: Fully agreed. So the lack of rounding instructions for this characters is the DejaVu font bug. The autohinter should also take care of this in accordance with FreeType rounding convention. This is a FreeType autohinter bug.
|
Alexei Podtelezhnikov <podtelez> |
Wed 11 Oct 2017 12:55:02 PM UTC, comment #23: Box characters are special. To make them work two assumptions must hold: (1) The rendering environment must use the line spacing as given in the font – systems like TeX ignore this. (2) To avoid visible overlaps, the y values of the box elements must be aligned to the grid, exactly fitting the global ascender and descender values.
|
Werner LEMBERG <wl> |
Wed 11 Oct 2017 12:37:01 PM UTC, comment #22: On the other hand, all fonts are monospaced in y-direction, so it make sense to limit the user choice to the rounded values. But the box drawing characters must be hinted to the rounded values. I do not know if it can be done through blue zones, or phantom points, or if TrueType has some special facility for that. There is no way around it. The top and bottom of box drawing must be aligned to the line edges.
|
Alexei Podtelezhnikov <podtelez> |
Wed 11 Oct 2017 11:19:32 AM UTC, comment #21: We round for historical reasons – I fully agree that it is a bad idea in general – the user should do it to fit the desired purpose –, but changing that would be backward incompatible.
|
Werner LEMBERG <wl> |
Wed 11 Oct 2017 10:57:58 AM UTC, comment #20: The glyph is question is neither hinted nor autohinted. The problem occurs regardless of hinting. Your suggested code would not work.
|
Alexei Podtelezhnikov <podtelez> |
Wed 11 Oct 2017 06:13:38 AM UTC, comment #19: FreeType's values for `ascender' and `descender' in FT_Size are `all-inclusive'. If you need something better – in particular for TTFs –, follow the advice given in commit 08e2e311.
|
Werner LEMBERG <wl> |
Wed 11 Oct 2017 03:27:42 AM UTC, comment #18: Werner, rounding the ascender up and the descender down can clearly leave a huge gapping hole, see attached. The table drawing glyphs do not seem to be hinted or autohinted in this font. What fix do you suggest in this case?
|
Alexei Podtelezhnikov <podtelez> |
Sun 08 Oct 2017 10:20:48 AM UTC, comment #17: I've already contacted the author of xterm (with CC to you), pointing to this bug report – hopefully, xterm can be fixed soon. Please do the same for other programs where you notice bad behaviour. |
Werner LEMBERG <wl> |
Sun 08 Oct 2017 10:08:55 AM UTC, comment #16: Unfortunately, it was not announced in Debian. And the fact is that several applications are currently based on this "bug" (perhaps because the TrueType fonts are the most common and the default in practice, at least for these applications and most users use the default hinting method). Otherwise the problem would have already been reported. |
Vincent Lefèvre <vinc17> |
Sun 08 Oct 2017 09:38:55 AM UTC, comment #15: It was properly announced in the CHANGES file!
|
Werner LEMBERG <wl> |
Sun 08 Oct 2017 09:18:14 AM UTC, comment #14: Note that's an ABI change (because of visible change of the behavior, affecting some applications), and an API change too, because some applications are now required to use "values from the `FT_Face' structure and scale them manually". This should have properly been announced. |
Vincent Lefèvre <vinc17> |
Sun 08 Oct 2017 08:39:10 AM UTC, comment #13: I've just improved the documentation in git. |
Werner LEMBERG <wl> |
Sat 07 Oct 2017 05:45:04 PM UTC, comment #12: Regarding comment #9: Thanks for the data, I now know the cause. It's a change introduced in version 2.8 to make the handling of all fonts the same. From the CHANGES file:
Global size metrics values in the `FT_Size_Metrics' structure can be different for TrueType fonts. Reason is that in older FreeType versions the metrics were rounded differently to integer pixels compared to all other font formats, yielding an inconsistent behaviour if you used non-native hinting. Starting with this version, global size metrics for TrueType fonts are handled the same as other font formats: `ascender' gets rounded up, `descender' getsrounded down, `height' gets normally rounded, and `max_advance' gets normally rounded, too. If you need more precise values of (global) ascender, descender, height, or `max_advance', please take the corresponding values from the `FT_Face' structure and scale them manually. As you can see, the rounding for ascender and descender has changed. |
Werner LEMBERG <wl> |
Sat 07 Oct 2017 04:44:57 PM UTC, comment #11: Regarding comment #8: In your GNOME snapshots, you are definitely using native v35 TrueType hinting in your 2.6.1 image! And you are definitely using native v40 TrueType hinting in your 2.8 image. No slight hinting at all...
|
Werner LEMBERG <wl> |
Fri 06 Oct 2017 02:44:04 PM UTC, comment #10: Should FreeType enforce that ascend + descend = height? Or, should Xft prioritize the height?
|
Alexei Podtelezhnikov <podtelez> |
Fri 06 Oct 2017 11:02:37 AM UTC, comment #9: On a different machine (my desktop machine, which shows the same issues), I've rebuilt xterm with --enable-trace to get debugging information and compare the traces obtained with FreeType 2.6.3 and 2.8.0. Concerning the differences for the fonts, I get:
|
Vincent Lefèvre <vinc17> |
Fri 06 Oct 2017 08:07:39 AM UTC, comment #8: When doing my tests comparing 2.6.3 and 2.8.0, I just upgrade/downgrade the libfreetype6 Debian package with apt/dpkg. So the fonts and the fontconfig versions remain the same.
|
Vincent Lefèvre <vinc17> |
Fri 06 Oct 2017 04:35:57 AM UTC, comment #7: If the FREETYPE_PROPERTIES environment variable doesn't make a difference, then the machine with FreeType 2.8 (assuming a normal build of the library) uses the auto-hinter, at least for the `DejaVu Sans Mono' font. You should check your fontconfig settings and switch to `full' hinting. And just to be sure you should also check whether your DejaVu fonts are identical.
|
Werner LEMBERG <wl> |
Thu 05 Oct 2017 08:06:27 AM UTC, comment #6: fc-match says that it's "DejaVu Sans Mono" "Book", and if I use this font directly in the GNOME Terminal preferences, this looks the same and I get the same issue.
|
Vincent Lefèvre <vinc17> |
Thu 05 Oct 2017 05:44:58 AM UTC, comment #5: `Monospace Regular 10' is an alias. Please try to find out what font this really is (for example, using the `fc-list' program) so that I can check the font's built-in line height values. What dpi value are you using?
|
Werner LEMBERG <wl> |
Wed 04 Oct 2017 10:28:10 PM UTC, comment #4: I can reproduce the problem with GNOME Terminal. See the attached screenshots. This is with Monospace Regular 10. |
Vincent Lefèvre <vinc17> |
Wed 04 Oct 2017 09:16:16 PM UTC, comment #3: AFAIK, there are no such problems with applications that are based on Qt or Pango, for example KDE or Gnome – can you verify that?
|
Werner LEMBERG <wl> |
Wed 04 Oct 2017 09:01:17 PM UTC, comment #2: I normally use 10. If I set 9.9, the window height is slightly smaller (but not as small as with 2.6) but I still get the blank line. Same result with 9.8, 9.7 and 9.6. Ditto with 9.5 except that the window is narrower, which is not OK. |
Vincent Lefèvre <vinc17> |
Wed 04 Oct 2017 08:32:06 PM UTC, comment #1: Try using a slightly smaller, fractional point size for your terminal font, e.g., 12.8pt instead of 13pt.
|
Werner LEMBERG <wl> |
Wed 04 Oct 2017 12:02:54 PM UTC, original submission:
Under Debian/unstable, after the upgrade of the libfreetype6 Debian package from 2.6.3-3.2 to 2.8-0.2, there is a blank line between characters. This has several consequences:
|
Vincent Lefèvre <vinc17> |
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 11 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2017-10-11 | podtelez | Carbon-Copy | - | Added -email is unavailable- | |
2017-10-11 | podtelez | Attached File | - | Added bar_gap.png, #42118 | |
2017-10-08 | wl | Status | Need Info | Wont Fix | |
Open/Closed | Open | Closed | |||
2017-10-07 | wl | Attached File | - | Added v35-v40-light.png, #42079 | |
2017-10-06 | wl | Status | None | Need Info | |
Assigned to | None | wl | |||
2017-10-04 | vinc17 | Attached File | - | Added gnome-term-263.png, #42066 | |
Attached File | - | Added gnome-term-280.png, #42067 | |||
2017-10-04 | vinc17 | Attached File | - | Added ft263.png, #42059 | |
Attached File | - | Added ft280.png, #42060 |
Powered by Savane 3.13-4448.
Corresponding source code
The new tracker 52215.