AltME groups: search

i'm lost  i haven't being following here closely but why VID is externalised 
? well it always was and optional thing ... the main thing being 
rebol/core... so this tendency is made more clear. Will this allow 
 people to access the graphical side extension and modifies it independently 
of  rebol/core (the host ?). Are they other side package planned 
?

is it possible to know who work on what in the GUI topic and have 
a slight idea of the steps done and the steps to be done ....

ok so then does ritch text is a really something to be set as default 
inside the VID extension or isn't it wiser to let that as a side 
project to make research about the perfect way it could be done... 
and we let in draw a set of basic commands related to draw (a revamped 
set ofcourse) for instance I think that a ritch text engine is too 
much for the syntaxe colored editor we made ... it's like taking 
a nuke bomb to kill a single little fly .... but such an engine by 
default can anyway open new perspectives. but what annoys me in the 
process is to do this  raw script -> conversion to ritch text dialect 
-> conversion to draw by the rich text engine ...  instead of doing 
this raw script text from file.r -> conversion to draw using parse. 
But maybe i'm wrong ... anyway one way or another i will do a port 
of area-tc. and i assume that if the rich text engine seems too much 
for me then i could still do my proper engine relying on the draw 
for text lower level instructions.... (not to mention i like the 
idea of learning parse through  experiements)

and if the rich text engine doesn't handle clickable link display 
how can we add that to the rendering engine ? for example during 
a moment Steeve planed to add to area-tc the hability to render url 
in the rebol header block in a special way  in order to have them 
click and open the navigator with tthe url you clicked over. in an 
open engine like area-tc adding this isn't difficult  but adding 
this to a black box called rich text rendering engine seems to me 
to be harder... but i'm certainly wrong ...

with rich text come a lot of  troubles like handling paragraphs resizing 
things etc... how and where images are inserted withing the text 
paragraphs etc ... Can at some point the image inserted within text 
can be a draw set instruction rendering (for graphics or SVG image 
rendering ) etc... how will that engine grow ?

if it's just a cheap intent to mimic rich text that will make people 
laugh but if it's a  main concern and a constant work then it can 
become something really awsome.

I don't think it will be a black box.. richtext will be part of host 
kit, I think. And tight integration of text rendering with richtext 
engine is good imho.

i'm not commenting what will be  done ofcourse i didn't see it.


But i already looked at the richtext engine carl proposed 2 years 
ago and that's far to be good.... 

In fact richtext engine is supposed to be dialect layer on top of 
draw. 

That dialect layer is adapted normally to handle text rendering the 
proper way which implies that the lower level text functionnalities 

in draw for text related effects is better done than previously. 
That's all i say ...


Building a layer richtext what ever it is if the AGG /draw dialect 
exploit poorly the text related effects that will be a pain and a 
very small benefit...

and more complexity you will add to your engine more unexpected problems 
you will face...


 Like what we experienced in area-tc... suddently our perffectly working 
 engine under wnidows XP shows strong bugs in rendering just by arriving 
 on windows7. After 6 month in searching the why  and not finding 
 any cause to that rendering jam I by chance tryed the ultimate thing 
 no programer does i retro versionned back like 10  version below 
 the rendering engine and there suddently i found that rendering problems 
 disapeared by miracle...


I spend 10 times more time searching why the rendering was defective 
on windows 7 than doing area-tc and viva-rebol.r.  And that's too 
what  completly killed my mood. What else can i do than try to make 
this community know my experience with extensive text processing 
in draw with R2 to not have the same conceptual lacks repeated in 
R3.


And clearly  in R2 the text commands in AGG/draw were not suited 
for docuement rendering... That  doesn't means AGG can't do it ... 
that means at that time the dialect draw wasn't designed to exploit 
 intensivly text rendering. I always said before runnning you have 
to learn to crawl, then to stand up, then to walk. for me the way 
i  saw the realisation of a rendering engine text oriented for draw 
dialect was first step changing the color of  choosen elements in 
the text, then changing the font spécificity anytime anywhere in 
the document then being able to do strong text manipulations like 
moving by drag and drop paragraphs, inserting multimedia content 
in the document, scaling paragraphs etc... 

ROBERT: 

In fact that depends what  the rich text engine aims ... for example 
read only rendering is pretty different of  real time editing wisiwyg 
engine... The complexity betwin both approach is like 1 to 100...

I just hat a short chat with Cyphre about this. And on Windows & 
Linux the glyph outlines are used to render the fonts.

but once again R2  AGG/draw text  wasn't desinged to handle this 
... we used fixed fonts because we had no other why to obtain the 
x and y size of each displayed glyph so in other word that a lack 
of a basic lower level function.

We are aware of most of the text rendering issues and IMO it makes 
sense that we try to get a release out of the door ASAP so you can 
all take a look and give feedback.

and ofcourse fied fonts where properly handle only on widows ... 
 fun thing was i tryed rendering using the same TTF file on linux 
but it was managed as unfixed font on linux ...

so see assuming fixed fonts is a global concept is a wrong thing 
it better to say ok font will be not fixed lets handle this properly 
and offer a way to manage them the easier way...

we needed to know the size of the letters displayed on screen because 
first of all in R2 when you call 2 times a text instruction the rendering 
at piled up at same place and not disposed one after another on the 
X axis with natural spacing... so draw [ text 10X10 "a" text "b"] 
renders a "b" over the "A" and not "A" followed by "B". And it's 
logical ... text instruct was then designed to handle a serie a letter 
or several series of letter organised in distinct block we can call 
words... but you see that concept doesn't fit with the need of having 
an interaction anytime with any letter componing the words.

and in the richtext proposition of Carl made 2 years ago (times flyes..) 
we find again this block concept wich is related to the way MakeDoc 
format handle things ...  like in HTML  for example you have flags 
that defines a rendering style. But the things betwin the flags can't 
evolve... they are not supposed to change font style or font size 
or font color. See that's what i would call a we treat text as block 
and not as single element able to singularly evolve on their own 
without affecting the surrounding elements.

ofcourse you still can say a <H1> </H1> instead of the basic regular 
seting will take this font this color this size but that will affect 
all it's content and not only a part of it ...

and then if you want to have an atomical approach then MakeDoc dialect 
becomes too verbous to be efficient... like in HTML more you want 
stylised things more you pile up flags and more you have problems 
debuging and having a direct acces to your raw document content... 
So it's clear that a real design have to be set for this richtext 
even if in the end rendering html or MAkeDoc or makeDocPro  with 
that dialect means a conversion stage.

that's why the proposition of carl to have an open flag system was 
cool ... he presented it years ago as a variable inside draw dialect 
to hold styles ... And i think people didn't see the good points 
in this approach ...

The idea is that we will have the low-level font rendering stuff 
accessible. Further a standard richt-text dialect will exist. If 
htis doesn't fit, you can change it and use any other concept to 
make richt-text available in apps.

And be sure I appreciate your efforts to terminate the job.

Steeve is shorter than me and but ruder than me :)  ... Steeve ....

but steeve have a point ...  it's ugly ... i don't know if that the 
antigrain thing but on the lower size fonts damn the rendering of 
the font is messed up ... you have on the same letter bigger and 
smaller parts... This was a problem we experienced on R2 too we noticed 
it. People said don't worry R3 is completly deferent etc... and in 
the result -> blured ugly fonts... like on R2  so wher is the gain 
?

when it gets important enough to fix. right now the priority is to 
get things working in the first place. we have an app to build and 
sell.

shadwolf: if font rendering quality(or whatever else)  is so critical 
for you I think with R3 you have couple of options now:


1) wait until you get it for free (some day) while bitching at AltME 
about it
2) download the HostKit and improve the code yourself

3) pay(or overpersuade or whatever) someone else to improve the HostKit 
for your needs


So it looks you have at least 2 more ways(besides the 1. point) how 
to solve it comparing to R2 situation. Isn't that great?

shadwolf: Take option 2 and send us the code, we will integrate is 
ASAP.

people often mistake rasterizing and outline generating process. 
  there can be bugs in both steps which affect output.

there can also be some side-effects between the outline generator 
and expected rasterizing process.

MS for example, dosesn't properly typeset its font.  The historical 
reason being that their fonts are very sharp and readle on low dpi 
monitors.


If that is a problem of the outline generation, the rasterizing or 
both is up for grabs but, its possible that we can get better results 
if we "fix" one or both of the problems.

right now, AFAICT, the team is using the known and working solution.


when the actual artifact source is totally understood, I am sure 
steps can be done to improve the final output.

Just discovered: R3 doesn't use the same method for doing its font 
rendering as R2, it uses AGG instead. So it doesn't have the bug, 
and can be further improved.

If you look at the sample here http://www.omniglot.com/writing/tibetan.htm
the script seems to start from just above the top line and drops 
to the bottom with some accents above.

And I thought you were being funny. Different baseline logic? I can't 
say.

and tracking

Hey guys, don't be so picky ;) about the test text strings. I only 
cut'n'pasted random chars from some of these pages http://www.alanwood.net/unicode/#links
that's all.

I personally don't plan to spend time on all the 'unicode normalization' 
and other tricky stuff and details. It seems there is enough linguistic 
experts even for tibetan script! So I'll kindly left that part as 
an exercise to the comunity :-P

OK, and what can be done to get more quality to the font display?

what can be done to get more quality to the font display?

 I personally would make research about the technique McSeem(AGG author) 
 published in his well known font rendering related article and tried 
 to use the core idea of his demo application for making 'production 
 quality' version which can be then used in the HostKit code base.

I'm wondering if the Tibetan baseline should be at the top and not 
the bottom

Graham, sorry, I really don't know the rules how code points in Unicode 
should be positioned. That needs to be studied and corrrections being 
made in the text rendering/layouting loop. Just a note, even now 
the text rendering/layouting code ismore than 50Kb of C++ code so 
either someone needs to study all the Unicode rules and make new 
replacement or publish patches to the current version.

So, does this mean these chars render inside a text field and we 
can backspace, del etc?

Graham, teeling the truth I'm glad I can write Czech chars properly 
(yes I'm selfish in that case :)) and I don't care about the details 
of oter scripts unless I need them ;)

How about a bounty for the text rendering?


To be honest I don't care to much about better quality at the moment. 
We need a way to display text and some formatting (which works) and 
special chars like Umlauts. That's good-enough for us to use R3 for 
commercial development. Optimal text-rendering is nice to have but 
invest to do it must be covered by some revenue first.

The bounty is possible - but who has the skills to do the real work 
apart from Cyphre? :-) And also - how many man-days approximatelly 
would it take? (research plus implementation).

that contradicts the bounty mechanism, and is typical example of 
bold opinion, which burries and always burried REBOL down ...

Graham: regarding the 'updating GUI from network protocol' question

I have found some older scripts I did and quickly added the progressbar 
to it so you should see how it works.
You can download it from here:
http://www.rebol.cz/cyphre/scripts/r3/net/client.r3
and
http://www.rebol.cz/cyphre/scripts/r3/net/server.r3


just run server and client on localhost and press enter in the client 
console to see how the server shows the progress of upload.

AdrianS: give it another try...it is highly possible Pekr's Apache 
instalation on this server is bugged so sometimes the links works 
and sometimes not ;)

you're right - it looks like a fairly even split between good response 
and 404

its almost impossible to reverse layout when it is expected (and 
much easier to compose) going down.

Which was derived from Postscript, and so inherited its coordinate 
model, for better or worse.

we just need to be able to switch to and from those based on the 
current task, IMHO.

It won't be transparent either way. Either you need to specify the 
direction of the coordinate system (declarative overhead) or specify 
the transform (procedural overhead). And there will be computing 
overhead either way.

The question model is which is more efficient to use, both at development 
time and runtime. Letters will be tough either way (likely more for 
bottom-up), but graphics will be simpler bottom-up until display 
time.

Top down is faster to render on a screen, and faster to make UI layouts 
for (extept for fixed-size windows).

top down for layout and bottom up for draw

Top down for layout and text gobs, bottom up for draw? That confusion 
is the declarative overhead I mentioned earlier.

this will not cause any procedural overhead, and will simply reverse 
the coordinates.

from within a gob, the origin becomes the lower left corner.

as long as the gob knows its size it knows how to move its origin 
wrt its parent gob and render upside down.

Having a switch on new gobs will add to complexity. Having it fixed 
per gob type lowers complexity (outside of docs and tutorials).

and allowing a switch to the gob, so it can tell *only* the rasterizing 
engine to render bottom up, using all of the internal coordinate 
values AS-IS.

this effectively adds very little overhead, and solves the issue 
for all cases.

Complexity is the enemy here. We don't want to add too many options, 
because processing them has overhead in mental, development time 
and runtime. Pick a coordinate system.

the fact that its implemented as above, means its consistent and 
simple.

You keep looking at procedural overhead and ignoring conceptual and 
declarative overhead. Keep those in mind, please.

conceptually is solves a problem in just about GUI engines out there. 
 and its dead simple to use and understand.

And with that added option, how simple is it to check the gobs to 
make sure the option isn't specified? Multiply that answer by the 
number of times that check would need to be added to code. That is 
why you lost me at "inherit". But if you can convince Carl and Cyphre, 
go for it.

the way I see it the direction would be managed at the same place 
and time any origin check is performed.

at the same place and time any origin check is performed
 - That is the added complexity, the origin checks.

And how often would user code written in REBOL need to add origin 
checks? Style writers?

I'm not sure if it helps, but in Flash you can set alignement as 
you need: http://www.adobe.com/support/flash/action_scripts/actionscript_dictionary/actionscript_dictionary674.html
In REBOL we have TL and Maxim asks for BL.

for somethings it is easier to use top left and others bottom left 
as 0x0

Well, even if we use the tranformation matrix the text and images 
will be upside down because that is the 'behaviour' of  Cartesian 
coordinates system.

So IMO in both case there needs to be done some additional changes 
so images/fill-patterns, vectorial text etc. will be rendered correctly. 
And I feel such changes fit more to some 'layout code functionality' 
than being part of low level rendering.

In other words it is much easier to write simple coordinate conversion 
function in REBOL for such needs.

The reason is simple: if we add that at low-level we'll slow-down 
the whole code even if you use the default coordinate system.

Just a quick thoughs so I'm open to any better ideas.

Cyphre and other :  LOL so it's all about monney ... your are a bunch 
of liars and pretenders ...  and you think how much it will take 
to get  R3 done ? Even if i give you ten thousand dollars i'm absolutly 
sure rebol will remain your last priority ...

and that's the truth and nothing but the truth and saying it's a 
monney main reason it's a cheap excuse. YOU WANT MY MONNEY MAKE A 
FOUNDATION PUT 100% OF REBOL CODE IN GPL AND THEN YOU WILL GET A 
CHANCE TO GET MY MONNE .In the current state no way ... plain and 
simple you are not anough apealing ....

Robert absolutly not and more i spend time here less i want to participate 
in anything .... that's how you motivate contributions...

shadwolf - maybe you should stop accussing guys, who try to do something 
for us. It is not about the money itself, it is about the manpower. 
We have to prioritise things, and money can make help here. As for 
me, I always fighted against - now you can code it yourself attitude 
- that simply sucks. But - in opposition to the past, we actually 
can let it happen - if you contract some developer. In the past, 
all sources were hidden from us ...

Pekr  WHAT HAVE YOU DONE THE PAST MONTH TO TRY TO GET ME CONVINCED 
TO PARTICIPATE IN THIS PROJECT ?


Any time I try get a serrious conversation here about  where are 
we going or how things are done i get cheap lame excuses and I'm 
tired of it ! 


I stated a long ago the current phylosophy in communautary contributions 
don't fit with me (it was in may 2005)  you can't sit on 2 chairs 
at same time and expect to be stable.


You can't say rebol is a commercial trade marked business  and don't 
pay  the contributors and give them credits for their contributions 
.

You can't say a part of it is commercial an other part is free that's 
ethically not right. 

That's my way to see it ...


Then i won't participate to a project where the all mighty god fater 
can come out of nowhere and trash my month of hard work in a blink 
of an eye without any justification.


I won't participate in a team with people that don't want to share 
knowledge.


I won't participate in a team where people can take in hostage the 
whole project to get  money for themselves. 


I won't participate in a project where i can't  do any proposal with 
being insulted...

Did I made myself clear ?

and that is the kind of  community YOU built the past 10 years and 
that why so many left it ... Face it and make the changes that needs 
to be done.

you can add :


I won't paticipate in a project where there is not global plan and 
only a short term view and a one shot tries stack of things.

anton that way you can keep your illusions and remain in dream land 
where everyone is happy gentle and smart ?

as stated you got me to the ~vent group to get me out of your sight 
and avoid the discussion... So predictable.

shadwolf -- this group is for <For discussion of the R3 GUI> (see 
first post).
You are posting about the whole of R3 and its development cycle.
This is not the appropriate group for that.

Please switch to a group that is on topic for that.....Or use one 
of the generic ones, such as ~vent as Anton has suggesfed.

sunanda if you send me read the first meassges here i will send you 
read the first messages i made with the questions i made and the 
repy I got from the intervenant that way the wanabe dictator you 
want to be will see that if actually we seems to be out of topic 
that's related to the way people treat my asks.


Sunanda  If i was speaking ot jesus I wouldn't be trearted that way 
but I would still be out of topic ...

Too few people have ever been banned for there to be hard-and-fast 
rules.

Approximatelt.....Combining [off-topic] with [personal abuse] and 
[failure to engage in dialog] would be the main markers for someone 
heading for a ban.

so ban me you will prouve you can't stand a conversation and opose 
true arguments...

And it won't change the actual noone cares about rebol situation 
and less about rebol3 GUI...

robert said yesterday "Ok, latest host-kit compiled. Rich-text now 
included."....

I don't know guys you have a boring shadwolf  clamining rich text 
stuff you insult him you say he is nothing but a jerk a troll etc 
but anyway the week later you have it ready (proof that it was a 
point of interrest for you too ) then you don't say to shadwolf hey 
look at this maybe that will get you involved with us ? 


Naaaaaaaaah it's so much more fun to insult me and act like kids 
....

Please keep the ranting out of here, and stick to more approriate 
groups for that.

why compiling things that don't work ? Ok so i should have understoud 
it more like rich-text widget is done now and it compiles well so 
on next release at that time you will be able to experience it. We 
are impatient to get your comments on this new module.

but you can compile only some code ? or have we changed century and 
now you can compile empty conceptual ideas ?

thank you sunanda ... but then we don't have any idea of the converting 
lenght ... ok so the info are ''at August 14 th  2010, the Rich text 
dialect is adapted to the new project GUI using host kit . And Robert 
could compile it properly"

and i think if i try to discuss the dialect content in the new host 
kit i will be once again of topic ...

Graham , you have to send small chunks of the data (according to 
Carls notes for the R3 schemes the chunk should be smaller than 32Kb..this 
is true othervise the port connection 'hangs' for me if the chunks 
are bigger ) and do the update during that periods when you need. 
That's all the magic.

and to traverse the pane of a face, you traverse the FACES block. 
the setup for the face tree is simpler to navigate than in R2, because 
you are for example not allowed to make that block into a face, I 
believe.

an alternative, probably a more sensible one for large GUIs is to 
reference the faces from within the layout and then using functions 
externally:

boo: func [face] [print get-face face]

view [f: field button submit 'f boo]

Bolek, our private world is down, so I have to post here:


1. Some pointers on SPACING, MARGIN and PADDING: I think they should 
be standardized so that SPACING is 2-5 pixels, while PADDING and 
MARGIN remain at zero, so we can special-case them. We should reference 
these values in each style by STANDARD-SPACING, STANDARD-MARGIN and 
STANDARD-PADDING, rather than hardcoded values.


2. The PAD style retains its color on a differently colored PANEL.

Bolek, I partially take back point 1. It seems that SPACING both 
does spacing outside the faces and between them. IMHO, they are two 
separate parameters.

the last one is very uninteresting gfx wise :-) Better let's add 
another 20 lines of code, and format it to look less dull ... :-)

Thanks for posting Henrik!


On About, let's not forget encapped apps and multi-script apps. That 
is, how we should use system/script/header in various scenarios.

after seing the few screen caps i would say it"s flat ...  teh whole 
interface apears so flat .... other while i like the grouping and 
the global look of gob elements.