Using FCKEditor 2.6.5, when my users copy from Word and paste into the FCKeditor field using the Paste From Word dialog, the copy comes in formatted with font and span tags.

Here's what I do:

  1. Copy a block of text in Word.
  2. Open a page for editing.
  3. Click on the 'Paste from Word' button.
  4. Select or do not select the 'Remove Styles definitons' option (it makes no difference which). Leave "Ignore Font Face defintions" selected.
  5. Paste into the dialog.
  6. Click 'OK'.
  7. Text is pasted in with color and size assigned. Clicking on the Source button reveals that lots of font tags have been brought in.

I can observe this behavior on both Windows and on a Mac: On windows, I've observed it when pasting from Word 2007 into FCKEditor running in IE7, and from Word 2003 into FCKEditor running in IE8; on the Mac, I've observed it when pasting from Word 2008 into FCKEditor running in Firefox 3.5.

Here's what I've tried to address teh situation:

  • Set FCKConfig.CleanWordKeepsStructure = true ; in fckeditor.config.js. No change in behavior.
  • Set FCKConfig.CleanWordKeepsStructure = true ; in the custom JavaScript field on the FCKEditor global config screen.
  • Upgraded from FCKEditor 2.6.2 to 2.6.5.

What I have NOT tried:

Downgrading to 6.x-1.4. (Is this likely to help?)

Note that there is no observable difference in behavior when FCKConfig.CleanWordKeepsStructure = true ; or FCKConfig.CleanWordKeepsStructure = false;.

According to every post I can find over on the FCKeditor forums, this problem was fixed several versions ago, and all I should need to do is set FCKConfig.CleanWordKeepsStructure = true ;. That's not turning out to be the case.

Can anybody offer any guidance on how to address this problem? This is a kind of urgent request -- the client is in production, and this leaves them having to paste in plain-text mode -- that multiplies their time-to-populate by a factor of about four or five over what it would be if the stuff were coming in semi-formatted.

Comments

escoles’s picture

escoles commented

Additional information:

I've tried a clean install of 6.x-1.4 on another site that's never had the FCKEditor module installed. The behavior is more or less identical within the test cases I've run so far.

I also learned through trial and error that the proper format for including variable assignments in the custom javascript field is CleanWordKeepsStructure = VALUE ;.

So I set CleanWordKeepsStructure = false ; and was able to observe a difference in behavior: <p> tagsets were replaced with <div> tagsets, though all the font information was still carried through.

So what seems to be happening is that neither "Ignore Font Face definitions" nor "Remove Styles definitions" are honored under any circumstance I have been able to identify.

[edit to correct FCKEditor module version]

Jorrit’s picture

Jorrit commented

I think it's a problem in FCKeditor, not the FCKeditor module. You can try to get support at http://ckeditor.com/

escoles’s picture

escoles commented
Status: Active » Closed (fixed)

Following up on this: Yes, this is an FCKEditor issue -- it's really an issue with how the feature is described, not with the functionality per se.

I was able to hack FCKEditor to do what I wanted, but I learned that the behavior I was looking for (which I thought I'd observed in the past, but must have been wrong about) was not the default behavior.

What I did was to make the following changes to fckeditor/editor/dialogs/fck_paste.html:

1: Added the following regex lines to the CleanWord() function to remove color and size attributes from font tags (which renders them impotent):

	// ES 2009-11-12: remove color, size attributes from font tags:
	html = html.replace( /\s*color="[^"]*"/gi, '' ) ;
	html = html.replace( /\s*color=[^ >]*/gi, '' ) ;
	html = html.replace( /\s*size="[^"]*"/gi, '' ) ;
	html = html.replace( /\s*size=[^ >]*/gi, '' ) ;
	html = html.replace( /\s*size="+[^"]*"/gi, '' ) ;
	// ES 2009-11-12: Remove empty paragraphs
	html = html.replace( /<p\s*[^>]*>&nbsp;<\/p>/gi, '' ) ;

(This is probably a total hack as regex code, but I don't really do regex.)

2: Set the default status for both chkRemoveFont and chkRemoveStyles to "checked", so users will always default to selecting the options that make sense for our environment. (chkRemoveFont was un-checked by default, previously.)

Clear browser cache, reload, and paste functions as desired. Just need to keep track of that file for future upgrades.

tg’s picture

tg commented

I find it also better to keep H* tags, furthermore to integrate nicely in the page structure shift them, so e.g. H1 becomes H3, and so on, like this:

        if ( FCKConfig.CleanWordShiftHeadings ) {
            for (var i=6-FCKConfig.CleanWordShiftHeadings; i>0; i--) {
                html = html.replace(new RegExp('<h'+i+'>'), '<h'+(i+FCKConfig.CleanWordShiftHeadings)+'>');
            }
        }
escoles’s picture

escoles commented

TG, that's a good point, except that you're universally shifting the value of the H* tags if you do it that way. That's only going to be useful if someone creates a document with a number of Heading 1 styles at the same level. I hardly ever see documents that look like that. Everyone else will be shifting their headings down 1 or 2 levels, and will either have to change their use of Word to accommodate the filter, or change the headings after pasting.

To me it makes more sense to make your use of Word conform to what the heading styles will end up as in Drupal. I.e., page title as Heading 1 (which will never get pasted), subheads starting at Heading 2 or Heading 3, depending on whether you use some kind of a lower-level subhead on your pages. (Which we usually do -- pages have an H1.title, an optional h2.subhead, and then subheads within the body of the text.)