Provide alternate preview text string for font faces with poor preview results #22
Comments
|
Here's a list of fonts I see that would benefit from alternative preview text (may not be complete!). Some are clearly meant for non-latin scripts, and should have previews in those scripts. Take the Noto Sans/Serif or Anek families of fonts, for example. The current previews all look nearly identical, you can't really preview the font unless using the characters the font is intended for. Other fonts were designed to support both latin and a primary script, like Kumar One, so could stay with the current preview text. But there should be some way to indicate that they are designed for another primary script. With over 300 of these fonts, there's roughly 20% of the collection that seem to be primarily intended for non-latin characters, so this seem fairly high priority to me.
|
|
Thanks, @creativecoder, for identifying other places where this idea could apply! 🙌🏻 Does the Here's an albeit simple result where {
"kind": "webfonts#webfontList",
"items": [
{
"family": "Bagel Fat One",
"variants": [
"regular"
],
"subsets": [
"korean",
"latin",
"latin-ext"
],
"version": "v1",
"lastModified": "2023-06-07",
"files": {
"regular": "https://fonts.gstatic.com/s/bagelfatone/v1/hYkPPucsQOr5dy02WmQr5Zkd0Btmvv0dSbM.woff2"
},
"category": "display",
"kind": "webfonts#webfont",
"menu": "https://fonts.gstatic.com/s/bagelfatone/v1/hYkPPucsQOr5dy02WmQr5Zkd4B9svw.woff2"
}
]
}When a translation or replacement string is in place, then the UI could include the representative string and also the latin-based font name for reference. E.g. this ugly mockup: 
|
@ironprogrammer Possibly? What I'm not sure of is how to differential between fonts that are primarily for non-latin scripts and those that happen to support it. For example, here's Roboto's It has a Vietnamese subset, but is more of a general purpose font. Perhaps a font with only latin(-ext) and one other subset would be an indicator? It needs more investigation.
I think having both is a good idea. |
Follow up to #20.
From #20 (comment):
The end result would be that the font family
namedisplayed in the UI would be taken from this string, whether as actual text (presuming the font face has been enqueued) or used in place offamily.nameduring the SVG preview generation process.The text was updated successfully, but these errors were encountered: