font-patcher: Add progress indicators

[Finii]

Fixes: #1345

Description

Please explain the changes you made here.

Requirements / Checklist

• Read the Contributing Guidelines
• I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan.
  Issue number where discussion took place: #xxx
• If this contains a font/glyph add its origin as background info below (e.g. URL)
• Verified the license of any newly added font, glyph, or glyph set. License is: xxx

What does this Pull Request (PR) do?

How should this be manually tested?

Any background context you can provide?

What are the relevant tickets (if any)?

Screenshots (if appropriate or helpful)

[Finii]

Something is wrong with the width when --variable and the glyph is align = c and has overlap 🤔

Compare handling of EE01 and 2630

[Finii]

• 2630
  • 1080
  • 0 ; 0
• E0B0
  • 1200
  • -72 ; 0
• EE00
  • 1178
  • 113 ; 59
• EE01
  • 1297
  • -60 ; -37 (@ 1260)

💡 fixed - The symbol font may not have negative bearings

[Finii]

😬

[Finii]

There is obviously a problem with center aligned glyphs... But that is already there before this MR :-(

Two notabke commits:

acd49cc font-patcher: Fix overlap for align c and r
5b36e8e font-patcher: Keep overlap in proportional font

    font-patcher: Fix overlap for align c and r
    
    [why]
    The box drawing glyphs (center aligned) and some Powerline glyphs (that
    are right aligned and have a limited xy-ratio) are positioned wrong.
    
    Affected are all box drawing glyphs (e.g. 2548) and some Powerline
    glyphs (i.e. E0B2, E0B6, E0C5, E0C7, and E0D4).
    
    [how]
    The box drawing glyphs are center aligned and have overlap. The code
    does not correct the overlap (left bearing) but uses the default case of
    'make the left bearing zero'. The code does just check left aligned
    glyphs and not center aligned ones.
    Add the correct overlap for center aligned glyphs (i.e. half the
    overlap).
    
    The Powerline glyphs are right aligned. Usually that works, because the
    glyphs are created with the right size, so that no additional
    manipulation is needed.
    But if the glyph has a ratio limit the resulting size will be different.
    We could in fact fix the size code, somehow, but that is rather
    complicated, formula-wise. Instead we just scale these glyphs (which are
    the 5 listed above) and shift them to the right position such that the
    correct overlap results.

    font-patcher: Keep overlap in proportional font
    
    [why]
    The previous commit is somewhat incomplete in some cases and plain wrong
    in others (with proportional fonts). Examples:
    
    The Heard 0x2665 gets a positive right side bearing, which is
    unexpected. The commits prevents negative right side bearings but not
    positive ones.
    
    The glyphs with overlap (which are the Powerline ones) like 0xE0B0 and
    0xE0B2 end up in wrong sizes.
    
    This can especially be seen with the Symbols-Only (non-Mono) font,
    because that is (secretly) a 'Nerd Font Propo' (--variable-width-glyphs)
    font.
    
    [how]
    This is kind of a design choice: As with the other patched font variants
    we ignore existing borders (positive bearings) around the glyph. The
    previous commit tried to keep them, which seems to be impossible and
    is inconsistent). Also negative bearings would be ignored (but there are
    none).
    
    The only place where bearings come into play is now when we have
    overlap. All non-overlap glyphs render without any bearing.
    
    If we have overlap we need to
    a) reduce the width by the overlap
    b) introduce a negative bearing on the appropriate side
    
    First we remove any left side bearing by transforming the glyph to the
    side, such that the bearing becomes zero.
    
    For left-side overlap we additionally transform the glyph by the overlap
    amount to the left (as usual). This creates the neg. left bearing.
    
    For right-side overlap we keep the left bearing to be zero.
    
    After correcting the left-side bearing (by transforming) we set the
    corrected width. That is the width subtracted by the overlap.
    In the left-aligned case this makes the right-side bearing zero.
    In the right-aligned case this results in a negative right-side bearing.
    
    Note how fontforge handles size and bearing changes:
      Fontforge handles the width change like this:
      - Keep existing left_side_bearing
      - Set width
      - Calculate and set new right_side_bearing

Glyphs to check

• 2548
• 2630
• 2665
• E0B0
• E0B2
• E0B6
• E0C5
• E0C7
• E0D4

master branch

NFP

NF

NFM

Commit 81d052b

NFP

NF

NFM

Commit ?

NFP

NF

Another

NFP

NF

NFM

[Finii]

Not centered in SymbolsOnlyNF

Also here in Propo

[Finii]

DEBUG: Advance of 0xF0A6 in BBDIMS set 0xF0A4 - 0xF0A7 is 1417, expecting 1890
DEBUG: Advance of 0xF155 in BBDIMS set 0xF153 - 0xF15A is 1175, expecting 1181
DEBUG: Advance of 0xF177 in BBDIMS set 0xF175 - 0xF178 is 1890, expecting 1417
DEBUG: Advance of 0xF05C in BBDIMS set 0xF059 - 0xF0B1 is 1537, expecting 1533

FONTA_SCALE_LIST         range(0xf0a4, 0xf0a7 + 1), # pointing hands
FONTA_SCALE_LIST         range(0xf153, 0xf15a + 1), # currencies   
FONTA_SCALE_LIST         range(0xf175, 0xf178 + 1), # long arrows   
WEATH_SCALE_LIST         [*range(0xf059, 0xf061 + 1), 0xf0b1], # wind directions 

[Finii]

So lets crate a list of fonts that need to be tested

• CascadiaCode NF NFM NFP
• SymbolsOnly NF(P) NFM
• BigBlueTermPlus NF NFM NFP

Preparing fonts prior to this PR...