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

 
 

bug #52215: Autohinter support for box drawing unicode range

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

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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.

Piotr Grochowski <piotrgrochowski>
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.

Piotr Grochowski <piotrgrochowski>
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>
Project 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>
Project Member

 

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

Attach Files:
   
   
Comment:
   

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 piotrgrochowski (Posted a comment)
  • -email is unavailable- added by vinc17
  • -email is unavailable- added by podtelez (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 50 encouragements so far.

    Only logged-in users can vote.

     

     

     

    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.5