Return whether we loaded from a secondary font

[da-x]

No description provided.

[chrisduerr]

?

[da-x]

@chrisduerr it's needed for this alacritty/alacritty#663 (comment)

[kchibisov]

I don't see how those relates, could you elaborate?

[da-x]

@kchibisov see the Alacritty change depending on this -

da-x/alacritty@a2dde2a

The idea is to be able to align the letters in the center:

But it only needs to apply if a secondary font was picked. Can you see this implemented in Alacritty without this change?

[chrisduerr]

But it only needs to apply if a secondary font was picked. Can you see this implemented in Alacritty without this change?

Why are you making decisions based on it being a secondary font or not? That seems irrelevant for your example. Sounds like you're just trying to shoehorn a non-monospace font, or a font with different monospace width, into the width of the primary font.

[kchibisov]

If you want to do so, I'd assume a completely different approach to shift everything by a main font baseline, so they characters align, which might be not a bad idea.

[da-x]

@kchibisov Maybe the issue with my original change, that the fixup for the secondary font: glyph.left += ((self.metrics.average_advance - glyph.width as f64) / 2.0) as i32; is wrong for primary font because I should have picked something other than average_advance? That other thing should be equal to width for the primary monospace font so that we can simply remove the condition and it would work for all fonts.

[kchibisov]

I'm just saying that you don't need this change to crossfont to implement what you want, you know that font is different by the fontkey.

[da-x]

@kchibisov I'm confused - looks to me that load_regular_font returns only a single FontKey representing both the primary and the internal crossfont fallback that is used only for the Hebrew letters. How can I make use of that in load_glyph?

[kchibisov]

Hm, indeed. You can generally, identify downstream whether and how you need to make adjustment, since you know what the glyph from the main font looks like (the one you've initially asked for).

Though, I agree that API is not optimal, since we don't have metric information for fallback fonts, and what fallback font even is, since we use information from the main font primary.

That being said, the proposed API feels more like a hack, rather than proper way to give a clear description of fonts and identity of fallback fonts.