Problem reports with WysiwygPlugin.

Sorry for giving you all the runaround, but due to the volume of reports (thanks everyone!) it's too hard to edit here, so I'm moving the tracking to the Bugs web (http://develop.twiki.org/~develop/cgi-bin/view/Bugs/WysiwygPlugin). Please report problems there.

• Mark the report as AppliesTo: "Extension"
• Put the ExtensionName: "WysiwygPlugin"

Thanks!

C.

---

---

---

---

Fixed problems

---

---

click-n-miss for twiki icons leaves null image

Reported by	JosMaccabiani 09 Sep 2005
Type	Bug

Details

V0.16
When the 'insert twiki icon' button is clicked, and the user clicks inside the icon box but not on an icon, a null image is inserted. The result:

Test Case

See above.

Response

Fixed in 0.17. Until then, be careful!

-- CrawfordCurrie - 20 Sep 2005

---

Form data is cached for radio buttons

Reported by	CharlesJohnson 10 Sep 2005
Type	Bug

Details

If you change a radio button in an edited topic then save it, the next time you go to edit it, the value before the change is displayed. If you then refresh your browser, it picks up the setting you just saved.

I'm using the latest version of the plugin (0.16) running on Cairo September2.

Test Case

Create a topic and add a form with a multi-selection radio button. Edit the topic with Kupu and change the radio button setting then save it. Edit it again with Kupu and you will notice the radio button is set to the value before your edit. Now, refresh your browser and it will pick up the edit you just made.

If you didn't notice this, and re-save the topic, the radio button setting will have the value that was set before the first edit.

Response

Argh; blasted browser caches everything it can!

OK, I set everything I can to expire as soon as it can, and suppressed the browser cache at every opportunity. If that doesn't work, may have to consider some other way of getting the form data. In 0.17

-- CrawfordCurrie - 20 Sep 2005

---

Incorrect processing of links to non-existing topics

Reported by	JosMaccabiani 03 Sep 2005
Type	Bug

Details

V0.15
When an existing page, which contains a link to a NonExistingTopic is Kupu-edited, then the editor shows the following link:

Please note the font color and the ? (which is a link, see the red cross in the tool bar)

Saving the topic produces for the link:

<span class="twikiNewLink"><font color="#0000ff">BeginselenVanSpanningspaden</font> 
[[http://url.to.twiki/bin/edit/Sandbox/BeginselenVanSpanningspaden?
topicparent=Sandbox.TestTopic5][<sup>?</sup>]] </span>. 

So I feel there are two problems here:

1. Kupu should not show the ? because it's a useless feature during edit
2. After saving, the text version should just be the WikiWord without any spans, font tags etc. The TWiki rendering engine knows how to deal with it in the appropriate manner.

Cheers!

Test Case

• Use classic-edit to create a link to a non-existing topic and save
• Kupu-edit (you should notice the editor problems)
• Kupu-save
• Classic-edit (you should notice the html tags)

Response

Hmmmm. That's not supposed to happen. The link should be converted back to a wikiword. It' probably something to do with the parameters on the link.

I think this was an artifact of another problem. Anyway, it's gone in 0.16.

-- CrawfordCurrie - 09 Sep 2005

It still behaved like this on my install, untill I disabled SectionalEditPlugin (2 May 2005 version). It works as advertised now!

-- JosMaccabiani - 09 Sep 2005

---

Save inserts html anchor over and over

Reported by	JosMaccabiani 03 Sep 2005
Type	Annoyance

Details

V0.15
When a topic contains headings, and the topic is Kupu-edited and Kupu-saved, a html anchor is inserted before the heading titles.

After several Kupu-edit cycles, there are a lot of those before every heading, e.g.:

---+ <a name="a_a_a_a_a_De_triaxiaalproef"></a><a 
name="_a_a_a_a_a_De_triaxiaalproef"></a><a 
name="a_a_a_De_triaxiaalproef"></a><a name="_a_a_a_De_triaxiaalproef"></a><a 
name="a_De_triaxiaalproef"></a><a name="_a_De_triaxiaalproef"></a><a 
name="De_triaxiaalproef"></a>De triaxiaalproef

The over-and-over part seems a bug, and I'm not sure if the anchors should be inserted in the first place

Test Case

1. Classic-edit topic, insert some headings
2. Classic-save
3. Kupu-edit topic and Kupu-save without changing anything
4. Classic-edit (You should see the html anchors inserted)

Response

Works as expected in 0.16 -- CrawfordCurrie - 09 Sep 2005

---

Leave %TOC intact

Reported by	JosMaccabiani 03 Sep 2005
Type	WIBNIF

Details

V0.15
It would be nice if the Kupu-TOC would be converted to %TOC on save, and not to

<div class="twikiToc">
   * [[http://wiki.geodelft.nl/bin/view/Sandbox/TestTopic5?
skin=kupu;wysiwyg_edit=1#De_triaxiaalproef][De triaxiaalproef ]]
      * [[http://wiki.geodelft.nl/bin/view/Sandbox/TestTopic5?
skin=kupu;wysiwyg_edit=1#Beschrijving_diverse_typen_proev]
[Beschrijving "diverse typen" proeven ]]
      * [[http://wiki.geodelft.nl/bin/view/Sandbox/TestTopic5?
skin=kupu;wysiwyg_edit=1#Wanneer_de_triaxiaalproef_toepas][Wanneer de 
triaxiaalproef-toepassen? ]]
      * [[http://wiki.geodelft.nl/bin/view/Sandbox/TestTopic5?
skin=kupu;wysiwyg_edit=1#Bronnen][Bronnen ]]
</div>

Test Case

1. Create headings and TOC using Classic-edit
2. Kupu-edit and Kupu-save
3. The TOC looks great, just like %TOC!
4. Classic-edit (you should now see the complex TOC versus %TOC

Response

Darn; you should be seeing %TOC% in kupu-edit. Expansion of variables should be suppressed.

Just tested on 0.16, and it works as expected. -- CrawfordCurrie - 09 Sep 2005

---

Center column does not stick

Reported by	AlanDayley 29 Aug 2005
Type	Annoyance

Details

WysiwygPlugin v0.14

Editing a table, when changing the column to be centered, it displays centered in the editor. However, once saved, the column is not centered.

If the column is centered in TML the editor will continue to save it as centered so it does not break what is already there.

Test Case

1. Edit a page.
2. Add a table, columns are left aligned by default.
3. Click the Insert / Edit Table button.
4. Choose column alignment center.
5. Save the page.
6. Column is not centered.

Response

Fixed in 0.16 -- CrawfordCurrie - 09 Sep 2005

---

Handling of font changes in tables messed up

Reported by	ThomasWeigert 05 Sep 2005
Type	Bug

Details

(This is using IE as browser.)

When a table is inserted within a bolded or italicized text the subsequent table formatting appears buggy, as can be seen in the test case below (shown for the bold face situation). If a table is inserted with the font set to regular, these problems do not arise.

Note that the incorrect behavior is slightly different depending on whether the table is inserted at the end of the bolded or italicized text, or in the middle of it.

Test Case

If you have text typeset in bold ("B" icon highlited), place your cursor at the end of the bold section and insert a table, the text in the table appears regular, but the "B" icon is highlighted. The code rendered engulfs the table in bold, however. Result:

*abcd<table border="1"><tbody><tr><td>efg</td><td> </td></tr><tr><td> </td><td> </td></tr></tbody></table>*

-- Main.TWikiGuest - 05 Sep 2005

Now highlight the text in a table cell (shown unbolded, but rendered bold) and click bold again in the hope to unbold. Now the text shows bolded, but the "B" icon is not highlighted. Result:

*abcd<table border="1"><tbody><tr><td> *efg* </td><td> </td></tr><tr><td> </td><td> </td></tr></tbody></table>*

-- Main.TWikiGuest - 05 Sep 2005

with the effect that two spurious asterisk appear in the rendered text, and the text is rendered bolded until the end of the topic, including the topic actions.

Now select the text after the table and click bold, in the hope of toggling bold face off. However, the clicking has no effect... it is not possible to turn bold mode off for the selected text.

Now select the whole page and click bold. The bold mode toggles off and the "B" is shown not highligted. The code rendered is now:

abcd
|efg| |
| | |

-- Main.TWikiGuest - 05 Sep 2005

Note how the appearance of the table borders suddenly has changed due to that now the table is rendered as TML while earlier the table was rendered in HTML.

Response

The problem arises right back at the beginning of your tale. The conversion back to using * should have been suppressed, because the span of that tag included HTML that could not be converted to TML. IMHO Kupu does a dreadful job of handling font highlights, though it is really the fault of the browser rather than Kupu. -- CrawfordCurrie

Are you saying that this is or is not a problem? --TW

Oh, it's a problem, all right. I have generated a testcase and will fix this specific case, but the fundamental problem - that typing at the end of a line inserts inside the close tags of any formatting on the line - is a browser issue and there's not much I can do about it. -- CrawfordCurrie - 07 Sep 2005

Hmmm. It appeared to me that there are two issues here:

• Inserting at the end of a line inserts inside the close tag
• Once that happened, certain manipulations yield incorrect results due to partial conversion back to TML.

We might not be able to address the former, but the latter should be in our control? --TW

Unfortunately neither is within our (or Kupu's) control. These functions are all delegated to the browser.

-- CrawfordCurrie - 08 Sep 2005

The specific problem Thomas reported above should be fixed in 0.16. -- CrawfordCurrie - 09 Sep 2005

---

Ordered list confusion

Reported by	AlanDayley 29 Aug 2005
Type	Annoyance

Details

WysiwygPlugin v0.14

We have a number of TWiki pages with program log dumps that include a section with a hexadecimal memory dump. These log sections are surounded by <verbatim> tags so that they are not disturbed.

The hex dump sections are converted into HTML ordered lists when loaded into the WysiwygPlugin editor and then saved back out. Because they are in a <verbatim> section, the <ol> and <li> tags are displayed in the page in the normal view.

Test Case

The original:

<verbatim>
 192:0c0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ........ ........
 208:0d0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ........ ........
 224:0e0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ........ ........
 240:0f0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ........ ........
</verbatim>

Open the page in the editor and then save it. The above ends up displayed as:

<ol>
<li> :0c0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ........ ........
</li>
<li> :0d0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ........ ........
</li>
<li> :0e0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ........ ........
</li>
<li> :0f0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ........ ........
</li>
</ol>

Response

Huh? Very strange. Are you sure there isn't another plugin interfering? I'll try to reproduce this.

Later: the above example works fine on 0.16, so if the symptoms re-occur we can be pretty sure it's an interfering plugin.

-- CrawfordCurrie - 09 Sep 2005

This works on my 0.16 install, but inserts newlines (producing extra empty lines). So

<verbatim>
 192:0c0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ........ ........
 208:0d0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ........ ........
 224:0e0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ........ ........
 240:0f0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ........ ........
</verbatim>

becomes, after opening & saving with Kupu,

<verbatim>
 192:0c0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ........ ........

 208:0d0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ........ ........

 224:0e0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ........ ........

 240:0f0 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ........ ........

</verbatim>

This is on IE6 on Win2k (after disabling the SectionalEditPlugin, see above)

-- JosMaccabiani - 09 Sep 2005

---

Wikiwords not always escaped

It doesn't properly change exclamations to nop's if the word doesn't have a space after it.

-   * !NetReg/Quarantine/etc system
+   * NetReg/Quarantine/etc system

Response

It's supposed to use exaclty the same code to handle ! as TWiki itself does. I'll check.

OK, fixed in 0.16 -- CrawfordCurrie - 08 Sep 2005

---

Forced link with anchor breaks

I've been seeing some problems with the current version (0.14). If I have a page that has a forced link with an anchor it breaks if I just open and save the file with kupu.

(For instance "[[FAQ.NetworkInternet#Pomona_Network][Test Link]]" became "<a href="FAQ.NetworkInternet#Pomona_Network">Test Link</a>") 

Needless to say, this caused the link on the saved page to be broken.

-- JeffersonCowart - 03 Aug 2005

Response

Works as expected in 0.16 -- CrawfordCurrie - 08 Sep 2005

---

Don't kill spaces

It killed a space before an exclamation when replacing it with a nop

-      * Move ITS test site to web5 leaving web5 as !MySQL host
+      * Move ITS test site to web5 leaving web5 as<nop>MySQL host

-- JeffersonCowart - 03 Aug 2005

Response

Hmmm. Shouldn't do that. I'll add a test-case....

I added a testcase, and it works fine. Please try to reproduce on 0.16

-- CrawfordCurrie - 08 Sep 2005

Works fine on my 0.16 install

-- JosMaccabiani - 09 Sep 2005

---

URL not replaced in IMG tag

Small problem:

I noticed after inserting one of the icons (from the Kupu menu) that after saving the img tags remained instead of the path in the Plugin settings page. I.e.:

<img width="16" src="http://wikiserver/twiki/pub/TWiki/TWikiDocGraphics/choice-yes.gif" height="16"></img>

instead of:

<img src="%PUBURL%/TWiki/TWikiDocGraphics/choice-yes.gif" alt="" />

-- JosMaccabiani - 07 Aug 2005

Response

Yep, that's the way it works. Trying to cater for all these possible cases just makes the plugin more an more complex; it's a question of diminshing returns.

-- CrawfordCurrie - 22 Aug 2005

The problem with this approach, as I see it, is that it might be a lot of work to change all the links when the twiki has to be served from a different domain for some reason (corporate acquisition, re-branding, ...). At the same time, TWiki has this nice mechanism of variable URI's so that people can port or exchange contents to wherever they like.

It hasn't got the highest priority, consider it a WIBNIF for this very desirable plugin to: - leave explicit http:// links intact - leave variable %PUBURL% type links intact - attach new images as variable links

-- JosMaccabiani - 22 Aug 2005

OIC - I misinterpreted the report. Your point is valid, it ought to fix that.

-- CrawfordCurrie - 22 Aug 2005

If possible, it would also be nice if the plugin would leave %ATTACHURL type links intact in addition to %PUBURL type links

-- JosMaccabiani - 03 Sep 2005

This should be fixed in 0.15.

-- CrawfordCurrie - ??

This is not fixed on my install of 0.16. Could it be some interference with one of the plugins below?

WysiwygPlugin, DefaultPlugin, FormQueryPlugin, SpreadSheetPlugin, CommentPlugin, SlashFilenamePlugin, EditTablePlugin, FindElsewherePlugin, GenerateSearchPlugin, HistoryPlugin, InterwikiPlugin, LatexModePlugin, RenderListPlugin, RevCommentPlugin, SessionPlugin, SlideShowPlugin, SmiliesPlugin, TablePlugin, TreePlugin, UserInfoPlugin, WebDAVPlugin 

-- JosMaccabiani - 09 Sep 2005

This is not fixed with the whatever version is running in DEVELOP. Editing an attached image with:

<img src="%ATTACHURLPATH%/T-logo-16x16.gif" alt="T-logo-16x16.gif" width='16' height='16' />

turn into this after a WYSIWYG edit cycle:

<img alt="T-logo-16x16-t.gif" height="16" src="../../../../%7Edevelop/cgi-bin/view/Sandbox/%ATTACHURLPATH%/T-logo-16x16-t.gif" width="16"></img>

See http://develop.twiki.org/~develop/cgi-bin/view/Sandbox/PThTestTopic

-- PeterThoeny - 06 Oct 2005

This is still not fixed, even in the 6 december release (on my install). Since registration doesn;t seem to work on DEVELOP right now, I hope someone will notice this and file the bug report for me, thanks.

• You don't need a new account on DEVELOP in order to file a bug report. Use your TWiki.org WikiUserName/password or TWikiGuest/guest. -- FJ

-- JosMaccabiani - 06 Dec 2005

---

Email addresses should not be replaced with mailto: links

E-Mail addresses shouldn't be replaced with explicit mailto: links:

-         * E-mail z@a.b.c about Win32 API from .Net
+         * E-mail [[mailto:z@a.b.c][z@a.b.c]] about Win32 API from .Net

-- JeffersonCowart - 03 Aug 2005

Response

Why not? It far more explicit and intention-revealing. -- CrawfordCurrie - 22 Aug 2005

IMHO:

• users expect that e-mail addresses are auto-linked
• overly complex edit screen (the explicit link without any additional meaning for it) scares off casual contributers (KISS)
• changing an e-mail address suddenly requires changing it in two places

-- JosMaccabiani - 22 Aug 2005

OK, I changed this in 0.15

-- CrawfordCurrie - 25 Aug 2005

This is not fixed on my install of 0.16. Could it be some interference with one of the plugins below?

WysiwygPlugin, DefaultPlugin, FormQueryPlugin, SpreadSheetPlugin, CommentPlugin, SlashFilenamePlugin, EditTablePlugin, FindElsewherePlugin, GenerateSearchPlugin, HistoryPlugin, InterwikiPlugin, LatexModePlugin, RenderListPlugin, RevCommentPlugin, SessionPlugin, SlideShowPlugin, SmiliesPlugin, TablePlugin, TreePlugin, UserInfoPlugin, WebDAVPlugin 

-- JosMaccabiani - 09 Sep 2005

Could someone confirm that this works on their 0.16 install, and share the list of installed plugins? Thanks.

-- JosMaccabiani - 30 Oct 2005

---

Space after link

Testing 0.14 on a reasonably complex page I saw a few minor problems:

After a link it adds in a space even if there wasn't one before:

-         * Julie has asked me to write a BlogConsolidationPlan.
+         * Julie has asked me to write a BlogConsolidationPlan .

-- JeffersonCowart - 03 Aug 2005

Should be fixed in 0.15 -- CrawfordCurrie - 25 Aug 2005

---

Rejected Reports

%ATTACHURL%/file.file converting to http://...../...../..../%ATTACHURL/file.file

Reported by	VaidotasBarzdenas 14 Sep 2005
Type	Bug

Details

Bugs:

• • Kupu breaks Hyperlinks, e.g. %ATTACHURL%/file.file turns to http://.../.../%ATTACHURL/file.file
  • Kupu breaks Hyperlinks, e.g. %ATTACHURLPATH%/image turns to http://.../.../%ATTACHURLPATH/image

I'm using the latest version 0.16 running.

Test Case

See above.

Addition

I can only reproduce this when formatting this way:

  [[%ATTACHURL%/file][Link]]

turns to:

  [[http://.../.../view/Web/%ATTACHURL%/file][Link]] 

On Win2k and IE 6.0 running version 0.16 as well.

-- CedricWeber - 14 Sep 2005

Response

I just tried your example above, and it generates:

<a href="%ATTACHURL%/file">Link</a>

Less than ideal, but certainly not a broken link! Can you describe exactly what steps you performed to get the above result?

-- CrawfordCurrie - 20 Sep 2005

Crawford, you'll get

<a href="%ATTACHURL%/file">Link</a>

with Mozilla and

  [[http://.../.../view/Web/%ATTACHURL%/file][Link]] 

with Internet Explorer. In case of Mozilla users can survive with the results, but with IE pages are "ruined".

-- CedricWeber - 23 Sep 2005

---

Empty headings should be removed

Reported by	JosMaccabiani 09 Sep 2005
Type	WIBNIF

Details

Because users can change the formatting to 'heading x' using the top menu, it's possible to (clumsily and without wanting to) change the formatting for an empty line.

On save, these empty heading lines render a 'plus' (style depending on heading level)

It would be nice if Kupu was smart enough to remove empty headings

Test Case

The test case can be done without Kupu, with the textarea application: create the following topic content and save:

%TOC%
---+
---+ Heading 1
---++ Heading 2
---++

That's why it would be nice if Kupu would remove empty headings!

Response

Perhaps. However this would also violate the principle of retention; i.e. if an existing topic has an empty heading in it, then Kupu would remove the heading, resulting in an unintentional change to the topic. Empty headings are legal TML, and I don't think it's valid to hack them out.

-- CrawfordCurrie - 20 Sep 2005

---

Tab in TWikiVariables converted to single space

Reported by	ThomasWeigert 04 Sep 2005
Type	Bug

Details

V0.16
In TWikiVariables, e.g., %TOPICLIST{" * $web.$name"}%, after editing with the WysiwygPlugin the tab or 3 spaces before the bullet is converted into a single space. Of course, the list will then not render correctly after that. Manually typing in 3 spaces does not help either.

Test Case

Response

Argh yes. I was asked by the client to removed special interpretation of % variables, and I'm afraid this is one of the side-effects. It would be extremely difficult to make WysiwygPlugin space-preserving, because of the way it works - translation into the DOM, and then translation back.

I need to think about this; but for now, use the textarea to edit variables. The theory is that most contributors who use the Wysiwyg editor are unlikely to be editing variables anyway. --Main.CrawfordCurrie

It might be good to somehow treat variables special. E.g., insert them through a wizzard (such as tables or links) and do not subject them to any manipulation (space compaction). The wizzard could just be a dialog but it somehow would put some protection around the variable, maybe even exhibit it looking differently (color, box around)? --TW

I did that originally, but the client for this work asked that it be removed after a usability expert looked at it. One of the arguments is that use of variables is restricted to a small subset of the user community, and that subset are the most technically able to deal with variables without WYSIWYG support. -- CrawfordCurrie - 08 Sep 2005

---

PluginIncompatibleWithLatexModePluginOrMathModePlugin

Reported by	JosMaccabiani 05 Sep 2005
Type	Annoyance

Details

When Latex is included in a page (e.g. for using the MathModePlugin or LatexModePlugin), going through an edit cycle destroyes the latex:

• those latex plugins render images on view
• the wysiwyg plugin retains the images, saves html links
• latex is gone, only available in alt text

Test Case

You can only test this with LatexModePlugin or MathModePlugin installed. Just add latex math, save, edit with Kupu, save.

You had: %$ \alpha $%

You end up with: <img width="10" alt="$ \alpha $" align="bottom" src="http://path.to/twiki/pub/Sandbox/TestTopic5/latex01e448120fd802ada204b6f86aed2073.png" height="7"></img>

(NB: as long as you don't want to change the formula, it looks the same)

Response

The WysiwygPlugin works by installing a beforeRenderingHandler, which depends on the plugin being early in the plugins list, otherwise other plugins may get in before it. I suspect this may be happening here. Try putting WysiwygPlugin into the INSTALLEDPLUGINS list.

-- CrawfordCurrie - 6 Sep 2005

It was already in the list. I've also put it at the front of the list, but with no change to the behaviour: a link to the image is saved back in stead of the math string.

-- JosMaccabiani - 06 Sep 2005

I had a look at the MathModePlugin. It uses "non-standard" syntax conventions that the WysiwygPlugin has little or no chance of intercepting. There's no much I can do without modifying the TWiki core code.

-- CrawfordCurrie - 07 Sep 2005

ScottHoge pointed out to me that the current version (0.16) actually works as expected with the LatexModePlugin (showing the latex markup in kupu edit view). I checked it on my install, and indeed: perfect results using the standard %$ $% notation. It might be worth adding to the plugin topic that although MathModePlugin might not work, the same results (and more) can be obtained using LatexModePlugin.

-- JosMaccabiani - 30 Oct 2005

---

WIBNIF (Wouldn't it be nice if....)

---

Copy/paste from MS Word leaves the Word font formatting in place

Reported by	JosMaccabiani 03 Sep 2005
Type	Annoyance

Details

V0.15
When copy/pasting text from MS Word into the WysiwygPlugin, font type is preserved by surrounding the text with <font> </font> tags.

However, the plugin doesn't provide a mechanism to change this font type. Therefore, it would be nice if either:

1. the user can change the font type in the plugin
2. all font type information is removed on paste

NB: on a more general note - I showed the user (non-IT) who found this how to access the classic editor to remove the tags, but he was overwhelmed by 'the amount of wierd codes' in the text. He was referring to everything the WysiwygPlugin put in there in stead of TWikiML, like %TOC% etc.

Test Case

1. open an MS Word file with different font types (Arial, Times, etc)
2. copy and paste the text in the WysiwygPlugin
3. save

now there is text surrounded by <font> </font> tags

Response

I'm sure Word littered the HTML with more than just that. The plugin does the best job it can, but some additional filtering is no doubt required to fully support import from other HTML sources. Someone could easily use the WysiwygPlugin code modules to develop such a filter, simply by subclassing the Node class.

Should paste from MS Word work?

Details

I tried a copy and paste from M$ word - to my surprise the bullets and numbering screwed up. Can someone else test their install?

-- MartinCleaver - 28 Oct 2005

Test Case

On my 0.16 install, pasting a bulleted list gives me:

<font size="3">·</font>          <font size="3">gebruik maken van bestaande databronnen.</font>

So I guess it's probably not your install.

-- JosMaccabiani - 28 Oct 2005

Response

Duplicate of the above.

-- MartinCleaver - 30 Oct 2005

Additional editing for tables

Reported by	ThomasWeigert 05 Sep 2005
Type	WIBNIF

Details

TML allows additional table formatting features, such as left/right/center alignment, and horizontal/vertical spans. While these may not be rendered exactly as in the final text, in particular the spans, it would be good to allow these effects to be inserted from the command bar (like bold face).

Test Case

Response

This isn't going to happen any time soon, but would be a useful enhancement.

---

Undo in IE does not work

Reported by	ThomasWeigert 05 Sep 2005
Type	Bug

Details

V0.16
Using IE as browser, the undo button has no effect. The debug log shows that the command is being executed, but the visual appearance of the edit pane as well as the saved topic are not changed.

Test Case

Response

It depends on what you were trying to undo. Only functions delegated to the browser can be undone, as undo is a browser function, not a function of the editor.-- CrawfordCurrie

I am referring to the undo button in the Wysiwyg editor tool bar... certainly the user would expect that this refers to undoing things what one did with the editor? --TW

I know - and your assumption is totally reasonable. However I can't (or rather, Kupu can't) deliver on that promise. The issue is that undo applies only to functions delegated to the browser through the rather hairy and poorly defined MicroSoft method interface. Any operation which is not delegated - such as certain types of table manipulation - cannot be undone. That's why it depends on what you were doing; I need to know whether the function you were trying to undo was a delegated function or not. -- CrawfordCurrie - 07 Sep 2005

I see. It might be better to delete the undo buttons then, as this is confusing (the user will expect that Wysiwyg things are undone). The browser undo buttons are there also, so if only things that the browser can undo are undone, we might as well click the browser undo? --TW

Possibly. That decision has yet to be finalised. -- CrawfordCurrie - 08 Sep 2005

---

Don't use nops where ! will do

Annoyance I'd prefer if it didn't replace exclamations with nop's. An exclamation is two keystrokes a nop is 7.

-- JeffersonCowart - 03 Aug 2005

Response

Yeah, it would look nicer. Perhaps in some future release.

---

Don't translate entities

It would be nice if it didn't do this translation with the greater/less than symbols:

-         * Jefferson - MB25A/B - 024026/024027 - (4 patches on 2 plates -> 2 pa
tches on 2 plates) - Also needs configuration change
+         * Jefferson - MB25A/B - 024026/024027 - (4 patches on 2 plates -> 2
 patches on 2 plates) - Also needs configuration change

-- JeffersonCowart - 03 Aug 2005

Response

Perhaps some day. Right now, there's too much risk of confusion with HTML.