AltME groups: search

I want to improve the esmtp:// protocol to fix a few bugs reported 
to RAMBO... and make it more conformant to the RFC

no, actually, you can support EHLO and have no extensions.

and I would think most email clients would fall back ...

How about net-logging a prominent message when falling back ? That 
way, it should eventually turn up in someone's log, and we'll see 
it that way.

good idea... that way any techie does not miss it, if its at all 
important.  and any average user, gets improved mileage without the 
hassle.

I am accepting #4143. note, that although i think it is unlikely, 
this change could break old code that made assumptions about switch. 
so please do test this one when released (i assume 2.7.2), and if 
it breaks code, we can revert to the old switch, and maybe add a 
refinement or something like that.

#3666 applies to Linux: 1.3.2.4.2 and OpenBSD

(and I guess, that #3666 may apply to OSX too)

I've been using switch for years and have used other second values 
than blocks many times... its very usefull.  sometimes I put functions 
there.

max, there was a discussion here about switch and the new one was 
agreed to be a better solution. Ladislav can explain better what 
his concerns with the current switch are (mainly dealing with none 
i think). the feature with multiple values going to one block is 
very useful (i needed it many times and implemented my own switch 
because of that), so it seemed a good idea to integrate it in switch 
directly; but it could be a refirement if that would create too many 
problems.

max, i would be ok with switch/multiple. but is it worth to "bloat" 
switch? anyway if the change breaks actual code maybe we'll need 
to. do you think we should still let it in 2.7.2 and then you can 
test it and see how it goes in practice? if it only breaks one script 
in the world, it's quite easy to fix just that :)

I agree that the new switch is better in practice.  I will try it 
against my current code base and report back  I use switch profusely... 
so if its not an issue for me I think that it should be a good reference 
in general.

any tests wrt speed?  is it much slower than previous version?


I also think we should add /all  like the 'CASE.... since we are 
revisiting and operating on such a fundamental mezz, it could be 
a good time to make it as consistent with other similar mezz...  
 and the /all could be usefull. especially for handling non-exclusive 
refinements.

switch: func [
    "Selects a choice and evaluates the block that follows it."
    [ throw ]
    value "Value to search for."
    cases [block!] "Block of cases to search."
    /default case "Default case if no others are found."
    /all "Evaluate all matches (not just first one)"
][
    if system/words/all [
        cases: find cases value
        cases: find next cases block!
    ] [
        case: clear [ ]
        append case first cases
        cases: next cases
        while [
            system/words/all [
                all
                cases: find cases value
                cases: find next cases block!
            ]
        ] [
            append case first cases
            cases: next cases
        ]
    ]
    do case
]

Better to just have the WHILE, and break if not ALL ?

Haven't followed in detail; is there a reason it doesn't use FIND/ONLY 
instead of just FIND? We should also write a doc on SWITCH, SELECT, 
CASE, and DISPATCH (any others?) to note their differences. These 
funcs are an easy place to introduce subtle bugs if you don't understand--or, 
like me, sometimes forget--exactly how they work.

I think I was more concerned with the fill function itself and its 
range of arguments... I agree that the reverse stuff is not optimal. 
  could 'FILL itself (a faster implementation) be considered for 
2.7 ?  I've had to implement this kind of func so often...?  it handles 
all series, and transforms non series automatically...  so you can 
easily fill any value:

fill 1 3
== "1  "

also:

zfill: func [i len][fill/with/right i len 0]
zfill 1 3
== "001"


/right might be /left depending on POV  I prefer /right in the sense 
where the output is right justified... a /center could also be added 
pretty easily.

.. and the other line..
	all

switch: func [
    "Selects a choice and evaluates the block that follows it."
    [ throw ]
    value "Value to search for."
    cases [block!] "Block of cases to search."
    /default case "Default case if no others are found."
    /all "Evaluate all matches (not just first one)"
][
    while [
        system/words/all [

            any [head? cases all] ; only continue if at the beginning or /ALL 
            was specified
            cases: find cases value
            cases: find next cases block!
        ]
    ] [

     if any [default none? case][default: none case: clear []] ; only 
     clear case the first time
        append case first cases
        cases: next cases
    ]
    do case
]

switch: func [

    "Selects a choice and evaluates the first block that follows it."

    [throw] ; <-- allows RETURN to be used by the user to jump out of 
    an enclosing function (not just this one)
    value "Value to search for."
    cases [block!] "Block of cases to search."
    /default case [block!] "Default case if no others are found."
    /all "Evaluate all matches (not just first one)"
    /local rule new
][
	rule: [
		1 1 () ; <-- value
		to block! set new block! ; <- re-use the 'case variable
		(

      if any [default none? case][default: none case: clear []] ; only 
      clear case the first time
			append case new
		)
		to end ; <--
		| skip to () ; <-- type? value
	]
	rule/3: value
	change back tail rule type? value
	rule/11: either all [type? value]['end]
	parse cases [some rule]
	do case
]

I don't know that I would want to break switch for it since the name 
"Switch" implies that you are switching.  But since switch is built 
on the select function and it sounds more like what your looking 
for - I would think something like a select/all would be the route 
to go.

paul, the new switch allows multiple cases, thus /all makes sense. 
actually, I was able to use that in the imap protocol, which was 
using a "trick" to obtain the same results. so, now it's more readable 
and more elegant.

multi-switch: func [
    "Finds a choice and evaluates what follows it."
    [throw]
    value "Value to search for."
    cases [block!] "Block of cases to search."
    /default case "Default case if no others are found."
    /multi "evaluates what follows all matching choices"
][
    either multi [
        while [all [not none? cases not tail? next cases]][
            cases: find cases value 
            either not none? cases [ 
                do first cases: at cases 2
            ][
                either default [do case][none]  
            ]
        ]     
    ][
        either value: select cases value [do value][
            either default [do case][none]
        ]
    ]
]

ladislav, I understand that in the current version there is no native 
way to find the first value of integer! (not an integer! type value 
but the datatype value itself)  maybe that could be added to 2.7 
as a refinement.  its a valid request, especially since we are considering 
and openly commiting to updating the switch .   no?

Ah yes, you are right. Parse tries to evaluate the word. Hmm... Looking 
worse and worse...

rebol is the boss here, not html.  and if this means escaping block 
chars in other datatypes, well I think it should be done.

Maybe then if we just add all the valid cases that meet the criteria 
to a block during the while loop and then evaluate each item in the 
while loop is completed?

Max, WRT FILL, I have similar funcs, and I agree that we need something 
like this. I tried FILL and PAD as names, but didn't like them as 
much as JUSTIFY. JUSTIFY is longer, but IMO it removes the ambiguity 
for /left and /right.

Rather than pushing for R3 inclusion, we should try to get revault 
up, and put things there. :-)

At work today, and got a chance to try out the postscript printers. 
 It's amazing .. I can print from my draw preview to either the network 
colour postscript printer, or to the old HP Laserjet 4MP on the lpt1:

and with ridiculously little code

I remember that NeXT printers were so cheap because all the postscript 
processing was done by the NeXt OS, and so the printer was just a 
bare engine.

If you don't have a postscript printer .. I recall in the old days 
you created a large bitmap in memory, and then printed it all out 
dot by dot.

Now to do desktop publishing, need a hyphenation dictionary, and 
a way to do kerning.

If you're talking about the rotated and transformed text, I think 
it's because there's a glitch in the way scaling etc is computed. 
 Probably my fault, and since I don't need scaling or rotations, 
I haven't looked at it very hard.

you can see the same problem with the shaded box which rotates and 
moves in closer to the middle as the size is reduced.

No, I mean all the different text strings disappear and reappear 
at different times as you drag the slider. Something to do with font 
size ?

and where do you get the hint data from?  Is it read from the font 
somehow?

this version allows you to print to a network printer, to lpt1, or 
to a disk file, and then it calls the RoPS viewer.

I have a button "Edit" which imperfectly shows you the dialect source 
( strings lose their quote marks).  Not formatted though.  And save 
which is supposed to re-render any changes doesn't work .. because 
the data needs to be converted from text to a block, and without 
the quote marks for the text, it dies.  Too late for me to find a 
fix.

you can edit and save, and it redraws it.

But there is a context problem with the colours .. so I had to replace 
(red) and (black) with their tuples.

graham, did you figure out how to use the parallel port and was that 
for printing?

Graham: yes, and data is parsed from the Adobe Font Metrics file 
and included in pdf-maker.r for the 14 standard postscript fonts.

Henrik, my latest demo has a button that prints to the parallel port. 
 As for choosing trays and paper size, I think you can set that in 
the postscript comments.

and you know the page size

so, my approach would be to create a center dialect word, and have 
a postscript implementation and a draw implementation

presumably you can use it in vid and use those values.

http://www.hmkdesign.dk/run14.png<--- the offset can be seen at 
the bottom. I haven't tested, but maybe the kerning between the VID 
and DRAW font rendering isn't the same.

How did you do those lists with the rows and columns? : - )  Just 
kidding, Looks great.

well, there might actually be one feature missing in 0.0.38: focusing 
and unfocusing of list views

post a RAMBO and see what happens. at least on the size difference 
between fonts in VID and fonts in DRAW

I can't confirm it, and I haven't worked that much with it yet to 
be certain.

pdf does not support unicode fonts, and i guess the same might be 
true for ps... so good luck :)

about DRAW, I'm sure how fit it is for this yet. I had serious problems 
with it under Linux today (misalignment and crashes too)

Did I mention that I have three columns of text snaking up and down 
an A4 page?

if I could test it... wasn't on my machine and I couldn't get console 
output

My aim is to get perfect postscript output .. and at least a rough 
approximation in draw.

yes, at least in a clear way to make sure that the postscript is 
like it should be: that centered output really is centered, font 
size is completely accurate and such

And with postscript, you can create your own fonts

I've created pdfs with jpegs .. and they seemed to be okay.

but maybe it was because it was an external bitmap and not one created 
by rebol

Looking at algorithms for text justification.  One I looked at says, 
collect all the words that will fit on a line with a space, count 
the spaces, and the area left over, and allocated part of that extra 
space to all of those spaces.

Text flow, with justification, word wrapping, and footnotes is not 
a simple task.

Since your centering routine didn't work, I just stuck with my original 
one, and that seems to work for me.

I've got a box with text in it, and all the text is centred.  I can 
translate that box to anywhere on the screen.

and postscript.

Text flow, with justification, word wrapping, and footnotes is not 
a simple task.
 you bet :) that's 60% of TeX.

Without re-writing TeX, what I am trying to do is allow text to flow 
from one text box to another on the same page, and then on to other 
pages.

Is a "fudged" example of page with two textboxes where the text flows 
down one textbox and then into the other while nearly being justified.

If you use the "edit data" button, and change the word "justify" 
to "left", and save, the text reappears without the full justification.

As you can see, the justification algorithm is imperfect .. and it's 
still a little ragged on the right.

and of course i plan to document it very well (again, as good as 
TeX) so that everyone will be able to use it

and, in pdf 1.4, optional alpha channel data

since 0x0 is bottom left in ps, and top left in Rebol ...

on unix you usually create ps and send it to the print spooler

and, if you had a ps printer, ps files

how "good" is already w3c's stuff here? I mean html plus css and 
it's media (printing) capabilities? browsers are everywhere ....

then, ghostscript got put in between lpr and the printer, so that 
you could always use ps even for non-ps printers

It's all html and you can't print it.

I think HTML/CSS is not good enough for printing, even with the printing 
oriented CSS commands. It's a nightmare to match margins, and browsers 
don't interpret the settings equally.

and why i studied TeX

yesterday I looked at two big printers here (not very skilled in 
that direction) and I found PCL, PJL, LPR you mentioned. What are 
PCL and PJL? Othere languages to support printing?

The problem with floating tables and images, is that if they don't 
fit in their entirety on the current page, you have to move them 
to the next page.

Gabriele - I know, browsers are just containers for other technologies. 
It will last at least one or two years, before browsers  (for most 
userbase) support  ajax, svg, css 3, etc., but they are actively 
developed and will always be at user's desktops .... there is also 
one czech product, called formfiller ( http://www.ff.cz), which 
allows (internally hopefully xml) docs.  xForms is the standard we 
should watch ...

The idea here is to produce postscript as the last thing, just before 
sending the data to the printer. We shouldn't produce postscript, 
that we then need to preview before printing, because we then need 
to solve the problem of converting postscript to something viewable 
on the screen. It's better to work with DRAW or whatever developers 
use to visualize their content and have preview at that level. Then 
in the end, the user wants to print and now, finally the content 
is converted to postscript to be sent to a printer.


Having a postscript printer is a huge benefit, because you can say 
goodbye to printer drivers and all the trouble, those cause. The 
REBOL postscript dialect is your driver. :-)

A postscript printer is a printer, that understands the postscript 
format. It reads the text commands, a postscript file is, and print. 
Data like images is inside the postscript file as hex or something.

(Of course if the printer isn't a postscript printer, and you want 
to print a postscript file, you need a driver to convert from postscript 
to the format, the printer understands. So people without a postscript 
printer can still print from postscript-producing REBOL programs. 
They then just need a printer driver.)

and why javascript should have been promoted more for the last 10 
years.

Yes, it happens alot to me too and is a waste of paper. Good that 
many websites has that little printer-friendly-version icon.

Volker, OpenOffice doesn't include a browser (the versions I've used), 
while StarOffice did (when I used that). So opening a HTML doc in 
OO gives you the wordprocessor with the concept of paper-pages, and 
then you print, what you see.

www.rebol.com opened OK in NeoOffice, and I could change to "Print 
Layout". Right-margin is not perfect (as often with HTML, because 
it isn't a wysiwyg format), and it can probably be configured. Saving 
as PDF gave me exactly what was seen on the screen.

Volker, so my first impression is, that OO is OK to handle HTML, 
but not perfect (and how could any program be with all that misunderstanding 
of HTML out there).

Some small progress .. I can now get floating text tables, and text 
that flows from one textbox on one page to the next page.  But not 
completely error free yet :(

I have two textboxes on the first page, and one on the second.  Text 
flows from the first page to the second, sort of justified.

the point of having this dialect is to create page templates for 
viewing data from databases or whatever.  The text is replaced either 
by evaluation or by compose, and you have your draw layout.

That's how it looks in draw and also when printed to a postscript 
printer.

I don't have a problem with font positioning in draw and postscript.

Just text rotations and other fancy stuff.

I have text centring and flow across multiple pages