bugThe FreeType Project - Bugs: bug #42522, Autohinter - dots too close with...

 
 

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

bug #42522: Autohinter - dots too close with 'i', 'j', '?', '!'

Submitter:  zboobzor <zboobzor>
Submitted:  Sun 08 Jun 2014 02:33:54 AM UTC
   
 
Severity:  3 - Normal Item Group:  Incorrect behaviour
Status:  Confirmed Privacy:  Public
Assigned to:  wl Open/Closed:  Open
Planned Release:  None

Jump to the original submission

Tue 26 May 2020 06:05:15 AM UTC, comment #11: 

Whatever :-)  I think an even better solution would be to make ttfautohint handling this as the default, with a possibility for the designer to switch it off in the control file.

I don't have time to dive into this topic, but your comments might be helpful to a forthcoming GSoC student to analyze the whole issue in more detail.

Werner LEMBERG <wl>
Group administrator
Tue 26 May 2020 05:45:25 AM UTC, comment #10: 

Another better option might be to allow adding 'important' gaps to Control Instructions File. This way font developers could select which gaps are critical due to design flaws, and add them. For instance e vs ɵ (it can be seen that Microsoft Arial preserves this gap even at 9ppem and 10ppem).

- <_194785>
Tue 26 May 2020 05:38:51 AM UTC, comment #9: 


comment #8:

> I heavily disagree.  Ensuring a gap is exactly what TrueType bytecode instructions would do in such cases.  Again: if an 'i' character looks like 'l' because the gap is missing, text becomes illegible.  And such rounding problems sometimes can happen even at larger ppem values if the font design has just a narrow gap between dot and body.


Those kinds of adjustments don't belong into autohinter hacks. The legibility example you have shown is a design flaw of many fonts and has nothing to do with ttfautohint. Design flaws like this are a major nightmare of font designers that must either have poor legibility, or drastically change the design to avoid the design flaw. For instance, DMCA Sans Serif does not have this silly design flaw as those specific characters are made with serifs, so this autohinter hack would make no sense. You might as well have the autohinter iterate through all ASCII characters and distort any character similar to another (or vice-versa); this would actually find all cases where a design flaw exists rather than this oddly specific one. If the autohinter designers keep having an oddly specific mindset like this, I might have to quit ttfautohint.

- <_194785>
Tue 26 May 2020 05:04:05 AM UTC, comment #8: 

I heavily disagree.  Ensuring a gap is exactly what TrueType bytecode instructions would do in such cases.  Again: if an 'i' character looks like 'l' because the gap is missing, text becomes illegible.  And such rounding problems sometimes can happen even at larger ppem values if the font design has just a narrow gap between dot and body.

Werner LEMBERG <wl>
Group administrator
Mon 25 May 2020 01:17:52 PM UTC, comment #7: 


comment #6:

> Well, the i dot must be separated from the body at any cost.  Only if the ppem value is too small they might collide.
>


That does not make any sense. If the gap between the base character and the accent is closer to zero than one then it makes more sense to round that gap to zero rather than stretch and distort. Please do not change this behavior, and even then not by default.

- <_194785>
Mon 25 May 2020 12:31:40 PM UTC, comment #6: 

Well, the i dot must be separated from the body at any cost.  Only if the ppem value is too small they might collide.

Werner LEMBERG <wl>
Group administrator
Mon 25 May 2020 05:23:51 AM UTC, comment #5: 

comment #4:

> Since this also happens for sizes > 10ppem for some fonts, it should be eventually fixed.
>
> I've added a GSoC idea, see https://www.freetype.org/gsoc.html


But why, just why? Wouldn't that only cause unnecessary distortions if the distance between the base character and the accent is closer to zero pixels than one?

- <_194785>
Sat 16 May 2020 04:19:54 AM UTC, comment #4: 

Since this also happens for sizes > 10ppem for some fonts, it should be eventually fixed.

I've added a GSoC idea, see https://www.freetype.org/gsoc.html

Werner LEMBERG <wl>
Group administrator
Fri 15 May 2020 07:34:03 PM UTC, comment #3: 

This is not a bug. The autohinter is working as intended and will not attempt to exaggerate those particular counters. Do not change this behavior.

- <_194785>
Sun 29 Jun 2014 04:41:09 PM UTC, comment #2: 

OK, I would be very grateful if you could look into this when you have time.

Thanks again.

zboobzor <zboobzor>
Mon 09 Jun 2014 07:52:41 AM UTC, comment #1: 

It has to be investigated whether this is easily possible.  I say yes with some limitations, however, I currently don't have time to work on this.

The very problem is that the gap between the dot and the rest of the character has to be extremely enlarged (to have a vertical size of approx. 1px), compared to the rest of the glyph at those ppem sizes.  Normally, the auto-hinter doesn't do this: shape prevention is more important.  For example, if you have a series of vertical dots, how shall the auto-hinter hint this?  At small sizes, it is impossible to always have a 1px gap between the dots; this would increase the glyph's vertical size far too much.

Such cases are much better handled with manual hinting, which actually can take care of such situations.  I think that auto-hinting below 10pt will always have some problems, and that corrections can only be partial, based on some script-specific heuristics.

Werner LEMBERG <wl>
Group administrator
Sun 08 Jun 2014 02:33:54 AM UTC, original submission:  

When using the autohinter set to hintslight the dot above 'i' and 'j' and below '?' and '!' is often too close to the rest of the character.
This can make 'i', 'l' and '!' hard to differentiate for example.

This can be seen with numerous fonts at certain sizes and weights, such as :
Verdana bold 9 and 10 pt (96 dpi)
Open Sans regular 11 pt (96 dpi)
Source Sans Pro bold 8 and 9 pt (96 dpi)
DejaVu Sans bold 8 pt (96 dpi)

Would it be possible to guarantee a certain amount of space between the dot and the rest of the characters ?

Thanks.

zboobzor <zboobzor>

 

(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 _194785 (Posted a comment)
  • -email is unavailable- added by wl (Posted a comment)
  • -email is unavailable- added by zboobzor (Submitted the item)
  •  

    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 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-06-09 wl StatusNone Confirmed
        Assigned toNone wl

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code