World: r3wp

primitives will have the possibility to setup run-time manipulators, 
which modify the internal primitive data on their own.  


this means you might not even notice that there is a frame jump in 
setup because the manipulators are still active, using the old data.... 

ex:  

'PRIMITIVE-A  has a targeting manipulator which keeps this model 
always aiming another model, 

'PRIMITIVE-B has a manipulator using a constant speed which ends 
up moving it in space.


now picture a situation where the scene update where taking longer 
than the sleeping time (or it just started at the wrong moment and 
occurs just before rendering starts).

if the main thread where responsible for triggering the refresh, 
you would see a noticeable lag. 


 but with this setup,  both primitives  would still continue to move, 
 while the speed is adjusted... when all the setup is done, the renderer 
 knows it can update and it then adjusts its internal data to reflect 
 the high-level changes made by the main thread.


the manipulators are C functions, so they will be very fast.  (there 
will be a special REBOL callback mode for testing, but it will be 
much slower)

now because both threads can work independently, we can do much more 
processing in the main thread and simplify the rendering so that 
manipulators just "use" data and process as little as possible, allowing 
for much higher scene density.  :-)

( and CPU fan noise  ;-)

Added a few recommendations in the host-lib section of R3 chat.... 
please add comments there, if you have any... 

just saying you agree is good as it shows Carl that the ideas are 
shared by several of us.

Added a few recommendations in the host-lib section of R3 chat.... 
please add comments there, if you have any... 

just saying you agree is good as it shows Carl that the ideas are 
shared by several of us.

and by the way, all the suggested macros are actually being used 
in real code, so they work.

I have published 'unofficial' proposal with improvements to the current 
RichText dialect in R3. If anyone is interested in this topic you 
can read the proposal here: http://www.rebol.cz/~cyphre/docs/rich-text.html
Any feedback is appreciated.

not found

Cyphre - what about using direct rebol.cz plus subfolder - you've 
got access to it. ClearOS is crappy in that regard - I sent bug report 
to them, with no result at all ...

everyone - hit reload several times, then you will get the document 
....

where should we discsuss it, here?

What does it mean?:

- Embedded GOB containers in text
- Gob - Renders GOB embedded in text


I can't imagine, how this stuff works, and is organised. However 
- i am buying a book on text typography and layout, but so far from 
what I have read, you basically divide page into columns or boxes 
section, you can link them, those columns/rows have those typical 
margins, origings, etc. set, but we are talking DTP tools here :-) 
Are we getting something similar here?:


It is possible to have multiple paragraphs defined in one Rich Text 
block. Paragraphs are positioned one ofter another vertically. Vertical 
space between pargraphs is defined by PARA/INDENT/Y values. Use COLUMNS 
command(see below) to define how many paragraph columns should be 
used for paragraph layout.


... some wireframe model showing the terms on the image would be 
usefull ... but maybe others will understand, what's your idea ...

Pekr, sorry, I forgot to upload the paragraph layout example image. 
Just reload the page it should be there.

Embedded GOB containers in text: that means you will be able to insert 
gob! objects inside the text flow

The document has been moved to http://www.rebol.cz/docs/rich-text.html

Just a detail... first paragraph should not be indented. The indent 
should be used only between paragraphs.

yes, the para/indent values depend on you so you can set it as you 
need..or am I missing something?

indent is not typically used as a term to mean spacing between columns 
- is the dialect already set?

the inter column space is called alley, usually

nothing is set in stone so if you know better wording I'm open to 
changes...

Maybe it would be good to see and example how the multiple paragraph 
text is supposed to be specified.

Btw.. the columns support is interesting, but will it be possible 
to select text from multiple columns?

And is it normal that glyph-metrix returns pairs for advance and 
kerning?

yes, text selection should work in multi-paragraph layout

pairs for advance and kerning: yes, that should be possible as someone 
may need to layuout text vertically. Not sure in how many cases/fonts 
the vertical values are used but they are supported by the system.

What about right-to-left direction?

AdrianS, according to the diagrams it looks like origin is doubling 
as the alley, not indent.

The vertical portion of the indent is the intracolumn spacing between 
paragraphs, not the intercolumn spacing between columns.

is the vertical spacing in para/space just for specifying glyph spacing 
when using vertical writing or does it also specify the line spacing 
when using horizontal text?

Brian - what does intra-column mean when talking about the setting 
for just one paragraph?

can't each paragraph have it's own settings?

multi para example:
[
	columns 2
	origin 20x20
	margin 20x20
	para p1
	text "abcd..."
	para p2
	text "efgh..."
]

all the spacing, indentation will be defined in the p1 and p2 objects 
(see the doc for all possible fields)

well, the margin shouldn't be probably relative to the gob/size but 
rather absolute pair position  so it is possible to define paragraphs 
that can be scrolled.

( so in this example it could be: margin (gob/size - 20) )

It would be good to have per paragraph margin imho.

So you could indent complete paragraph.

how it would work in the multi-column mode?

I'm not sure if I understand what do you mean by absolute margin 
position, but sounds to be quite difficult to work with it.

margin only inside the size of the column of course.

In most cases there will be one columns only texts and complete paragraph 
indentation is used very often. At least in web pages.

one thing which is sorely missing in the general GUI concepts of 
text is flowing text from boxes to boxes.
  

multi-columns are an example of a simple floating text box implementation... 
maybe you could go all the way and add support for arbitrary text 
boxes which flow with content from "previous" boxes when text reaches 
the end of the previous box?

in HTML is not only margin, but also padding.

Maxim, you are asking for InDesign made in REBOL? ;)

problems is that if you model some of this on CSS in terms of spacing, 
insets, etc, you lack the higher level stuff like columns, flows 
between areas (like Petr and Max are saying)

problem is...

Oldes, imagine you have gob of 200x300 size but you want to have 
layout of two paras in total size of 400x600. In such case you'll 
set MARGIN 400x600 to ensure the paragraph layout is filled inside 
this space. And then you can use SCROLL to move the content inside 
the gob.

its actualy not that complicated... in the sense that you must only 
know the coords of the boxes (something like sub gobs) and then when 
the text reaches the lower right corner of a box, a decision is made... 
either the box can stretch a little or you jump to a new box to render 
into.


implementing columns thus becomes a specific case of a generalized 
solution.  just provide two sub gobs and texts flows from one to 
the other.


note that the text boxes are independent from paragraph... these 
boxes are the actual "page" area which the rtf uses to calculate 
bounds and word-wrapping and offsets and such.

(I was replying to AdrianS)

Maxim, I talked about the floating toext to multiple gobs with Henrik. 
I think we could add feature that will tell you at what position 
the text reached the lower right corner of gob and then you could 
pass the rest to any other gob using REBOL code. It is imo better 
to not make this system at the low-level as it can get easily complex.

Only square embedded gobs? No curve-around-image? Just asking...