Looking at wysiwyg.module this is what I find:

  wysiwyg_add_editor_settings($profile, $theme)
    $config = wysiwyg_get_editor_config($profile, $theme)
      $settings = $editor['settings callback']($editor, $profile->settings, $theme)

Hope that helps a bit.

Status:Active» Postponed (maintainer needs more info)

Why do you want to configure the width and height per field in the first place?

And why can't you use CSS to adjust the width of the surrounding container?

Why do I want to do it? One word - "multigroups". If you haven't tried them yet in CCK (currently in version 3.x), then you're missing out! When I get in to work tomorrow, I'll show a screenshot of what I'm working with. But for now, I was able to find a work around of sorts.

First, there was a bit of code which specified the height of all WYSIWYG boxes to be 400px, which I commented out. This has the result of using the fckeditor default height of 200px, which was better for me.

Second, since there is code which I mentioned before that specifically disallows the changing of the height/width of a WYSIWYG box, I instead made the text areas the last item in the multigroup row and then specified the widths of all of the items before it. This allowed the text area to fill the remaining space. I would imagine though, that there could be times where it is not convenient to reorder form elements to make this accommodation.

If you don't know what code I'm referring to when I say that there is a function that disallows the changing of the width and height, I'll look it up for you. There is actually a comment there in the code that says 'prevent', or 'don't allow', or 'disallow' or something like that. You could do a search. I don't recall whether that was in fckeditor itself or WYSIWYG. I think it was in fckeditor since the dimensions are supposed to be passed in as constructor parameters. So... what I really need is a way to set the constructor parameters for each instance of the WYSIWYG.

Make sense?

well, multigroup or not - do you think that admins will (and want to) configure editors separately for every single field in their Drupal site?

obviously, you give them the default that now exists. But really, yes, I do think admins want this, which is why most of the basic CCK fields have width/length settings. I mean, the standard text area allows you to set the height, which this module also doesn't honor.

I realize that others haven't chimed in on this, but then again, this post isn't very visible. Without multigroups, which is in the 3.x version of CCK now and will be official soon, one can always move the text area to another line. With multigroups, you can't.

Try multigroups before you decide one way or the other.

Configuring the height of fields is very important. If you need to create a CCK field which needs to contain a small amount of formatting information, you'll want to be able to keep those fields from blowing up your edit form vertically.

On every site we do, I configure at least five additional filtered-text fields for every node that is ever rendered as a page:

  1. "Kicker" or "eyebrow" headline, to be displayed above the title, which must be able to include markup and special characters.
  2. Alternate "formatted title", for cases where the Title needs to include markup or characters that can't be included in the standard node TITTLE field.
  3. Secondary headline, displayed below the Title, which must be able to include markup and special characters.
  4. Side Content field, to be displayed in the sidebar.
  5. Abstract (Teaser) field, to serve as a teaser.

The first three need to be shorter than body copy fields, or you have the following problems with users:

  • Users are already intimidated by the many-page vertical scroll of a node edit form that includes extra fields and features; if you can't shorten the edit box, it gets even worse.
  • There's also a usability issue in that with fields having related function (e.g., the Formatted Title over-rides the Title), the very large boxes tend to force the fields onto different screens from one another.
  • They are liable to see the large size of textareas as a tacit encouragement to add too much text or do formatting that's not appropriate to the layout.

Short version: This is just something people need to do. Other editor modules support it. It's a significant usability problem to not have it. WYSIWYG is not a viable option for any site my company implements until this feature is included.

Just to add to the discussion... being able to set the dimensions of each field is quite an important feature. I often have textarea's that should only be 2 lines long, and others that should be significantly more, depending on the context.

"And why can't you use CSS to adjust the width of the surrounding container?"

@sun - I'm not sure how to make this work. I'm using fckeditor and have been playing around with the CSS for quite awhile to get it to the right height. In FF this isn't a problem, but in Safari the scroll bar goes far beyond the end of the textarea when I do this. Basically the surrounding container's height is shorter, but the inner container isn't respecting that in Safari at least. How can the height be set properly using CSS? I can attach a screenshot if that would help.

- Scott

Also, I notice that this has been set to "postponed (maintainer needs more info)" for quite a while. What info do you need for this to move forward?

new1.42 KB

Here's a patch that's basically just a quick hack using the $rows attribute of the textarea field. I'm not sure how reliable converting rows into pixels is, but it seemed to work ok for me.

Title:Set width for each fieldAllow individual width/height per field
Component:Editor - FCKeditor» Code
Status:Postponed (maintainer needs more info)» Active

Any headway on this? It seems like the FCK editor should adjust height based on the number of rows in the textarea so we don't have to do this granular adjustment.

I think I mentioned in another issue that a bug related to FCKeditor not always respecting the textarea's height got fixed recently in the FCKeditor library. Could you try with the latest version and report back?

im using the latest version of fck editor -, ckeditor is not supported right? or i should say with imce. i want whatever editor is going to work with imce or some kind of image uploader

If you ask that, then you are at least not using the latest version of Wysiwyg module. ;)

I'm using version 6.x-2.1, what am I supposed to be using?


I can change the width by overriding CSS values for CCK text area's which get a unique id e.g. #edit-field-textarea-0-value-wrapper.
But this will give problems with multiple content types that need different widths.

edit: created a unique body class for each content type which allows me to target each individual content type.

subscribe (using ckeditor)

I have a similar issue, which perhaps could fall into a different request, but I'll put it here and leave it for you to decide.

I'm using WYSWYG with CKEditor

A project I'm working on requires very customized node edit displays, that differ substantially per cck node type. Substantially not just in CSS look and feel, but in layout and additional form elements.

I want to be able to customize each CKEditor depending on what the node type is, and again depending on what display that is.

I'm using

module_wysiwyg_editor_settings_alter(&$settings, &$context)

to alter the width and height settings using arg(n) checks to see where I am.

But one would think you could add a 'node' index to the $context array - so that a coder can more cleanly make adjustments to the size and shape of the editor depending on node values.

Thought about this more.

Would actually be smarter to append the $form object somehow to the $context, as that would deal with more situations.

I agreee with #11, the editors heigth (and possibly width) should adjust to the nr of rows (cols) provided in cck.

Status:Active» Reviewed & tested by the community
new1.9 KB

#9 works for me with TinyMCE editor. Thank you! I am attaching modified #9 patch for TinyMCE and FCKEeditor.

new3.33 KB

This approach makes sense to me - rather than deciding all textareas must and shall be 420 pixels high, why not estimate based on #rows?

I'm attaching a reroll that adds ckeditor support and fixes minor code style issues.

+++ wysiwyg.module 23 Jun 2010 00:44:35 -0000
@@ -170,6 +170,10 @@ function wysiwyg_process_form(&$form) {
+              $profile->settings['height'] = $field['#rows'] ? 40 + 29 + 15 * ($field['#rows'] - 1) : 400;

Maybe we should do this calculation in the editor implementations and just store the number of rows here?
The reason being we don't know how many toolbar rows there will be. (Actually, the implementations don't know that either yet, so I think we could change that later if needed.)

+++ wysiwyg.module 23 Jun 2010 00:44:35 -0000
@@ -170,6 +170,10 @@ function wysiwyg_process_form(&$form) {
+              ¶

Tab. ;)
No need to reroll for that.

Powered by Dreditor.

Status:Reviewed & tested by the community» Needs work

+++ wysiwyg.module 23 Jun 2010 00:44:35 -0000
@@ -170,6 +170,10 @@ function wysiwyg_process_form(&$form) {
+              // Rough estimate of textarea height in pixels:
+              // 40 for the toolbar, 29 for the first row, and 15 for the rest.
+              $profile->settings['height'] = $field['#rows'] ? 40 + 29 + 15 * ($field['#rows'] - 1) : 400;
+              ¶

1) We should make sure that modules that are altering profile settings can override this value. Not sure when the drupal_alter() actually happens, but ideally of course, the pre-calculated height should be contained already (i.e., making the alter come afterwards).

2) Looks like $field['#rows'] is presumed and required to exist? Possibly the test should have been !empty().

3) Do I need to understand the -1 (minus one)? A field having 1 row will lead to a height of 0 (zero).


Powered by Dreditor.

Status:Needs review» Needs work

1) I assumed the alter hook would be called after this, I might be wrong though, need to check the code.

2) You're right.

3) "29 for the first row", 1 row means 40+29+(15*0) pixels. This is part why I wanted to move this calculation to the implementations, those constants may not be valid for all editors.

4) =P

EDIT: Had missed a quite important little word, see highlight above.


The methodology in #22 is mostly working for me with ckeditor. My only problem right now is that a CCK multi-line text field is not honoring the number of rows in a node creation form. I'm using the Rubik theme if that matters (not sure why it would). The strange thing is that TinyMCE seems to honor the number of rows properly within the same form.\

Any thoughts?

This also doesn't seem to be working if there are multiple fields on a single form w/ different row values. For instance, I have 4 textareas on a single form, but wysiwyg_ckeditor_settings is only being called for the first one (and the rest of the textareas are using the same settings).

Oh, this is happening because of this function:

function wysiwyg_add_editor_settings($profile, $theme) {
  static $formats = array();
  if (!isset($formats[$profile->format])) {
    $config = wysiwyg_get_editor_config($profile, $theme);
    // drupal_to_js() does not properly convert numeric array keys, so we need
    // to use a string instead of the format id.
    drupal_add_js(array('wysiwyg' => array('configs' => array($profile->editor => array('format' . $profile->format => $config)))), 'setting');
    $formats[$profile->format] = TRUE;

It's caching by format, not by a particular field's format. Since these could each be unique, and fields shouldn't repeat, this needs to be rewritten so that it works on a per-field basis and not a per-format basis.

Status:Needs work» Needs review
new7.23 KB

OK, here's a patch that addresses the issue I mentioned in #29.

Re: sun's first issue in #24: the drupal_alter comes after the height computation here, so it's not an issue.

@mcarbone, thanks!! initial testing with your #30 patch seems to be working great.

This patch in #30 worked with ckeditor.
Thank you!

#30 works with ckeditor for me too. Thanks a lot!!!!

Status:Needs work» Needs review

#30 works nice (tested for FCKeditor 2.6.6. so far), resolved my strong headache, thank you!!!

Status:Needs review» Reviewed & tested by the community

#30 <-- works perfekt!

This is the fourth test and considered to be rtbc.

I tested this with ckeditor and fckeditor.

Very good patch!

patch #30 worked for me. I'm using recommended version 6.x-2.1. Had some offset's show up when running the patch but it still worked. Thanks a lot

Status:Reviewed & tested by the community» Needs review

Thanks for working on this! However, it seems like this patch is now touching logic that is essential for all editors. It doesn't look like it has been tested with any other editor than (F)CKEditor. Those changes require some careful review, but also testing all other supported editors.

It seems to work for me using CKEditor. I am only using it for 1 field and I dont allow them to add another. It is also very limited with buttons like bold, italic, underline, etc. I haven't seen any issues yet but haven't tried to do anything out of the normal for a basic user.

Status:Needs review» Needs work

Hmm, this is not good..
If we need this feature, it sould eliminate the wysiwyg profile cache system complete, if the a field has #row attribute.
This happens, if preview something: #939258: ckeditor disappears if pressing preview

I don't know, what would be the best, maybe a checkbox in profile edit form, to enable resize editor made on textarea #row settings..

For CCK fields there is this patch for the standalone CKEditor - it adjusts the height of editor by CCK field setting

Seeing same issue mention in #39 (CKEditor disappear when user is previewing a node as a consequence of patch at #30)....:-(

I can confirm this problem. Any suggestions for how to get around this? The width patch is very important but so is this issue of the node preview. Thanks for your help.

#30 worked like a charm but crucial to note that it only worked against 6.x-2.1. This solved a lot of headaches for me. thanks.

Subscribe this is really useful. I'll work on re-rolling this for 7.x-2.x tonight.

@Dave, would you mind moving the hard-coded constants added to the calculations out to the editor implementation files while you're at it? That way the height/width can accomodate for variations in toolbar heights etc between editors.

I haven't tried the patch in #30 yet, but one of the things worrying me is that on a page with a lot of format-fields, Drupal.settings.wysiwyg.configs might become huge as all format settings are duplicated per field, except for the width/height. (Sorry if I'm misinterpreting the patch.)
I would rather have per-field settings stored somewhere separate (maybe Drupal.settings.wysiwyg.configs.fields[field][editor], if they aren't going to be different per format). Or something like the global per-editor settings, so these can be merged together from "normalized data pools" (thinking of normalized SQL tables here) with as little duplication as possible.

That reminds me of a possible issue in D7 now that formats have machine-names... currently they are all stored with a 'format'-prefix, but if we eliminate that we'll get issues if someone names their format "global". Maybe we should keep prefixes after all...

Version:6.x-2.x-dev» 7.x-2.x-dev

I share the concern about duplicating the entire editor settings.

Long-term, we need an inheritance cascade of global » format » field settings. For this issue, we need to introduce format » field overrides.

Is there a way to tell if the patch has been rolled into the latest 6.x dev version?

@highrockmedia, the easiest way to determine that is by looking at the status and version fields. We roll new features/fixes for 7.x-2.x-dev when an issue reaches RTBC, then we backport to 6.x-2.x-dev (if this doesn't happen immediately the issue is marked "patch (to be ported)") and finally mark it "fixed" once committed to all relevant branches.
So, this patch has not made it to CVS for any version yet, because of the problems mentioned in #45 and #46.

@TwoD - thanks for the info. :)


I tried to fix the issues, but failed. We need some help from an experienced maintainer. #46 is not enough clear to me.

Those recommending to use CSS for width, can you please elaborate which id / class it could be applied to for CKEditor? I successfully adjusted the height by the following (making editor less bulky for the comment entry):

.comment-form .cke_contents {
    height: 150px !important;

But this does not work for width, and there are so many layers of encapsulation, divs upon divs, and I may be missing something - applying width to some elements does not help, applying it to others breaks the editor.

Thanks for any help!




I've manually applied the patch in #30 to Wysiwyg 6.x-2.4 with CKEditor and encounter this error on any page with a Wysiwyg field:

Fatal error: Cannot use object of type stdClass as array in .../sites/all/modules/wysiwyg/wysiwyg.module on line 367

That's the line:
drupal_add_js(array('wysiwyg' => array('configs' => array($profile->editor => array('format' . $profile->format => array($field['#id'] => $config))))), 'setting');

The patch appeared to be designed with Drupal 6.x. Have I overlooked something, or does this not work with the 2.4 version?

My quick and dirty solution:

  $form['MYTEXTAREA'] = array(
    '#type' => 'text_format',
    '#attached' => array(
      'js' => array(
        'MYTEXTAREA = setInterval(function() {
           if (jQuery("#cke_contents_edit-MYTEXTAREA-value").length == 1) {
             jq("#cke_contents_edit-MYTEXTAREA-value").css("height", "100px");
        },1);' => array('type' => 'inline', 'scope' => 'footer', 'weight' => 5)

Change '100px' to your desired height.


Subscribe. (Using ckeditor and 7.x and could really use this feature.)

Subscribe... for D7 and CKeditor

Subscribe... for D7 and CKeditor


@DrupalRevisited -- Just curious about your solution in #57. Where and how do you implement this? Is it a module, in template.php or are you hacking an existing piece of code that could get overwritten later?

Yep, patch #30 alone works for me! Using D6.22, wysiwyg-6.x-2.4, CKEditor library 3.6.2
Serious thanks mcarbone. Ups the usability 10fold!

new5.99 KB

Patch #30 works, though as stated above it breaks the node preview, but that's not an issue for me. Many thanks!

Attaching the same patch, but made with git and slightly modified to work with wysiwyg-6.x-2.4.

new5.82 KB

I understand and agree with the maintainers' concerns in #45 and #46 but I don't know the module well enough to do that kind of refactoring. So in the meantime here's a version of #30 rerolled for Drupal 7, for those who need it. Conveniently it doesn't break node previews anymore. I'm guessing that's because #208611: Add drupal_array_merge_deep() and drupal_array_merge_deep_array() to stop drupal_add_js() from adding settings twice got fixed in core. So the only problem I see with the D7 version of the patch is the architectural concern.

Check the following posts for a solution: -> D7 version for

And this issue from the D8 core:

#65 worked for me on 7.x-2.1. Note that you need to use the -p1 switch on the patch command i.e.

cd sites/all/modules/wysiwyg
patch -p1 < path/to/patch/file

Thanks guys.

Status:Needs work» Reviewed & tested by the community

This patch (#65) worked for me and was VERY useful on my site!

(git apply works fine without any -p1 btw)

Status:Reviewed & tested by the community» Needs work

The patch from #65 does not work for textfields. Textfields have no row setting, though they will always be one row high.

Status:Needs work» Needs review
new6.19 KB

Patch from #65 adjusted to work with textfields (which will have a height of one row). Also moved hard-coded constants out to the editor implementation files, as per #45, first remark.

#65 worked for me on standard node fields, but caused problems when using Field Collection module.

Say I have a field collection defined with a long text field and using WYSIWYG formatter. I can create a node and fill out the first field collection entity. When I click to 'add another item', the WYSIWYG editor disappears and the field blanks out.

Reverting to the unpatched WYSIWYG module resolved the problem.

I found myself in a situation where I needed to use the patch in this issue alongside the one in #356480: Lazy-load editors.

It turns out they don't play nice together, but if you apply the additional patch I've attached here, that makes it so they do. (Since that other issue looks like it will probably be committed soon, the attached patch will need to be merged into this issue's main patch once that happens. But for now, it's only needed if you're trying to make both patches work together correctly.)

I must agree with #71 and I will add that when you save your node using Field Collection fields, the textarea won't get saved.

I'm using #70 patch.

Reverting solved the problem. Must live for the moment with my text area's height not configurable.

#65 did a good job with the height..

new6.19 KB

Patches in #65 and #70 failed to apply with git. Had to use patch -p1 < wysiwyg_per_field.patch to pull in the code from #70. Re-rolled the patch in #70 against the latest 7.x-2.x branch. Patch generated with git diff > wysiwyg_height_per_field-507696-75.patch and confirmed that it applies correctly using git.

This functionality is more gigantic wysiwyg editors that completely ignore the field's rows setting.

Applied patch in #64 and it worked perfectly, but had to apply it by hand. Using version = "6.x-2.4" with ckeditor. Thanks!

Applied patch in #75 and field row settings for textarea fields are working great with CKEditor. Thanks all!!

Confirming patch in #75 works for me. Thank You!

While I had to apply the changes in the patch manually, adjusting for some code shifts, the code in patch #75 also appears to work with CKEDITOR on version 6.x-2.4. I did not patch the other editor include files.

#64 worked great, thanks!


Confirming that #75 is working as expected and applies without error.

#356480: Lazy-load editors has landed. The now superfluous extra pre-initialization has been removed. @David_Rothstein: the other patches will now work without conflict resolution.

#75 is working-ish for me, but there are some issues with Field collections as mentioned in #71 and #73. This might be an issue for all fields where number of values are set to "unlimited" (so you get the "add another item" button), but haven't tested that.

* The editor is there when you start, but after you click "add another item" the textarea (with content) for the first item disappears completely
* The new textfield in the new collection is there, but with no editor
* I am not able to add a third collection after this
* ..however, I can save the node and the two first collections are saved. On editing the node again I can add one two more, save, add two more etc..

Console log says:

Uncaught [CKEDITOR.editor] The instance "edit-field-faktaboks-und-0-field-faktatekst-und-0-value" already exists. ckeditor.js:25
Uncaught TypeError: Cannot read property 'document' of null ckeditor.js:20

..if I set an absolute number of Field Collections, say 3, everything works just fine!

edit: screenshot here:

With the newest version (7.x-2.x-dev) and the patch in #75 the height is set correctly..

But as a nasty sideeffect all buttons are showing, ignoring the choices I made in the editor settings.

Anyone else seeing this?

It turns out I just needed to clear caches to get the buttons back as they were before the patching.

So I can confirm that #75 is working when caches has been cleared.


So, #75 is working, except when using a Field Collection field in combination with the "Add another item" button.

I tested this:

  • the patch from #75
  • wysiwyg 7.x-2.x-dev 2012-Nov-11
  • field_collection 7.x-1.0-beta4
  • CKEditor 3.6.5
  • Firefox 16.0.2 and Chromium 22.0.1229.94 Ubuntu


  1. This did work using text areas. No problem adding another item.
  2. This did not work using a text field. Adding another item resulted in the first text field being empty (the editor itself on that first text field is shown though).


Was super excited to find this thread, but once again field_collections strikes again. I swear, field_collections is the most popular yet poorly supported module in Drupal 7.

So I tried my hand at debugging the issue in #86 - Text Fields in Field Collections with WYSIWYG editors.

I wasn't able to fully figure it out, but I think I have some good observations that someone may be able to leverage in narrowing down a solution.

The problem seems to be that in the UI, the data is not transferring between the WYSIWYG editor and the actual text field in the background. So if I enter "Hello World" into the WYSIWYG, and then switch to "plain text" mode which displays the text field (an <input> control) the value is empty. Further, if I enter "My name is Joe" into the text field, and then switch back to the WYSIWYG editor, it will still display "Hello World" instead of my new value. If I save the node, "My name is Joe" will be successfully saved from the text field. On viewing the node again, it will appear that the value is not there if I am looking at the WYSIWYG editor, but if I switch to plain text mode the value will indeed be there.

So as I said before, it appears the issue is with communication of the value between the WYSIWYG editor and the text field. I think a very indicative symptom of the problem is something I noticed in the HTML (using firebug) after modifying the value in the WYSIWYG editor and then switching to plain text mode. Though the "value" of the <input> field is not updated to match the WYSIWYG editor value, the value of the WYSIWYG editor is inserted as a node to the <input> tag. i.e. instead of <input value="val from wysiwyg"/>, I get <input value="old value">val from wysiwyg</input>

So something in ckeditor is making it think that it gets and sets the value of the Text Field by getting/setting the innerHTML of the node instead of the "value" attribute. When I look at the ckeditor.js library (I have 3.6.3) I see some code that leads me to believe this is indeed happening - i.e.'textarea')?m.getValue():m.getHtml(); Note that this field is an 'input', not a 'textarea', so this logic will indeed pull the innerHTML instead of the value.

This is as far as I am able to take it at this point, due to time constraints and the fact that I dont have the time to try to figure out how to generate an uncompressed version of ckeditor.js to better debug. I'm hoping these clues can help someone else figure it out.

Adding to my comments in #88, a potential other clue is that if I comment out the following lines of the patch:

elseif ($field['#type'] == 'textfield') {
$profile->settings['rows'] = 1;

It appears that my Text Field somehow picks up the row value of the Text Area field below it, within the same Field Collection.

the patch from #75 is no longer working with the latest dev (2013-Feb-23)

Status:Needs review» Needs work

#75 still works for 7.x-2.2

For all Drupal 6.x'ers still around: I can confirm that you can apply modifications from #75 patch on 6.x-dev "manually".
That is, looking at the patch code, and change wysiwyg.js,wysiwyg.module and

#75 is great, although not compatible with #741606-45: Teaser splitter / text fields with summary support.

new2.56 KB

As a follow up to #94 the attached patch adds rudimentary support for setting the height of summaries. Note that you have to have previously applied the patch in #75 and the patch referenced in #94.

new6.24 KB

#75 no longer applies-- here's an straight reroll against the current dev.

#96 works great. Thank you.

Issue summary:View changes
Status:Needs work» Reviewed & tested by the community

There seems to be a problem with #96 with current dev. There is no wysiwyg.js file in the js/ directory

Also, changes listed in #96 to wysiwyg.module cause WSOD.

#96 works great. Also on Field Collections.

@trainingcity: In my wysiwyg dev there is no js/ directory at all. The wysiwyg.js file is in the module root.

The patch applies cleanly and works great.

I can confirm that patch #96 works great, even with my module's custom fields! ;-)

Anyone know if a similar patch is available for the CKEditor Module? I prefer it over WYSIWYG Module as it allows me better control over the menu button layout.

new8.27 KB

It looks like the patch in #106 was mistakenly created from the drupal root, not the wysiwyg directory.

I can confirm that the patch in #96 does apply cleanly to the dev version, and continues to work great.

+1 for RTBC on #96

Update: patch #96 no longer applies to latest dev, and patch #106 (as mentioned) was created from Drupal root instead of the wysiwyg directory (it also causes a fatal whitespace error from last file line).

Status:Reviewed & tested by the community» Needs work

Updating to needs work per #108

Re-rolled against latest dev.

Status:Needs work» Needs review

new6.16 KB

Fixed last patch - missed one line when re-rolling patch.

I tested #112 against latest dev (Wysiwyg 7.x-2.2+33-dev (2014-Mar-19)) and it failed on hunk#2 at 471.

new6.21 KB

Hmm, weird. Re-rolled again and tested against 33-dev. Applied clean.

That works for me now. It look care of a directory path (page not found) issue I was getting in my error log for font.css and micro fonts in my wysiwyg field areas.

Thanks so much!