REBOL 3.0

Comments on: Default TEXT setup in DRAW?

Carl Sassenrath, CTO
REBOL Technologies
28-Aug-2008 18:33 GMT

Article #0143
Main page || Index || Prior Article [0142] || Next Article [0144] || 20 Comments || Send feedback

The DRAW dialect requires each TEXT command to setup its font, para, and other attributes. However, for things like GUI's, most of the time, those attributes are the same.

Question: should we find a way to specify default TEXT attributes that are valid for the duration of the DRAW block?

This would reduce the overhead for things like the GUI, which tend to use a large number of TEXT blocks within DRAW GOBs. (E.g. for text-list styles.)

Example of current method:

drawing: [
    some-graphics
    text 5x5 [font f1 para p1 "choice 1"]
    text 5x25 [font f1 para p1 "choice 2"]
    text 5x45 [font f1 para p1 "choice 3"]
    ...
]

Possible future method:

drawing: [
    some-graphics
    text-options [font f1 para p1]
    text 5x5 "choice 1"
    text 5x25 "choice 2"
    text 5x45 "choice 3"
    ...
]

We may have talked about this before, but it's time to reach a conclusion.

20 Comments

Comments:

Peter Wood
28-Aug-2008 20:21:52
drawing: [
    some-graphics
    text-option text-1 [font f1 para p1]
    text-option text-2 [font f2 para p2]
    text 5x5 ["choice 1" text-1]
    text 5x25 ["choice 2" text-2]
    text 5x45 ["choice 3" text-3]
    ...
]
..... looks good to me.
shadwolf
28-Aug-2008 20:34:04
(E.g. for text-list styles.) ---> Or for RTE-area (area where you can display Rich Text) too .... that would be a pity to have such a drawing power and not use it widely. Hum I mean in a widget that most of use will use most of the time...

I like that idea Carl ^^ and as you could figure out I'm working on RTE using draw and the font settings needed for each and every single character in the text increase alot the size of the data stack.

hum and what about the pencil ? in my code (RTE line) I use a pencil set to the current text color for each char. like this

; datas generated by my rendering engine

[font make object! [ name: "arial" style: [normal] size: 12 color: 0.0.0 offset: 2x2 space: 2x0 align: 'center valign: 'center shadow: none ] pen 0.0.0 text 5x0 "a" font make object! [ name: "arial" style: [normal] size: 12 color: 0.0.0 offset: 2x2 space: 2x0 align: 'center valign: 'center shadow: none ] pen 0.0.0 text 12x0 "b" font make object! [ name: "arial" style: [normal] size: 12 color: 0.0.0 offset: 2x2 space: 2x0 align: 'center valign: 'center shadow: none ] pen 0.0.0 text 19x0 "c" font make object! [ name: "arial" style: [normal] size: 12 color: 0.0.0 offset: 2x2 space: 2x0 align: 'center valign: 'center shadow: none ] pen 0.0.0 text 26x0 "d" font make object! [ name: "arial" style: [normal] size: 12 color: 0.0.0 offset: 2x2 space: 2x0 align: 'center valign: 'center shadow: none ] pen 0.0.0 text 33x0 "e"]

maybe for text purpose an enhancement too could be to not have to declare the pencil formaly it should be implicite the text is set through it's text-options wich implicate the color no need to be redundant and have to formally call for the pencil setting.

(Or maybe I'm not conding it well that's a possibility too )

shadwolf
28-Aug-2008 20:54:08
I like the idea to set a flag for the different text-options this way we can have 2 part in the datas draw block! on the top we con have text-options declaration and following we can have the text use.
shadwolf
28-Aug-2008 21:07:29
is it possible to do text-options [ t1 [font f1 para p1] t2 [font f2 para p2] etc... ] regrouping the text-options into one block can be a good thing to save data space.

John Niclasen
29-Aug-2008 3:47:58
Are we talking styles within styles? Would it be any benefit defining styles within DRAW as a concept?
Maarten
29-Aug-2008 4:39:56
Go with your option 2. It's close in text to the way word processors work.
Graham
29-Aug-2008 4:49:41
I would prefer to do it the same way as is done in postscript .. viz. specify the font and thereafter all text uses that font until the font is changed.

If we keep it similar to postscript, it will make it easier to emulate postscript in draw.

Rebolek
29-Aug-2008 5:25:12
text 5x5 ["choice 1" text-1]

this looks like absolute positioning to me. Sad :(

Icarii
29-Aug-2008 5:54:51
That would work fine for simple strings of similar formatted text but for text with bold/italic/underline/color changes this would become rather messy.

Perhaps it would be better to have the ability for draw text to accept a function value where you could have the parameters evaluated and passed back eg:

>>text pos [pair!] clip-size [pair!] my-func-that-returns-a-block func-params

text 5x5 hilight-weblinks some-text-with-links

that way you could have functions doing all the format layout work.

-pekr-
29-Aug-2008 7:42:12
Some two months ago you propose method of "auto" inheritance with styles:

 button [
    up [
       props: [
          ;--- properties here
       ]
       draw []
    ]
    down [
       props: [
          ;--- properties here
       ]
       ;--- inherits draw
 ] 

So:

1) I don't like, when things are "out of bounds" - the inheritance is not obvious in code tree. Things that share the same properties, should be ideally enclosed in a block (like 'panel does for its content). Of course it might not be ideal, so we have 'across, 'below ... which behave more as a "switches" But - we can get used to it, if it is clearly stated as a concept.

2) So - now we know, that we'll get some kind of inheritance with styles and their definition. I am against any other "function polution", as 'text-option. What's next? 'effect-option? I know that we talk different levels here - style definition, vs style usage inside layout. But - why not to use 'style, 'stylise (for inline styling)? That is really nice concept. So - now you have got my answer for your question - the second option is absolutly wrong imo.

Robert Shiplett
29-Aug-2008 8:37:53
In the Curl expression-based web-content language, any Visual can have 'options' which can be 'local' or 'non-local'. It has proven to be very useful. Non-local are picked-up or 'assumed' by your graphical 'children'; local are your own. In Curl, {text } expects to be passed a Visual such as {text this is a string} || no kidding If that 'text' expression is in a graphical hierarchy, options apply. Curl uses value expressions such as {value this-thing} where we use :thing so you get 'local' override of options with {text {value this-thing}} or with {text {value my-string}, optionX = y, optionA = b } I love Rebol, but I work in Curl and various Smalltalk implementations for a living. Both are marvelous on the Visual end of things ...
Gregg Irwin
29-Aug-2008 12:20:36
I think Graham has a good point.

The main thing is to clearly document that VID is a bunch of face definitions that have state, style inheritance, etc., DRAW is a series of commands, some of which may set state for future commands, and never the twain shall meet.

shadwolf
29-Aug-2008 13:53:16
Less space taken by settings is not a futil thing. In the axample I gived, it's obvious than it would be better to not have 95 percent of the draw block! taken by the font object declaration.
Henrik
29-Aug-2008 13:53:32
Since DRAW now can work with blocks inside blocks, maybe it's appropriate to simply allow blocks to be used to store blocks of words:

drawing: [
    some-graphics
    my-text: [text font f1 para p1]
    my-text 5x5 "choice 1"
    my-text 5x25 "choice 2"
    my-text 5x45 "choice 3"
    ...
]

and it would just insert that block part where you re-use the word. Of course it's hard/impossible to create dynamic content in the block like that, but as far as I can see, that's not the intention here.

Gregg Irwin
29-Aug-2008 14:12:43
That brings up a good point though Henrik. Is the target manual or dynamic creation of draw blocks? Or does it need to serve both masters equally?
Graham
29-Aug-2008 16:25:14
At present I use draw for print preview and allow the user to scale the preview smoothly. I currently create a font object for each piece of text, and when I resize I have to recreate each of those objects. There should be an easier way.
shadwolf
29-Aug-2008 21:30:01
We already can set the font and pen to affect all the following draw commands that follows it until new settings call is done.

I wasn't aware of it and that allowed me to update my RTE-line and reduce alooooot the amount of data contained in the draw block!. With effect to speed alot the rendering (graham is going to be all happy)

As for the proposition of variabilisation of font setings well the problem is that in dynamic generation of draw block, we are unable to figure out wich variable belongs to the current font settings appliable to the current text commands. So this improvement seems to not apply to that field.

shadwolf
29-Aug-2008 21:33:35
short example of the RTE-line new draw block content:

font make object! [
        name: "arial"
        style: [normal]
        size: 12
        color: 0.0.0
        offset: 2x2
        space: 2x0
        align: 'center
        valign: 'center
        shadow: none
    ] pen 0.0.0 text 5x0 "a" text 10x0 "b" text 17x0 "c" text 24x0 "d" text 31x0 "e" text 38x0 "f" font make object
! [
        name: "arial"
        style: [italic]
        size: 30
        color: 0.0.0
        offset: 2x2
        space: 2x0
        align: 'center
        valign: 'center
        shadow: none
    ] pen 0.0.0 text 42x0 "A" text 64x0 "B" text 86x0 "C" text 108x0 "D" text 130x0 "E" font make object! [
        name: "arial"
        style: [italic]
        size: 30
        color: 0.255.0
        offset: 2x2
        space: 2x0
        align: 'center
        valign: 'center
        shadow: none
    ] pen 0.255.0 text 152x0 "F" text 165x0 "D" text 187x0 "S"
]

the datas needed to handle 14 chars is half the amount of the ones needed to handle 5 chars ^^

Norm
31-Aug-2008 9:24:32
From experience in publishing, most texts simply exploits variations of few fonts (2-3), otherwise it gets ugly. That normal behavior of most users is reflected in the way Postscript works, as Graham reminds us. Styles could be inheritable to reduce the draw blocks.

We should not adress the problem of text formats from the standpoint of supporting at once any variations imaginable (texts are not pictures, even when drawn); text gets difficult to read when it looks like a Christmass tree. Why not first adress the needs of the most frequent 10% possible styling options that will be used 90% of the times?

Styling text options supported by draw will be a nice addition to the features of the Rebol language. In a plugin, it could be a fierce competitor to CSS.

oldes
1-Sep-2008 8:01:01
I prefere the second method. It's really similar like the changing color. There is really no need to specify font all the time I want to draw a letter. Maybe it could be more compatible with the richtext dialect, where it's now possible to do:

para my-para
font big-font
"Hello World" newline
"Welcome to RichText"

Pekr is absolutly wrong imo:) We are talking about the way how is the text rendered inside drawing, not how is defined layout itself.

And to rebolek: it's 'internal' draw dialect here. It's good to have absolute positions here. You must have own script which does the automated positioning if you need it (which produces the code above with the positions). So the positions are calculated only when you really need it. Not on each redraw.

And if it's static draw block, it can be optimised as well, I hope:)

Post a Comment:

You can post a comment here. Keep it on-topic.

Name:

Blog id:

R3-0143


Comment:


 Note: HTML tags allowed for: b i u li ol ul font span div a p br pre tt blockquote
 
 

This is a technical blog related to the above topic. We reserve the right to remove comments that are off-topic, irrelevant links, advertisements, spams, personal attacks, politics, religion, etc.

REBOL 3.0
Updated 28-Mar-2024 - Edit - Copyright REBOL Technologies - REBOL.net