bugThe FreeType Project - Bugs: bug #52215, Autohinter support for box drawing...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #52215: Autohinter support for box drawing unicode range

Submitter:  Alexei Podtelezhnikov <podtelez>
Submitted:  Thu 12 Oct 2017 03:41:38 PM UTC
Votes: 50
 
Severity:  1 - Wish Item Group:  Wishlist
Status:  None Privacy:  Public
Assigned to:  wl Open/Closed:  Open
Planned Release:  None

Mon 18 May 2020 04:39:37 AM UTC, comment #5: 

comment #3:

> No, this was apparently true in the past, but this is no longer what I could observe with xterm's debugging messages on the DejaVu Sans Mono font.


I don't know what renderer are you talking about, but the rounded WinAscent+rounded WinDescent behavior is the actual behavior in GDI. To see how to do it in FreeType, this is how TD renderer gets the font top and font bottom:
```
int32_t tdr_getfonttop(uint32_t ppem){ // Font top is ALWAYS the rendered top
TT_OS2* info = (TT_OS2*)FT_Get_Sfnt_Table(tdr_face, FT_SFNT_OS2);
return ((ppem*(info->usWinAscent))+(tdr_face->units_per_EM/2))/tdr_face->units_per_EM;
}

int32_t tdr_getfontbottom(uint32_t ppem){ // Font bottom is ALWAYS the rendered bottom
TT_OS2* info = (TT_OS2*)FT_Get_Sfnt_Table(tdr_face, FT_SFNT_OS2);
return -(((ppem*(info->usWinDescent))+(tdr_face->units_per_EM/2))/tdr_face->units_per_EM);
}
```
and the rendered bitmaps must be also clipped to those vertical boundaries to simulate GDI behavior.

- <_194785>
Sun 17 May 2020 09:58:53 PM UTC, comment #4: 

commentaire #3 :

> +Xft metrics screen->renderFontNorm[0] = 20 (16,5)* advance 10, actual 10
> +Xft metrics screen->renderFontBold[0] = 20 (16,5)* advance 10, actual 10
> +Xft metrics screen->renderFontItal[0] = 20 (16,5)* advance 10, actual 10


I forgot to say that this was with "Xft.dpi: 88" in the X resources. With "Xft.dpi: 132", this is worse:

Xft metrics screen->renderFontNorm[0] = 21 (18,5)* advance 11, actual 11
Xft metrics screen->renderFontBold[0] = 21 (18,5)* advance 11, actual 11
Xft metrics screen->renderFontItal[0] = 21 (18,5)* advance 11, actual 11

So the rounded ascent + the rounded descent = 23, while the height is 21.

Note that for this particular case, the blank lines between glyphs are only due to the fact that xterm increases the height to match rounded ascent + rounded descent. But other terminals seem to behave in the same way (rxvt is actually worse since it also increases the horizontal space).

Vincent Lefèvre <vinc17>
Sun 17 May 2020 09:43:40 PM UTC, comment #3: 

commentaire #2 :

> The font height is the sum of the rounded value of WinAscent and the rounded value of WinDescent.


No, this was apparently true in the past, but this is no longer what I could observe with xterm's debugging messages on the DejaVu Sans Mono font.

-Xft metrics screen->renderFontNorm[0] = 20 (16,4) advance 10, actual 10
-Xft metrics screen->renderFontBold[0] = 20 (16,4) advance 10, actual 10
-Xft metrics screen->renderFontItal[0] = 20 (16,4) advance 10, actual 10
+Xft metrics screen->renderFontNorm[0] = 20 (16,5)* advance 10, actual 10
+Xft metrics screen->renderFontBold[0] = 20 (16,5)* advance 10, actual 10
+Xft metrics screen->renderFontItal[0] = 20 (16,5)* advance 10, actual 10

The "-" lines correspond to FreeType 2.6.3, where one has asc 16 + dsc 4 = height 20.

The "+" lines correspond to FreeType 2.8, where one has asc 16 + dsc 5, which is no longer equal to height 20. As a consequence, xterm increased the height to 21, which is more than what I expected.

BTW, I've done some tests with various monospaced fonts in the last few days, and actually the problem is more general. The ascent and descent values do not seem to be reliable. If I understand correctly, this is a known issue: https://www.freetype.org/freetype2/docs/tutorial/step2.html

This affects box drawing (only a part of my complaint), but also interline spacing (space on screen is important, so that one should not waste space between text lines).

Vincent Lefèvre <vinc17>
Sun 17 May 2020 07:32:02 PM UTC, comment #2: 

The font height is the sum of the rounded value of WinAscent and the rounded value of WinDescent. A combination of scaling and translation vertically can match the two (because in box-drawing characters baseline is irrelevant), and then a horizontal scaling can match the integer width.

I also suggest extending the range of this to 2320—2321 2500—259F 25E2—25E5 to include the other characters that rely on tiling as well.

- <_194785>
Thu 12 Oct 2017 03:59:59 PM UTC, comment #1: 

Never mind my first suggestion. It is impossible to scale to both rounded ascender and rounded descender lines at the same time, as those are two different scaling factors. Only rounding the pixel positions would work. So, indeed, autohinter support is necessary.

The same idea should apply to the native hinting. The truetype fonts must provide their own rounding instructions as well. DejaVu fonts as of 2.37 do not instruct box drawing characters.

Alexei Podtelezhnikov <podtelez>
Group Member
Thu 12 Oct 2017 03:41:38 PM UTC, original submission:  

For the box drawing to work, the characters in this range (U+2500-U+257F) have to be monospaced and span the exact distance between the descender and ascender lines. This distance and the distance between the lines is always rounded to pixels. Therefore, arbitrary scaling does not work for these characters. We should either

1) use discrete scaling that corresponds to the rounded metrics, or
2) round the edge pixels to the ascender and descender lines in the autohinter.

Note that, it is probably incorrect to modify the ascender and descender lines and line spacing for these characters because they are routinely used with other normal glyphs to draw tables.

Alexei Podtelezhnikov <podtelez>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by vinc17 (Posted a comment)
  • -email is unavailable- added by _194785 (Posted a comment)
  • -email is unavailable- added by vinc17
  • -email is unavailable- added by podtelez (Submitted the item)
  •  

    There are 50 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.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-10-15 vinc17 Carbon-Copy- Added vinc17

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code