As we all know, we can embed a font into Director and render text to the screen with the embedded font when the font is not on the user's system or the projector is running on a different platform.
However, with member().html, this is NOT the case. Unless the font is on the user's system (and on Mac OS X in system:fonts) Director will strip out the font tag completely and set the text to a default font face (Times New Roman on XP) before rendering any HTML to the screen.
So in a case of (I am omitting font tags in case your mail utility wants to render them.)
Some text that needs to be Arial. Text that should be SomeCustomEmbeddedFont *. More text in Arial...
For the above to render properly in member's html, the text wrapped with the tags for SomeCustomEmbeddedFont needs to be installed on the users system. Trust me, or try it for yourself... I have tested it extensively.
So, the not-so-elegant solution at the 11th hour, install the font to the user's sytem on a virgin startup-- not the best or worst thing in the world, it works.
Along comes OS X, and its new security model that wants permission to add a font to system:fonts... Fine. Copy the font to the root of the hard drive and then evoke an AppleScript to move it into the system:fonts folder. Up comes the security dialog, user types in password, and font gets installed.
Now projector sees the installed custom font when rendering the html.
As for the project being in this predicament:
Client is supplying HTML to be displayed in Director via a V12 database and some parsing on the fly. Within the text are special characters, such as the "Delta" character, "less than equals", etc...
These characters definitely exist in most fonts, but only much higher up in the ASCII table... Director only renders characters to a text field that have an ASCII index of less than 256, 0 - 255...
So, the solution was to create a custom font and move the needed special character glyphs into lower indexes and then wrap them in font tags that set them to the needed custom font. So for example the "dollar sign" would actually render the "delata" glyph...
This is all well and good except for one little problem, the client... ;) They don't like the idea of installing any kind of footprint (in this case a font) to the user's machine. And practically, in the field it could cuase some security/admin issues.
Anybody ever run into this type of scenario before or have any helpful suggestions????
The only ugly solution I can think of would be to have an image of the glyph 'follow' a special charater in the field and overlay it at all times. (we are actually doing this already to fake embedded images in the HTML.)
TIA,
Andy D.
[To remove yourself from this list, or to change to digest mode, go to http://www.penworks.com/lingo-l.cgi To post messages to the list, email [email protected] (Problems, email [EMAIL PROTECTED]). Lingo-L is for learning and helping with programming Lingo. Thanks!]
