This month I travelled around Australia and met with several long term Ephox clients and talked with them about their experiences with EditLive!, what they’d like to see in the product and what’s coming in EditLive!.

Their feedback was very valuable and it’s safe to say that the trip is likely to be the first of many very client focused trips.  In fact, if you’d like to share your own EditLive! experiences, please get in touch with us via the LiveWorks! mailing list, we’d love to hear from you.

One of the things that came up a few times was some inconsistencies between HTML and Word rendering that can cause confusion when users are importing content from Word. There are two simple things you can do to your web site’s CSS to help users out with this.

Firstly, default top and bottom margins.  Users experiencing this issue often complain that, when content is pasted from Word into EditLive! there’s “double spacing” between paragraphs.  This happens because the top and bottom margins on paragraphs in Word are set to 0, but in HTML it tends to be around 6 pixels or so.  The simple solution here is to override the HTML defaults in your CSS by adding something like this:

p{
        margin-top:0px;
        margin-bottom:0px;
}

It’s worth noting that you could also fix this issue by changing the top and bottom margins in your word processor’s default document template (normal.dot in Word) to match HTML, but it’s much easier to change this in your style sheet because it’s settings are centrally administered.

The second thing that often confuses people more used to creating content on their desktop rather than online is the nature of HTML tables.  This is because tables in desktop word processors have a single border, whereas HTML tables, by default actually have two borders.  You usually can’t see this because there’s no cell spacing specified.  However, if you look at the table below where I’ve set the cell spacing attribute to 2 you can clearly see the borders.

This is because each cell border is made up of two border lines - the border of the cell and the border of either the table or the neighbouring cell.

Fortunately CSS comes to the rescue again.  In order to make HTML tables behave just like tables in desktop word processors all you need to do is collapse the table borders.  This can be done by adding the following code to your site’s CSS:

table{
        border-collapse:collapse;
}

Which will make your table look more like this (note I’ve not changed the cell spacing here, just applied border-collapse):

And that’s it.  These two simple CSS changes can make a world of difference for your EditLive! users, especially when they’re importing content from desktop word processors.  Just a couple of final things to remember before you start applying this CSS everywhere:

• Remember if you’ve got a CMS often the published CSS is different to the authoring CSS that EditLive! uses.  Make sure you make the required changes to both sets of styles.
• You’ll want to test this CSS in a development/testing environment first to make sure it doesn’t have an unexpected impact on your web site’s layout.
• If you’ve already got CSS specified for the “p” tag and/or the “table” tag just add these properties to what you already have.
• If you add this CSS to the root element style (i.e. not a class style) like I have above, it should inherit across all the other classes you have in your CSS for tables and paragraphs.

Hopefully you’ll find this very useful and if you’ve got any questions just get in contact with us via the LiveWorks! mailing list.

Once EditLive! downloads the first time, it is cached on the user’s machine so that in the future it starts up lightning fast. Unlike most content from web sites, EditLive! isn’t cached in the browser’s cache because items in browser cache are regularly discarded as other web site content is downloaded and cached instead. EditLive! is actually cached by the Java plugin which provides a long term cache.

So where is it? It depends. Where the Java cache is actually stored on disk will vary depending on what OS you have, what Java version you have and how it’s all configured. Fortunately, the Java Control Panel provides an easy way for you to view what’s in the cache and delete entries from it. On Windows, there should be a “Java” icon in the Control Panel directory. On Mac, the application is called “Java Preferences” and it’s located in /Applications/Utilities/Java/. Finally on Linux and Solaris you need to run the ControlPanel executable from the bin directory of your JRE. For more information see Sun’s documentation.

If you integrated EditLive! prior to the 6.0 release, the style toolbarComboBox definition in your configuration file probably looks like this:

<toolbarComboBox name="Style">  <comboBoxItem name="P" text="Normal"/>  <comboBoxItem name="H1" text="Heading 1"/>  <comboBoxItem name="H2" text="Heading 2"/>  <comboBoxItem name="H3" text="Heading 3"/>  <comboBoxItem name="H4" text="Heading 4"/>  <comboBoxItem name="H5" text="Heading 5"/>  <comboBoxItem name="H6" text="Heading 6"/>  <comboBoxItem name="PRE" text="Formatted"/>  <comboBoxItem name="ADDRESS" text="Address"/></toolbarComboBox>

The 6.0 release maintained backwards compatibility with this format, but if you’re still using it then you are missing out on the translations we added.  The new format removes the text attribute:

<toolbarComboBox name="Style">  <comboBoxItem name="P"/>  <comboBoxItem name="H1"/>  <comboBoxItem name="H2"/>  <comboBoxItem name="H3"/>  <comboBoxItem name="H4"/>  <comboBoxItem name="H5"/>  <comboBoxItem name="H6"/></toolbarComboBox>

Once it is removed, you will see that your english-only style names suddenly become translated in all supported languages.

We have included translations for all major block tags:

• P
• DIV (in 6.4)
• H1-6
• PRE
• ADDRESS
• TD
• TH
• TR
• TABLE
• LI
• UL
• OL

We’ve even included some of the less common ones like DT and DL.  These translations will apply to styles loaded via CSS as well as from the configuration file.

Preventing users form inserting images requires two parts:

1. Remove the insert image related items from the configuration file so the insert image dialog is unavailable.
2. Prevent users from pasting images into the editor.

The first part is quite simple, just delete the “ImageServer” menu item and toolbar buttons from your configuration file.

The second part however isn’t directly supported by EditLive! Fortunately, we’ve now made a plugin available that automatically strips any images out of pasted content. Like all the plugins on LiveWorks! we don’t offer direct support for the plugin, but the full source code is included and help is generally available on the mailing list. The instructions for using the plugin are on the plugin page - it’s just a simple line of JavaScript.

If you look at the source code for the plugin you’ll find it’s a very simple PasteFilter (see this previous article). The main method simply uses a regular expression to filter out the img tags:

public String filterIn(String source) {
  String regex = "<img[^>]*";
  if (FILTER_ONLY_LOCAL_IMAGES) {
    regex += "src=[\"']file:[^>]*";
  }
  regex += "/?>";
  Pattern pattern = Pattern.compile(regex,
      Pattern.DOTALL | Pattern.CASE_INSENSITIVE);
  Matcher matcher = pattern.matcher(source);
  return matcher.replaceAll("");
}

FILTER_ONLY_LOCAL_IMAGES is a final variable declared at the top of the file. It’s set to false in the standard version so that all images are removed, but if you change it to true, only local images will be removed and remote images will be pasted normally. This is a great way to prevent users from pasting in local images but still allow them to use images from the repository or other sites. It also shows how simple it is to adapt the regular expression to be more selective about which images to filter out. With a little knowledge of regular expression and this plugin as a starting point you should be able to achieve whatever image filtering policy you need.