World: r3wp

I just wanted to mention that when I run the gui demo and click the 
"text view" test it causes an error on my vista machine.

Yup, Paul, that's a known bug.

Someone, BrianH I think, posted a link to this group (I think) to 
a document on DocBase that talks about the performance differences 
with some of the loop functions in R3.  I can't seem to find it though. 
 This is why MediaWiki bothers me.  It search sucks.

I would like to see such a document as well. I know that the loop 
functions in R3 are faster since they are all native, but I don't 
know how much faster. Clearly if I was the one who posted it I forgot 
where it was too :(

Paul, yes, this is due to one text area trying to load the source 
code for the original version of the demo, which doesn't exist anymore. 
However it throws a different bug than it should, so it's lucky that 
it came up.

Ammon, BrianH, it's search sucks: Which is why such a document should 
be a cookbook recipe. Easier to find.

anyone has tested size-text on a gob ?

is there a problem?

i get  a wrong size/x

example?

wait a minute...

I've not noticed anything yet, but there could be problems with certain 
fonts, multiple lines or shadows.

in fact there is a rich text bug that causes a size to be calculated 
incorrectly by a couple of pixels in a very specific condition.

i get the bug with the standard font too.

try this:
gob: make gob! [offset: 50x50 text: ["test"]]
gob/size: size-text gob
view gob

here "test" is truncated

y is incorrect too, missing some pixels (tested with text: ["gggjj"]

yes, I think that's a bug.

another one bug, if the size of the gob is previously set to 0x0, 
size-text is entering in an eternal loop.
gob: make gob! [size: 0x0 text: ["test"]]
size-text gob

i wonder how th

i wonder how the VID can work currently

size-text is used by some styles

Actually, not.

In VID, Size-text is only used to change the y coordinate of a gob, 
which means the bug has never been traced.

yes, I've not noticed the problem before. Now that I look at it, 
it seems to be constantly about 2 chars too narrow and a tad too 
short in height.

actually less than 2 chars.

That  sounds like a very high priority bug to me.

I agree

probably something Cyphre needs to fix.

Could you post the 2 bugs ?

Yes, however I think they need to be more exact. It looks like it 
could be related to the old rich text bug I saw a long time ago.

because of that i can't progress in my rich-text editor ;-)

exact = test with different font sizes and string lengths to see 
if the error is constant.

the error is constant, i tried several font and several para

http://curecode.org/rebol3/ticket.rsp?id=345&cursor=3

The original report.

OTOH it may not be related.

ok, thanks. I'll write up the report.

thanks

btw. are there any margins to adjust? could it be that?

i don't think so, the margin and origin are too low to explain the 
gap

i tried with a margin of 2x2 and an origin of 2x2, but what is missing 
is 30-50 pixels

then the error is not constant. I experienced an error of about 2-4 
pixels here.

try with a big font

hmmmm.... seems you're right. By removing origin and margin, i got 
the correct size.
Arghhhh, it was not a bug actually

Forget the bug Henrik, thanks for your help.

A good evolution would have size-text taking in account origin and 
margin

no problem and yes, that could be a good idea.

Heh, Steeve.  You are working on a rich text editor too, huh? 


Are you using a single face, gob and draw, faces and gobs, just gobs 
or something entirely different?

1/ I mix several gobs of all types (effect draw text color). Basicaly, 
drawings can be mixed with texts.

2/ only gobs which are modified are reconstructed, it should be fast 
to insert modify text.

3/ The structure of gobs is build using an external  grammar (with 
parse), depending of the source file type. The parser convert the 
source text into a DOM structure,  which is converted into a gobs 
structure further usings a style grammar (external too).

4/ It will be a verstatil richtext editor. By changing of external 
grammars (basically a set of parse rules), we change the rendering.

5/ The grammar for a specific markup langage will be tiny. Currently, 
the grammar of makedoc2 is less than 2 Kb.

6/ In theory, easy conversion between different makup language could 
be done by the engine (makedoc <-> postscript <-> pdf ...)

7/ After makedoc2 rules will be ok, I'll build a grammar for rebol 
sources of course.

Sounds like a pretty awesome engine.  Can't wait to play with it. 
=D

Is there a way to complement bitsets in R3 ?
I liked the NOT proposal in parse, but it's not done yet.

Theoretically you could build a complement set in R2 and just copy 
the bitset to your R3 script but I think that will cause you some 
problems with unicode, which, as I understand it, is why complement 
has been removed in R3.