Is this a Bug or is it related to the browser.

A recent (/wiki/?diff=minitar minitar) edit shows garbage characters between '''RealTek(RTL8181)at''' and '''11:22:57 CST 2003 version 1.0''' .

Displayed below hopefully...

> - ---!RealTek(RTL8181)at ¶g¥| 8?ë 7 11:22:57 CST 2003 version 1.0 

Interestingly, it appears to morph into something else while toggling between '''Preview''' and '''Edit Text''' ,and also reproduces itself. Perhaps it's something to do with the preview mode although the next occurence was (I think) before the preview was introduced.


They also show up in (/wiki/?diff=ConnectingToTheNetworkFAQ Connecting To The Network FAQ) under '''Convert degrees, minutes, and seconds to decimal degrees''' - apparently the degrees symbol won't display and conjures up a replacement ;-)

> +*  The latitude and longitude needs to be converted to decimal degrees for locfinder. For example, the AMG coordinates for my house at lat. -37° 50' 43.53603" and long. 145° 5' 31.85668" need to be converted to lat. -37.8454° and long. 145.0922°. Many scientific and engineering calculators have an hours.minutes.seconds-to-hours (decimal) function which can do this. Otherwise, do the following steps. 

I know first hand about the last one as I reimported the relevant section and it appeared to be fine straight after the import, it's since morphed into the garbage characters again.

I'm currently viewing using IE5 version 6.0.26 under win2000. The edit I refer to fixing above was Mozilla 1.6(?) under Linux Fedora core 1.

[GlennMcKechnie graybeard]


Okay, you've got me stumped.  I think this bug is probably related to unicode character translations.  All of the wiki backend is written in ASCII, but it wouldn't suprise me if the browser reinterpreted some of the ASCII as Unicode/ANSI.  I'm using Mozilla Firefox 0.8, and when I look in the __V__iew menu under the __C__haracter Coding submenu I can see that '''Unicode (UTF-8)''' is selected.  If someone gets a chance to play, let me know if you can narrow this down a little more.

Update: I had trouble saving the above paragraph, I'm pretty sure that something is barfing on unicode input.  This may be a PHP bug rather than a RegExpWiki bug or browser bug...

Update 2: Looking at the page source of preview mode, things start to take shape.  It seems that the PHP functions used to ensure correct transfer of special characters such as the degree symbol on the preview form across to the save page are translating too much or too little, or perhaps the browser is interferring with the expected form inputs.  I might have even used the wrong function at one end of the transfer...

Update 3: Lets try a single degree symbol and see what happens in preview mode... here we go: �°  (ends up getting translated to '''�°''')

Update 4: Seems I may have found a (http://lists.oasis-open.org/archives/docbook-apps/200205/msg00348.html clue) - but the problem is that I'm already including the HTML head element that is suggested.  D'oh.  :/
[TysonClugg tc]


Nothing to add unfortunately, I've just trimmed the page as it had grown to approx 105 KBs and IE wasn't coping with it to well. I've trimmed the examples to show the minimum effect while reducing the growth problem.
Interestingly your '''Update :3''' doesn't appear to grow/expand, apparently only certain characters come into play for that to occur.

One observation, under IE the problem text wordwraps, Under Mozilla 1.7-beta it doesn't wordwrap but goes into page widening mode. ;-)

This browser (IE) is set to Unicode(UTF-8) encoding, the one I reported it from is set to Western European(ISO). The growth occurs with them both.

[GlennMcKechnie graybeard]