World: r3wp

:)

so do you notice the change in performance graham  ?

not tried yet ... busy busy busy!

Much faster!

thank you ^^

well  with 10 times less datas that's obvious

data = plural.

datum = singular :)

so for the text-option i like the idea but  I agree that's not applyable 
to dynamic drawblock generation

( it's Latin ... not English )

ok so datas ;P

cause i'm me and hum I do what please me that's what the concept 
of freedom is all about  :P

the concept of freedom is another channel !

graham i'm kiding thank you for the explanation ^^...

Has anyone given any thought to what printing model R3 is going to 
use?

as in printing to physical printers?

On behalf of Graham: Yes as in printing to real printers.

That's going to be very difficult unless we simply employ some form 
of postscript output, similar to VID.

I've worked extensively for many months with a printing system for 
R2 and it works, but only in conjunction with Ghostscript. It's not 
possible to print directly to a postscript printer unless you want 
to adapt your output to each single printer to work around hardware 
bugs.

I've just built a direct printing library for R2, Windows only. It's 
a wrapper on Win32 Print API, so it supports all printers. It support 
a subset of Draw dialect as input. I was needing it to print reports 
for the project I'm currently working on. It still needs some additionnal 
work to be released publicly (like adding a port scheme layer for 
more intuitive usage).

dockimbel, that sounds very interesting

Yep, very interesting.  So, I presume that you have screen preview 
as well?

Currently I use the postscript dialect and do a preview with draw, 
but because of the difficulties of rotations, and translations, anything 
that involves those screws up the screen preview.

And scaling.

Well, as my lib use Draw dialect, you can have preview support almost 
for free ;-). Scaling is supported by my lib, it even has a auto-scaling 
default mode to workaround different printer's hardware margins.

I was thinking about adding also a few other import filters for makedoc, 
pdf-maker dialect and View layouts, so something like this should 
be possible : write printer:// layout [...]

But as my free time is very reduced, I'll just release my lib with 
the scheme wrapper and let the community add layers upon that.

I don't plan to support Draw rotation, translation or matrix operations 
in the first release, but someone can add it quite easily.

(sorry for being off topic)

Once we have some sane documentation of the Windows printing model 
(read: the code you've written so far) it shouldn't be too hard. 
Not off-topis, btw: We can adapt your code to R3 and it might serve 
as the germination of a REBOL printing model.

(moving to Printing group)

Does R3 already have support for loading DLL ?

I don't think so, as the library API is considered to be a good candidate 
for a complete redo as the Plugin API.

That doesn't mean we can't get started on designing a good printing 
dialect.

Having the plugin API is good for static linking, but dynamic linking 
will still be needed (unless I missed something about R3 plugins?).

You did. R3 plugins are to be a cross between a REBOL module and 
a library wrapper, and can be dynamically loaded like modules.

So, do you mean that with R3 to access a DLL I have to build (in 
REBOL and/or C) a plugin, then dynamically load the plugin and then 
the plugin will load the DLL ?

It's not that different from writing a script wrapper for a DLL now, 
just easier and more powerful (in theory).

Does the DLL wrapper need to be written in C or REBOL ?

I gather that it depends on how awful the DLL's API is. Again, in 
theory because we haven't done plugins yet.

I expect that most useful wrappers will be a mix of both.

Well, in R2, you always have the option of writting a small wrapper 
DLL in C to interface with a complex API, if it's not possible to 
make a direct wrapper with only REBOL code.

It is the intension that all of this be easier in R3.

tion

Did Carl published any example code of how such plugin code would 
look like ?

Aside from knowing that they will be based on modules, no work has 
been done or published on plugins. Since even the module API is a 
work in progress, that means that all we have is discussions (unless 
Carl has been working on it in his current coding session, not as 
unlikely as you may think).

Brian - it is not correct that no work was done. Carl told me few 
months ago, that plugins are some 80-90% done. They have forma API, 
they are just disabled. The plugin simply exports some info for REBOL 
to load and bind or something like that ...

Some info from Carl from the past:


The DLL access is very complicated code that is specific to every 
CPU and OS.The DLL access is very complicated code that is specific 
to every CPU and OS.

The problem with plugin is not the code itself, but the security 
of it.

If we can set security aside for a while, we can certainly have the 
method for it.
I think it is probably ok for 3.0 to make this statement:

If you want to use plugins, you can -- but, you will want to only 
use those from trusted sources. Do not execute unknown plugins from 
the web.

the complex part of the security model is some method of digital 
signing.

We could use a simple hash method, but the problem is with public/private 
certification.

What makes it complicated is that we must port the R2 encryption 
code to R3.
That project could take a few weeks.

security for plugin should be the same as for any fileacess no ? 
 and once again you are not supposed to use software you didn't documented 
before on it. I think there is more risk to damage you computer and 
data by simply surfing the net with IE 7  than using rebol.

DLL  are black boxies you only can figure out the I/O  inteface what 
is precisely done in the plug is impossible if you don't have access 
to the plug source to figure out