Searching for special characters

[doug1120]

I need to use the Find/Change dialog to search for special characters (like the Greek symbol for Omega).  I can copy the character from the body of my document and paste it into the Find window, but in this case it pastes the letter W.  While this does find the Omegas accurately, it also finds any word with the letter W in it.

How can I search for special characters using the Find/Change dialog?

Thanks!

[Winfried Reng · Accepted solution]

Hi Doug,

Probably you have Symbol or a similar font applied.

Then FrameMaker cannot find this text.

You could copy your Omega character into the clipboard and then search for "Text and Character Formats on Clipboard".

Best regards

Winfried

[Bob_Niland]

Winfried: Probably you have Symbol or a similar font applied.

More precisely, a legacy overlay/codepage font applied, where the character code points are in what is now the Unicode Basic Latin/Latin-1 Supplement (0x00-0xFF), but the glyphs in the assigned font are completely different. For non-Latin characters, things usually had to be done that way pre-Unicode (and pre-FM8), as there were usually only 256 codepoints to work with.

Most of the glyphs in the legacy Windows and Zapf Symbol overlay fonts have codepoints in Unicode, and most competent Unicode fonts populate them. For revised or new FM documents, don't use overlay fonts where your body font has the Unicode character needed.

Modern way: just type the character as an Ω, or enter it via a dialog as \u03a9

It is sometimes necessary to use the old method, chiefly with glyphs never/not-yet adopted by Unicode, not populated in your Unicode fonts, or where the obligatory entity typeface itself covers only the 8-bit range. In such cases, I suggest implementing these characters as consistently identified variables, so that they are easy to batch-revise at some future font review.

Suppose the corporate font is Woeful Sans, and lacks an Ω.

Create a Character Format that is As-Is except for Family, referencing the font with the glyph, for example Liberation Sans.

Create a Variable for the character, using the formal Unicode name where there is one:
Name: U+03A9 GREEK CAPITAL LETTER OMEGA
Definition: <Liberation Sans>\u03a9

Never do it as a local override.

[doug1120]

How do I enter \u03a9 in a dialog?

[Bob_Niland]

doug1120: How do I enter \u03a9 in a dialog?

It depends on the dialog. Some support \x and \u notation, some don't.

For main edit window in recent FMs, just use:
Insert » Character » Hex Input [03a9] Enter

[doug1120]

I asked this question because my HTML was displaying the W instead of the Ω symbol when Firefox was the browser; Chrome, IE, and Edge all display the Ω accurately.

Any idea why Firefox doesn't display the character when formatted with the Symbol font?

Thanks,

[Winfried Reng]

Hi Doug,

Thank you for pointing me to this issue! I also just started to set up the conversion to HTML5.

And I had not noticed yet that Firefox (which I also use) does not display the symbol font characters.

My currect font is Google Open Sans, and this has the Ohm character.

And this is converted nicely.

Can you switch to a similar font with the Ohm character?

I am pretty sure that e.g. Arial also this character.

Of course you must test this also on your mobile devices.

Best regards

Winfried

[doug1120]

Yes, I'm currently switching fonts from Symbol to another font.  Not sure which just yet, but I've found that a good number of them support this symbol.  The same goes for Mu Epsilon, which Firefox also botches (display "me" instead of "UE").  I'm sure there are others, I just need to scan my docs for these special symbols.

I consider them symbols, which is why I chose the Symbol font in the first place.  Sigh.

Thanks!

[Bob_Niland]

doug1120: Any idea why Firefox doesn't display the character when formatted with the Symbol font?

A peek at the generated HTML would probably provide some clues. My guess is that there's some CSS involved, that is calling for perhaps "font-family: Symbol", and different browsers have different implementations and fallbacks, and behavior might vary by client system (fonts installed, and fonts available to browser).

In the specific case of the character at hand, be aware that there are at least two of these in Unicode:
Ω (U+03A9) and Ω (U+2126)
The former is semantically the Greek letter, and the latter is the legacy electrical ohm symbol, and I say legacy because it's considered deprecated in Unicode.

[doug1120]

I went to the Firefox help site and found this:

Fonts like the Symbol font that map on the basic ASCII set may not work in Firefox.

It is best to always use the Unicode representation of characters to avoid font problems because in that case any font that supports those symbols can be used and it works on all platforms if you have a font that covers that Unicode range.

Apparently they want web content developers to follow a certain set of standards and best practices (which the other browsers don't mind you flaunting, I guess).  In other words, Mozilla has done this on purpose. 

[Bob_Niland]

doug1120: (which the other browsers don't mind you flaunting, I guess).

Browsers actually have to be tolerant of a lot of legacy, sloppy and damaged markup, but they have limits.

re: In other words, Mozilla has done this on purpose.

We'd have to research the development history to really frame this, which I haven't.

Browsers already have to perform a lot of font magic. Suppose the page developer specifies a font that isn't populated for some character code point - or is, but not on the users device (e.g. phone) - or the user has done a font override on the page. Does the browser try to figure out how to fake it?

I do content support for a couple of Wordpress blogs, and the rendered page almost never fails to display the intended glyph, even for some obscure and recent codepoints. Sometimes what is displayed is actually an embedded graphical object, with metadata containing the Unicode code point. Impressive.

Adding typographical archeology to this (trying to figure out what appears to be a "W" is really supposed to be some other glyph, based on relatively-Windows-centric 1994 customs), might be a "bit" too far in the context of some browser's overall algorithm base.

Don't generate web pages in EBCDIC or Baudot either