AltME groups: search

distinguishing between [] and () in a writer's mind seems very logical.

Lists in English are now: Item 1, Item 2, and Item 3.

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

and has you notice it (cause you are very clever) both format have 
no format heading in files like =MDP or =MD2 at the very begining 
of the .txt file witch countains the

has the flag are the same how user can make the difference betwin 
one and other ...

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 ;)

GRaham =url or =image or /table \table are not formated the same 
way in MDP and MD2 ;)

MDP formated tables just crash MD2 engine and vis et versa

if you modularise the parser and rendering engine, then you can add 
in Geomol's version as well :)

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

Graham I could add Excel and Word too but that's not the main actual 
purpose IMO

sources are freely downloadable and modificatable If your challenge 
is to merge them why not

but the resulting app will be very bogus , veryheavy  and very slow 
....

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

NicomDoc has things from MD2 and things from MDP + things really 
new

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

I guess one could choose to ignore the colouring and just pass it 
through

but once again in the very futur things like that could be added 
with full perf and until this time we train our selves on simpliest 
format (simpliest for the VID statement at least)

I wonder what the proportion of users are for mdp and md2

so I can say that each of them have is own duty asigned MD2 to release 
quick and not very very sofisticated text MDP for articles with more 
sophistication in it ...

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

Color Text (Rich Text). One week ago I talked to Carl here about 
various topics and reminded him of rich text, he said it is important, 
so I put together few notes we produced in the past and he noted 
that he has something slightly different in mind and that he may 
say publicly something to it, so let's hope he will do so ...

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

and this helps you to see what direction the MDP-GUI project is taking 
I hope this 1.3.4 version will be at your taste. :)

Okay, I downloaded makedoc2 from rebol.org the other day and I still 
haven't figured out how to create links. In makedoc all you did was 
"url=http://www.rebol.com"REBOL" " but that just shows up as text 
in makedoc2. Could you help me out?

So, I could just edit the HTML file and add it afterwards?

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.

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

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

And the output: http://home.tiscali.dk/john.niclasen/nicomdoc/example.html

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

and wiki rendering like to ... it's closer from IRC or chat or web 
php/forum it include Smyleys ;)

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

what's new : - Better rendering images and tables support. Try to 
load the default make-doc-pro.txt that come with Make-Doc-Pro

[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!

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

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

Created this group for comments and suggestions regarding the web 
mirror for this AltME world.

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

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.

all you need to do is insert <br> as you parse each conversation 
and limit each line to some reasonable length

I do:

write %test.ps postscript [page [path [linewidth 10 at 72x72 box 
72 72]]]
and then open test.ps with Finder.

I guess, linewidth mean nothing in that example and can be left out. 
Sorry about that!

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.

so both "at 3x3" and "at 3 3" can be used?

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.

geomol, and BSD license

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

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.

It's possible to use all different kinds of fonts. On my Mac, I have 
e.g. Papyrus, and combining fontnames with -Bold, -Italic and -BoldItalic 
is ok.

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.

Also, let me confirm something, can I take any existiing PS file, 
and simply pass it to this, and it will render it?

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.

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.

The prolog is quite important to allow document managers to manage 
the postscript file properly.

It was interesting to note that postscript file managers can pull 
out the colour graphic pages and send them to be printed on colour 
lasers, and let the rest be printed on the monochrome lasers.

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

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.e. there is no common ground between PS and HTML and so on.

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.

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.

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

Yes, good ideas! It's not the meaning, that people should write in 
the postscript dialect directly. Building higher level dialects and 
primitives/applications on top of the dialect is the way to go.

that's true... maybe it would be better to approach it through DRAW 
and let postscript.r do the dirty work

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.

and slim.

and steel.

and clipping ... argh, tough one, me thinks.

and matrix

And Gouraud shaded triangle (if anyone uses those).

test: form ps [
	font Times-Roman 40
	linewidth 0
	at 72x720 "REBOL PostScript Dialect"
	at 72x716 line 520x716	
	font Times-Roman 16

 at 96x680 "With this dialect it's possible to easily produce PostScript 
 output."
	font Courier 24
	at 96x600 "You can use different fonts."
	font Times-Roman 16
	gsave
	at 120x550 rotate -30 
	"Make"
	grestore
	gsave
	at 160x450 rotate 30 scale 2 4 "transformations"
	grestore
	at 96x400 "And do graphics:"
	at 100x320 box 200x40 stroke
	gsave
	at 180x240 rotate 20 
	setgray .6 
	box 100x80 fill
	grestore
	at 150x250 line 200x290 180x305 194x340
	font Helvetica-Oblique 12
	at 72x72 "Postscript is copyright Adobe."
]

Good work! And a very fine alternative. This is the time to deside, 
how the dialect should be formed. Situation is, I had no experience 
with PostScript before starting this dialect, so I have no feeling 
about, how the dialect should look. If only there were an SGML definition 
for PostScript, but the closest we come to some rules is the DSC 
(Document Structure Conventions).

As long as we can satisfy out aims of text on paper, and some graphics 
...

We need information about, what can be inside one path, and how they 
are used in other PS files.

In my lates PS output, there is also a problem, where the box and 
the filled box is made. The box ends with a closepath and a stroke, 
but there is no newpath to start the next. I think, that's not 100% 
correct, but it seems to work.

presumably, stroke, fill, and show close the existing path.

A good dialect is one with some simple rules, and where it's difficult 
to produce something wrong.

I'm too tired now and am going to bed. Good night!

no, the barcode is already working fine. it's the position of the 
image on the paper and general arrangement of the code that needs 
to be worked out

Thinking of what John said, I suspect if you try and automate the 
newpath etc, you'll get into problems.

at least we gain by .. losing the rpn notation, and also using pairs 
instead of two numbers.

actually only the text was harder because in PS you point to a position 
and start writing, where you in PDF-maker need to define a text box 
before writing

works fine with barcode readers. have tested with both cheap and 
expensive ones. just need a good printer

and produces this postscript output