Possible Issue with Code Tag Select All Button

[Karatorian]

When you I press the select all button and then copy the selection in Firefox (3.6.10 Ubuntu Patch 1.0) it always ends up copied with four spaces at the beginning of each line. This wouldn't be much of an issue, except that Golly then parses RLEs as picture format instead, which reduced the patterns to gibberish. So now I have to manually select everything, which is a pain for larger patterns.

It seem to be some kind of browser issue, because I sometimes get the spaces when manually selecting stuff. However, I haven't tested it on any other browsers, so I can't be sure. It probably has something to do with the code block being in a <dd> tag, which are traditionally displayed indented. So if you selected a definition list, the plain text would turn out somewhat resembling the page layout. Of course, as the dd tag is being repurposed (perhaps inappropriately) here, things don't turn out so well.

It may be possible to slightly edit the template to use a more appropriate tag (div probably) or work around the issue in the select button JavaScript. I know a bit about web development and would be willing to look into this if you're interested. Or should I just go bug the phpBB guys instead?

So, does anyone else have the same issue, or is it just me?

[Extrementhusiast]

I also have the same problem, but I have a rather simple remedy: Paste the selection in Word, select all of it (by using CTRL/COMMAND-A), cut it (CTRL/COMMAND-X), and then it should work. I also had this same problem, but I didn't realize that it was the code tag's "Select All" button that was causing all of the trouble.

[Paul Tooke]

I have a simpler remedy. The Golly/Python script below strips out leading whitespace from anything in the clipboard. To install it, just save it into your Golly Scripts/Python folder as fixrle.py or somesuch. To use it, click the "Select All" link on the web page, copy to clipboard, and then in Golly click on the script name before pasting. If you keep your scripts folder open all of the time this adds just one mouse click to the entire copy-and-paste operation and doesn't require another application to be open(ed).

Of course a more thorough script would fix broken or missing header lines, but I haven't suffered from those enough to write a script to deal with them.

Code: Select all

# A Noddy Golly/Python script to fix broken RLE in the clipboard 
import golly as g

def fixRLE(input = ""):
	outstr=""
	for l in input.split('\n'):
		outstr += l.strip() + '\n'
	return outstr

# Is it a coincidence that the Golly help for these functions
# describes precisely what we're trying to do here?
g.setclipstr(fixRLE(g.getclipstr()))

[Karatorian]

I was thinking about writing a script to do just that, but I hadn't gotten around to it. Sweet.

EDIT

So, I did some investigating and found a possible solution to this issue. If the dd tag in the code block is changed to a div, the selection copies just fine. Of course, then the code block ends up being a weird hybrid structure which consists of a dl containing a dt and a div. It would make more sense (from a semantic HTML point of view) to change the whole structure into just divs, but that breaks the stylesheets (I was surprised that changing the dd didn't), so it would be more work. As the semantic value of the current structure is questionable at best, I don't think this really matters.

Well, actually, one stylesheet does produce different results when you use the div, that being the print stylesheet. Note that this is not the stylesheet you get when you hit the print view button, but the one that gets used when you just print the normal view. The code block is no longer indented if you use a div. However, I don't think the difference really matters that much. Besides the print view button produces much better results anyway. (Realistically, they ought to be the same. but that's a deeper phpBB issue.)

So hopefully this issue can be fixed fairly easily.

[dvgrn]

The problem seems to occur only on Firefox -- neither IE7 nor Google Chrome seem to have any trouble with copied Select-All RLE from the forums.

Can someone confirm that the script works OK on Mac and Linux systems? Sometimes problems show up because 'standard' newline characters in text data are different in different OSes -- but it might be OK for data copied out of a browser window. Of course, Safari or Opera or Konqueror or (pick your favorite Mac or Linux browser), or even the Mac/Linux version of Firefox, might not produce RLE with leading whitespace in the first place. It might be easier just to manually add whitespace to standard RLE text -- try testing with the following:

Code: Select all

    #C sample RLE with leading whitespace
    x = 9, y = 5, rule = B3/S23
    3obo2b2o$obobo2bo$2o2bo2b2o$obobo2bo$obob2o2bo!

Seems to me this might just be worth fixing permanently, with a minor parsing-code change for Golly 2.2 -- even though it's technically a Firefox-specific bug. I've seen other cases, mostly involving forwarded or quoted emails, where RLE gets extra whitespace added to the beginning of each line. Is there any reason why this shouldn't Just Work?

For headerless RLE I could see a problem; you can't necessarily tell a short RLE snippet from a short ASCII picture-format snippet, and spaces are sometimes used as OFF cells. But if there's whitespace in front of a standard "x = ..., y = ..." header, then I think the same whitespace could safely be ignored before all following lines.

Comments? Suggestions?

[Karatorian]

Can someone confirm that the script works OK on Mac and Linux systems? Sometimes problems show up because 'standard' newline characters in text data are different in different OSes -- but it might be OK for data copied out of a browser window.

I haven't tested the script yet, but as Python's strip function removes all whitespace from the front and back of the string (including /n, /r/n, and /r, the three common line breaks) it should work fine on all platforms.

Of course, Safari or Opera or Konqueror or (pick your favorite Mac or Linux browser), or even the Mac/Linux version of Firefox, might not produce RLE with leading whitespace in the first place.

Actually, I'm using the Linux version of Firefox, so I can confirm it appears there.

Seems to me this might just be worth fixing permanently, with a minor parsing-code change for Golly 2.2 -- even though it's technically a Firefox-specific bug.

As I've confirmed it's the dd tag that causes the issue, I don't think the Firefox team would consider it a bug. Indenting the contents of a dd tag is a reasonable display when converting HTML to plain text, which is what happens when you copy and paste. So they'd consider it a feature. It's only phpBB's silly use of the dd tag that causes the issue.

That said, changing Golly's RLE parsing to handle such cases would be nice as well.

[dvgrn]

I haven't tested the script yet, but as Python's strip function removes all whitespace from the front and back of the string (including /n, /r/n, and /r, the three common line breaks) it should work fine on all platforms.

Well, but the script's first act is to split the input on '\n'. I've occasionally had to deal with Mac-formatted text files that use '\r' as a newline delimiter, with no '\n' at all -- just not sure whether a Mac browser might produce \r-delimited text somehow.

From a Google search just now, it appears that Mac OS X switched over to Linux/Unix-style '\n'-only newline delimiters, and the '\r' delimiters are only for OS 9 and before (wow! talk about breaking legacy code... but it makes sense, I suppose, given OS X's roots.) So \r-delimited text may no longer be a problem worth worrying about.

[BurningPi]

I can confirm that this bug occurs in the OS X version of Firefox. It doesn't happen in safari, though.
I can also confirm that the line-terminator on OS X is the *nix \n, rather that Windows \r\n or MacOS 9 and below \r.

The Python script Paul Tooke Posted above works for me, by the way.

[Andrew]

Can someone confirm that the script works OK on Mac and Linux systems?

It didn't work on my Mac (using Safari to copy the RLE lines -- not sure why it worked for BurningPi), but the following script has some minor changes that should work on all platforms:

Code: Select all

# A Golly script to remove spaces at the start of RLE lines in the clipboard.
import golly as g

def fixRLE(input = ""):
   outstr=""
   for l in input.split('\n'):
      outstr += l.strip() + '\n'
   return outstr

CR = chr(13)
LF = chr(10)
g.setclipstr(fixRLE(g.getclipstr().replace(CR+LF,LF).replace(CR,LF)))

I'm not that keen on modifying Golly's RLE-reading code to handle such problems. If Karatorian is right about changing the tag stuff then I'd rather Nathaniel fix things that way.

[Awesomeness]

It's clearly a problem with the Gecko layout engine, since Camino has the same problem and it's based on Gecko too.

[ssaamm]

well, is there any way that the code could be modified or custom code inserted to beat this problem at the source?

[Nathaniel]

I've implemented Karatorian's suggested fix and things seem to be working fine for me in Firefox now. Let me know if the select all button is/isn't working as you all would hope now.

[Karatorian]

Just tried it in Firefox and it works.