AltME groups: search

AFAIK Linux has the DRAW text support added(using fretype2 library). 
The only problem is how to get path to a font on Linux.(as there 
seems to be no 100% 'standard' way how to get it on all distros we 
need to use yet another dependency :-/ )

btw font handling paths in linux is a problem for all apps... not 
just REBOL.

I've thought about doing that as well Henrik, but by needs ended 
up being very static. I have also considered a test app that you 
could use to preview the result and then copy the command line, life 
effect-lab and font-lab.

its independent of gobs as you can use it inside draw already - eg:

text 100x100 [font "Arial" size 20 240.240.0 "this is some text" 
255.0.0 "this is some more text"]

Anton: regarding the DRAW fonts on Linux. The font redering is supported 
(at least it worked on all distros I had to use in recent 3 years 
or so). The essential problem is how to automatically get the paths 
to your Linux truetype fonts so you don't need to specify the font/name 
with absolute path as it is now....

If anyone knows about any efficient method how we could get path 
to the font files on Linux so it works on all distros let me know. 
Solving this issue would definitely improve the DRAW font usage a 
lot.

another thing which is missing is explicit font path.   The Os might 
not know, but at least if we could configure it manually then we 
could script independently of linux install.

Andreas, you are not getting that /View is not installed until viewtop 
can run properly. And that needs user directories, and font paths.

Who cares of blistering fast GFX apart from games, when you can't 
have the same anti-aliased font output on your form? :-)

I've never seen a single font which didn't have at least a single 
letter which was grossely mis-AAed.  often its the s, the o, or the 
e..... they stick out in every word and its annoying.

And because "you don't even have the same fonts on various OSes", 
I like that in Flash you can embed own font glyphs.

true type and the ttf lib are pretty much on all OS nowadays... its 
just a question of having the right to distribute a font with your 
apps... which in theory is the same issue with flash I would guess.

The problem with TTF is, that in most cases the fonts are copyrighted, 
so zou cannot give them with the app. You can embed glyphs you need 
into Flash, but the the font is not TTF anymore so nobody can use 
it in other apps.

ah yess I see the nuance.  so font authors are wary of allowing re-distributable 
licenses?

but the true thing is windows XP have  10  years now it's more than 
deprecated OS. If the font probleme on R2 cant't be solved ok i'm 
ready to wait other year to get a R3 draw/font relation working perfectly 
everywhere. The lessons of area-tc are:

4) the font system should be able to used every where

Shadwolf,

re glyph engine in R2: The glyph manager is used inside DRAW dialect. 
But the internals were never exposed at the REBOL laguage level. 
Should I really explain why? I hope not.


R3 text improvements: As I wrote week ago here to you on AltMe there 
are no limits for you to make it happen. You can already build your 
own font engine+dialect in C/C++ or whatever and use it as EXTENSION 
for prototyping your contributions. If I was able to protoype using 
R2 dll interface you have now even more possibilities. So where is 
the problem?

Reposting from R3 chat (which seems a bit quiet lately).


I've been looking at the rich text gob! functionality and it seems 
the following dialect commands are supported:

	anti-alias logic!
	bold [off]
	italic [off]
	underline [off]
	size integer!
	left|center|right
	drop integer!
	font object!
	para object!
	caret object!
	scroll pair!
	string!


Are there any I've missed? Any doco on this yet? I havn't figured 
out how to use drop or caret yet. Anyone have any working examples 
for these?


A design question: is there any reason for retaining font and para 
support given that we could move the few remaining unsupported words 
out of those objects and into the dialect itself? (e.g. have the 
dialect directly support font names and valign words).


Also, it would be nice if we had control over the default font name, 
size and alignments [at the very least]. Perhaps a system/view/text 
object?

Any other dialect word (e.g. scroll, size, bold, color) prevents 
caret from working (i.e. if you use caret you are forced to use font 
and para objects).

Also, it seems the caret object could be simplified down to:

	caret: make object [
		caret: start: end: none
	]


Are the blocks (caret/1 start/1 end/1) supposed to have any other 
values in them? (e.g. color tuple, 2nd string!, etc)

Any way of using anti-alias with caret? Seems:

	[text: [anti-alias on s caret c]]


kills the caret and font/para objects don't have an anti-alias word.

I see R3-gui has a gob called 'code-area which uses a monospaced 
font.

I could use text-list instead of table if that can be used with a 
monospaced font.

It looks I can use a monospaced font in a text list by changing the 
text-list-box face/text-style to 'code instead of 'list-item ... 
but quite unclear to me how one does this easily

Is there an easier way to do this than this?

    code-text-list: tight [

        about: "List of selectable text lines with scrollbar using a monospaced 
        font."
        facets: [
            max-size: 150x3000
        ]
        options: [
            list-data: [block!]
        ]
        content: [

            text-list-box :list-data :area-color options [ text-style: 'code 
            ]
            scroller
        ]
        actors: [
            on-init: [
                if select face 'reactors [
                    extend face/faces/1 'reactors face/reactors
                ]
            ]
            on-set: [
                set-face/list face/faces/1 arg
            ]
            on-get: [
                get-face face/faces/1
            ]
        ]
    ]

Make sure the word is not used anywhere else in the R3 GUI. Font 
changing, AFAIR is a little cumbersome. In the R3 GUI, fonts are 
a resource, similar to colors, certain draw blocks or materials.

henrik hidden widget is used to retrieve size sample for a character 
displayed on screen in draw using dynamically adapted font (according 
to the inputs setting of the user )

shadwolf, I'm not sure we'll keep using convoluted methods for obtaining 
font size information. we have the ability to make this nice and 
simple now.

good to hear Carl is documenting his ideas for the GUI. Is Cyphre 
already doing some low-level work? :-) Is there actually any priority 
for low level work? E.g. unicode display, better cross-platform font 
handling, draw improvements, transparent top windows, etc.?

recycle/ballast 50000
screen: system/view/screen-gob
system/view/event-port: open event://
font1: make system/standard/font [size: 20]
fire: [
	line-width 0.5 pen black fill-pen white line-pattern white 
	text vectorial 0x70 [font font1 bold "F I R E !!!"]
]

insert strokes: skip find fire 'line-pattern 2 rand: [0 0 1 1 2 3 
3 4 4 5]
img: make image! xy: 100x100

show append screen gob: make gob! [offset: xy size: xy image: img]

forever [
	change img copy/part skip img 0x1 100x76
	change strokes random rand
	draw img fire
	effect img [blur difference 2.5.10]
	wait 0.03
	show gob
]

recycle/ballast 50000
screen: system/view/screen-gob
system/view/event-port: open event://
font1: make system/standard/font [size: 20]
insert strokes: skip fire: [
	image img (first random [1x-2 0x-2 1x-2 0x-2 -1x-2])
	line-width 0.5 pen red fill-pen white line-pattern black 
	text vectorial 0x40 [font font1 bold "F I R E !!!"]
] 'line-pattern 2 rand: [0 1 1 1 2 5 ]
img: make image! xy: 100x70

show append screen gob: make gob! [offset: xy size: xy image: img]
forever [
	change strokes random rand
	draw img fire
	effect img [difference 3.5.8 blur img]
	wait 0.05 show gob
]

I'm sure the font rendering would be much more stable if this AA 
were used.

very thin lines also keep much more of their color , instead of blending, 
which is why I think this AA would make a big difference in font 
rendering.

in GLASS I had to take AA off in some text sizes for the font I am 
using.   some letters looked bold and some didn't.  On some letters 
with round corders (like S, g, D) the AA changes the width of the 
line so much its annoying to read.

font rendering: this is separate chapter imo..it would be great if 
this algorithm looks as good on text as on the images drawings.

The issue with AGG font rendering is that we are not using the 'clear 
type' like techinque yet. It would look much better even with current 
AA. I believe it will be part of R3 once HostKit is avaliable.

on the other hand, if the hostkit allows us to use system font rendering 
routines, then all the font issues will be solved.

btw - what is the situation/plan with fonts? Initial (recent) VID3 
(View) font rendering was not sometimes too pleasant. Was it due 
to not so precise font metrics 'tex-size calculations, or was it 
due to not being able to use more advanced (licensed/patented) techniques? 
Is there any way of how to resolve this issue?

Pekr, there are still options in the font rendering engine not exposed 
in DRAW. we need the host kit for that.

Pekr, re font rendering improvements....have a look at this famous 
article: http://antigrain.com/research/font_rasterization/index.html#FONT_RASTERIZATION

Mcseem describes possible way we could try in R3 version but it would 
need some more expereiments.

that's a very nice summary of various font issues.

Proportionnal resizing without font resizing has no use, IMO.

As for resizing - how much I can influence the scaling aspects? I 
mean - e.g. I have simple reblet, a calculator. Now while it resizes 
buttons etc., what if I want it also to properly scale on large display? 
I mean - making the UI element just bigger, including borders, font 
metrics, etc.?

ok then. Then there's Graham's question towards font  or generally 
UI scaling :-) Will it be possible?

IE9 preview 3 adds support for WOFF (Web Open Font Format). I wonder 
if there is something usefull in such standards, what we could possibly 
integrate to improve fonts?

doing 2D using  3D hardwar stacks generates a lot of problems due 
to the antialiasing and mipmaping manipulation ( and  drawing text 
without true font but with mipmaps  provide you no gain the card 
will not use it's fonts acceleration then)

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...

So, this uses OS native font infrastructure.

nice  :) beacasue R2 font system was a pain ... knowing what works 
where was difficult...

I experienced it when porting area-tc to linux ... the rendering 
was ok but as the font wasn't fixed size the editing part was messed 
up.

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...

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 ...

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.

Because it's not pixel precise font. I would like to see support 
for pixel precise font which could be in just a simple bitmap format.

the font handling has not changed, AFAIK

Because it's not pixel precise font.
 That's absolute nonsense.

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 
?

shadwolf for the 56743892th time, the font rendering is not properly 
utilized from AGG yet,

I appreciate the effort too ... but when i say this part needs a 
real work that's not to be rude etc... that's true !! damn how can 
i provide a simple functionnality like Zoom + / - for text if bellow 
font-size 14 bold the font rendering is ugly ?

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?

If AGG (or R2) was relying on the OS font rendering, the behavior 
shadwolf decribed could be caused by Cleartype. If Cleartype is turned 
on, but the REBOL renderer isn't rendering with compatible antialiasing, 
fonts would look bad.

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.

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.

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.

cyphre... seems like the best plan, for the best quality font rendering 
on any platform  :-)

font quality code - that will have to be done one day, as the View 
app font quality is really not nice. So let's hope that one day it 
will move up in the priority list :-)

There is no charset selection. You just provide valid UTF-8 codes 
for the appropriate unicode chars, thats all. Also ofcourse you need 
to have font that contains that chars. I was using 'Arial Unicode 
MS' font in the test screens which is a huge font containing big 
chunk from all the unicode pages.

it depends on gob type.  font should not inherit by default, draw 
should.  but I might want to render text upside to create a reflection, 
without incurring the hit of applying a transform to the coordinates...

Today, I made some tests (again) with vectorial fonts using draw.

And... It's not that bad when the gamma correction is... corrected.

My test:

font: ["verdana" size: 15]
gamma 2.0
pen none 

http://sites.google.com/site/rebolish/test-1/not_bad.png
(look at the white text)

steeve is doing an irc mini client like ... the font is well designed 
but a gamma correction 2.0 isn't it a bit too clear ? why 2.0 and 
not 20.0 ? seems something completly arbitrary again a speudo hack 
to solve a lack of real work ...

and for A105

>> do %r3-gui.r3
Script: "Untitled" Version: none Date: none
** Script error: expected command! not font

** Where: size-text font-char-size? make make-text-style parse fontize 
catch eit
her either applier do
** Near: size-text gob

It's not just the font but also the scroll bar which seems to be 
too wide and arrows too large for me.. but I like your sliders - 
to tell something positive as well:)

Maybe font metrics differ under XP and Vista/W7.

I cannot reproduce font offset problem under W7 (Parallels), looks 
same as in XP (Parallels).

What's left (not necessarily in order):

- test framework for GUI
- dialogs
- form validation, which meshes with dialogs
- help system, which meshes with form validation
- database record management, which meshes with form validation
- actor documentation parsing

- better View function that supports initial states for forms and 
dialogs
- some issues with resizing
- work on text editor core
- general style work
- skin comes last


Of course over time we get new ideas or stumble into design issues 
that need to be solved, before we can move on. That's necessary to 
make sure that some future feature is going to be simple to do.


All this is of course separate from hostkit, font rendering, and 
DRAW enhancements.

font quality is not nice, but still - Amiga got R3 View almost running. 
One year ago I would not believe it. Now we could get some Linux 
guru onboard ....

I aven thought about possibility to link to native widgets, but just 
to mimick skin parameters. I am not sure it is possible, but when 
you e.g. create skin, which looks like OS native one, then users 
will be confused, if you set OS native feel differently. Under windows, 
there's not much of possibilities, except for some Windows bar size/decoration, 
or font size. But under AmigaOS and e.g. MUI, you can change the 
look of widgets quite a lot. The question is, if someone would be 
willing to simulate such a complex system as MUI is, and define all 
the skins. The app would also have to be notified, that user changed 
central setting, to readjust ...

Am I missing something really basic......Here's my first attempt 
in many months to play with the R3 GUI.
New console session, R3-a110.exe:
    >> load-gui
    Fetching GUI...
    GUI Version: 0.2.1
    (Developer test GUI theme)
    ** Script error: size-text has no value

    ** Where: font-char-size? make make-text-style parse fontize do do 
    either load-gui
    ** Near: font-char-size? self

I used to develop a Chinese Font Engine in R2 using Win32 API GetGlyphOutline(). 
Now I am trying to do it again in R3, but this time I will get the 
glyth data from OpenType font files directly. Basically, I can read 
the Glyph data now, However, when the glyth has zero contour, my 
OpenType font format parser got error. The OpenType Spec offered 
by Microsoft is not clear to me on this.... Hope I can solve this 
problem soon. I cannot wait to see Chinese Characters in My R3 GUI. 
:-)

Does RM-asset version of A110 support the SHAPE dialect? I can access 
the glyphs in OpenType Font File now, and I would like to draw the 
Chinese characters using SHAPE dialect in R3.

I don't want to rely on the fact that   'red-button-which-doesnt-resize-aligns-right-bold-with-larger-white-font 
  is a style   ;-)

A quick question: is proper alignment along font baselines planned 
for the GUI?

I would first welcome fixing the quality of font display, which is 
really 80ties quality :-)

Not that I understand anything about GUI implementation, but font 
rendering sounds like a mere technicality for me.

Proper alignment of elements along font baselines sounds like it 
_could_ have a deeper impact and requires some planning.

I agree that precise use of the baseline should be doable.  its the 
only way to properly handle multi-font display.  it would also be 
nice to be able to inspect the font so that we can measure the different 
metrics of a font.


x-height, descent, ascent, cap height, linegap (leading), H space 
width, etc.


On the Amiga, I used to align text with these values in code and 
it seemed to be much better.

Andreas: "A quick question: is proper alignment along font baselines 
planned for the GUI?" - no, it is not, since the understanding is, 
that it has already been implemented... In case you see some quirks, 
please, let us know.

What's the current font size?

I'm trying to change the font color and size in a button, and in 
a field ... need some help !

Something like this?


view layout [button "Help" with [font: [size: 16 colors/1: 255.0.0]]]

Some comments:

-the TEXT style in the release has incorrect resizing settings so 
it makes layouts that are being resized ugly. We'll fix that.


-regarding the introduced and discussed:  options [box-model: 'some-word] 

The defined word! symbol should specifiy box-model preset. By 'box-model 
preset' we mean group of facets attributes that affect the box-model 
settings of the specific face/style. So this option is IMO correctly 
named.

Currently the box-model option was added as temporary solution to 
the PANEL style only. But in the next release it will be possible 
to set it on any face in the layout or style definiton. Also we'll 
add basic set of such box-model presets that will be part of the 
system by default.


-ALIGN vs. HALIGN: yes, we borrowed the terms ALIGN/VALIGN from HTML(but 
note, it is used also in R2 font object and in R3 para object) . 
As people today are familliar with it and have it 'wired' in their 
heads using the same name could avoid silly bugs in their code.

I presonally don't think this must be consistent with names of styles 
but if majority people insist of such kind of consistency we would 
probably need to unify also the align word in the PARA object as 
well.

I've done quite a few html analysers and with a bit of experience 
I have found that going with a brute force parse on pages ends-up 
being very effective.  I did a font downloading script for www.acidfonts.com 
a few years ago and it took more time to actually download all the 
pages than build the script.  :-)

the windows code is filled with truetype font stuff for example

ssolie: the only file that needs to be reformatted so it supports 
other platforms than windows is agg_truetype_text.cpp + .h

Otherwise there is already available FreeType wrapper so the rest 
of code can work  even on OS4

But the current hostkit code needs some more work to extract the 
font/text rendering parts so they can be controlled by defs.

If you don't want to waste time on this I can have a look at it over 
the weekend and make the changes so you should be able compile without 
the text code for now. Just let me know.

BTW last night I added freetype font rendering to the hostkit so 
ssolie will be able to try render text on AmigaOS4.

Feetype: by this addition in the hostkit we can theoretically get 
font rendering on Amiga, Linux, OSX etc. For OSX it would be great 
to switch to native fonts(Quartz?) later though.

I'm trying to run the hello world example at http://www.rebol.com/r3/docs/gui/guide.html

Here is what happens when I try load-gui:
>> load-gui
i
Fetching GUI...
GUI Version: 0.2.1

(Developer test GUI theme)

** Script error: expected command! not font

 ** Where: size-text font-char-size? make make-text-style parse fontize 
 do do either load-gui

** Near: size-text gob

Is this a host-kit issue or ?

Rebol strings are stored either as ANSI (one byte) or wide char (double 
byte). Of course the rich-text module is currently doing the conversion 
for every rendered ANSI string in realtime. Any sophisticated rich-text 
caching is not yet implemented. (note: this has nothing to do with 
font glyph cache which works well) But even though the cache of large 
text block is missing the performance is still very usable for normal 
GUI cases so the priority to spend time on the line-cache is not 
too high at the moment.

I modified text-test3.r3 script from the host-kit to use normal sized 
font (12) not anti-aliased and used a little bit longer text content 
(but not extremely much. just two lines with length cca 1400 chars)... 
the result is:

Good news: I do not notice any difference between ansi/unicode content.

Bad news: in both cases R3 uses almost 23% of my CPU time when I 
just move mouse over the text, which is pretty much:/