The 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: |
- <_194785> |
Sun 17 May 2020 09:58:53 PM UTC, comment #4:
|
Vincent Lefèvre <vinc17> |
Sun 17 May 2020 09:43:40 PM UTC, comment #3:
|
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.
|
- <_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.
|
Alexei Podtelezhnikov <podtelez> |
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
|
Alexei Podtelezhnikov <podtelez> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
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 |
Powered by Savane 3.13-02a9.
Corresponding source code
comment #3:
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.