• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

Item5492: Black font tags are usually unwanted

Item Form Data

AppliesTo: Component: Priority: CurrentState: WaitingFor: TargetRelease ReleasedIn
Extension WysiwygPlugin Enhancement Confirmed   n/a  

Edit Form Data

Reported By:
Applies To:
Current State:
Waiting For:
Target Release:
Released In:


When pasting from word or open office I often get font tags in the output. This is very annoying, especially when they are black fonts, or excessively pre, something like this:

1 <pre><font color="#000000"><font size="2">Login details</font></font></pre>
1 <pre><font color="#000000"><font size="2">Web interface</font></font></pre>
1 <pre><font color="#000000"><font size="2">Hosting Account</font></font></pre>
1 <pre><font color="#000000"><font size="2">SSH level</font></font></pre>
1 <pre><font color="#000000"><font size="2">Web admin level</font></font></pre>
1 <pre><font color="#000000"><font size="2">domain set-up</font></font></pre>
1 <pre><font color="#000000"><font size="2">mysql interface</font></font></pre>

A couple of iterations through WYSIWYG and TML and, by the magic of http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4850, we end up with something like:
   1 <pre>%BLACK%All the functionality in mrjc-feedwordpress-filters &ndash; can we find something that does similar but:%ENDCOLOR%</pre>
      1 <pre>%BLACK%This might be to merge the functionality of mrjc-feedwordpress-filters into feedwordpress%ENDCOLOR%</pre>
         1 <pre>%BLACK%Do they have a wiki?%ENDCOLOR%</pre>
         1 <pre>%BLACK%Is the code base open yet?%ENDCOLOR%</pre>
      1 <pre>%BLACK%Has manageabilty by administrator%ENDCOLOR%</pre>
         1 <pre>%BLACK%Has a UI for both the manager and the user%ENDCOLOR%</pre>
         1 <pre>%BLACK%Able to select what items get filtered in%ENDCOLOR%</pre>
         1 <pre>%BLACK%User gets the opportunity to select what categories, keywords they want%ENDCOLOR%</pre>
         1 <pre>%BLACK%Should be able to retrospectively rescan the content.%ENDCOLOR%</pre>
      1 <pre>%BLACK%Can show a table of all blogs syndicated, the number of entries, whether the feed is automatically updating and the date of last update. Also the ability to kick off another update%ENDCOLOR%</pre>
      1 <pre>%BLACK%Can filter in extra categories / tags%ENDCOLOR%</pre>
         1 <pre>%BLACK%User should be able to state what tags should get added for all their postings%ENDCOLOR%</pre>
         1 <pre>%BLACK%Administrator should have the %ENDCOLOR%</pre>

If you can't see the %BLACK % tags in the above, see http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5492?raw=on

http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4790 and http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4831 have some related entries.



  1. Is there an existing sequence of tinymce button clicks that normalises this? Is this something that can be done with http://develop.twiki.org/~twiki4/cgi-bin/view/TWiki/WysiwygPluginSettings?
  2. If its not a http://develop.twiki.org/~twiki4/cgi-bin/view/TWiki/WysiwygPluginSettings job, where would code go to fix it?
  3. What approach should someone take? Is this a Javascript task?
  4. How much work might it be to implement? I'd consider doing it myself or paying a student to do if its fairly trivial.


Crawford added: Irritating, isn't it? Unfortunately the only filtering mechanism I was able to implement stops at the "are there any attributes" level; it can't parse attributes to determine if they have any value (and frankly, in the above case, the decision can't be made without parsing and analysing the CSS as well). Add to this the fact that M$ make heavy use of "M$ private" attributes that are only meaningful to IE.....

My advice is to do what I have done, and develop whatever bespoke pre-filters work for you (and most especially your client's HTML, as it can differ quite widely depending on how Word is used). I personally use HTML::Parser to create an in-perl DOM tree that I run plug-in analysers on to remove such no-op constructs.

-- TWiki:Main.MartinCleaver - 02 Apr 2008


> I'd consider doing it myself or paying a student to do if its fairly
> trivial.
Trivial to do trivially (regexes). Harder to do properly (HTML::Parser). Very, very difficult to do well (generic no-op detection and rewriting).

-- TWiki:Main.MartinCleaver - 02 Apr 2008

Of course, you would also have to detect this case: Some blue some green some black some more green some more blue .

%BLUE% Some blue %GREEN% some green %BLACK% some black %ENDCOLOR% some more green %ENDCOLOR% some more blue %ENDCOLOR%
Tricky, huh?

-- TWiki:Main.CrawfordCurrie - 04 Apr 2008

Another way would be to have a "strip fonts" control available to the user; that could work on either the entire or selected part of the textarea.

I wondered whether the search and replace widget could be made available in plain text mode, but the regexes needed to remove fonts is probably beyond most users anyway.

-- TWiki:Main.MartinCleaver - 13 Apr 2008

I note that http://twiki.org/cgi-bin/view/Support/HtmlWithTinyMCEPlugin talked about an inverse problem: at some point WYSIWYG plugin was stripping font tags, supposedly because KEEP_WS was not set. (I say supposedly because KEEP_WS seems to influence whitespace).

-- TWiki:Main.MartinCleaver - 13 Apr 2008

At a JS level, this might help: http://codingforums.com/archive/index.php?t-86923.html

-- TWiki:Main.MartinCleaver - 13 Apr 2008

The plugin does strip font tags, if you tell it to. As I said, there are controls that allow selection of tags to strip based on what attributes they have, but you want something more; you want to strip tags based on the value of an attribute and that is much harder.

This is an enhancement, not a bug.

-- CrawfordCurrie - 16 Apr 2008

Summary Black font tags are usually unwanted
ReportedBy TWiki:Main.MartinCleaver
Codebase 4.1.2, 4.2.0
SVN Range TWiki-5.0.0, Sun, 09 Mar 2008, build 16496
AppliesTo Extension
Component WysiwygPlugin
Priority Enhancement
CurrentState Confirmed


TargetRelease n/a

Edit | Attach | Watch | Print version | History: r6 < r5 < r4 < r3 < r2 | Backlinks | Raw View |  Raw edit | More topic actions
Topic revision: r6 - 2008-04-16 - CrawfordCurrie
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2023 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback