AltME groups: search

(I know that's ascii...was just downloading the chart...but guess 
I should write a script...)

Is there an existing Rebol function that will escape ascii from hex 
to char?  ie from %7C to | ?

There is nothing standard when it comes to ascii.. bin version, hex 
version, oct version, binary version, windows 2k version, windows 
XP version, IBM PC version, and many others, no doubt.  I have more 
lines of code dealing with ascii, then all the rest combined :(

I have a block of value pairs, and can do a foreach [ascii chara][replace/all 
..] but that seems rather crude

It's not a perfect solution, I still need a block of values to handle 
odd browser escaping.. for example, when you add a © to  a url, Mozilla 
escapes it with "%C2%A9"  .. adding that extra ascii character for 
some reason.

And, while you are critiquing the Library, check out the Articles 
section.
http://www.rebol.org/cgi-bin/cgiwrap/rebol/art-index.r
It's often overlooked, and frankly quite bare of content.

But it is a central place to publish articles. And it accepts them 
in most common REBOL mark-up languages (MakeDoc variants, eText. 
ASCII etc) so no additional learning curve needed.

I'm rather badly needing a pagemaker pm5 file converted to ASCII 
format. My copy of Pagemaker has been corrupted, and I just want 
to print a document using LaTeX. The file is about 309 MB. Is there 
anyone here that can do this for me?

1.  link tasks with the calendar

2.  "clear all" a simple button which removes red color of all groups. 
usefull when skipping a few days...

3.  HIDE groups (and users).  just add simple check mark to  window 
which lists all available groups and any you check-off are removed 
from the list you look at (yet you still receive their posts, if 
you want to look at them another time).

4.  per group moderators for private AND public groups (delete posts, 
insert posts, manage users, etc.   A part from "opting out", users 
are not able to change the setup (like deleting the group), group 
name, list of users in private group, etc ).  

5.  single file export of all selected task lists and their tasks 
(ascii or html)

6.  SORT task list... we cannot sort the task lists... only the tasks 
they contain... a real bitch when working with others...

7.  Also allows read-only mode for private groups for people not 
in private users list.   Great to manage announcements for private 
tools.
8.  'workdays only - weekend only' option for calendar

9.  properly support hours in calendar tasks, so that hours are always 
available, right now, the software often ignores any data we put 
in the hours field..

Of course there are some limitations:
 1. if a post does not have a
    rebol []

    to identify the start of the code, we may fail in executing text
 2. ditto if there is text after the script
 3. assumed to be ascii file (not UTF-8 etc) right now
 4. post may take 12 to 18 hours to appear on REBOL.org archive

to-binary treats its input as a string -- not a number -- and converts 
each byte to it's hex ASCII respresentation  -- not ar all an intuitive 
meaning for to-binary.
Even worse, perhaps is
>> enbase/base "23" 2
== "0011001000110011"

which appears to have converted to binary. But, again, it's the ASCII 
for "2" and "3" not the binary for 23.

I think rebol doesn't load #"^M" and #"^J" because they are CR (ascii 
13) and LF (ascii 10).  In rebol, these are molded to #"^M" and #"^/".....

I wonder what font AGG use ? None of the ASCII 128+ char are displayed, 
 except 251 that show "OBJ" in a box !!

test-address-import: func [

 {Returns true if pass, false if discrepency and none if failed with 
 error.}
	limit [integer!] "Number of TO address to generate."
	/quiet "Does not display error."
	/local to-list eml sep msg obj
] [
	to-list: copy {} sep: ""
	repeat i limit [
		eml: to-email join "test-" [i "@test.com"]
		repend to-list [sep {"'} eml {'" <} eml {>}]
		if empty? sep [sep: {,^/	}]
	]

	msg: replace copy {Date: Thu, 12 Feb 2004 11:41:49 +0100
From: test <[test-:-test-:-com]>
MIME-Version: 1.0
To: TO_LIST
Subject: [REBOL] test message - edited copy of real message
Content-type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
Sender: [rebol-bounce-:-rebol-:-com]
Reply-to: [testing-:-testing-:-com]
Status:   


Test message.
} {TO_LIST} to-list

	either error? set/any 'result try [
		obj: import-email msg
		limit = length? obj/to
	][if not quiet [print mold disarm result] none][result]

]

parsing binary is a bit different than parsing ASCII...and I have 
done a bit for mp4...but I think your point of making it simple is 
a good thing.

Hello;
  How do you convert a letter (ASCII) to it's hex equivalent?

  I've tried to-hex but it wants an integer!?  You would think it would 
  be easier than:


print to-integer to-string to-hex to-integer to-decimal to-char "a"

which works but there has got to be an easier way.

seems like an empty block should only take 2 bytes...but then that 
is just the ASCII representation...binaries are bigger than their 
source code...I would expect some list links pointing, some datatype 
info...dunno.  Maybe try a small program like REBOL[] probe empty: 
[] and inspect the RAM of it.

hex-editor or ascii or decoding this unix-rights-numbers or such.

- Read a part of the file. If every byte is ASCII (or 8-bit), it's 
text, else it's binary. This is only a good guess, of course!

- Many types of files have some header information right at the start 
of the file. Make a list of those headers. (I think, this is the 
way, many datatypes works in Amiga OS.)

When you import data using "data: read/binary {sometextfile}" you 
seem to get a string of hex values.  Ex:

probe 'data' of a file containg the word "Hello"  results in #{48656C6C6F} 
but if you 

probe first data it returns 72.  So when you probe the entire data 
stream it returns it in hexidecimal format
but when you probe each character it returns a decimal value.


At any rate how do you convert the characters in the variable 'data' 
back into ASCII values?  IOW, how do you convert the decimal value 
of 72 back into an "H" or the #{48656C6C6F} back into "Hello"?

not saying /lines has an issue, but I have loaded 700MB ascii files 
on a 1GB RAM computer... 150 is peanuts.  but I never use the /lines 
argument.

The following code: 

unicode-to-ascii: func [ from to /local fs ts sz] [
    fs: open/binary/direct/read from
    ts: open/binary/direct/write to
    sz: size? from
    fs/1 fs/1 ; discard the first two bytes, FFFE
    for i 3 sz 2 [
        append ts to-char fs/1 
        fs: skip fs 1 ; SKIP is the problem
    ]
    close fs
    close ts
]
unicode-to-ascii %/c/Unicode.txt %/c/Ascii.txt

In REBOL/View 1.2.7.3.1 12-Sep-2006 Core 2.6.0
** CRASH (Should not happen) - Expand series overflow

In REBOL/View 1.3.2.3.1 5-Dec-2005 Core 2.6.3
** Script Error: Not enough memory
** Where: do-body
** Near: fs: skip fs 1

I need to sort some French words but REBOL's SORT puts accented characters 
on the end (sorts just by ASCII). Has anybody got some enhanced SORT 
for French?

Slight change of subject but here I  am all happy saving/all  and 
loading my objects and then it hits me: Just what is this "serialized" 
data? How is it different (outside of that fact that it's ascii representation 
is different.) I don't know if I need to know to use it but in case 
I'm ever on TV I want to answer it correctly.

Ok, I found the problem. When I saved the file with the Windows program, 
I saved it in utf8 format. Resaving it in ascii format solved the 
problem.  I realized the problem with I noticed some Chinese characters 
in the output past what I pasted in above.

kib2: "Does that mean that we can use unicode encoding with the help 
of r2-forward ?"

No, I only can only spoof datatypes that don't exist in R2, and R2 
has a string! type. The code should be equivalent if the characters 
in the string are limited to the first 256 codepoints of Unicode 
(aka Latin-1), though only the first 128 codepoints (aka ASCII) can 
be converted from binary! to string and have the binary data be the 
same as minimized UTF-8.

There's already an optional "see also" header, eg:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=ascii-chart.r

And there's no reason why that can't generate a footnote in the same 
way that the "replaced-by" header does, eg:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=calc-engine.r


All we need now is a volunteer to go through 600+ scripts and group 
them together.

Use the download URL, eg:

do http://www.rebol.org/cgi-bin/cgiwrap/rebol/download-a-script.r?script-name=ascii-chart.r

There is big problem with rebol.org library if you are using different 
than ascii chars. I've just submited a script which contains latin2 
chars and it's not uploaded correctly as there were converted to 
utf8 (so the script will not be working correctly as the chars are 
used in parse.

I just added ascii-math.r to the library. It looks fine in the  view 
, but the downloaded file contains gibberish characters before each 
non-standard ascii char. This problem may be related to the problem 
that Oldes was having on 14-Mar-08.

Thanks for the script -- and for the problem report.

Looks to me like the script, as uploaded, contained non-UTF8 characters, 
and they are being treated as multi-byte characters.

REBOL, and REBOL.org can really only handle ASCII....Unicode and 
such like is for R3.


If you email (preferably in a ZIP to prevent email software from 
chewing up the code) the original script, I'll take a look.

If most of it is currently ascii, would it not just be a case of 
adding a few filters?

We've had a similar problem before (I've just checked the source 
code, and it's prompted my memory).


To solve it, we analyse the script for various extended ascii chars 
and then perform some messing around on HTTP content-type headers.


It's messy, and it's worked up til now......But obviously, we need 
some more analysing and messing around for this script.

Results of a tiny bit of debugging on the ascii chars problem:
-- problem seems to be at the input stage:

     -- if you have exended ascii characters (top bit set, like the 1/4 
     used in the script) what we get from the webserver is bad (extra, 
     unexpected extended ascii chars)

    -- only download is (visibly) affected, although the extra extended 
    ascii chars are present in the text streams

     -- though there is some REBOL mezz code (decode-cgi) that may be 
     doing something I do not understand

    -- I can replicate the problem with both Apache and Xitami which 
    suggests the problem may be in REBOL rather than a given server.


-- the quick fix would be to add accept-charset="ISO-8859-1" to the 
<form ....> or <textarea ....>

    -- but that stops all extended ascii, including the ones we want. 
    So we won't do that.

-- the slower fix has yet to emerge from the available options.

does not support UTF-8

 - what do you mean by "support"? if you mean having native encoders/decoders, 
 no, it does not. but, utf-8 is just 8 bit characters, and it is backwards 
 compatible with ascii. if you can handle ascii, and leave alone any 
 char > 127, you already support utf-8.

Sadly, REBOL running as CGI under the two servers I've tested (Apache 
and Xitami) does not seem to support the whole range of ASCII -- 
ASCII chars with the 8th bit set seem to cause problems.

I don't know where the problem really is, but right now, we do not 
even support 8-bit ASCII, let alone anything more modern :-)

Sunanda, can you publish some files with the 8-bit ascii and note 
what the problems are ?

Anton, REBOL.org uses 2.5.6.4.1

The obvious bad file is the one Scott added recently:
http://www.rebol.org/view-script.r?script=ascii-math.r

If you view it with that URL, all looks good.

If you click the [Download script] link you'll see many spurious 
high-ascii chars in the source.

Those high ascii _are_ actually in the source. But where they came 
from is a mystery.

Sunanda, you're right about that ascii-math.r file. When I clicked 
the [Download script] link, the browser (konqueror) downloaded and 
directly opened it with the editor (SciTE). SciTE thought it was 
8-bit ascii, and showed the characters incorrectly. All I had to 
do was change the file encoding from 8-bit to utf-8 and the characters 
appeared correctly. I guess the editor had no way of determining 
the encoding, and incorrectly guessed 8-bit ascii.

Thanks Gabriele -- that's a clear explanation, and has helped me 
work out what is going on.


Anton and Gabriele -- I have tried changing the charset we emit on 
the download to say UTF-8. But that makes little difference. As both 
of you note, once the file has been saved then (without a MAC-type 
resource fork) there is no obvious indication of the encoding. And 
several editors I have tried get it wrong -- thus "revealing" the 
extra ASCII chars.


Not sure what the solution is other than to de-UTF-8 files on download.

Anton -- not yet run a crawl to check for other scripts with high 
ascii chars.

It seems the responsibility lies with the clients to interpret encodings 
properly. As we move to a unicode world, software assuming 8-bit 
encodings are some ASCII encoding should drop off. But until the 
transition is complete, there's not much we can do about client software 
guessing wrong like that, except stating the encoding in the script 
header, in the web page that provides the download link, and by helping 
confused newbies.

If the offending downloaded script is executed in Rebol/Core, the 
extra ASCII chars are also present in the executed code.  The script 
defines ½ to be 0.5. If "help ½" is typed into the console, the result 
is "Found these words:   ½              decimal!  0.5". However, 
if the script is executed in Rebol/View, the result is "½ is a decimal 
of value: 0.5". It seems that View handles it correctly, while Core 
doesn't.

Thanks guys.
Other scripts with the same problem.....there are a couple. 

About 10% of all scripts have at least one extended ASCII char....But 
most of them are acceptable in LATIN-1 code page / charset (eg copyright 
symbol, some accented letters). It's just a very few scripts that 
use 1/4 and similar symbols that cause the problem.


What other editors? Windows NOTEPAD is one example of a common one 
that gets this wrong.

Of the various editors / word processors I have immediately to hand:

-- credit.exe -- [my usual editor] shows incorrect chars, and has 
no option to switch to UTF-8

-- open office writer -- works fine if you take the UTF-8 option 
when asked
-- ms word -- claims file is corrupt
-- word perfect -- makes a complete mess

-- R2/View's built in editor ( editor %/c/path to my local copy//ascii-math.r) 
-- shows incorrect chars

Ok, so there are some editors which don't support unicode, don't 
guess encoding correctly, or can change encoding only with difficulty.

How about this suggestion; if a rebol.org script is known to be UTF-8, 
then an additional link should appear:

[Download as ASCII] download-a-script?script-name=ascii-math.r&encoded-as=8-bit-ascii
which transcodes a UTF-8 file to ASCII.
Just have to get a conversion function in place for this to work.

Thanks everyone.

I think our first step is to add a warning to any download for scripts 
that contain UTF-8 chars.

So, for that I need a function:

     utf-8?: func [data [string!] [ ...]   ; returns true or false [and 
     perhaps "not sure" in ambiguous cases]

I've done the easy part :-)
Can anyone help with the difficult "..." part ?


It is not as simple as just looking for ASCII > 128 .... some high 
ASCII is acceptable as part of, say, ISO 8859-1

Something new in the Library....If you own scripts, you can add images 
to them to make it all a bit more graphic.

Only example to date here:
    http://www.rebol.org/view-script.r?script=ascii-chart.r

Notes about how to add images to yoour scripts here:
    http://www.rebol.org/boiler.r?display=script-images

Thanks to Maxim for the original change request.

insert is a word because there is no char for it in ascii; there 
is a char for delete, so it's a char :)

Gabriele, 

Actually, Oldes is right. Showing two-byte characters is good enough. 
IME is not necessary for REBOL/View, because every Chinese/Japanese/Korea 
OS has proper IMEs installed. IME sends the codes encoded in the 
OS codepage to the focused window. For Example, If the codepage used 
by Windows XP is Big5 and I type in the Character which means one 
( #{A440} in Big5, #{4E00} in Unicode, see http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=4E00
), my REBOL/View program will get two key events sequentially, which 
are #{A4} and #{40}. REBOL/View shows it as two characters instead 
of one. I hope that REBOL/View can let the OS do the text-drawing, 
like the REBOL/core console does. REBOL/core console doesn't have 
the Chinese-Character-Showing issue, because it basically send the 
#{A4} and #{40} to the console, and let the OS do the text-drawing. 
the OS knows that #{A4} and #{40} should be combine to one Big5 Character, 
so it just show it as one character. Of course, if I type in two 
ASCII characters, the OS is smart enough not to combine them into 
one "non-existing" Big5 Character. CJK encodings are supersets of 
ASCII, just like UTF-8 is a superset of ASCII.


It's nothing to do with Unicode, so it is not too difficult to fix, 
I guess. Please fix this in 2.7.5 or 2.7.6 please ... 

It's on my wish list for Santa Claus this year.

Base 64 in REBOL is, basically, a type of ASCII represention. It 
can stand a certain amount of damage (like whitespace being inserted 
-- imagine it is sent as an email) and can still be reconstructed:
    str: "abcdefabcdef"      ;; a string
    s64: enbase str    ;; enbased to base-64 by default

    replace/case/all s64 "W" "  W  "   ;; whitespace polluted in transit
    str = to-string debase s64    ;; do we get it back intact?

Sort sorts only by ascii, the other things you need to compare yourself.

In my largest grammar, where incoming data may be malformed, I've 
found it invaluable to have the rule tracing built in, enabled by 
a flag. e.g. 

    TSAFE-CHAR: [
        (rule-trace "TSAFE-CHAR IN")
        copy =TSAFE-CHAR charset-21
        | charset-22
        | charset-23
        | charset-24
        | charset-25
        | NON-US-ASCII
        (rule-trace "TSAFE-CHAR OUT")
    ]

    rule-trace: func [value /local rule-name action] [
        rule-name: first parse value none

        ;print [tab rule-name tab found? find don't-trace rule-name]
        action: second parse value none
        if all [
            any [
                trace-rules? = true
                action = form trace-rules?
            ]
            not found? find don't-trace rule-name
        ][
            val: attempt [mold get to word! join "=" rule-name]
            print ["===" value  any [val ""]]
        ]
    ]


Don't-trace allows you to turn off selected rules that may get called 
a lot. You could also set tracing levels if you wanted.

I have no plans on jumping into R3 at this point, since there are 
so much even on R2 I need to learn. But for the future reference, 
is there any plan for a tool (or mode in Rebol itself) to help Flagging 
out those R2->3 differences... For example, I remember seeing that 
PICK works differently on R3 (right, unlike R2 which is offsetted 
by one), it'll be quite hard to spot all those from source alone, 
since parameters are often defined at runtime?


Some changes will of course be obvious (for spotting), like sockets, 
since their parameters have been canged a lot. but difference on 
data readiding/writing (ascii/binary/unicode etc) may hide itself 
quite a while.

>> append #{} 15
== #{3135}
>> append #{} "15"
== #{3135}


Why if I append an integer to a binary it is first converted to an 
ascii string?

IMHO it should be like this:
>> append #{} to-char 15
== #{0F}

Then there's ascii char 160, which you can generate in rebol with 
to-char 160. I think they call it a 'hard space' or something.

then I found a very simple way to convert a unicode file to ascii 
in DOS,
TYPE my-unicode-file > my-ascii-file


This line converts the file to ascii, just non-convertable characters 
looks wierd but rest is ok.

what is MDP-Browser ? MDP-Browser is a software designed to work 
with IOS server  in a wiki like way. MDP-browser is a merge betwin 
MD-Viewer and  MDP-GUI some kind of nutural son of those two programs. 
It's similar to his parents but entends truelly the capabilities 
of both program.  First of all VID rendering have been improved (bullet 
points  are drawn using effect/Draw and not any more ascii chars), 
Viewed text resizing exist

Yeah, it's amazing that good old text format is now starting to break 
down as we head toward different encodings.  System designers like 
to outsmart themselves sometimes.  :)  Not that advancing out of 
an English only ASCII character set is a bad thing, but it may take 
a while to get everything back to quick and easy again.

non-ascii: the only supported encoding so far is latin1 (basically... 
more precisely i think i have it set to the Windows variation, which 
iirc is windows-1252) - that is, the same that View uses on western 
Windows installations.

space/spc
whitespace/wsp
alpha
digit(s)
alpha-num	; should digit be num?
ctl/control
non-US-ASCII/high-ASCII
quoted-string
escaped-char    ; what is the escape though; REBOL ^, C \, etc.?

What other standard sets would we want?

ah, got reply on Chat from Carl towards complementing:


Re #5718: Pekr, that's a good question, and I think the answer must 
be YES. We need to be able to complement bitmaps in a 

nice way". Otherwise, Unicode bitmaps, even if simply used on ASCII 
chars, would take a lot of memory.


This change should be listed on the project sheet, and if not, I'll 
add it there."

Is there any advantage in breaking up charsets that represent a large 
varied range of the 16-bit character space? For example, XML names 
are defined as below (excluding > 2 ** 16), but are most commonly 
limited to the ascii-friendly subset:

	w1: charset [

  #"A" - #"Z" #"_" #"a" - #"z" #"^(C0)" - #"^(D6)" #"^(D8)" - #"^(F6)" 
  #"^(F8)" - #"^(02FF)"

  #"^(0370)" - #"^(037D)" #"^(037F)" - #"^(1FFF)" #"^(200C)" - #"^(200D)" 
  #"^(2070)" - #"^(218F)"

  #"^(2C00)" - #"^(2FEF)" #"^(3001)" - #"^(D7FF)" #"^(f900)" - #"^(FDCF)" 
  #"^(FDF0)" - #"^(FFFD)"
	]
	w+: charset [

  #"-" #"." #"0" - #"9" #"A" - #"Z" #"_" #"a" - #"z" #"^(B7)" #"^(C0)" 
  - #"^(D6)"

  #"^(D8)" - #"^(F6)" #"^(F8)" - #"^(037D)" #"^(037F)" - #"^(1FFF)" 
  #"^(200C)" - #"^(200D)"

  #"^(203F)" - #"^(2040)" #"^(2070)" - #"^(218F)" #"^(2C00)" - #"^(2FEF)" 
  #"^(3001)" - #"^(D7FF)"
		#"^(f900)" - #"^(FDCF)" #"^(FDF0)" - #"^(FFFD)"
	]
	word: [w1 any w+]

Both w1 and w+ appear to be very large values.  Would it be smart 
to perhaps do:

	[[aw1 | w1] any [aw+ | w+]]

Where 'aw1 and 'aw+ are limited to ascii values?

claude... so, did you try to run it as a script?


one thing I would do... since this is a strange error is to retype 
this:

 " ^-"


in your editor... to make sure its not using the wrong ascii character 
on your os... it should not be a problem... but there is something 
weird going on here.

>> db: open mysql://root:[gaia-:-127-:-0-:-0-:-1]/information_schema
connecting to: 127.0.0.1
>> insert db "select * from collations"
== none
>> length? copy db
== 124
>> probe copy db
none
== none
>> insert db "select * from collations"
== none
>> probe copy db

[["big5_chinese_ci" "big5" "1" "Yes" "Yes" "1"] ["big5_bin" "big5" 
"84" "" "Yes" "1"] ["dec8_swedish_ci" "

dec8" "3" "Yes" "" "0"] ["dec8_bin" "dec8" "69" "" "" "0"] ["cp850_general_ci" 
"cp850" "4" "Yes" "" "0"] [
cp850_bin

 "cp850" "80" "" "" "0"] ["hp8_english_ci" "hp8" "6" "Yes" "" "0"] 
 ["hp8_bin" "hp8" "72" "" ""
0

] ["koi8r_general_ci" "koi8r" "7" "Yes" "" "0"] ["koi8r_bin" "koi8r" 
"74" "" "" "0"] ["latin1_german1_c

i" "latin1" "5" "" "" "0"] ["latin1_swedish_ci" "latin1" "8" "Yes" 
"Yes" "1"] ["latin1_danish_ci" "latin1"

 "15" "" "" "0"] ["latin1_german2_ci" "latin1" "31" "" "Yes" "2"] 
 ["latin1_bin" "latin1" "47" "" "Yes" "1"

] ["latin1_general_ci" "latin1" "48" "" "" "0"] ["latin1_general_cs" 
"latin1" "49" "" "" "0"] ["latin1_spa

nish_ci" "latin1" "94" "" "" "0"] ["latin2_czech_cs" "latin2" "2" 
"" "Yes" "4"] ["latin2_general_ci" "lati

n2" "9" "Yes" "" "0"] ["latin2_hungarian_ci" "latin2" "21" "" "" 
"0"] ["latin2_croatian_ci" "latin2" "27"


 "" "0"] ["latin2_bin" "latin2" "77" "" "" "0"] ["swe7_swedish_ci" 
 "swe7" "10" "Yes" "" "0"] ["swe7_bin"

 "swe7" "82" "" "" "0"] ["ascii_general_ci" "ascii" "11" "Yes" "" 
 "0"] ["ascii_bin" "ascii" "65" "" "" "0"

] ["ujis_japanese_ci" "ujis" "12" "Yes" "Yes" "1"] ["ujis_bin" "ujis" 
"91" "" "Yes" "1"] ["sjis_japanese_c

i" "sjis" "13" "Yes" "Yes" "1"] ["sjis_bin" "sjis" "88" "" "Yes" 
"1"] ["hebrew_general_ci" "hebrew" "16" "

Yes" "" "0"] ["hebrew_bin" "hebrew" "71" "" "" "0"] ["tis620_thai_ci" 
"tis620" "18" "Yes" "Yes" "4"] ["tis

620_bin" "tis620" "89" "" "Yes" "1"] ["euckr_korean_ci" "euckr" "19" 
"Yes" "Yes" "1"] ["euckr_bin" "euckr"

 "85" "" "Yes" "1"] ["koi8u_general_ci" "koi8u" "22" "Yes" "" "0"] 
 ["koi8u_bin" "koi8u" "75" "" "" "0"] ["

gb2312_chinese_ci" "gb2312" "24" "Yes" "Yes" "1"] ["gb2312_bin" "gb2312" 
"86" "" "Yes" "1"] ["greek_genera

l_ci" "greek" "25" "Yes" "" "0"] ["greek_bin" "greek" "70" "" "" 
"0"] ["cp1250_general_ci" "cp1250" "26" "

Yes" "" "0"] ["cp1250_czech_cs" "cp1250" "34" "" "Yes" "2"] ["cp1250_croatian_ci" 
"cp1250" "44" "" "" "0"]

 ["cp1250_bin" "cp1250" "66" "" "" "0"] ["gbk_chinese_ci" "gbk" "28" 
 "Yes" "Yes" "1"] ["gbk_bin" "gbk" "87
 
 

Yes" "1"] ["latin5_turkish_ci" "latin5" "30" "Yes" "" "0"] ["latin5_bin" 
"latin5" "78" "" "" "0"] ["

armscii8_general_ci" "armscii8" "32" "Yes" "" "0"] ["armscii8_bin" 
"armscii8" "64" "" "" "0"] ["utf8_gener

al_ci" "utf8" "33" "Yes" "Yes" "1"] ["utf8_bin" "utf8" "83" "" "Yes" 
"1"] ["utf8_unicode_ci" "utf8" "192"


 "Yes" "8"] ["utf8_icelandic_ci" "utf8" "193" "" "Yes" "8"] ["utf8_latvian_ci" 
 "utf8" "194" "" "Yes" "8"

] ["utf8_romanian_ci" "utf8" "195" "" "Yes" "8"] ["utf8_slovenian_ci" 
"utf8" "196" "" "Yes" "8"] ["utf8_po

lish_ci" "utf8" "197" "" "Yes" "8"] ["utf8_estonian_ci" "utf8" "198" 
"" "Yes" "8"] ["utf8_spanish_ci" "utf

8" "199" "" "Yes" "8"] ["utf8_swedish_ci" "utf8" "200" "" "Yes" "8"] 
["utf8_turkish_ci" "utf8" "201" "" "Y

es" "8"] ["utf8_czech_ci" "utf8" "202" "" "Yes" "8"] ["utf8_danish_ci" 
"utf8" "203" "" "Yes" "8"] ["utf8_l

ithuanian_ci" "utf8" "204" "" "Yes" "8"] ["utf8_slovak_ci" "utf8" 
"205" "" "Yes" "8"] ["utf8_spanish2_ci"
utf8

 "206" "" "Yes" "8"] ["utf8_roman_ci" "utf8" "207" "" "Yes" "8"] ["utf8_persian_ci" 
 "utf8" "208" ""
Yes

 "8"] ["utf8_esperanto_ci" "utf8" "209" "" "Yes" "8"] ["ucs2_general_ci" 
 "ucs2" "35" "Yes" "Yes" "1"]

 ["ucs2_bin" "ucs2" "90" "" "Yes" "1"] ["ucs2_unicode_ci" "ucs2" "128" 
 "" "Yes" "8"] ["ucs2_icelandic_ci"
ucs2

 "129" "" "Yes" "8"] ["ucs2_latvian_ci" "ucs2" "130" "" "Yes" "8"] 
 ["ucs2_romanian_ci" "ucs2" "131"


 "Yes" "8"] ["ucs2_slovenian_ci" "ucs2" "132" "" "Yes" "8"] ["ucs2_polish_ci" 
 "ucs2" "133" "" "Yes" "8"]

 ["ucs2_estonian_ci" "ucs2" "134" "" "Yes" "8"] ["ucs2_spanish_ci" 
 "ucs2" "135" "" "Yes" "8"] ["ucs2_swedi

sh_ci" "ucs2" "136" "" "Yes" "8"] ["ucs2_turkish_ci" "ucs2" "137" 
"" "Yes" "8"] ["ucs2_czech_ci" "ucs2" "1

38" "" "Yes" "8"] ["ucs2_danish_ci" "ucs2" "139" "" "Yes" "8"] ["ucs2_lithuanian_ci" 
"ucs2" "140" "" "Yes"

 "8"] ["ucs2_slovak_ci" "ucs2" "141" "" "Yes" "8"] ["ucs2_spanish2_ci" 
 "ucs2" "142" "" "Yes" "8"] ["ucs2_r

oman_ci" "ucs2" "143" "" "Yes" "8"] ["ucs2_persian_ci" "ucs2" "144" 
"" "Yes" "8"] ["ucs2_esperanto_ci" "uc

s2" "145" "" "Yes" "8"] ["cp866_general_ci" "cp866" "36" "Yes" "" 
"0"] ["cp866_bin" "cp866" "68" "" "" "0"

] ["keybcs2_general_ci" "keybcs2" "37" "Yes" "" "0"] ["keybcs2_bin" 
"keybcs2" "73" "" "" "0"] ["macce_gene

ral_ci" "macce" "38" "Yes" "" "0"] ["macce_bin" "macce" "43" "" "" 
"0"] ["macroman_general_ci" "macroman"
39

 "Yes" "" "0"] ["macroman_bin" "macroman" "53" "" "" "0"] ["cp852_general_ci" 
 "cp852" "40" "Yes" "" "0
] [

cp852_bin" "cp852" "81" "" "" "0"] ["latin7_estonian_cs" "latin7" 
"20" "" "" "0"] ["latin7_general_ci
 

latin7" "41" "Yes" "" "0"] ["latin7_general_cs" "latin7" "42" "" 
"" "0"] ["latin7_bin" "latin7" "79" ""

 "" "0"] ["cp1251_bulgarian_ci" "cp1251" "14" "" "" "0"] ["cp1251_ukrainian_ci" 
 "cp1251" "23" "" "" "0"] [
cp1251_bin

 "cp1251" "50" "" "" "0"] ["cp1251_general_ci" "cp1251" "51" "Yes" 
 "" "0"] ["cp1251_general_cs
 

cp1251" "52" "" "" "0"] ["cp1256_general_ci" "cp1256" "57" "Yes" 
"" "0"] ["cp1256_bin" "cp1256" "67" ""

 "" "0"] ["cp1257_lithuanian_ci" "cp1257" "29" "" "" "0"] ["cp1257_bin" 
 "cp1257" "58" "" "" "0"] ["cp1257_

general_ci" "cp1257" "59" "Yes" "" "0"] ["binary" "binary" "63" "Yes" 
"Yes" "1"] ["geostd8_general_ci" "ge

ostd8" "92" "Yes" "" "0"] ["geostd8_bin" "geostd8" "93" "" "" "0"] 
["cp932_japanese_ci" "cp932" "95" "Yes"

 "Yes" "1"] ["cp932_bin" "cp932" "96" "" "Yes" "1"] ["eucjpms_japanese_ci" 
 "eucjpms" "97" "Yes" "Yes" "1"]
 ["eucjpms_bin" "eucjpms" "98" "" "Yes" "1"]]

== [["big5_chinese_ci" "big5" "1" "Yes" "Yes" "1"] ["big5_bin" "big5" 
"84" "" "Yes" "1"] ["dec8_swedish_ci
 
dec8" "3" "Yes" "" "0"...

I'm working on a text to speech processor that could use MBROLA  
as  engine ASCII TEXT would be converted to PHO mbrola phonetic describtion 
file. Of course using rebol/view  1.3
 :)

REBOL is using a windows function for decimal to ascii conversion 
that wine implements incorrectly.

I use have used Unix without a gui  well  forever,   but unless gimp 
has an ascii rendering mode  (netpbm does) it may not be what you 
want .

Well, in Rebol/View 2.7.6.4.2, I can paste the multiply sign (copied 
from ascii-math.r) straight into the console and it shows correctly. 
In a field, however, it shows incorrectly, eg. if I try to paste 
it in the field:
	view layout [f: field]
I get two characters,  'Ã' and a dotted box, displayed instead.

The binary information is correct, it's just not rendered correctly, 
for if back in the console I do:
	probe f/text
then I get the multiply symbol displayed correctly again.

So it looks like View face/text rendering is expecting 8-bit ascii 
of some encoding.
Probably ISO/IEC_8859-1

re: ios, if you have non-ascii chars, it could be a problem.

Take a look at http://www.johnsons-web.com/cgi-bin/test.r.This is 
very bizarre! If you use netscape, you will see the entire usage 
message from rebol displayed prior to the mime-type header. If you 
use IE, it is likely that some but not all of these effects will 
be obfuscated, but you should be able

to see the entire output if you view the source. The sources from 
the script is being sent from a windows computer to a linux server. 
Now, if

I use a FTP client like WS_FTP which as a "ascii" mode, it automatically 
converts line enders to unix style, and this problem does not occur.

Janeks,  here are some things to try:

1. Make sure you uploaded the rebol exe as binary and the rebol script 
as ascii.

2. make sure you chmod your rebol files, rebol and even the cgi-bin 
(755).

Hope that helps. I have seen the same thing as you many times when 
I first set up rebol.

From Didier

	; decode ISO-8859-1 / ASCII-US encoded text

 decode-iso8859: func [str /local ascii non-ascii char text emit quoted-printable 
 encoded-word res b e] [
		emit: func [v][append res v]
		ascii: charset [#" " - #"^(7f)"]
		non-ascii: complement ascii
		text: exclude union ascii non-ascii charset ["="]
		char: exclude ascii charset ["?_=^-"]
		encoded-word: [
			"=?" ["ISO-8859-1" | "us-ascii"] [
				"?q?" some quoted-printable |
				"?b?" b: to "?" e: (emit to-string debase copy/part b e)
			] "?="
		]
		quoted-printable: [
			"_" (emit #" ") |
			b: some char e: (emit copy/part b e) |

   b: "=" (emit do rejoin [ {#"^^(} second b third b {)"} ]) 2 skip
		]

		res: make string! length? str

  parse/all str [any [encoded-word | "=" (emit #"=") | "^/ " | b: some 
  text e: (emit copy/part b e)] to end]
		res
	]

rebmail 4.10.11 & associated helptext has been released (18/06/2005) 
...

Changes Since 4.9.6
4.9.7   - Enhancement - Import emails" "Phil Bevan" 21/02/2005]

4.9.8   - Enhancement - Apply rules to a folder" "Phil Bevan" 30/05/2005]

4.9.9   - Bug Fix - Correct backdrop on getmail progress window" 
"Phil Bevan" 31/05/2005]

4.9.10  - Enhancement - decode ISO-8859-1 / ASCII-US encoded text" 
"Phil Bevan" 31/05/2005]

4.9.11  - Enhancement - allow Shift select to select multiple emails" 
"Phil Bevan" 01/06/2005]

4.9.12  - Bug Fix - Ensure download time is updated correcly" "Phil 
Bevan" 01/06/2005]
4.10.1  - Enhancement - Add options window
4.10.2  - Enhancement - Add rules maintenance
4.10.3  - Bug Fix - Remove Debugging info
4.10.4  - Bug Fix - Make Select Folder in Rules work
4.10.5  - Bug Fix - Apply send patch under View 1.3
4.10.6  - Bug Fix - Better Error trapping when applying fixes
4.10.7  - Bug Fix - Fix folder returned from unknown folder name

4.10.8  - Bug Fix - Do not try to copy email to itself when applying 
rules
4.10.9  - Enhancement - Add default inbox for incoming mail

4.10.10 - Bug Fix - Make Select Folder in Rules datila work for View 
1.2
4.10.11 - Bug Fix - Ensure preferences work on new install


rebmail.r can be found at .... http://www.upnaway.com/~philb/philip/pbmail/readmail.r

reabmail is also the following formats 

rip format at  .... http://www.upnaway.com/~philb/philip/pbmail/readmail.rip

zip format at  .... http://www.upnaway.com/~philb/philip/pbmail/readmail.zip


the archive containing rebmail.r & rebamail.html (rip = compressed 
self extracting rebol archive)
 
Any problems let me know.

Kru, as I understood on unix, filenames could contain any ascii characters 
0-255, but using characters such as "?" would confuse a lot of programs, 
so it was avoided. I don't know what the situation is these days.. 
Maybe they are more restrictive of allowed filenames.

Visit  http://www.TGD-Consulting.de/Download.htmland take a look 
at

the final release of Hex-It!. (I posted on behalf of Dirk Weyand, 
since he cannot reach AltME)


Hex-It! is a small but powerful hex-editor. You can use this tool 
to analyse
or alter the "fingerprints" for any kind of files.

Known first as a contribution to the REBOL Demo 2006 contest, the 
final
release with enhanced features is available now.
Features of Hex-It! v1.2.0:
---------------------------
* cross platform hex-editor

* free "save-feature" for small files sized lesser 15 KB, to edit 
larger
  files purchase a license-key that unlocks this limitation
* enhanced spot navigation with mouse scroll-wheel support
* non blocking file access 

* support of large files (a maximum chunk of 1MB file-data is only 
held in
  memory at once)
Some notes and useful tips & tricks on the usage of Hex-It!:
------------------------------------------------------------

- Modifications of files were automatically saved on exit, if you 
load

another file or if a different chunk of the same file is selected.
- Byte selection:

  + Select a byte with a left mouse button (LMB) click on the hexadecimal
    values to the left. The byte is highlighted then.

  + If a byte is selected, either use the cursor keys or the scroll-wheel 
  of
    the mouse to scroll through the bytes of the file.

  + Change a selected byte with plus (+) & minus (-) or just enter 
  its

    new value. Single characters, three digit numbers or single hexadecimal
    values are valid.

  + Use the right mouse button (RMB) to deselect a highlighted byte.
- Spot-navigation:

  + The spot specifies the index/position of a byte in the file. If 
  no byte

    is selected it shows the position of the top left byte displayed. 
  + Enter a number to set directly the spot to a byte-position.

  + Skip a certain amount of bytes relative to the current spot by 
  using

    plus (+) & minus (-), e.g. "+10000" skips 10000 bytes forward and
    "-1000" skips 1000 bytes backwards. 

  + Skip to end of file: Click with the RMB on the arrow-down Spot-button
    or use the "End"-Key.

  + Skip to first byte of file: Click with the RMB on the arrow-up
    Spot-button or use the "Home"-Key. 
- Seek:
  + ASCII- or Hex-Strings are valid queries.

  + LMB click on the "Seek"-button seeks from the current position.

  + RMB click on the "Seek"-button seeks from the beginning of the 
  file.

Please note, that the license of this release is not BSD like anymore.

Renote v0.9.2


Adds many little improvement, bug fixes, and you can now export the 
whole view into an ascii file.
Filtering is much improved (its interactive everywhere)

same download url

pics:
http://www.pointillistic.com/open-REBOL/moa/files/renote-1.png
http://www.pointillistic.com/open-REBOL/moa/files/renote-2.png
http://www.pointillistic.com/open-REBOL/moa/files/renote-3.png
http://www.pointillistic.com/open-REBOL/moa/files/renote-4.png
http://www.pointillistic.com/open-REBOL/moa/files/renote-5.png

I just finished adding complete Macro control to Renote (v0.9.3). 
 


basically, you can use any one-line REBOL script and assign it to 
keys f1-f9.   Nothing is prevented, so you have full access to the 
running script data.  a small level of sandboxing even allows you 
to safely assign values to words without risk of side-effects.


In a single line, I can thus save out an ascii version of the filtered 
view and call notepad on it... its so fast, it feels like notepad 
is a window of the app!

Use REBOL/Core and an ASCII interface then! ;)

I agree about the pictures. Too bad AltME uses variable length fonts, 
or I could do ASCII art. It's a good thing that denismx already told 
us that he is familiar with C++, so I don't have to explain what 
I mean by a pointer or a string here.

Look at the binary/ascii value of those chars; what are they?

Gregg -- I dont know how to reveal the binary/ascii values of the 
file, but the spanish y looks like it may be hex FF.  Do you have 
rebol code that can convert the characters into hex?

here's list from my system:

connecting to: www.jablunkovsko.cz
Net-log: [none ["220" "230"]]
Net-log: "220 (vsFTPd 1.2.1)"
Net-log: [["USER" port/user] "331"]
Net-log: "331 Please specify the password."
Net-log: [["PASS" port/pass] "230"]
Net-log: "230 Login successful."
Net-log: ["SYST" "*"]
Net-log: "215 UNIX Type: L8"
Net-log: ["PWD" "25"]
Net-log: {257 "/"}
Net-log: "Opening listen port 50061"
Net-log: [["PORT" port/locals/active-check] "200"]
Net-log: "200 PORT command successful. Consider using PASV."
Net-log: "Type: dir"
Net-log: ["TYPE A" "200"]
Net-log: "200 Switching to ASCII mode."
Net-log: ["LIST" ["150" "125"]]
Net-log: "150 Here comes the directory listing."
Net-log: "Closing listen port 50061"
Net-log: "Closing data port 193.85.151.2 50061 20"
Net-log: [none ["226" "250"]]
Net-log: "226 Directory send OK."
Net-log: "Caching cmd-port www.jablunkovsko.cz 50060 21"

I tried it here, here's where it starts to differ:

Net-log: ["TYPE A" "200"]
Net-log: "200 TYPE is now ASCII"
Net-log: ["LIST" ["150" "125"]]
Net-log: "150 Accepted data connection"
Net-log: "Closing data port 194.9.94.127 50078 56405"
Net-log: [none ["226" "250"]]
Net-log: "226-Options: -a -l "
Net-log: "226 11 matches total"
Net-log: "Caching cmd-port 194.9.94.127 50077 21"

apl/ apl101/ apl104/ apl105/ apl201/ apl202/ apl204/ apl206/ visaprom.com/

No.     Time        Source                Destination           Protocol 
Info

     90 2.750586    192.168.2.108         194.9.94.127          FTP   
        Request: TYPE I

     97 2.823074    194.9.94.127          192.168.2.108         FTP   
        Response: 200 TYPE is now 8-bit binary

     98 2.828500    192.168.2.108         194.9.94.127          FTP   
        Request: PASV

    113 3.171841    192.168.2.108         194.9.94.127          FTP  
        [TCP Retransmission] Request: PASV

    114 3.244193    194.9.94.127          192.168.2.108         TCP  
        [TCP Previous segment lost] ftp > mgemanagement [ACK] Seq=80 
    Ack=15 Win=16500 Len=0

    131 3.889034    194.9.94.127          192.168.2.108         FTP  
        [TCP Retransmission] Response: 227 Entering Passive Mode (194,9,94,127,250,69)

    137 3.984887    192.168.2.108         194.9.94.127          FTP  
        Request: STOR ik104test.zip

    149 4.247163    194.9.94.127          192.168.2.108         TCP  
        ftp > mgemanagement [ACK] Seq=80 Ack=35 Win=16500 Len=0

    210 7.046287    194.9.94.127          192.168.2.108         FTP  
        Response: 150 Accepted data connection

    241 7.218716    192.168.2.108         194.9.94.127          TCP  
        mgemanagement > ftp [ACK] Seq=35 Ack=110 Win=16269 Len=0

   1613 17.145048   194.9.94.127          192.168.2.108         FTP 
        Response: 226-File successfully transferred

   1617 17.172970   192.168.2.108         194.9.94.127          FTP 
        Request: SIZE ik104test.zip

   1620 17.277591   194.9.94.127          192.168.2.108         FTP 
        Response: 213 566605

   1623 17.375906   192.168.2.108         194.9.94.127          FTP 
        Request: TYPE A

   1628 17.498619   194.9.94.127          192.168.2.108         FTP 
        Response: 200 TYPE is now ASCII

   1629 17.516657   192.168.2.108         194.9.94.127          FTP 
        Request: PASV

   1633 17.644044   194.9.94.127          192.168.2.108         FTP 
        Response: 227 Entering Passive Mode (194,9,94,127,205,237)

   1637 17.750889   192.168.2.108         194.9.94.127          FTP 
        Request: LIST

   1643 17.835367   194.9.94.127          192.168.2.108         FTP 
        Response: 150 Accepted data connection

   1644 17.863490   194.9.94.127          192.168.2.108         FTP 
        Response: 226-Options: -a -l 

   1645 17.863548   192.168.2.108         194.9.94.127          TCP 
        mgemanagement > ftp [ACK] Seq=75 Ack=364 Win=16015 Len=0

Thanks Petr. He may have to wait for a supported UNICODE-enabled 
release.


Having given it a few moments thought, he may be able to fake it 
in *some* controls with font-name:

    view layout [box "hello" font-name "xxx"]  ;; where xxx is the name 
    of an installed font on his machine.

I tried that with my ASCII chart script, making that change. And 
it does (for me) show some Cyrillic. Not sure it's a complete solution 
though:
   http://www.rebol.org/view-script.r?script=ascii-chart.r

Thank you Pekr and Sunanda for your replies and suggestion on my 
question about unicode and cyrillic. I tried ascii-chart script and 
it unfortunately doesn't show any cyrillic letters :-(  I understand 
you, I have to wait until r3 is released, but I don't want to wait 
for it (as I can see from forum posts it could be not very soon).

Alexandr: < I tried ascii-chart script and it unfortunately doesn't 
show any cyrillic letters>
What I did that showed me some cyrillic was this:
** download the ascii-chart.r script from rebol.org
** change this line
     [append hex-lo [box 25x25 blue]
to
    [append hex-lo [box 25x25 blue font-name "WP CyrillicA"]
WP CyrillicA

 is a Cyrillic font I happen to have installed on my Windows PC. Any 
 Cyrilic font you have is likely to have a different name. When specifying 
 the font name it is case sensitive.


If this works for you. it may also help for many VID styles (BOX, 
BUTTON etc) It probably won't help for ALTER and other pop-up boxes

REBCODE is AMAZING ...


I am trying to convert a 300+ MB file from little-endian 16-bit Unicode 
to UTF-8. I am pretty sure that all the characters in this file are 
ASCII characters, so I can just discard the second byte (0x00) of 
every 16-bit Unicode character. Beside that, the beginning 2 bytes 
(0xFFFE) need to be discard too. 


In these two days, I wrote REBOL scripts for this purpose in different 
ways, and I suffered in different ways, too. Sometime I got out-of-memory 
error, sometimes I didn't. Even if I didn't get any error, the performance 
would definitely dramatically dropped down after few minutes because 
of the memory issue, I guess. I would take me 30 minutes to convert 
the file in my PC. I was trying to make it less than 10 minutes, 
so I kept asking stupid questions in the AtlME REBOL3 World.

 

Few ours ago, REBCODE came to my mind out of the blue. I remembered 
Carl said something like 10-30 faster. Because I am no REBOL expert, 
I'd never used REBCODE before. I took 1-2 hours to read the REBCODE 
document, then I do my very first REBCODE code in my life. Guess 
what? It turned out very well. The REBCODE version took only 45 seconds. 
It's AMAZING.

It's quite possible these days that it doesn't take ascii.

in Datamatrix definition is written capacity of max 2335 bytes per 
one symbol of size 144x144 pixels, with some inbuilt compression 
it can be 3116 ascii characters (readable chars are ess than 8bit 
encoded), scanner may read mutiple symbols at once. much more importand 
characteristics is using reed-solomon self repairing code to ensure 
readability up to 30% picture damage for each symbol.

ascii art

as for UTF8 - is it compatible to current +128 char extension? I 
mean e.g. czech alphabet uses special characters above 128 ASCII 
value ....

UTF-8 is a strict extention of ASCII, but ASCII is only defined between 
0 and 127. Characters 128+ are not ASCII, they are extensions, and 
their meaning depends on the codepage. The codepage of an 8-bit string 
is unknown, unless you specify it externally (or do a lot of statistical 
calculations). Strings or scripts with characters extended by a codepage 
will have to be translated by a codepage-to-utf-8 function or process 
specific to the particular codepage, ahead of time. Fortunately, 
such a process can be fast and even implemented in a byte-oriented 
language easily.

ASCII characters fit in one byte, the rest take some more. It can 
progress up to 5 bytes but those are rare.

I can understand how Pekr, Graham and many others feel about the 
lack of R3 releases especially given all the early announcements 
and the first public alpha. However, I really feel that Carl is still 
prototyopng R3, he is a long way from settling on the design of R3. 
There is too much missing for the current version to be considered 
an Alpha (e.g. No modules, no threads, ASCII GUI, Host environment 
& Runtime Core in a single executable,)


This is seems to be Carl's way of working and something that he has 
to work through step by step.

I would not trust non-ascii characters for now. With any luck the 
server saves the messages as binary UTF-8, don't know yet.

Not trusting non-ascii characters infers  that the current desing 
of  RebDev is "ignorant"of character encoding. If that is the case, 
it is a shame as RebDev could have been a great example of an "up-to-date" 
application built with R3.

If you look in postscript.r, I encode the image data in line 211-220. 
It's just normal hex written as ASCII, so you get '0'-'9' + 'A'-'F'.

Looks like Cheyenne is trying to create a new form of ASCII art :-). 
First time I see that on Cheyenne. Will reset the server at once.