PDA

View Full Version : Different Font and Font Size in Email Field


-Lisa-
October 8th, 2010, 12:10 PM
Does anyone have a rule that returns a different font and front size for the "@" symbol in an Email field?

Thanks in advance!

Dan Korn
October 11th, 2010, 05:03 PM
Something like this:
return ReplaceSubstring(Field("email"), '@', '<span font="Arial" pointsize=20>@</span>');More about the <span> tag
(http://forums.printable.com/showthread.php?p=1819#post1819)

esmith
October 12th, 2010, 08:32 AM
I always forget about the span tag, but in the case of substituting a font for a character(s) what is the advantage to using a span tag (<span></span>) instead of just surrounding the character(s) with a font tag (<f></f>) instead?

Of course, I can see where the span tag might be a better solution when using tags that don't have a closing tag (<z>, <setwidth>) versus having to trail the changed string with another tag to revert the attribute. Which begs the question, why don't these tags have associated closing tags?

Dan Korn
October 12th, 2010, 09:22 AM
I always forget about the span tag, but in the case of substituting a font for a character(s) what is the advantage to using a span tag (<span></span>) instead of just surrounding the character(s) with a font tag (<f></f>) instead?

Of course, I can see where the span tag might be a better solution when using tags that don't have a closing tag (<z>, <setwidth>) versus having to trail the changed string with another tag to revert the attribute.
Yes, that's exactly it. The rule above works without any knowledge of what running point size it has to revert to.
Which begs the question, why don't these tags have associated closing tags?
Because FusionPro's tagging is (loosely) based on HTML, which has ending bold, underline, and italic tags, but doesn't have an ending point size tag. (Actually, HTML doesn't really have true point size tags at all, although CSS offers more fine-grain control.) And probably because the people who designed FusionPro's tagged markup to handle pre-generated tagged markup files didn't foresee every possible use case involving tagging generated via JavaScript rules.