From tim.terlegard at valentinewebsystems.se Wed Jul 2 11:37:56 2008 From: tim.terlegard at valentinewebsystems.se (=?ISO-8859-1?Q?Tim_Terleg=E5rd?=) Date: Wed, 2 Jul 2008 11:37:56 +0200 Subject: [kupu-dev] UnicodeDecodeError with umlauts in image title Message-ID: <7CA659FE-BA29-43B9-AF95-B3644C2E8F4B@valentinewebsystems.se> Hi kupuers, I get an error when I have an image with a title that contains umlauts and use that image inside a document with caption enabled. The error is triggered by the transform in html2captioned.py on these lines: if isinstance(data, str): data = data.decode('utf8') html = IMAGE_PATTERN.sub(replaceImage, data) replaceImage returns utf8, so data should also be utf8, otherwise the sub() method will fail when there are umlauts involved. Things work if I remove the conversion to unicode on the line above. I'm not sure why the conversion to unicode was added some months ago. I have changed the tests to use umlauts and removed the conversion to unicode. The tests pass. Should I commit this or is there something I'm missing? /Tim From duncan.booth at suttoncourtenay.org.uk Fri Jul 4 09:36:02 2008 From: duncan.booth at suttoncourtenay.org.uk (Duncan Booth) Date: Fri, 4 Jul 2008 07:36:02 +0000 (UTC) Subject: [kupu-dev] UnicodeDecodeError with umlauts in image title References: <7CA659FE-BA29-43B9-AF95-B3644C2E8F4B@valentinewebsystems.se> Message-ID: Tim Terleg?rd wrote: > Hi kupuers, > > I get an error when I have an image with a title that contains umlauts > and use that image inside a document with caption enabled. > > The error is triggered by the transform in html2captioned.py on these > lines: > > if isinstance(data, str): > data = data.decode('utf8') > html = IMAGE_PATTERN.sub(replaceImage, data) > > replaceImage returns utf8, so data should also be utf8, otherwise the > sub() > method will fail when there are umlauts involved. > > Things work if I remove the conversion to unicode on the line above. > I'm not sure why the conversion to unicode was added some months ago. > I have changed the tests to use umlauts and removed the conversion to > unicode. The tests pass. Should I commit this or is there something I'm > missing? > > /Tim > No, don't commit that. You haven't said which version of Plone you are using. The problem is that some versions of Plone return unicode here and some return byte strings so the code has to work in both situations. However it is important that the regular expression be working on unicode. You should never do manipulations on utf8 encoded strings as it is possible (albeit unlikely) that the regex could mess up parts of multi-byte encoded characters. That's why the decode (and later on an encode) are present. If on your system replaceImage is returning utf8 then the fix should be to ensure that it decodes its result before returning. Probably change: return template(**d) to: result = template(**d) if isinstance(result, str): result = result.decode('utf8') return result From tim.terlegard at valentinewebsystems.se Thu Jul 10 09:01:12 2008 From: tim.terlegard at valentinewebsystems.se (=?ISO-8859-1?Q?Tim_Terleg=E5rd?=) Date: Thu, 10 Jul 2008 09:01:12 +0200 Subject: [kupu-dev] UnicodeDecodeError with umlauts in image title In-Reply-To: References: <7CA659FE-BA29-43B9-AF95-B3644C2E8F4B@valentinewebsystems.se> Message-ID: <21885701-DA4A-4CF0-A86E-DDA0B84A8846@valentinewebsystems.se> On Jul 4, 2008, at 9:36 AM, Duncan Booth wrote: > Tim Terleg?rd wrote: > >> I get an error when I have an image with a title that contains >> umlauts >> and use that image inside a document with caption enabled. >> > No, don't commit that. > > You haven't said which version of Plone you are using. The problem is > that some versions of Plone return unicode here and some return byte > strings so the code has to work in both situations. However it is > important that the regular expression be working on unicode. Right, my change only worked in 2.5, not in 3.1. So I changed the code a bit and now it works on both. I commited it in r56399. /Tim From johnny at johnnydebris.net Mon Jul 14 12:24:09 2008 From: johnny at johnnydebris.net (Guido Wesdorp) Date: Mon, 14 Jul 2008 12:24:09 +0200 Subject: [kupu-dev] Undo functionality Message-ID: <487B2949.905@johnnydebris.net> Hi! A while ago, someone asked me to implement 'proper' undo/redo for Kupu. I implemented the first bits, and then the requester didn't reply anymore, so I never got round to implement it in full, but fortunately some other customer now showed interest too and allowed me to complete the last bits (well, mostly, it still could use some tests and docs...). In other words: there is now full undo/redo support (so not just for execCommand actions, but for everything) in Kupu. It's easy to enable: just include the 'jsincludes' part of the 'undo' feature in your head part (make sure to also update include.kupu) and add the following lines to your kupuinit.js: var undotool = new KupuUndoTool('kupu-undo-button', 'kupu-redo-button'); kupu.registerTool('undotool', undotool); It's already enabled in the default (demo) file, so to try just open common/kupu.html (after running 'make', if you hadn't done so already). Hope you find it useful, if you have questions or remarks, feel free to send me an email... Cheers, Guido From danny.bloemendaal at informaat.nl Mon Jul 14 14:19:58 2008 From: danny.bloemendaal at informaat.nl (Danny Bloemendaal) Date: Mon, 14 Jul 2008 14:19:58 +0200 Subject: [kupu-dev] UnicodeDecodeError with umlauts in image title In-Reply-To: <21885701-DA4A-4CF0-A86E-DDA0B84A8846@valentinewebsystems.se> References: <7CA659FE-BA29-43B9-AF95-B3644C2E8F4B@valentinewebsystems.se> <21885701-DA4A-4CF0-A86E-DDA0B84A8846@valentinewebsystems.se> Message-ID: <136AB5D2-73B0-4024-8594-48329D492E9C@informaat.nl> I'm suddenly seeing unicode errors with kupu and images lately in 2.5. Is this related? On 10 jul 2008, at 09:01, Tim Terleg?rd wrote: > On Jul 4, 2008, at 9:36 AM, Duncan Booth wrote: > >> Tim Terleg?rd wrote: >> >>> I get an error when I have an image with a title that contains >>> umlauts >>> and use that image inside a document with caption enabled. >>> >> No, don't commit that. >> >> You haven't said which version of Plone you are using. The problem is >> that some versions of Plone return unicode here and some return byte >> strings so the code has to work in both situations. However it is >> important that the regular expression be working on unicode. > > Right, my change only worked in 2.5, not in 3.1. So I changed the code > a bit and now it works on both. I commited it in r56399. > > /Tim > _______________________________________________ > kupu-dev mailing list > kupu-dev at codespeak.net > http://codespeak.net/mailman/listinfo/kupu-dev From tim.terlegard at valentinewebsystems.se Mon Jul 14 14:26:17 2008 From: tim.terlegard at valentinewebsystems.se (=?ISO-8859-1?Q?Tim_Terleg=E5rd?=) Date: Mon, 14 Jul 2008 14:26:17 +0200 Subject: [kupu-dev] UnicodeDecodeError with umlauts in image title In-Reply-To: <136AB5D2-73B0-4024-8594-48329D492E9C@informaat.nl> References: <7CA659FE-BA29-43B9-AF95-B3644C2E8F4B@valentinewebsystems.se> <21885701-DA4A-4CF0-A86E-DDA0B84A8846@valentinewebsystems.se> <136AB5D2-73B0-4024-8594-48329D492E9C@informaat.nl> Message-ID: You say "lately", do you mean after my commit a few days ago? I hope not :-) If you customized the caption template or have non-ascii characters in the title or descripton of an image that you have inside a document, you might get this unicode error. /Tim On Jul 14, 2008, at 2:19 PM, Danny Bloemendaal wrote: > I'm suddenly seeing unicode errors with kupu and images lately in 2.5. > Is this related? > > > On 10 jul 2008, at 09:01, Tim Terleg?rd wrote: > >> On Jul 4, 2008, at 9:36 AM, Duncan Booth wrote: >> >>> Tim Terleg?rd wrote: >>> >>>> I get an error when I have an image with a title that contains >>>> umlauts >>>> and use that image inside a document with caption enabled. >>>> >>> No, don't commit that. >>> >>> You haven't said which version of Plone you are using. The problem >>> is >>> that some versions of Plone return unicode here and some return byte >>> strings so the code has to work in both situations. However it is >>> important that the regular expression be working on unicode. >> >> Right, my change only worked in 2.5, not in 3.1. So I changed the >> code >> a bit and now it works on both. I commited it in r56399. >> >> /Tim >> _______________________________________________ >> kupu-dev mailing list >> kupu-dev at codespeak.net >> http://codespeak.net/mailman/listinfo/kupu-dev > > _______________________________________________ > kupu-dev mailing list > kupu-dev at codespeak.net > http://codespeak.net/mailman/listinfo/kupu-dev From danny.bloemendaal at informaat.nl Mon Jul 14 14:36:04 2008 From: danny.bloemendaal at informaat.nl (Danny Bloemendaal) Date: Mon, 14 Jul 2008 14:36:04 +0200 Subject: [kupu-dev] UnicodeDecodeError with umlauts in image title In-Reply-To: References: <7CA659FE-BA29-43B9-AF95-B3644C2E8F4B@valentinewebsystems.se> <21885701-DA4A-4CF0-A86E-DDA0B84A8846@valentinewebsystems.se> <136AB5D2-73B0-4024-8594-48329D492E9C@informaat.nl> Message-ID: <5A24651B-AFE6-4BFA-B208-B6D54F9DA539@informaat.nl> revision 56306. If I update to a newer version then it will break IE with obscure js errors. I reported this to duncan and guido. No reaction so far. But what I see here is that a user inserts an image (captioned) (without weird characters in any title/description) and then upon save he gets the error. On 14 jul 2008, at 14:26, Tim Terleg?rd wrote: > You say "lately", do you mean after my commit a few days ago? I hope > not :-) > If you customized the caption template or have non-ascii characters in > the title or descripton of an image that you have inside a document, > you > might get this unicode error. > > /Tim > > > On Jul 14, 2008, at 2:19 PM, Danny Bloemendaal wrote: > >> I'm suddenly seeing unicode errors with kupu and images lately in >> 2.5. >> Is this related? >> >> >> On 10 jul 2008, at 09:01, Tim Terleg?rd wrote: >> >>> On Jul 4, 2008, at 9:36 AM, Duncan Booth wrote: >>> >>>> Tim Terleg?rd wrote: >>>> >>>>> I get an error when I have an image with a title that contains >>>>> umlauts >>>>> and use that image inside a document with caption enabled. >>>>> >>>> No, don't commit that. >>>> >>>> You haven't said which version of Plone you are using. The >>>> problem is >>>> that some versions of Plone return unicode here and some return >>>> byte >>>> strings so the code has to work in both situations. However it is >>>> important that the regular expression be working on unicode. >>> >>> Right, my change only worked in 2.5, not in 3.1. So I changed the >>> code >>> a bit and now it works on both. I commited it in r56399. >>> >>> /Tim >>> _______________________________________________ >>> kupu-dev mailing list >>> kupu-dev at codespeak.net >>> http://codespeak.net/mailman/listinfo/kupu-dev >> >> _______________________________________________ >> kupu-dev mailing list >> kupu-dev at codespeak.net >> http://codespeak.net/mailman/listinfo/kupu-dev > From tim.terlegard at valentinewebsystems.se Mon Jul 14 14:46:54 2008 From: tim.terlegard at valentinewebsystems.se (=?ISO-8859-1?Q?Tim_Terleg=E5rd?=) Date: Mon, 14 Jul 2008 14:46:54 +0200 Subject: [kupu-dev] UnicodeDecodeError with umlauts in image title In-Reply-To: <5A24651B-AFE6-4BFA-B208-B6D54F9DA539@informaat.nl> References: <7CA659FE-BA29-43B9-AF95-B3644C2E8F4B@valentinewebsystems.se> <21885701-DA4A-4CF0-A86E-DDA0B84A8846@valentinewebsystems.se> <136AB5D2-73B0-4024-8594-48329D492E9C@informaat.nl> <5A24651B-AFE6-4BFA-B208-B6D54F9DA539@informaat.nl> Message-ID: <82220C71-D7E1-4838-9069-3876817E9097@valentinewebsystems.se> Then I think this is unrelated, I made this fix in r56399. I only saw the error when having non-ascii characters in title/description or when having a customized kupu_captioned_image.pt You need to dig deeper :) /Tim On Jul 14, 2008, at 2:36 PM, Danny Bloemendaal wrote: > revision 56306. If I update to a newer version then it will break IE > with obscure js errors. I reported this to duncan and guido. No > reaction so far. > But what I see here is that a user inserts an image (captioned) > (without weird characters in any title/description) and then upon save > he gets the error. > > On 14 jul 2008, at 14:26, Tim Terleg?rd wrote: > >> You say "lately", do you mean after my commit a few days ago? I hope >> not :-) >> If you customized the caption template or have non-ascii characters >> in >> the title or descripton of an image that you have inside a document, >> you >> might get this unicode error. >> >> /Tim >> >> >> On Jul 14, 2008, at 2:19 PM, Danny Bloemendaal wrote: >> >>> I'm suddenly seeing unicode errors with kupu and images lately in >>> 2.5. >>> Is this related? >>> >>> >>> On 10 jul 2008, at 09:01, Tim Terleg?rd wrote: >>> >>>> On Jul 4, 2008, at 9:36 AM, Duncan Booth wrote: >>>> >>>>> Tim Terleg?rd wrote: >>>>> >>>>>> I get an error when I have an image with a title that contains >>>>>> umlauts >>>>>> and use that image inside a document with caption enabled. >>>>>> >>>>> No, don't commit that. >>>>> >>>>> You haven't said which version of Plone you are using. The >>>>> problem is >>>>> that some versions of Plone return unicode here and some return >>>>> byte >>>>> strings so the code has to work in both situations. However it is >>>>> important that the regular expression be working on unicode. >>>> >>>> Right, my change only worked in 2.5, not in 3.1. So I changed the >>>> code >>>> a bit and now it works on both. I commited it in r56399. >>>> >>>> /Tim >>>> _______________________________________________ >>>> kupu-dev mailing list >>>> kupu-dev at codespeak.net >>>> http://codespeak.net/mailman/listinfo/kupu-dev >>> >>> _______________________________________________ >>> kupu-dev mailing list >>> kupu-dev at codespeak.net >>> http://codespeak.net/mailman/listinfo/kupu-dev >> > > _______________________________________________ > kupu-dev mailing list > kupu-dev at codespeak.net > http://codespeak.net/mailman/listinfo/kupu-dev From duncan.booth at suttoncourtenay.org.uk Mon Jul 14 19:52:27 2008 From: duncan.booth at suttoncourtenay.org.uk (Duncan Booth) Date: Mon, 14 Jul 2008 17:52:27 +0000 (UTC) Subject: [kupu-dev] UnicodeDecodeError with umlauts in image title References: <7CA659FE-BA29-43B9-AF95-B3644C2E8F4B@valentinewebsystems.se> <21885701-DA4A-4CF0-A86E-DDA0B84A8846@valentinewebsystems.se> <136AB5D2-73B0-4024-8594-48329D492E9C@informaat.nl> <5A24651B-AFE6-4BFA-B208-B6D54F9DA539@informaat.nl> Message-ID: Danny Bloemendaal wrote: > revision 56306. If I update to a newer version then it will break IE > with obscure js errors. I reported this to duncan and guido. No > reaction so far. The IE6 problem was fixed today. From alexman at seas.ucla.edu Tue Jul 15 00:04:40 2008 From: alexman at seas.ucla.edu (Alex Man) Date: Mon, 14 Jul 2008 15:04:40 -0700 Subject: [kupu-dev] Getting through the HTML Filter of the Kupu editor by saving in HTML source mode Message-ID: <200807142205.PAA22607@whittier.seas.ucla.edu> Hi kupuers, I was wondering about how secure the HTML Filter in Kupu is so I did the following little experiment: * By default, the element isn't allowed in both the Kupu HTML Filter and safe_html in Zope * Added "font" to the list of valid_tags in safe_html in Zope so that the element can be rendered * Edited a page in Plone and add the code test in the HTML source mode * Switched back to normal WYSIWYG mode and save * As expected, the tags were removed, leaving the text "test" there * Tried adding the code test again but this time... * Didn't switch back to the WYSIWYG mode. Instead, click the "Save" button directly in the HTML source mode * And the element got saved this time! Is it how the Kupu HTML Filter is supposed to work? If that is so, is there a way to configure it so that it removes the banned elements in both the WYSIWYG mode and the HTML source mode? I'm using Plone 2.5.5 and Kupu 1.4.10. Thanks a lot! Regards, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/kupu-dev/attachments/20080714/4298de96/attachment.htm From duncan.booth at suttoncourtenay.org.uk Tue Jul 15 12:54:34 2008 From: duncan.booth at suttoncourtenay.org.uk (Duncan Booth) Date: Tue, 15 Jul 2008 10:54:34 +0000 (UTC) Subject: [kupu-dev] Getting through the HTML Filter of the Kupu editor by saving in HTML source mode References: <200807142205.PAA22607@whittier.seas.ucla.edu> Message-ID: Alex Man wrote: > --=====================_5065187==.ALT > Hi kupuers, > > I was wondering about how secure the HTML Filter in Kupu is so I did > the following little experiment: > * By default, the element isn't allowed in both the Kupu > HTML Filter and safe_html in Zope > * Added "font" to the list of valid_tags in safe_html in Zope so > that the element can be rendered > * Edited a page in Plone and add the code color="blue">test in the HTML source mode > * Switched back to normal WYSIWYG mode and save > * As expected, the tags were removed, leaving the text > "test" there * Tried adding the code color="blue">test again but > this time... > * Didn't switch back to the WYSIWYG mode. Instead, click the > "Save" button directly in the HTML source mode > * And the element got saved this time! > Is it how the Kupu HTML Filter is supposed to work? If that is so, is > there a way to configure it so that it removes the banned elements in > both the WYSIWYG mode and the HTML source mode? I'm using Plone 2.5.5 > and Kupu 1.4.10. Thanks a lot! > > > Regards, > > Alex > Attachment decoded: untitled-3.txt > --=====================_5065187==.ALT > > > Hi kupuers,

> I was wondering about how secure the HTML Filter in Kupu is so I did > the following little experiment: >
    >
  • By default, the <font> element isn't allowed in both the Kupu > HTML Filter and safe_html in Zope >
  • Added "font" to the list of valid_tags in safe_html in >Zope > so that the <font> element can be rendered >
  • Edited a page in Plone and add the code <font > color="blue">test</font> in the HTML source mode >
  • Switched back to normal WYSIWYG mode and save >
  • As expected, the <font> tags were removed, leaving the text > "test" there >
  • Tried adding the code <font > color="blue">test</font> again but this time... >
  • Didn't switch back to the WYSIWYG mode. Instead, click the > "Save" button directly in the HTML source mode >
  • And the <font> element got saved this time! >
Is it how the Kupu HTML Filter is supposed to work? If that is so, > is there a way to configure it so that it removes the banned elements > in both the WYSIWYG mode and the HTML source mode? I'm using Plone > 2.5.5 and Kupu 1.4.10. Thanks a lot!

No, if it does that it's a bug: it is supposed to apply the filtering even if you are in source mode. OTOH as from Plone 3 the filtering done by kupu and the safe html transform in Plone are linked together so anything which escapes kupu's filtering will get caught anyway. For earlier Plones this isn't automatic but it wouldn't be sensible to tell kupu to filter something and not also block it in safe html. Besides, you can *always* bypass Kupu's filtering, just use a browser which doesn't support kupu. The filtering in Kupu is intended as a 'nice to have', its the filtering in Plone itself that is supposed to provide a modicum of security. From alexman at seas.ucla.edu Tue Jul 15 22:19:40 2008 From: alexman at seas.ucla.edu (Alex Man) Date: Tue, 15 Jul 2008 13:19:40 -0700 Subject: [kupu-dev] Getting through the HTML Filter of the Kupu editor by saving in HTML source mode In-Reply-To: References: <200807142205.PAA22607@whittier.seas.ucla.edu> Message-ID: <200807152020.NAA02778@whittier.seas.ucla.edu> Duncan, Thanks for the reply! I've already submitted a ticket for the bug at http://dev.plone.org/plone. At 03:54 AM 7/15/2008, Duncan Booth wrote: >Alex Man wrote: > > > --=====================_5065187==.ALT > > Hi kupuers, > > > > I was wondering about how secure the HTML Filter in Kupu is so I did > > the following little experiment: > > * By default, the element isn't allowed in both the Kupu > > HTML Filter and safe_html in Zope > > * Added "font" to the list of valid_tags in safe_html in Zope so > > that the element can be rendered > > * Edited a page in Plone and add the code > color="blue">test in the HTML source mode > > * Switched back to normal WYSIWYG mode and save > > * As expected, the tags were removed, leaving the text > > "test" there * Tried adding the code > color="blue">test again but > > this time... > > * Didn't switch back to the WYSIWYG mode. Instead, click the > > "Save" button directly in the HTML source mode > > * And the element got saved this time! > > Is it how the Kupu HTML Filter is supposed to work? If that is so, is > > there a way to configure it so that it removes the banned elements in > > both the WYSIWYG mode and the HTML source mode? I'm using Plone 2.5.5 > > and Kupu 1.4.10. Thanks a lot! > > > > > > Regards, > > > > Alex > > Attachment decoded: untitled-3.txt > > --=====================_5065187==.ALT > > > > > > Hi kupuers,

> > I was wondering about how secure the HTML Filter in Kupu is so I did > > the following little experiment: > >
    > >
  • By default, the <font> element isn't allowed in both the Kupu > > HTML Filter and safe_html in Zope > >
  • Added "font" to the list of valid_tags in safe_html in > >Zope > > so that the <font> element can be rendered > >
  • Edited a page in Plone and add the code <font > > color="blue">test</font> in the HTML source mode > >
  • Switched back to normal WYSIWYG mode and save > >
  • As expected, the <font> tags were removed, leaving the text > > "test" there > >
  • Tried adding the code <font > > color="blue">test</font> again but this time... > >
  • Didn't switch back to the WYSIWYG mode. Instead, click the > > "Save" button directly in the HTML source mode > >
  • And the <font> element got saved this time! > >
Is it how the Kupu HTML Filter is supposed to work? If that is so, > > is there a way to configure it so that it removes the banned elements > > in both the WYSIWYG mode and the HTML source mode? I'm using Plone > > 2.5.5 and Kupu 1.4.10. Thanks a lot!

> >No, if it does that it's a bug: it is supposed to apply the filtering >even if you are in source mode. > >OTOH as from Plone 3 the filtering done by kupu and the safe html >transform in Plone are linked together so anything which escapes kupu's >filtering will get caught anyway. For earlier Plones this isn't >automatic but it wouldn't be sensible to tell kupu to filter something >and not also block it in safe html. > >Besides, you can *always* bypass Kupu's filtering, just use a browser >which doesn't support kupu. The filtering in Kupu is intended as a 'nice >to have', its the filtering in Plone itself that is supposed to provide >a modicum of security. > >_______________________________________________ >kupu-dev mailing list >kupu-dev at codespeak.net >http://codespeak.net/mailman/listinfo/kupu-dev Regards, Alex From simon at joyful.com Fri Jul 18 19:19:59 2008 From: simon at joyful.com (Simon Michael) Date: Fri, 18 Jul 2008 10:19:59 -0700 Subject: [kupu-dev] why is kupu converting br to p ? Message-ID: CMS users want to add br tags sometimes, using Kupu's HTML mode. But when switching to HTML mode, existing br tags are converted to p. I see this with Kupu 1.4.6 and 1.4.10 in all browsers. This is with Plone 2.5. Both Kupu control panel and portal_transforms seem to allow br tags by default. Using the correct
form doesn't make a difference. Help ? What's going on ? From alexman at seas.ucla.edu Fri Jul 18 20:27:21 2008 From: alexman at seas.ucla.edu (Alex Man) Date: Fri, 18 Jul 2008 11:27:21 -0700 Subject: [kupu-dev] why is kupu converting br to p ? In-Reply-To: References: Message-ID: <200807181827.LAA20830@whittier.seas.ucla.edu> Simon, I'm using Kupu 1.4.10 and it doesn't convert
tag to

when I switch back and forth between WYSISYG mode and HTML mode or when I save the page. By the way, you can create a line break
by pressing Shift+Enter in the WYSISYG mode. At 10:19 AM 7/18/2008, Simon Michael wrote: >CMS users want to add br tags sometimes, using Kupu's HTML mode. But >when switching to HTML mode, existing br tags are converted to p. > >I see this with Kupu 1.4.6 and 1.4.10 in all browsers. This is with >Plone 2.5. Both Kupu control panel and portal_transforms seem to allow >br tags by default. Using the correct
form doesn't make a difference. > >Help ? What's going on ? > >_______________________________________________ >kupu-dev mailing list >kupu-dev at codespeak.net >http://codespeak.net/mailman/listinfo/kupu-dev Regards, Alex