World: r3wp

what about storing differences instead of absolute coordinates?

I don't that is even needed.

since all values are within one byte.

it could probably be done, but it's not worth it without slowing 
it down a lot. I wonder how coords are stored in fonts normally.

that depends how much ram he is using... at some point the GC slows 
down soooo much that speed exponentially decreases.

I wasn't following how the data block is generated. was that with 
a C# program?

Anton, the shape dialect was generated by my REBOL script. So it's 
not easy to optimize it. I wrote a C# program, which get all the 
glyph data of Chinese characters. I put these data in this format 
: x y type x y type ... where type is the type of the point. My REBOL 
script loads the glyph data, and generates a Shape dialect for every 
character.

Chinese! :-) Cool! To better see the character, you can make it larger 
with this:

view layout [
	box 4 * 128x128 black effect [draw [
	scale 4.0 4.0
	anti-alias on
... followed by the rest of Jerry's program.

is it possible to use any drawing this way and not only kanji/chinese 
chars?

Someone should train a neural network to make calligraphy, then the 
chinese chars could maybe be made with less information.

eeek  I'm affraid of the amount of neurons needed for such an endeavour 
especially since it would need one output for each pixel...   :-)

probably after a few years of training... it would be able to actually 
draw something ;-)

I'm always thinking in generalization, creating an easy way to import 
vector drawings in rebol.

Henrik, if info about points or whatever the drawing is made of is 
available, then I see no problem. (If I understand you correctly.)

Clipart is a good example.

What data format is used for clipart? An importer to DRAW dialect 
shouldn't be too big a problem, if the format is easily read.

yes! I've always wanted to see all that kitchy clipart available 
to Windows users since Windows 3.1...

There is probably a lot stored in SVG (Scalable Vector Graphics) 
format. There's been talk about that format around here, I think.

would be nice to integrate this into postscript.r (wink wink) :-)

yeah! :-)

here is a draw glyph compressor  :-)

rule: [
	any[
		[copy val pair! (
			val: first val
			bignum: max bignum max val/x val/y
			append bin to-binary to-char val/x
			append bin to-binary to-char val/y
		)] |

  [copy val word! (append bin select [curve #{81} line #{82} move #{83}] 
  val )]
	]
]

the above glyph takes up 2223 bytes

oops... forgot to remove bignum check...

rule: [
	any[
		[copy val pair! (
			val: first val
			append bin to-binary to-char val/x
			append bin to-binary to-char val/y
		)] |

  [copy val word! (append bin select [curve #{81} line #{82} move #{83}] 
  val )]
	]
]

to use it:

bin: copy #{}
parse draw-shape-block rule

W3C link to this from their SVG page: http://openclipart.org/cchost/

so there's a lot of clipart in SVG format, I guess. SVG uses XML, 
so it should be easy to import using my RebXML packet. Problem is 
to figure out content  of the format.

Hmm, it seems to be a large format, so it's not a week-end project: 
http://www.w3.org/TR/SVG11/

isn't shadwolf working on something?

doesn't Cyphre already have an AGG SVG viewer

how is the tiger demo done?

There is a "SVG RENDERER" group here.

my god profiling stuff in REBOL in quite rewarding!

my latest shape compressor is now 2.5 times faster, by using a list! 
instead of a binary while accumulating values, and then converting 
it to binary!

Can you try a hash!?

there is no point... since I'm never accessing it... list! is the 
fastest insert series in REBOL

ok. Do you preallocate space for all the entries beforehand? So it 
doesn't have to expand along the way.

and since I'm only converting it to binary at the end, a lot of GC 
processing is alleviated.

oh, and 1000 of the above glyphs now takes 4.5 seconds to compress... 
imagine if we had rebcode !

lst: make list! 5000

rule: [
	any[
		[copy val pair! (
			insert lst val/1/x
			insert lst val/1/y
		)] |

  [copy val word! (insert  lst select [curve 130 line 131 move 132] 
  val )]
	]
]
parse draw-shape rule
bin: to-binary head lst
clear head lst

lst: head lst  ; a small quirk in list! datatype... it MUST be reset 
to head after a clear.

and 1000 glyphs takes 8.95 MB of RAM which is quite optimal IMHO 
   :-)

How does that compare with:

	glyph: compress mold draw-blk
	load decompress glyph

didn't try, I was having fun with parsing  ;-)

using compress is 2 times faster but takes up 20% more ram

(in compression)

but there is no comparison in decompression... using decompress  
is 4 times faster so far.. I could probably squeze a bit more more 
out of parse... but not much.

Maxim, it's not "tsai", it's "yung". The meaning is some kind of 
traditional chinese musical instruments. http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=93DE

Henrik, it is possible to draw all the characters this way, not just 
Chinese characters. I am designing my own Text-Rendering System this 
way.

To condense the font data, there is a better way. Almost every Chinese 
character consists of many parts. if reusing the parts, a Chinese 
TTF file can be condensed from 4 MB to 100 KB. However, doing that 
would need lots of analysis of Chinese characters. That's would not 
be easy. Also needed is a part-combining engine.

For example, the left part of the "yung" Chinese character is "jin", 
meaning "gold" or "metal". The left part of any  metal-related character 
is exactually the same as the left part of "yung". There are hundreds 
of such characters. And "metal" is just an example, we also have 
"water", "fire", "soil", "bird", "dog", "hand", "human", "tree" ... 
this list goes on and one.

Presumably that is how it is done.  Divide into radicals, and further 
divide radicals into elemental strokes.