AltME groups: search

MDP and MD2 are to far on rendering method to be correctly handle 
in a single app ...

has MDP rendering is very distinct from MD2 we can merge them .. 
one little example section on MD2 it's sised text folowed by a red 
line on MDP it's black line  folowed by newline then Num_section 
(example 1.2.4)  folowed by text then newline again ....

making 2 rendering engine will encrease and complicate the application 
for very not a good result ...

I prefer a dedicate mode but MD2IDE and MDP-GUI can enritch them 
eatch other ;)

so it's better to have to product each of them comply with a spécific 
task and avoid user crankles

MDP is a more sofisticate way to process and for example with section 
rendering I still have some counting problem on next refresh

GEOMol's NICOMDOC is pretty but in vid rendering outch !!! Plz carl 
enhance VID rendering engine because NICOMdoc coloring text is a 
perf kill for VID ...

but colored text in VID there I said NO, NO, NO, NO, NOOOOOOOOOOOOOO 
!!!! IMG parsys this kind of heavy flaged an recompose it to VID 
it's a hudge task and very process consumist

doesn't didier have a rich text style?

yes but it's not talking nicomdoc it's talking RLD a low flaged dialect 
hand even in this case we absolutely don't know what it could produce 
on VID rendering time for very large text coloring (like source code 
text syntax colored highlighted etc...)

NicomDoc is a step over this two that's sure but it's heavyly using 
html capabilities and adapting this to VID HUM HUM HUM

GRaham note that I don't say I'm not interrested on making NicomDoc 
quick and easy editor but this format has too a lot of things to 
make a VID parse writer mad hehehehe or maybe I'm not enought skilled 
...

Its good to have competing mark-up languages ... they can all gain 
by learning from the strengths of the others.

HTML and VID are such different concepts that you can't easily start 
from a single "higher" dialect and make full use of both VID and 
HTML

MakeDocX {x=2 or Pro or blank)  gives you very little comtrol over 
the emitted HTML -- so it is less powerful but more generic....hence 
thoughts of PDF and other emitters.

NicomDoc is more powerful as a HTML generator but, as shadwolf says, 
not nearly so easy to VID....Though let's give it time to develop: 
it's only days old.

Mulch (my dialect) gives you total control over the HTML and CSS 
with almost zero chance of a VID version being possible..... http://www.rebol.org/cgi-bin/cgiwrap/rebol/boiler.r?display=mulch-help

in actual way we have to parse the MDX(retake of sunanda notation 
see up)  file then create a page with will content style and data 
to so in this operating way making complicate conposing like a heavy 
colored text or a content linked table of content (=toc) will include 
a new parsing statement in the parsing statement this will increase 
a slow rendering process

MDP-GUI v1.3.4 include a remade IHM a bug correction and the rendering 
of the list of content

I know that I'm making every day a new realease of an unstable project 
but this helps me to figure out for eventual bugs...

But the HTML tag <a> should work.

Yes, or write <a href="http://www.rebol.com">REBOL</a>in your text.

Problem is, if you wanna build a system to have other output than 
HTML.

True. That would be a little more difficult.

I've written a MakeDoc2 summary. Look here: http://home.tiscali.dk/john.niclasen/nicom-md2-spec.html

Cool. Now I have a reference!

I'm going on skivacation for a week, but I desided to put my work 
so far on the NicomDoc document format up on my website. It's NOT 
version 1.0 yet, so some features are not supported. I'll write a 
short specification in a moment.


Parsing a NicomDoc document to HTML goes in two passes, first the 
raw document is converted to RebXML format. This is done by this 
script:
http://home.tiscali.dk/john.niclasen/nicomdoc/nicomdoc.r


Next the RebXML version is converted to HTML. This is done with this 
script:
http://home.tiscali.dk/john.niclasen/nicomdoc/rebxml2html.r


I've also made a little script, that will do the whole conversion 
in one go by calling the other scripts. It works much like calling 
makedoc2.r, and it can be found here:
http://home.tiscali.dk/john.niclasen/nicomdoc/ndoc.r


Those of you, who want to work with this format, e.g. make VID output, 
should work from the RebXML version of the document (after first 
parsing from raw document to RebXML with the first script), because 
this script handle all the complicated rules, so the RebXML version 
is much easier to work with.

Notice! As this is not version 1.0 of NicomDoc, some things will 
probably change. The namespace might change. Example: I use 'p' for 
paragraph in the RebXML version to make it short (also if someone 
wants to make XML output, which is bloated), but I might change it 
to have a more saying name for a paragraph. And URL keyword might 
go away and be replaced by a more general term like a reference.

It's of course possible to make XML output of a NicomDoc document 
by first parsing it with nicomdoc.r and then use http://home.tiscali.dk/john.niclasen/rebxml/rebxml2xml.r
on the RebXML version. And back again with http://home.tiscali.dk/john.niclasen/rebxml/xml2rebxml.r

I love the way makedoc2.r shows the out of place markups...so you 
can see why something didn't work...for example, if you do a # without 
the para...it shows the out of place # in the html

has there been any ways suggested with making colspans in tables? 
otherwise I would suggest a:

\colspan

col1

col2

col3

/colspan


tag. Just build the table as normally and enclose the columns you 
want in a specific row with those tags.

It's tricky to make tables easy to produce for the writer, and at 
the same time give opportunities to have colspan and rowspan. And 
do we have the need to have tables within tables? That'll just make 
it even more complicated. I guess, learning by doing is a good way 
to figure it out. (That's one idea behind my NicomDoc format. To 
try things out.)

Has I  forget toremove a disgracingprobe I can fix that too

[MDP-GUI DEV NEWS ] I improved the rendering speed by 300% integrating 
the MDViewer rendering method that ASHLEY created. That new algorithm 
really rocks !!! I had to change the inline formating flags to conserv 
the most speed. I conserv the ashley way to deal with inline marcker 
has HTML tags (e.g: <b>text bold</b>) I adapt ashley's code for all 
little  other différences that exist beetwin MD2 and MDP format. 
Next step is to enhance the toc rendering process. I remade the first 
start up process. I plan to give MDP-GUI.r, make-doc.r, make-doc.txt, 
ms-word.gif, in a single ZIP archive that make easier the release 
and use. As johnatemps says to me people wants to download and use 
and not try to configure the program durring lot of time.

maybe later i will wrap all the zip package into a .exe file using 
grebox wrapper from shadwolf and spag' :)

New version of NicomDoc is out. It's still not v.1.0, so things will 
change.


Specification: http://home.tiscali.dk/john.niclasen/nicomdoc/NicomDoc.html

Example: http://home.tiscali.dk/john.niclasen/nicomdoc/example.html

Example source: http://home.tiscali.dk/john.niclasen/nicomdoc/example.txt

Main script (this is the one, you should run. Works like makedoc2.r.): 
http://home.tiscali.dk/john.niclasen/nicomdoc/ndoc.r

NicomDoc to RebXML script: http://home.tiscali.dk/john.niclasen/nicomdoc/nicomdoc.r

RebXML to HTML 4.01 script: http://home.tiscali.dk/john.niclasen/nicomdoc/ndrebxml2html.r


Changes from previous version are: simpler tables, better magic mode 
(rich text), better handling of paragraph states like centered text 
(won't effect the inner of e.g. tables), better handling of faulty 
input, tables within tables, same with notes (not sure, if you could 
that in previous version) ... and probably some more, I can't remember.


You need atleast REBOL/Core 2.5.3, because of new break word within 
parse rules. So it won't work with official REBOL/View 1.2. Get a 
newer one!

Oh, you mean "how to export a NicomDoc document --> html" ?

No luck finding a free polish - english translator..

I can translate a bit from polish

A couple of issues with makedoc2:


1. Table headers are double height and the text in the last column 
is pushed half a line down in Gecko based browsers

2. \note ... /note boxes are wider than the document itself in Gecko 
based browsers

I haven't seen them in RAMBO, but is a fix being done by anyone?

Just a note, I'm getting some free time in the next week and will 
work on MDP. I already have fixed some bugs and will make it more 
MD2 compatible. Further the interface between parser and generator 
will become MD2 compatible so that things like MDP-GUI / MDViewer 
can swap the engine beyond.

So, I have made some enhancements to MDP and put a beta online. You 
can find it at: http://www.robertmuench.de/download/make-doc-pro.r

The following changes have been made:
*Bugs fixed:*

#State tracking flags weren't correct, could lead to strange results 
when using tables where cell text used inline markup. Especially 
in site-mode.

*New Features:*

#Code can now be included via ~=include code <filename>~ where the 
included code will be automatically indented and hence handled like 
an example by the output format emitter.

*Programmatic changes:*
#Celeaned up the global word pollution (Thanks to Ahsley Truter)

#Renamed ~generate-files~ function to ~scan-doc~ to meet MD2 wording

I will set an entry to rebol.org as this version is a stable one

Have you looked at uploading it as a package?

yes a package is weird to set ...

well in fact the script countains lots of different files and handle 
them one by one it a true torture

The good news is that there is now a different error.  With .ZIP 
it said that mdpgui1-4-1 was not a package now it is saying the package 
is unavailable...

If anyone has a small html hyperlink detector, it might be nice to 
add that into the code.

Ok, missed this group -- Carl, just a thought (and see what others 
think) -- it's a little odd looking at the messages with newest on 
top.  Another suggestion would be to do newest at bottom and put 
an anchor at the end so that incoming links start reading the page 
at the bottom to mirror the AltME view...

olivier auverlot comments: that a tiny interface for message submition 
would be a very very appreciated functionnality for the rebolers 
witch are on os that  doesn't support AltMe

that's very unlikely to happen. sorry olivier, but you can use the 
ml and we can relay messages here when needed. someday (hopefully 
soon) we'll have a communication forum that is reachable by everyone.

one would think there should be a more elegant way to force html 
to stay within a certain % or pixel size

I remember Carl has some code to breal scripts halfway intelligently.

Best way to suggest it to him (in this instance) is a Feedback to 
the blog.

I'd completely forgotten this group existed :-)

Just as a reminder to anyone else with a sieve-like memory: REBOL.org 
now hosts a mirror of the [web-public] groups in this world too. 
It has (in my opinion) three main improvements over the REBOL.net 
mirror:
1. all posts archived (not just latest 300 per group)

2 (therefore) permanent URLs if you need to point someone to a post
3. áll posts searchable

http://www.rebol.org/cgi-bin/cgiwrap/rebol/aga-groups-index.r?world=r3wp

http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=ean13.r
<--- did this one a year ago. it uses PDF maker to generate barcodes

I only test it on the screen under MacOS, where there is an automatic 
converter. Can someone test it on a PS printer?

Maybe box shouldn't be inside a path block, but be an instance of 
itself?

PostScript normally uses units of "points" for placing graphics on 
the page. I find it more convenient to work with centimeters. I got 
the following snippet of PostScript code from a public domain program 
called "GLE" which I believe is available at any large ftp site; 
I recommend this graphics program. By examining the PostScript output 
of that program I collected the following piece of PostScript code:


matrix currentmatrix /originmat exch def /umatrix {originmat matrix 
concatmatrix setmatrix} def [28.3465 0 0 28.3465 10.5 100.0] umatrix


What this basically does is rescale the page so that now all following 
commands will work as if the centimeter is the basic unit of length. 
This places (0,0) near the bottom left of the page and (21,24) near 
the top right of the page.


If you don't do this, then (0,0) is the bottom left corner of the 
page and (612,792) is the top right corner of the page (if you are 
using an 8 1/2 inch by 11 inch sheet of paper). These are the default 
PostScript units; 72 of these to an inch. 28.3465 to a centimeter, 
thus the numbers above in the last line of PostScript code.

AT can both be specified as a pair and 2 numbers.

I can't find the switch y-axis thing right now. Maybe a matrix is 
needed?

well, my postscript printer printed out a gray box!

again coords can be a pair or 2 numbers, also decimals.

just a basic one with text and some graphics.

how about pulling a "NeXT" and making a PS VID? : )

Gabriele is writing a PDF emitter for MakeDoc and QML.

I think Sun also made a PS window manager

I have a cool idea for PS with our Qwikis then.

Henrik, are you going to develope your ean13.r any further so that 
everything is there and saves to a file?   


http://www.isbn-international.org/en/download/implementation-guidelines-04.pdf

don't know how a ps engine will cope with this

>> view-ps-color orange
== [1 0.588235294117647 3.92156862745098E-2]

New version! PostScript is default set to DeviceGray with no colours. 
To set it to DeviceRGB, I made a command in the dialect for that. 
Try:
do http://home.tiscali.dk/john.niclasen/postscript/postscript.r

write %test.ps postscript [DeviceRGB page [switchy linewidth 5 path 
[setcolor 255.0.0 line 50x50 50x100 setcolor 0.255.0 line 50x100 
100x100 setcolor 0.0.255 line 100x100 100x50 setcolor 255.0.255 line 
100x50 50x50]]]

louis, the one on rebol.org seems to be a bit old. the one I have 
locally can generate bitmaps as image! in 1x, 2x, 4x and 8x size 
and vectors for PDF Maker. it can generate an EAN13 code with the 
correct checksum. it doesn't save to file, but it's only a couple 
of lines of code to do that

It seems, that Times has to be named "Times-Roman". Here on my Mac, 
I have "Times" and "Times New Roman" installed, so I'm a bit confused.

Fantastic work guys!
Graham, perhaps a better name for view-ps-color is to-ps-color.

Yeah, in QML we ran into the same font problem.  So what we did was 
make Times, Helv, and Courier forced to be the defaults, then allowed 
any font name to be called as bassed to a variable as the real name 
of the font.  On windows you can have font names with spaces "Times 
New Roman" for example.  By have the top three just be one simple 
word everyone can remember I figured it would make people happy.

Henrik, are you sharing that new ean13.r file? If so, do you have 
a link?

Well, the dialect doesn't take PS as input, it produces PS. A PS 
file can be printed from REBOL in a way, Graham showed. Like:
>> port: open/direct tcp://192.168.1.253:9100
>> insert port read %boys-0-36-length-weight.ps
>> close port


192.168.1.253 is the IP of the printer, 9100 is the port, where the 
printer get data.

The dialect, I'm developing here, is for making it easier to produce 
PostScript output from within REBOL. Next step is to make a converter 
from the DRAW dialect to PostScript, so any DRAW data can be printed.

And now I'm at it, learning a bit PS and all, it'll make sense for 
me to make PS output from my NicomDoc format.

Reichart, the thing, you're asking, is taking a PS-file as input 
and render it, like GhostView does. It'll take a bit more work to 
parse PS-files, but it's not impossible. I have no intension doing 
that for now though.

John, postscript uses a number of defined fonts.  Ignore the fonts 
on your system. The ones important are the ones in your postscript 
printer.

louis, check out http://www.hmkdesign.dk/rebol/barcode/

There are no docs, but I hope the demos are a bit explanatory

Henrik, thanks, I will play with it.  I have this great Mac sitting 
on my desk, but I don't seem to use it enough.


NOTE: I'm still tied to my PC, and TRYING to get away....so far it 
seems I'm held to just a couple of issues....I have not had time 
to write up the "PC MAC LINUX" chart I want so I can figure out what 
it takes for me to move over.  But the first big one is still a thumbnailer. 
 I use ThumbPlus.  If they were on Mac and Linux, then I think the 
move would be a lot better.  I use this about 10 times every day. 
 We can move this chat if you want to engage me on the Mac issue.

John, just reading that link you gave to a postscript document structure, 
and I think we should change the prolog to say 
%!
instead of
%!PS-Adobe-3.0
as the latter says that the document is fully conforming.

Looks like we need to terminate the document with a comment
%%EOF

the point of writing conforming postscript is that a manager might 
take that document and print it 2 or 4 up or whatever.

Just wondering whether it is preferable to build the dialect so that
postscript-dialect => postscript, or => draw

rather than trying to write a parser that converts draw to postscript.

I think the most common scenario for those of us wanting to do printing 
is to to compose a page, preview it and then print it.  This way, 
we have the one dialect that covers both bases.

Oh, agreed....................my thought was simply how many dialects 
we are all working with, and how this number will grow until there 
is need for a new approach.


For example, XML is a dialect of sorts, for transmitting discrete 
data.  PS for rendering information in 2D.  HTML for rendering information 
in such a way that those that are challenged can us verbal readers, 
or physically challenged can ID links and important parts.  MakeDoc 
for converting  few symbols to complex rendering instructions that 
can be represented by HTML.

Reichart, don't confuse language with dialect. PS and HTML are languages, 
not dialects (you can say that HTML is a dialect of SGML, to some 
extent).

I guess, the number of dialects is defined from the number of problem-domains. 
I think of them as the sub-languages different professions have. 
Doctors use their words, car-mechanics theirs, programmers yet other 
words and terms. So there might not be a limit for dialects, like 
there might not be a limit for new professions.

I think, it was Gregg, who pointed it out at last DevCon: Define 
a dialect, and you've solved the problem. Once you've defined the 
perfect dialect to solve some problem, the problem-solving code (programmed 
in the dialect) might just be 10 lines.

not if you hide behind a pseudonym!

But remember they'll only see the most recent 300 messages.

So the more popular a group is, the less the public can see of it.

Maybe we need a [web-archive] flag too for groups that will be published 
in full [reply in chat as this is off-topic for postscript)

New version of postscript.r uploaded! I've add the prolog %! and 
epilog %%EOF as Graham suggested. I also wrapped paths in the postscripts 
commands gsave and grestore, so transformations give less trouble. 
Try this:

do http://home.tiscali.dk/john.niclasen/postscript/postscript.r

write %test.ps postscript load http://home.tiscali.dk/john.niclasen/postscript/test.txt


You now have a postscript file "test.ps" produced by the dialect. 
It's content looks like this:
http://home.tiscali.dk/john.niclasen/postscript/test.png

To see, how using the dialect look in use, see the "test.txt" file.

The output postscript file from the dialect can be sent to a postscript 
printer, so no driver is needed.

The dialect is just a version 0.2.3, so it can be better!

now I'm imagining: this is really lowlevel stuff, but I think it 
would be neat to build standardized higher level primitives. a barcode 
is such a primitive. barcharts, 3D views and complex symbols could 
be other types of primitives. just brainstorming...

but it should also be consistent. a dialect with primitives? a library?

Developer libraries and standards are good! It's been a big part 
of my job the last 15 years or so making programming libraries for 
developers. If I could make money developing REBOL standards and 
programming libraries, I would use more time on it.

I think there are too few, then again, more might come if there was 
a consistent set of libraries. more than the current collection of 
scripts on rebol.org anyway

Let's see ... what is needed more in the dialect, before a DRAW -> 
PostScript converter can be made? Images! Something else?

How fills? You can fill a box with boxfill.

I was just having a play as well with the postscript dialect.

this is the source file which looks a little different