Bug 1

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

A recent minitar edit shows garbage characters between RealTek(RTL8181)at and 11:22:57 CST 2003 version 1.0 .

Displayed below hopefully...
(page widening bug example text removed - see history for details- graybeard 07/2004)

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 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

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.

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 View menu under the Character 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: (page widening bug example removed - graybeard 07/2004)(ends up getting translated to (page widening bug example removed - graybeard 07/2004) )

Update 4: Seems I may have found a clue - but the problem is that I'm already including the HTML head element that is suggested. D'oh.
tc


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

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.

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

minor update: Nope, Update :3 did grow. From the version diffs on this page, that I did at home, I didn't think it had changed between your edits. It seems this one with the Unicode encoding is adding it's own ingredients to the mix?

Cutting and pasting from the minitar page into this page reproduces the clipboard content faithfully, A Preview then Edit Text cycle does morph some of the characters (the generic 'empty square' takes their place)

graybeard

An attempt to fix things by avoiding use of the degree symbol (using (page widening bug example removed - graybeard 07/2004) instead): 12(page widening bug example removed - graybeard 07/2004)51' 12"

Version 13 (old) modified Mon, 26 Jul 2021 12:49:29 +0000 by tyson