From: David NG M. <d...@me...> - 2006-09-19 21:00:00
|
I created a narrative site and used the default Unicode encoding, but for some reason the page defaults as Western ISO-8859-1 in my browser. Here's an example: http://e-mu.org/david/gene/srn/c/f/cfeb57811ad53feab45d269a63dd32a5.html -- It should read K=FCng (I hope that shows, u mit umlaut). Using Firefox 1.5.0.7 in OSX 10.4 and Gramps is running in OSX as well, although I'd imagine that shouldn't make a difference, since the character encoding is in the web page's code, right? I can't tell if this is a bug or not. Cheers! David --=20 __ _ _ _ __ _ http://sintheta.org |
From: Duncan L. <du...@li...> - 2006-09-20 06:17:31
|
On Tue, 2006-09-19 at 16:59 -0400, David NG McCallum wrote: > I created a narrative site and used the default Unicode encoding, but > for some reason the page defaults as Western ISO-8859-1 in my browser. >=20 > Here's an example: > http://e-mu.org/david/gene/srn/c/f/cfeb57811ad53feab45d269a63dd32a5.html > -- It should read K=C3=BCng (I hope that shows, u mit umlaut). I think we'll call it a bug. Could you report it in the bug tracker at=20 I see the same result when I look at the page. If you try to validate the page at http://validator.w3.org/ you'll get (among others) this error: Character Encoding mismatch! =20 The character encoding specified in the HTTP header (iso-8859-1) is different from the value in the <meta> element (utf-8). I will use the value from the HTTP header (iso-8859-1) for this validation. =20 I think this means that the server says to the browser that the page is in iso-8859-1 encoding but the page itself tells the browser that it's utf-8 encoding (which is plainly wrong). =20 I've never seen that particular failure before so I can't comment on why that's happened. Did you manually edit any of the pages after gramps generated them? If you did and the editor you used saved the pages as iso-8859-1 then that'll probably be the problem. I'm not sure if this could have happened just by setting your ftp settings wrongly. Make the bug report and some people will look into it (http://sourceforge.net/tracker/?group_id=3D25770&atid=3D385137). For now, for yourself, you can manually set the encoding in your browser to iso-8859-1 and it'll look right again. Duncan --=20 Linux user: 372812 | GPG key ID: 21A8C63A | http://lithgow-schmidt.dk |
From: Eero T. <oa...@he...> - 2006-09-20 18:14:58
|
Hi, On Wednesday 20 September 2006 09:17, Duncan Lithgow wrote: > Character Encoding mismatch! > > The character encoding specified in the HTTP header (iso-8859-1) > is different from the value in the <meta> element (utf-8). I > will use the value from the HTTP header (iso-8859-1) for this > validation. > > I think this means that the server says to the browser that the page is > in iso-8859-1 encoding but the page itself tells the browser that it's > utf-8 encoding (which is plainly wrong). > > I've never seen that particular failure before so I can't comment on why > that's happened. www-servers are often configured in HTTP header to tell pages with certain extensions to have certain encoding. I would have thought the Content-Type tag to override that though. Either complain to your webmaster or use on the pages the charset that your www-hosting lies your pages to be using. While on the subject of Narrative Web site report... There are two quite annoying things: - I was generating a report from a database I had copied from somewhere else without moving the images to proper place. Before I could get rid of the report dialog, I had to click through couple of hundred "Missing media object" dialogs. Couldn't tje report just show a list of all errors at the end of report generation? Scrollable, non-editable textview would be nice for this as its content can be copy&pasted, whereas dialog text cannot - Progress and error dialogs which block the report dialog are not transient to it as they should be. Everything that is modal to some other window *should* also be transient to it - Eero |
From: David NG M. <d...@me...> - 2006-09-21 03:07:18
|
Hi all, I didn't edit the pages after the fact. But the server *is* a windows box, not a unix box. Might this explain why it's being stupid with the character coding, as Eero said? If that's the case, then I assume that it's not a bug. You know, I'll try putting the pages on a unix server and see if I get the same problem. D On 20/09/06, Eero Tamminen <oa...@he...> wrote: > Hi, > > On Wednesday 20 September 2006 09:17, Duncan Lithgow wrote: > > Character Encoding mismatch! > > > > The character encoding specified in the HTTP header (iso-8859-1) > > is different from the value in the <meta> element (utf-8). I > > will use the value from the HTTP header (iso-8859-1) for this > > validation. > > > > I think this means that the server says to the browser that the page is > > in iso-8859-1 encoding but the page itself tells the browser that it's > > utf-8 encoding (which is plainly wrong). > > > > I've never seen that particular failure before so I can't comment on why > > that's happened. > > www-servers are often configured in HTTP header to tell pages with certain > extensions to have certain encoding. I would have thought the Content-Type > tag to override that though. Either complain to your webmaster or use on > the pages the charset that your www-hosting lies your pages to be using. > > > While on the subject of Narrative Web site report... > There are two quite annoying things: > - I was generating a report from a database I had copied from somewhere > else without moving the images to proper place. Before I could get rid > of the report dialog, I had to click through couple of hundred "Missing > media object" dialogs. Couldn't tje report just show a list of all errors > at the end of report generation? Scrollable, non-editable textview would > be nice for this as its content can be copy&pasted, whereas dialog text > cannot > - Progress and error dialogs which block the report dialog are not > transient to it as they should be. Everything that is modal to some > other window *should* also be transient to it > > > - Eero > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Gramps-users mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-users > -- __ _ _ _ __ _ http://sintheta.org |
From: David NG M. <d...@me...> - 2006-09-21 03:11:10
|
It turns out it must be the server's fault. It works on a linux server: http://onsight.id.gu.se/~mccallum/gene/srn/c/f/cfeb57811ad53feab45d269a63dd32a5.html Is there anything that can be done in the HTML code to make sure the Windows servers don't act naughty with the character coding? D On 20/09/06, David NG McCallum <d...@me...> wrote: > Hi all, > > I didn't edit the pages after the fact. > > But the server *is* a windows box, not a unix box. Might this explain > why it's being stupid with the character coding, as Eero said? > > If that's the case, then I assume that it's not a bug. You know, I'll > try putting the pages on a unix server and see if I get the same > problem. > > D > > On 20/09/06, Eero Tamminen <oa...@he...> wrote: > > Hi, > > > > On Wednesday 20 September 2006 09:17, Duncan Lithgow wrote: > > > Character Encoding mismatch! > > > > > > The character encoding specified in the HTTP header (iso-8859-1) > > > is different from the value in the <meta> element (utf-8). I > > > will use the value from the HTTP header (iso-8859-1) for this > > > validation. > > > > > > I think this means that the server says to the browser that the page is > > > in iso-8859-1 encoding but the page itself tells the browser that it's > > > utf-8 encoding (which is plainly wrong). > > > > > > I've never seen that particular failure before so I can't comment on why > > > that's happened. > > > > www-servers are often configured in HTTP header to tell pages with certain > > extensions to have certain encoding. I would have thought the Content-Type > > tag to override that though. Either complain to your webmaster or use on > > the pages the charset that your www-hosting lies your pages to be using. > > > > > > While on the subject of Narrative Web site report... > > There are two quite annoying things: > > - I was generating a report from a database I had copied from somewhere > > else without moving the images to proper place. Before I could get rid > > of the report dialog, I had to click through couple of hundred "Missing > > media object" dialogs. Couldn't tje report just show a list of all errors > > at the end of report generation? Scrollable, non-editable textview would > > be nice for this as its content can be copy&pasted, whereas dialog text > > cannot > > - Progress and error dialogs which block the report dialog are not > > transient to it as they should be. Everything that is modal to some > > other window *should* also be transient to it > > > > > > - Eero > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share your > > opinions on IT & business topics through brief surveys -- and earn cash > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > > Gramps-users mailing list > > Gra...@li... > > https://lists.sourceforge.net/lists/listinfo/gramps-users > > > > > -- > __ _ _ _ __ _ > http://sintheta.org > -- __ _ _ _ __ _ http://sintheta.org |
From: Duncan L. <du...@li...> - 2006-09-21 04:22:46
|
On Wed, 2006-09-20 at 23:11 -0400, David NG McCallum wrote: > It turns out it must be the server's fault. It works on a linux server: >=20 > http://onsight.id.gu.se/~mccallum/gene/srn/c/f/cfeb57811ad53feab45d269a63= dd32a5.html >=20 > Is there anything that can be done in the HTML code to make sure the > Windows servers don't act naughty with the character coding? On Wed, 2006-09-20 at 23:11 -0400, David NG McCallum wrote:=20 > It turns out it must be the server's fault. It works on a linux server: >=20 > http://onsight.id.gu.se/~mccallum/gene/srn/c/f/cfeb57811ad53feab45d269a63= dd32a5.html >=20 > Is there anything that can be done in the HTML code to make sure the > Windows servers don't act naughty with the character coding? If you can change the html files to iso-8859-1 you should be fine, most european characters work with that encoding. Duncan --=20 Linux user: 372812 | GPG key ID: 21A8C63A | http://lithgow-schmidt.dk |
From: Duncan L. <du...@li...> - 2006-09-21 04:24:16
|
On Wed, 2006-09-20 at 21:17 +0300, Eero Tamminen wrote:=20 > While on the subject of Narrative Web site report... > There are two quite annoying things: > - I was generating a report from a database I had copied from somewhere > else without moving the images to proper place. Before I could get rid > of the report dialog, I had to click through couple of hundred "Missing > media object" dialogs. Couldn't tje report just show a list of all err= ors > at the end of report generation? Scrollable, non-editable textview wou= ld > be nice for this as its content can be copy&pasted, whereas dialog tex= t > cannot > - Progress and error dialogs which block the report dialog are not > transient to it as they should be. Everything that is modal to some > other window *should* also be transient to it Your description of the problem has me a bit confused - but you'll be glad to know that the upcoming 2.2 has a media manager which makes fixing such broken links on mass much easier. Duncan --=20 Linux user: 372812 | GPG key ID: 21A8C63A | http://lithgow-schmidt.dk |
From: Eero T. <ee...@us...> - 2006-09-21 19:07:54
|
Hi, On Thursday 21 September 2006 07:24, Duncan Lithgow wrote: > > There are two quite annoying things: > > - I was generating a report from a database I had copied from somewhere > > else without moving the images to proper place. Before I could get > > rid of the report dialog, I had to click through couple of hundred > > "Missing media object" dialogs. Couldn't tje report just show a list > > of all errors at the end of report generation? Scrollable, > > non-editable textview would be nice for this as its content can be > > copy&pasted, whereas dialog text cannot > > - Progress and error dialogs which block the report dialog are not > > transient to it as they should be. Everything that is modal to some > > other window *should* also be transient to it > > Your description of the problem has me a bit confused - but you'll be > glad to know that the upcoming 2.2 has a media manager which makes > fixing such broken links on mass much easier. The reason why I got the errors was that I did something stupid, but what happened was still quite annoying. Instead of showing potentially thousands dialogs user needs to click away, I would suggest showing just one dialog having a list of all the problems encountered during the report generation. Then I happened to try simulating a device with not enough (<1/2MB) space left for the report (as could easily happen with a small USB stick) to see whether I would then get also hundreds/thousands Gramps warning dialogs: $ dd bs=1024 count=500 if=/dev/zero of=test.img $ sudo mkfs.msdos test.img $ mkdir test $ sudo mount -o loop,uid=$USER,gid=users -t msdos test.img test <select "test" directory as the Narrative Web site report output directory> I didn't get the warning dialogs. Gramps froze instead and in console it had following backtrace: ------------------------------------------- Traceback (most recent call last): File "/home/eero/garnome/share/gramps/gramps_main.py", line 1987, in menu_report options_class,translated_name,name,category) File "/home/eero/garnome/share/gramps/Report.py", line 1879, in report report_class(database,person) File "/home/eero/garnome/share/gramps/plugins/NavWebPage.py", line 2603, in __init__ self.make_report() File "/home/eero/garnome/share/gramps/plugins/NavWebPage.py", line 2696, in make_report MyReport.write_report() File "/home/eero/garnome/share/gramps/plugins/NavWebPage.py", line 2113, in write_report self.person_pages(ind_list, restrict_list, place_list, source_list, archive) File "/home/eero/garnome/share/gramps/plugins/NavWebPage.py", line 2196, in person_pages place_list, source_list, self.options, archive, self.photo_list) File "/home/eero/garnome/share/gramps/plugins/NavWebPage.py", line 1368, in __init__ self.display_tree(of) File "/home/eero/garnome/share/gramps/plugins/NavWebPage.py", line 1495, in display_tree f_father = self.draw_connected_box(of,center1,center2,2,m_family.get_father_handle()) File "/home/eero/garnome/share/gramps/plugins/NavWebPage.py", line 1419, in draw_connected_box self.draw_box(of,center2,col,person) File "/home/eero/garnome/share/gramps/plugins/NavWebPage.py", line 1389, in draw_box of.write('<div class="border" style="top: %dpx; left: %dpx;"></div>\n' % (top-1, xoff)) File "/usr/lib/python2.3/codecs.py", line 509, in write return self.writer.write(data) File "/usr/lib/python2.3/codecs.py", line 179, in write self.stream.write(data) IOError: [Errno 28] No space left on device ------------------------------------------- Also, regardless of situation, if some dialog is modal to another dialog/window (i.e. user cannot input to the previous window while the modal dialog is open), it *should* also be set transient to that window so that window manager knows to keep it above that window so that user doesn't "lose" the dialog. I once saw a new Gramps user start 20+ instances of Gramps (before I intervened) because Gramps showed a modal error dialog at startup which blocked input to the rest of Gramps and had each time accidentally gotten hidden (user had clicked Gramps window which window manager topped as transiency wasn't set). User thought that Gramps had (again) frozen, and as he couldn't close Gramps (dialog was blocking its input), he started again another instance and was getting pretty pissed up with Gramps... (In Gtk the dialog is modal if you just call gtk_dialog_run() as that creates another event loop for the dialog.) - Eero |
From: Brian M. <br...@gr...> - 2006-09-21 19:28:58
|
Eero, That's a great catch. Please file a bug report! ~Brian ----- Original Message ---- From: Eero Tamminen <ee...@us...> To: gra...@li...; du...@li... Sent: Thursday, September 21, 2006 2:10:47 PM Subject: Re: [Gramps-users] narrative website not displaying as UTF-8 Hi, On Thursday 21 September 2006 07:24, Duncan Lithgow wrote: > > There are two quite annoying things: > > - I was generating a report from a database I had copied from somewhere > > else without moving the images to proper place. Before I could get > > rid of the report dialog, I had to click through couple of hundred > > "Missing media object" dialogs. Couldn't tje report just show a list > > of all errors at the end of report generation? Scrollable, > > non-editable textview would be nice for this as its content can be > > copy&pasted, whereas dialog text cannot > > - Progress and error dialogs which block the report dialog are not > > transient to it as they should be. Everything that is modal to some > > other window *should* also be transient to it > > Your description of the problem has me a bit confused - but you'll be > glad to know that the upcoming 2.2 has a media manager which makes > fixing such broken links on mass much easier. The reason why I got the errors was that I did something stupid, but what happened was still quite annoying. Instead of showing potentially thousands dialogs user needs to click away, I would suggest showing just one dialog having a list of all the problems encountered during the report generation. Then I happened to try simulating a device with not enough (<1/2MB) space left for the report (as could easily happen with a small USB stick) to see whether I would then get also hundreds/thousands Gramps warning dialogs: $ dd bs=1024 count=500 if=/dev/zero of=test.img $ sudo mkfs.msdos test.img $ mkdir test $ sudo mount -o loop,uid=$USER,gid=users -t msdos test.img test <select "test" directory as the Narrative Web site report output directory> I didn't get the warning dialogs. Gramps froze instead and in console it had following backtrace: ------------------------------------------- Traceback (most recent call last): File "/home/eero/garnome/share/gramps/gramps_main.py", line 1987, in menu_report options_class,translated_name,name,category) File "/home/eero/garnome/share/gramps/Report.py", line 1879, in report report_class(database,person) File "/home/eero/garnome/share/gramps/plugins/NavWebPage.py", line 2603, in __init__ self.make_report() File "/home/eero/garnome/share/gramps/plugins/NavWebPage.py", line 2696, in make_report MyReport.write_report() File "/home/eero/garnome/share/gramps/plugins/NavWebPage.py", line 2113, in write_report self.person_pages(ind_list, restrict_list, place_list, source_list, archive) File "/home/eero/garnome/share/gramps/plugins/NavWebPage.py", line 2196, in person_pages place_list, source_list, self.options, archive, self.photo_list) File "/home/eero/garnome/share/gramps/plugins/NavWebPage.py", line 1368, in __init__ self.display_tree(of) File "/home/eero/garnome/share/gramps/plugins/NavWebPage.py", line 1495, in display_tree f_father = self.draw_connected_box(of,center1,center2,2,m_family.get_father_handle()) File "/home/eero/garnome/share/gramps/plugins/NavWebPage.py", line 1419, in draw_connected_box self.draw_box(of,center2,col,person) File "/home/eero/garnome/share/gramps/plugins/NavWebPage.py", line 1389, in draw_box of.write('<div class="border" style="top: %dpx; left: %dpx;"></div>\n' % (top-1, xoff)) File "/usr/lib/python2.3/codecs.py", line 509, in write return self.writer.write(data) File "/usr/lib/python2.3/codecs.py", line 179, in write self.stream.write(data) IOError: [Errno 28] No space left on device ------------------------------------------- Also, regardless of situation, if some dialog is modal to another dialog/window (i.e. user cannot input to the previous window while the modal dialog is open), it *should* also be set transient to that window so that window manager knows to keep it above that window so that user doesn't "lose" the dialog. I once saw a new Gramps user start 20+ instances of Gramps (before I intervened) because Gramps showed a modal error dialog at startup which blocked input to the rest of Gramps and had each time accidentally gotten hidden (user had clicked Gramps window which window manager topped as transiency wasn't set). User thought that Gramps had (again) frozen, and as he couldn't close Gramps (dialog was blocking its input), he started again another instance and was getting pretty pissed up with Gramps... (In Gtk the dialog is modal if you just call gtk_dialog_run() as that creates another event loop for the dialog.) - Eero ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Gramps-users mailing list Gra...@li... https://lists.sourceforge.net/lists/listinfo/gramps-users |
From: Don A. <don...@co...> - 2006-09-27 05:09:24
|
On Wed, 2006-09-20 at 21:17 +0300, Eero Tamminen wrote: > Hi, >=20 > On Wednesday 20 September 2006 09:17, Duncan Lithgow wrote: > > Character Encoding mismatch! > > > > The character encoding specified in the HTTP header (iso-8859-1= ) > > is different from the value in the <meta> element (utf-8). I > > will use the value from the HTTP header (iso-8859-1) for this > > validation. > > > > I think this means that the server says to the browser that the page is > > in iso-8859-1 encoding but the page itself tells the browser that it's > > utf-8 encoding (which is plainly wrong). > > > > I've never seen that particular failure before so I can't comment on wh= y > > that's happened. >=20 > www-servers are often configured in HTTP header to tell pages with certai= n > extensions to have certain encoding. I would have thought the Content-Ty= pe > tag to override that though. Either complain to your webmaster or use on > the pages the charset that your www-hosting lies your pages to be using. We've experienced problems with different web servers. Even if you specify the the encoding in the HTML file, for some reason, some webservers (including Apache) will override this with their own setting. For this reason, we allow you to specify your character set when you generate the pages. You should match this to what your web server wants to use. Don |
From: Brad R. <br...@fi...> - 2006-10-01 13:54:49
Attachments:
signature.asc
|
On Tue, 26 Sep 2006 23:09:15 -0600 Don Allingham <don...@co...> wrote: Hello Don, > We've experienced problems with different web servers. Even if you > specify the the encoding in the HTML file, for some reason, some > webservers (including Apache) will override this with their own > setting. Which version(s) of Apache is this true for, Don? I ask because the same issue has come up on another ML I subscribe to. --=20 Regards _ / ) "The blindingly obvious is / _)rad never immediately apparent" You're a sidewalk cipher speaking prionic jive Give You Nothing - Bad Religion |
From: Don A. <don...@co...> - 2006-10-01 14:02:41
|
Brad, I don't really know. I would assume this occurs on almost (if not all) versions of apache. I don't know about other systems. For my own purposes, I never stray out of the ASCII range of characters, so I never really see it. Don On Sun, 2006-10-01 at 14:38 +0100, Brad Rogers wrote: > On Tue, 26 Sep 2006 23:09:15 -0600 > Don Allingham <don...@co...> wrote: >=20 > Hello Don, >=20 > > We've experienced problems with different web servers. Even if you > > specify the the encoding in the HTML file, for some reason, some > > webservers (including Apache) will override this with their own > > setting. >=20 > Which version(s) of Apache is this true for, Don? I ask because the > same issue has come up on another ML I subscribe to. >=20 > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share y= our > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ Gramps-users mailing list= Gra...@li... https://lists.sourceforge.net/lists/lis= tinfo/gramps-users |
From: Brad R. <br...@fi...> - 2006-10-01 14:27:01
Attachments:
signature.asc
|
On Sun, 01 Oct 2006 08:02:34 -0600 Don Allingham <don...@co...> wrote: Hello Don, =20 > I don't really know. I would assume this occurs on almost (if not all) > versions of apache. I don't know about other systems. For my own > purposes, I never stray out of the ASCII range of characters, so I > never really see it. I'm the same WRT to characters used, too. Many thanks for the quick response. --=20 Regards _ / ) "The blindingly obvious is / _)rad never immediately apparent" Bet you thought you had it all worked out Problem - Sex Pistols |
From: Alex R. <sh...@gr...> - 2006-10-01 19:37:22
|
Brad, On Sun, 2006-10-01 at 14:38 +0100, Brad Rogers wrote: > > We've experienced problems with different web servers. Even if you > > specify the the encoding in the HTML file, for some reason, some > > webservers (including Apache) will override this with their own > > setting. >=20 > Which version(s) of Apache is this true for, Don? I ask because the > same issue has come up on another ML I subscribe to. Apache 1.x does this by default (not sure about apache2): # Default charset to iso-8859-1 (ttp://www.apache.org/info/css-security/= ). What happens is that the server supplies the header with charset=3Diso-8859-1 (in addition to the served page). The server's header has priority over the "meta" tag in the page itself. So if the server's header says iso-8859-1 then the <meta charset=3D"utf8"> gets ignored. So if you have control over the server, you would need to add the following directive to the /etc/apache/httpd.conf file: AddDefaultCharset UTF-8 and remove anything specifying other default charsets (if any). More details here: http://httpd.apache.org/docs/1.3/mod/core.html#adddefaultcharset If you don't have control of the server, then all you can do is to try converting characters to the server-enforced charset during website generation. Depending on your data this may or may not succeed. Alex --=20 Alexander Roitman http://www.gramps-project.org |
From: Brad R. <br...@fi...> - 2006-10-01 20:35:45
Attachments:
signature.asc
|
On Sun, 01 Oct 2006 12:39:12 -0700 Alex Roitman <sh...@gr...> wrote: Hello Alex, > Apache 1.x does this by default (not sure about apache2): > # Default charset to iso-8859-1 > (ttp://www.apache.org/info/css-security/). Many thanks for the full reply, Alex. With the info you supplied, and a bit of RTFM'ing, the other person has managed to sort the issue out. What they did was kill off /etc/apache2/conf.d/charset, and that fixed the problem. The old server he had was running v1.3.34 of Apache, and the new server 2.0.55. He was lucky, since he has access to the server (it's in his attic, I believe), running from his home, so he's not suffering at the whim of some faceless oick at a large server farm. --=20 Regards _ / ) "The blindingly obvious is / _)rad never immediately apparent" You're the psychotic daughter of a psychotic mother Pure Mania - The Vibrators |