Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Font fallbacks #42

Closed
dhardy opened this issue Aug 25, 2020 · 1 comment
Closed

Font fallbacks #42

dhardy opened this issue Aug 25, 2020 · 1 comment

Comments

@dhardy
Copy link
Contributor

dhardy commented Aug 25, 2020

@RazrFalcon have you thought about font fallbacks? As I understand, there are two parts: selecting fallback fonts, and building a virtual font pulling glyphs from the first supporting font. The second part could be supported here or could be left to a higher-level library.

The Face struct has several classes of methods:

  • from_slice constructor
  • has_table, table_data, character_mapping_subtables, ... — low-level stuff which it doesn't make sense to expose in a virtual "fallback font"
  • is_regular, is_monospaced, weight, ascender, ... — properties which could be taken from the first font (or perhaps in some cases combined via a func like max)
  • glyph_index(char), glyph_hor_advance(glyph_id), outline_glyph(glyph_id, builder), ... — glyph-specific functionality abstracted over by the virtual fallback font

The GlyphId type currently uses a u16 which is likely insufficient for the fallback font — this type could be made an associated type of a trait or simply larger.

Given the above, it might make more sense to implement font fallback at a higher level, e.g. via the ab_glyph::Font trait (if @alexheretic wishes to support font fallbacks), but I thought it would make sense to ask here first since (a) you (@RazrFalcon) may have already considered this and (b) whatever choice is made here has implications for downstream libraries (e.g. whether GlyphId becomes an associated type).

@RazrFalcon
Copy link
Collaborator

Font fallback is out of scope of this library and will probably be implemented in a separate crate using the fontdb. Also, I'm planing to use the shaper-based fallback. But I have to finish porting harfbuzz first.

I've actually have a sort of roadmap here. And as you can see, we're are miles behind. At least in a pure Rust way.

The GlyphId type currently uses a u16 which is likely insufficient for the fallback font

TrueType glyphs are always u16. So this is not a problem. And there is no point in supporting other font formats.

Anyway, this crate will remain just a low-level, zero-alloc TrueType parser. Nothing more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants