Symbols not rendering correctly as Webhelp

[zaneplove]

Hi


I recently replaced a whole lot of 'tick/check' images throughout my project with a Wingding symbol:

windingticks.png

But I get the following symbol in Webhelp output. PDFs look fine.

windingoutput.png

Any way to prevent this?


Thanks
Zane

[Tim Green]

Hi Zane,

You can't really use WingDings on the web because it's a Windows-specific font. Most web servers are Linux or Unix and they don't support Windows fonts. Much of this is the result of political squabbling -- open-source browsers sometimes refuse to display Windows fonts even when the browser is running on Windows, for example. The only real way around this is to use small graphics.

[Simon Dismore]

Any way to prevent this?

TL;DR: I don't know an easy solution. In my tests the results were inconclusive. It depends whether you want to use the check mark as a list bullet, or within a paragraph (i.e. inserted as a symbol within text), or both. The background is that WingDings is a Microsoft proprietary font that displays a check mark in place of ü (Unicode U+00FC lowercase u umlaut, hex ü, decimal ü). The correct Unicode character code for a check mark is U+2713 (hex ✓, decimal ✓). But to display this you need to use a font that actually contains the right "glyph" for a check mark.

If you use WingDings U+00FC as a list bullet: Help & Manual automatically substitutes U+2713 and sets the font to "Arial Unicode MS; Lucida Sans Unicode; Arial". A check mark is displayed if the client device has Arial Unicode installed, but nothing otherwise. AFAICS this works on current Windows, iPad and iPhone. I haven't tried it on Android yet.

If you use WingDings U+00FC within a paragraph: Help & Manual leaves it unchanged and sets the font to "WingDings". A check mark is displayed if the client device has the WingDings font installed. If WingDings isn't available—e.g. on a non-Windows device like an iPad or iPhone—the browser substitutes a different font and you see the ü instead.

Possible workarounds:

• Use a graphic file. Problem #1 is that the Help & Manual editor apparently can't use bitmaps (or SVG drawings) as list bullets for PDF or WebHelp. I think SVG should be supported because it can produce sharp PDFs at any resolution, and behaves better than bitmaps when scaled in modern browsers. But it is very much an HTML5-only feature. Graphics such as Iconic are available as both fonts and as SVG, so maybe that's a stepping stone.
• Use Arial Unicode U+2713. Problem #2 is that Help & Manual doesn't let you insert a symbol above U+00FF, so you have to paste it from Windows Character Map. Problem #3 is you can't rely on this font being available on all current and future platforms.
• Use a specific font and Unicode U+2713, e.g. Adobe Source Sans (which is free) to work around problem #3. Problem #2 still applies. Problem #4 is you have to work out how to package the font onto your website. Problem #5 is the overhead for each client to download a non-standard Unicode font.

In my opinion SVG will be the way to go in future. It is compact, resolution-independent, css-stylable and scriptable. But I haven't managed to convince Tim, so don't hold your breath for decent SVG support in H&M 7. But at least they should fix problem #1.

Resources:

• Alan Wood: Wingdings font should not be used in Web pages.
• Joel Spolsky: The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
• Apple: OS X: Fonts included with Mountain Lion
• Apple: iOS 7: Font list
• Adobe: Source Sans Pro, Adobe’s first open source type family
• Sourceforge: Source Sans Pro downloads
• Typekit: Source Sans Pro
• UseIconic: Iconic icons available as both SVG and font

[Tim Green]

Hi Simon,

Thanks for the great coverage of this topic!

In my opinion SVG will be the way to go in future. It is compact, resolution-independent, css-stylable and scriptable. But I haven't managed to convince Tim, so don't hold your breath for decent SVG support in H&M 7. But at least they should fix problem #1.

It's really not my decision. I'm all for SVG in principle, the problem is that the output needs to work across all publishing formats supported by Help & Manual, and according to Alexander and Michael, none of the converters they've tried so far produce acceptable results. And the problems are not just resolution: Since SVG is a vector format, the interpretation needs to be very accurate to be acceptable, and in the available converters it just isn't. The output doesn't just look bad, it looks downright wrong.

Here's an example, I'll let you see if you can guess which is the original SVG and which is the conversion:

svg_conversion.png

[zaneplove]

Thanks for the comprehensive answers Tim and Simon, very informative.