World: r3wp

The above update also cleans up loose words in the auto-crop-bitmap-text.r 
file.

I added a /pad option to mine so that it returns the text with a 
white space border.

which is needed for some ocr engines

/border
 makes more sense, doesn't it ?

maybe not...

updated 
	auto-crop-bitmap-text.r
removed old code and comments (file is 3.5k smaller)

updated again
	auto-crop-bitmap-text.r
replaced old comments with new ones.

Hmm.. I think the image padding might be outside the responsibility 
of an auto-crop function. Its job is to remove stuff, not add. It's 
probably better to write a small generalised function to do the padding 
(which could be useful elsewhere) and just feed the result of the 
auto-crop to it.

you're probably right

though it could be auto-crop to  as it were.

I think if you're going to make an "all-in-one" function, then its 
name should reflect that. eg. 
	crop-and-pad-ready-for-ocr: func [image][
		pad-image auto-crop-bitmap-text image 1x1
	]

(where pad-image is adding a 1x1 white border around the cropped 
image.)

auto-crop-bitmap-text: func ["Returns a cropped image, or none if 
the input image was blank"
	image [image!] 
	/local region
][
	if region: find-bitmap-text-crop-region image [ 

  copy/part skip image region/1 region/2  ; return a cropped image
	]
]

Looking at this, it appears to return unset! if region is none!

How about this 

	

auto-crop-bitmap-text: func ["Returns a cropped image, or none if 
the input image was blank"
	image [image!] 
	/local region
][
	all [
	 	region: find-bitmap-text-crop-region image  
		region: copy/part skip image region/1 region/2 
	]
	region
]

IF returns none when given false.

And your code redefines the meaning of 'region (which by itself is 
bad because it can cause confusion later) unnecessarily.
I could rewrite it more simply:
	all [
		region: find-bitmap-text-crop-region image
		copy/part skip image region/1 region/2
	]
but that's just equivalent to my IF above.

Ah ... ok.

I think it would be nice now to have the crop work on the sides as 
well.

Would it be hard to write a deskewing function?  basically I guess 
one finds a best fit horizontal line for the base of the text one 
finds, and then returns the angle needed to deskew it.

Is it really skew or do you mean rotate ?

It's normally called skew but it's the same.

To crop the right and left edges I think we can just rotate the image 
90 deg, crop it with the existing routines and then rotate it back 
again

Smart...

I was going to say that modifying the code to support horizontal 
cropping should be pretty easy. But that method is even easier !

(if a bit hackish.)

Seems to work ... but I have to rotate 270 deg and not -90 to get 
the original orientation back.  Does effect not take a negative rotation?

Seems to only do 0, 90, 180 and 270:
http://www.rebol.com/docs/view-system.html#section-9.5

Ahh.. that's no fun.  So, I can't use this to deskew.

Do you know, how to use DRAW to do image transformations?

nope

I usually learn enough about view to do something I need and then 
promptly forget it :(

You can rotate an image in DRAW like this:


view layout [box effect [draw [translate 40x0 rotate 60 image logo.gif]]]

that's how I'm doing the rotation now.

uhmm.. maybe not.

I'll try that out :)

( yes,  effect [draw [rotate]]  is different than  effect [rotate] 
)

Here's small challenge. I created following script which is surely 
full of junk. I am not good View coder :-) Now who helps me to simplify 
it and to get the movement smoother? :-)

screen-size: system/view/screen-face/size
news-bottom-offset: 0x100
news-height: 0x100

message: "This is short news scroller. Who makes me smooth? ..."

;--- style for draw dialect
bold64: make face/font [style: 'bold size: 64 color: white]


;--- But how to calculate text size for draw? Here's a workaround 
...
txt: make face compose [size: 2000X200 text: (message)]
txt/font: make face/font [style: 'bold size: 64 color: white]
text-size: size-text txt


view/offset/options layout/size [
  backcolor green

  ;--- we start behind the screen ....
  at (to-pair reduce [screen-size/x 10])

  t: box (to-pair reduce [2000 news-height/y]) ;--- box size ...
       effect compose/deep [
         draw [
           font bold64
           text (message)
         ]
        ] 
       rate 50
       feel [
         engage: func [f a e][
           if a = 'time [
             ;--- zde nastavujeme rychlost posuvu
             f/offset: f/offset - 3x0

             if (f/offset/x + (first text-size)) < 0 [f/offset/x: screen-size/x]
             show f  
         ]
        ]
      ]

] (to-pair reduce [screen-size/x news-height/y])(to-pair reduce [0 
(screen-size/y - news-bottom-offset/y - news-height/y)])[no-border 
no-title]

I don't think you can make it 100% smooth without knowing when the 
screen refreshes.

You have two faces (which you might need long term), but you could 
probably achieve the same text scrolling effect with just one face 
by modifying its para/offset.

No, you can't :) Of course, the window/text goes to the title-bar.

(so to get text in a window you always need at least one subface.)

Yes, you can :) but it's using Draw dialect text.

view/new window: make face [
	size: 800x150
	font: make face/font [size: 40]

 effect: compose/deep [draw [font (font) text 100x50 "Hello there"]]
	rate: 50
]
window/feel: make window/feel [
	engage: func [face action event][
		if action = 'time [
			window/effect/draw/text/x: window/effect/draw/text/x - 1
			show window
		]
	]
]
do-events
i

Anyway, it doesn't fix the basic problem.

Is it possible that 'jitter' that occures in Pekrs nice example sharing 
the same root cause as the 'heart-beat' that Geomol mentioned in 
a previous post?

not sure. HeartBeat might be TCP related. On my Core 2 duo I am not 
observing jitter, just not smooth animation. Now remember that Amiga 
with 7MHz CPU was able to provide us with absolutly smooth scrolling. 
But Win32API lacks vertical blanking period synchronisation, so I 
wonder if without DirectX or OpenGL we are able to actually make 
our situation better ...

Some time ago Carl told us, that View uses double buffering, but 
apparently it is not enough ....

Is there a way to have a face receive mouse input that is recieved 
via layouts in the faces pane?  This sounds weird, but when building 
components, if there is a generic face object that they all share, 
then on top of that face you add a layout with certain styles.  Is 
there a way(without adding a handler in the layout) to have the face 
receive the message as well?

Have you tried DETECT? http://www.rebol.com/how-to/feel.html#sect6.

I rarely use detect, but use insert-event-func quite often.

That might be what I need.  Messing with it seemed to overwrite some 
other handlers.  Suppose you have this:  my-face: make face [
			offset: offs
			size: sz
			color: 0.0.0

   text: win-title ;rejoin[window-counter ":" name] ;should this be 
   copy name?
			plugid: plug-id
			id: window-counter
			pane: copy []]