Develop strategy for handling user input of characters that are not in the current font

[kontur]

When a user writes and types glyphs that are not in the font it is not necessarily clear to the user that those signs are not coming from the selected font.

There could be multiple ways to handle this, possible via settings:

• Do nothing - uses site or browser or operating system fallback
• Prevent user from inputting unsupported characters
• Alert or highlight any such characters that are not included (i.e. served from fallback)
• Output instead the .notdef char of the current font (of a fallback, if current font has none)

[Vereschagin]

• Do nothing: User thinks something is wrong with the font. Lost sale.
• Prevent user from inputting: User thinks something is wrong with the site. Frustrated user.
• Alert or highlight: Preferred option. Better: alert and highlight.
• Output .notdef char: User thinks the full font does not contain the glyph(s) they need. Lost sale.

[kontur]

Thanks for your input! Can I ask... do you think it would be needed to have two classes of missing glyphs, so to react to them differently: One set of glyphs which is essentially detected from the actual file, and an optional set that you could provide that is "included in the font, but not the fontsampler tester woff".

So say å is in the actual font, but not in the Fontsampler woff. Fontsampler would detect that å is being typed or pasted in, but because the unicode for å was provided in the admin area as "supported" Fontsampler would alert "Font not in the Fontsampler preview, but included in the actual font". Whereas say the font does not actually have ল in it, so when ল is typed of pasted in, it would alert "ল not supported by this font".

For this example I could imagine it working well that the "not supported in preview" would simply render greyed out with a fallback, whereas the "not in the font" would render highlighted red in a fallback font. So users could really input whatever text, but the Fontsampler interface would give feedback on what the lack of support means.

Would be great to get more feedback on this issue first :)

[Vereschagin]

Good thinking. Having two different alert messages is definitely a good idea. I think it is necessary to advise the user on whether missing glyphs in the rendering (which we shouldn't call "glyphs" for the user, we should probably use "characters") is not in the preview font or not in the full font.

Think a bit more, there could be cases where a user might try both glyphs that are not in the preview WOFF and not in the full font. So distinguishing between the two in the rendering would be desirable. In such a case both alert messages should show and should be clearly visually linked to the missing glyphs in the rendering. Maybe through colour? The colour of the alert box would match the colour of the fallback glyph.

[lettersoup]

I do not understand why there should be a difference between the WOFF and the "full font". The usual case is: "What you see is what you buy". Everything else would be confusing. So maybe - Output .notdef char: Lost sale, because the user do not need that font. But also saved time for customer support if the user buys the font and then cancels the order.

[kontur]

Thanks for weighting in @lettersoup

I think for many users a common use case is to use a subset preview that does not contain all features or characters - in fact that is how I am using it myself as well. The implementation for this could have different options, some of which might be more or less suitable for users that use full fonts. Let's try make a list of possible reactions for characters outside the font range:

• Render .notdef (uses webfont's if supplied, fallback if not) for characters outside the font's range, no checks required
• Render nothing (i.e. block or remove input) for characters outside the font's range

This can then be combined with visual feedback:

• Visually highlight the missing glyph (fallback or .notdef)
• Show a message for characters outside the font's range
• Show a message for characters that are outside the font's range but included in a provided custom list of unicode codepoints (i.e. use case of showing subsets but wanting to communicate that the full font supports this character)

[lettersoup]

Hey Johannes, as a user, who uses full fonts I will be completely happy with: Render .notdef character of the current font I do understand the idea of using subsets to reduce the loading time. But I think from customers perspective thats not a good one, because the customer does not see the real performance (loading time) of the font. So following situation will be possible: He purchases the font, uploads it on his website and has a loading time of X sec. instead of Y sec. (X>Y)

The other solutions are also possible but a bit komplex. Such visual feedback will require customisation to look good in different use cases.

[kontur]

Yes, I agree. I think the biggest motivation for plugin users to use subsets are DRM concerns, meaning they do not want to expose the full webfont to piracy. I trust users that would like the message display are also invested enough to tailor the visual display to their needs, my implementation would be to show and then hide the message and provide a default way of displaying it in the Fontsampler UI.

Also, load times vary on a lot of factors, so I personally am not so much concerned with how potential subset usage distorts the load performance. Most uses of this plugin vary greatly from the actual font use, so loading many (subset) styles fast may be more desirable than to showcase a 1:1 copy of the webfont as provided on purchase.

[lettersoup]

I understand. So maybe a possible way would be to let the user to choose from one of this options. So everybody will be happy.

[kontur]

This feature will come with the next update. Available options on encountering a character in the input that is not defined will be:

• Do nothing (current behavior)
• Highlight visually (color)
• Force render of notdef character
• Block / remove that input

There is a javascript event that fires when this happens, so a custom message to the user can be implemented, but this warning is not included in the plugin code per se for now.

[kontur]

The above options are now available in the 0.4.0 update. You can also use the .fontsampler-glyph-highlight class to force overwrite the highlight style in your theme, if you want more than just a color highlight.