You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@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).
The text was updated successfully, but these errors were encountered:
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.
@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
constructorhas_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 likemax
)glyph_index(char)
,glyph_hor_advance(glyph_id)
,outline_glyph(glyph_id, builder)
, ... — glyph-specific functionality abstracted over by the virtual fallback fontThe
GlyphId
type currently uses au16
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. whetherGlyphId
becomes an associated type).The text was updated successfully, but these errors were encountered: