World: r3wp

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

does because I can get a virus surfing the web i will stop surfing 
the web ? does because i can get virus through the maili will stop 
using email services ?

Does rebol can countains 100%  of all the technologies ? Does rebol 
will be enhanced anytime some of those manies techs are improved 
? Looking to those simple fact it's obvious  rebol needs external 
extension system.

after if you really want to bring a 100 %  plug security you have 
to make the plugins centralised done only by RT and with some asymetirc 
key control system to ensure no one have modified the DLL  betwin 
RT repository and the customer compurter

now in day to damge your computer you just need to log it to internet 
without firewall and anti-virus no even need to do anything your 
computer will be infected straight by a tons of worms

Pekr, I am glad to hear that some work has been done on plugins even 
though the module model isn't finished. We have discussed the security 
issues before in the blogs and their comments. The CPU/OS problems 
could be partly resolved by doing some CPU/OS-independent standardization 
of the REBOL side of the plugin model and let the OS side take care 
of itself. Defines in C headers and all that.

digital signing is not the problem the problemis to whom rebol will 
ask a 100 %  trustable footprint patern ?

if RTmakesavailable  a signature bank for trusted pluging and when 
rebol runs a load-plug command this function send the name of the 
plug +  actual signature and compare it to what is stored in RT's 
bank but this mean offline using of plugs will be impossible

Could simply require confirmation on first run... when you retrieve 
the plugin.  Then only check again when online.  This wouldn't prevent 
the plugin from working.

Hum I proposed long along when I was complaining about load/dll unfriendly 
shape to make a ported library repository wich you can find the standard 
libraries and the bridge to use them . the repository could be acknoleged 
by RT who will grant the lib is tested and safe download it and distribute 
is widely

now it depends of how do we considere the rebol sharings. what about 
those who want to build custom "plugins" based on official other 
libs but with only in it what htey need and not the whole thing (like 
SDK allows you to customise the VMrebol version you are going to 
share with your application...) Like rebolinforms the user when a 
rebol script is accessing external data it will be first  an information 
about the fact the script is about to load a plugin   and ask for 
user to continue or cancel. And if the user says yes then the answer 
is stored by rebol (in registry for example) so in next run the user 
is not bothered anymore. If the user is plugin to internet then rebol 
could check on the offical repository if the plug is safe or not 
this will give the user  an ensurance that the plug is safe.

once the reply from officialRT plugin repository is retreived then 
VM rebol store the answer to not have to redo the checking on each 
run

once again load/DLL  exists for a long time but we can't says that's 
a widely used feature. Most because doing a bridge .R is painfull

Just tried Windows Speech Recognition on my Vista laptop and 2.7.6 
.. and it doesn't work.  I can dictate single letters into an area 
but not words :(  Hope R3 is better in that respect.

i dindt' even known it speeche recognition would work with rebol/area 
....

waow

Apparently Dragon Dictate is able to dictate into an area.

hum I figure out it works ...

audio converts to text and send it to the curent text field as if 
it was a normal keyboard input ?