World: r3wp

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.

Currently, i do this, but...

no-chars: make bitset! 256
foreach c "^/^-" [append no-chars c]
no-chars: complement no-chars

geez...
drop and off don't work in rich-text

known bug

Fuck !

sorry

:-) I'm not sure if there is a workaround.

Generally we'll have to talk to Cyphre one day. His bug list is getting 
quite large.

workaround...

bye bye my rich-text engine

another one project fail, my speciality....

Drop and Off?  What are you talking about?

used to discard previous commands in rich-text blocks (like bold, 
underline, italic)

Ah...  I'm sure they'll fix that eventually...

eventually, mwahahahaha

I'm building my rich text editor on the gob/face level so that won't 
be bothering me. Getting this parser right is proving to be tricky 
though!

eh ? i don't understand why you are not impacted...

when i talk about rich-text, i mean gob/text, so you are impacted

me too, i create my own gobs

i don't use those Carl's style

I'm not impacted because each style change creates a separate face.

I'm not using Draw directly.

and ? 
How do you handle imbricated styles in the same line of text ?
Like:

 gob/text: [ bold "this is bold" italic "this is it talic and bold" 
 off "this is bold" ]

Especially if the line is wrapped

don'

Hehe, I'm not writing that kind of Rich Text editor...  It's really 
just a syntax highlighter so all of the formatting is implicit.

if you construct linked gobs for the same line of text (one gob = 
one style), i say good luck to manage wrapped lines.

hum ok, it's more simple

you just change colors

Managing wrapped lines isn't a concern at the moment.   What I will 
be able to do with the structure I've chosen far outweighs the extra 
cost dealing with wrapped lines if I ever decide to add that functionality.

No, not just colors.  You have full font control, bold, italic, etc

i'm fucked, my current development is about editing makedoc documents, 
i can't bypass this request

i need wrapped paragraphs

rich-text at gob level must work

yeah, for what you are doing Drop and Off definitely have to work!

posted question to rebdev, how far are we with March dev plan, in 
order to sync sources with Cyphre once again and let him fix few 
things.

Steeve, I think one gob per character may operate fast enough, if 
it's a modern machine. But then you have to do your own paragraph 
flowing etc.

argh, i was hoping you will not notice this

one gob per line is my aim

one gob per char, i don't ever try it. It will be slow and memory 
consumming

That's how I did my editor replacement in R2. But then I started 
wondering how to do my own flowing and I decided multiple gobs per 
line is the way to go. Needs some clever way of indexing lines and 
caching gobs so small near-constant number of gobs are produced and 
reused per window of text.

Sorry, I didn't mean per char, but per font / formatting change.

i can manage multiple gobs per line (depending of the grammar) but 
i don't want to use a gob per char, what a pain in ass when the text 
is scrolled or modified ...