Great point. No you are right that is a problem, and yes the solution I built could solve it as is, but perhaps it is not the most elegant solution for those general cases. Every application wo uld have to add the fonts they think they will need. In my app's case this isn't a problem, I know exactly what fonts I will ever run into. But in other apps they may be pointing to content that has not yet been created, and it may reference a font that simply isn't on the system. The way HtmlRenderer does this today is it delegates to the parent through inheritance, and eventually to MS sans serif.
I do think technically what I proposed is the right solution, but perhaps for very common fonts that are often missing from HtmlRenderer could actually embed them within the assembly itself. During FontFactory constructor it would add these embedded fonts to the FontFactory. Philosophically it is no different than the fact that it HtmlRenderer comes with it's own default base CSS. You don't have to start from scratch with your CSS. You could say the same for the fonts, for common web fonts, they would already be included. The downside is this would slightly bloat the HtmlRenderer assembly. At a minimum, all of the fonts referenced by the default CSS should come from HtmlRenderer. That way it always has coverage for itself now matter what the end user has done to the local system.
By having these be loaded during FontFactory constructor, since it is a singleton, you could also then provide a FontFactory.Instance.Clear() method so that application that want to use THEIR OWN Helvetica for example can simply call Clear() before adding in their own FontFamily instances. That way some users get the benefit of automatic coverage for all common fonts, but other users who wish to ensure that THEIR version of those fonts are used for THEIR application and re-bundled them, and add them after calling Clear().
Best of both worlds.
Thoughts?
Later,
Ryan
I do think technically what I proposed is the right solution, but perhaps for very common fonts that are often missing from HtmlRenderer could actually embed them within the assembly itself. During FontFactory constructor it would add these embedded fonts to the FontFactory. Philosophically it is no different than the fact that it HtmlRenderer comes with it's own default base CSS. You don't have to start from scratch with your CSS. You could say the same for the fonts, for common web fonts, they would already be included. The downside is this would slightly bloat the HtmlRenderer assembly. At a minimum, all of the fonts referenced by the default CSS should come from HtmlRenderer. That way it always has coverage for itself now matter what the end user has done to the local system.
By having these be loaded during FontFactory constructor, since it is a singleton, you could also then provide a FontFactory.Instance.Clear() method so that application that want to use THEIR OWN Helvetica for example can simply call Clear() before adding in their own FontFamily instances. That way some users get the benefit of automatic coverage for all common fonts, but other users who wish to ensure that THEIR version of those fonts are used for THEIR application and re-bundled them, and add them after calling Clear().
Best of both worlds.
Thoughts?
Later,
Ryan