Some of this is only obliquely related to Golly...
I've always written RLE parsers assuming that the lines are left-justified, and are padded on the right if shorter than the header dimensions. Similarly, rows are top-justified, with blank lines at the bottom. So, I would argue that centering should be considered non-standard or an extension of the definition. (But it does seem to work nicely for bounded arrays.)
It seems that Golly adds whitespace on the left and top with runs of blanks ("nnnb") or multiple blank lines ("nnn$"). This works, except you end up multiple RLE strings that are different but encode the same object, making string matching more complicated.
Here's a Glider, for example:
Code: Select all
x = 58, y = 50, rule = B3/S23
22$31b3o$31bo$32bo!
Long ago when I needed to define multiple RLE bit-patterns that would overlay, I added two parameters to the header, "h=" and "v=", to specify the horizontal and vertical offset relative to the first pattern in the array. That pattern didn't need these additions, and was assumed to have its upper-left corner at the origin, unless there was a specific offset. So the above Glider would be:
(Note how that's not considered displayable because of the missing linebreak.)
Here's another example, using the stages of an monlithic construction pattern I got from Catagolue, compared to one partitioned into multiple patterns.
Code: Select all
x = 150, y = 50, rule = B3/S23
2bo$obo$b2o7$36bo$35bo$35b3o$29bo$29bobo$29b2o$33b3o$33bo$34bo$96b
2o2bo34b2o2bo$96bo2bobo33bo2bobo$97bobobo34bobobo$98bo2b2o34bo2b2o
$99b2o2bo34b2o2bo$102b2o37b2o$87b2o56bobo$86bo2bo55b2o$87bobo45bo
10bo$88bo46b2o$134bobo3b2o$90b3o46b2o$90bo50bo5b2o$91bo55bobo$147b
o$143b2o$142bobo$144bo5$19b2o$13b2o5b2o31b3o$4b3o5bobo4bo33bo$6bo
7bo39bo$5bo3$53bo$52b2o$52bobo!
Code: Select all
#C partitioned into stages
x=56, y=50
2bo$obo$b2o7$36bo$35bo$35b3o$29bo$29bobo$29b2o$33b3o$33bo$34bo23$19b2o$13b
2o5b2o31b3o$4b3o5bobo4bo33bo$6bo7bo39bo$5bo3$53bo$52b2o$52bobo!
x=18, y=14, h=86, v=18
10b2o2bo$10bo2bobo$11bobobo$12bo2b2o$13b2o2bo$16b2o$b2o$o2bo$bobo$2bo2$4b
3o$4bo$5bo!
x=16, y=18, h=134, v=18
b2o2bo$bo2bobo$2bobobo$3bo2b2o$4b2o2bo$7b2o$11bobo$11b2o$bo10bo$b2o$obo3b
2o$5b2o$7bo5b2o$13bobo$13bo$9b2o$8bobo$10bo!
(Note that I still try to respect the line length limit, although if I didn't, this could be formatted as three long lines.)
The partitioned version is a little larger than the solitary version, but I think it's worth it. This is the way stamp collections should be organized. It should be relatively easy to compare the encoded bitpatterns to find the changed objects or new objects. There could also be comment lines and blank lines annotating the pattern, too. Viewer programs like Golly could even have a "Paste as stamp collection" which would determine a nice layout based on the sizes of the sub-patterns.