AltME groups: search

so ppl now to  dl MDP-GUI 1.4.1 all you need is to append a rebol/view 
console and copy/paste  do http://www.rebol.org/library/public/repack.r

that to ashley and all the beta tester contributors idea teasers 
;) that allow me since november to heavyly enhance and make progress 
this app ;)

next step to MDP -GUI is to be made using RebGUI and encaped (wrapped) 
 by GREBOX  and a cute little installer for non rebol.org download 
;)

thank  to ashley and all the beta testers, contributors, idea teasers 
;) that allow me since november  2004  to heavyly enhance and make 
progress tMDP-GUI ;)

Shame on me, nice job to all working on MD, MDP, GUI, and Ashley's 
MD-Viewer and RebGui.

I'm thinking about refining how emiters for MDP can be written. How 
about this:
- The parser part will stay as is.

- There will be a generic scan-doc routine that can handle: string!, 
file!, url! and block!
  The block can be a mix of string!, file!, url!

- Than there will be one generator loop that loops over the output 
from the parser (the intermediate format)

   This loop has a gib SWITCH statement for all intermediate format 
   words generated by the parser

- The particular generator will be provided in a context to the GENERATOR 
function and than only needs to
   contain the function stubs.

What do you think?

Robert : For the structure, you can look at my 'Easy-Doc prototype:
http://rebol.dev.fr/view.php?sid=141
It works with 3 sets of modules: readers, parsers and writers. 

'readers have to supply a text string to parsers (ie. MS-Word files 
are scanned for text),

'parsers build a block in intermediate format (there is a makedoc 
parser,)

and 'writers output the result either in file or on screen (VID / 
html / pdf / rtf / swf).

Thanks I take a look. Well MDP is quite old and IMO needs some refactoring 
:-))

Did some one found a way to have a FAST Rebol editor.  I did remarked 
that the cursor is slowing to a crall on big texts in MDP-Gui.  It 
is also quite slow with VT-editor or ion-pe, or even with this very 
small editor in alt-me, the one with which I write now.  Tcl, for 
example, does have two tk texts widgets (text and C-text) to properly 
handle text.  Could there be a way to have a fast editor in Rebol, 
something that could handle a text of 100-200 pages in a manner that 
is as fluid as something like notepad.  I am a newbee and find MDP-Gui 
to be a nice course on how to play with text rendering.  Although 
I would rather have only one window, and alternate from the editing 
window to its rendered view.  Full window is nicer to write text. 
 Side by side is nicer to compare marked-up text to its rendering, 
but after a while, we know the rendering and simply want the fuss 
a a nicely rendered text.  I am fidling with this idea, but do stumble 
on the editor part.  I dont even know who is the culprit, area or 
the ctx-edit.  If someone has a simple solution to this, he should 
post it.

One pist could be to systimatically clone itch widget having them 
in two ways the first one would be a redered form based on face the 
other one would be based on field and will have stricly the same 
setting than it twin  If the rendered widget recive a mouse down 
even then we substituate the redered widget base on face by it's 
clone base on field  once this last receive a key  enter  event type 
we affect the clone content to the redered widget .... But with this 
system pref will be verry slow !!! and memory consumsion will be 
twice important ...

Last thing the pointer is slow on hudge text because of this F***King 
mad system base on caret  to handle the cursor position you store 
the current text that belongs after the cursor Writing and rewriting 
every time into this caret buffer the most part of the document is 
super slow  !!!

1- caret repositioning in a big text and 2- rendering text in the 
same window that we edit

will be to settle it by inverting the problem : edit text in a console 
or an editor, and have the console or editor to parse the text and 
transform it according to the commands it find in it.  I did search 
for that.  The closest library to such goal I found is either scintilla 
for an editor or tkcon, the adaptable tcl console.  But all this 
suppose that we dispose of Rebol source code to put the language 
parser in it, right (like ion.pe)?  So we would have to rely on R# 
(open source) instead of Rebol?  Either way, it does seem that handling 
the problem well is pushing us out of Rebol; not a charming proposition. 
 I am just expressing my frustration of not being able to solve a 
problem that is not existing in other languages.  As a priority, 
I do think that the repositioning of the caret is the show stopper. 
   I could live with NOT rendering in the SAME window as the editing 
window; I consider it a form of cosmetics.  But I can hardly ask 
people to start edit documents in a lame editor that takes seconds 
to go from page 120 to 130.   It would be nice if RT could find a 
solution to that, as it would ease the way to specialised IDE's, 
Ide for Rebol and the many specialised dialects.  By the way, did 
Ammon Johnson finished to wrote his REBOL-based IDE, called RIDE?

If you want a renderer and text box on the same page, just throw 
a wrapper around http://www.ross-gill.com/make-doc/and have the 
results show in an i-frame. piece of cake

allen Iframe ? and why not java ... are you joking having rendering 
and writing in two panes is yet possible with REBOL/View (see MDP-GUI) 
What I seek for is a merge of both systems Like MS Word But even 
sharper and made Fully in REbol/view code no external call to other 
idions technology :)

Exactly dideC but MDP-GUI yet renderise the documentation in VID 
like mdviewer. Why to see it in rebol/vid simply because it better 
IMHO to have a render preview and the MDP raw format in same window 
...

Now next evolution of the rendering system mut be a fusion betwin 
the MDP raw format and the MDP to VID renderer.  In order to have 
on one panel that display the doc. Ths will lead me to write a multi 
file handler as we have only one panel for each open document. Save 
wil be made by default in .txt files and you still get the possibility 
to render HTML when you judge the document is publicable

Someone asked me about NicomDoc recently. I just added font support 
and escape mode (to turn on and off using backslash as escape character), 
changed some definitions and fixed a bug or two. I'll add options 
and make it version 1.0 targeted at HTML output. Should happen within 
the next days, where I'll release it.

I came to version 1.0 of NicomDoc. See Announces! Next I will specify 
the RebXML tags used by NicomDoc, which will be needed, when making 
output engines for other formats than HTML, and to make input engines.

I would like to create an IOS Wiki application based on MDP syntax. 
So it should be a Wiki I can use as IOS user and browse / edit with 
some kind of editor. Here are some thoughts (unstructured). I'm looking 
forward for you comments.

1.) How to handle CamelCase links and content?
	- One approach is to create a TXT file for each CamelCase word.
	- Than new files need to be autoadded to the fileset or

 - The editor recognizes CamelCase words and creates new files, this 
 implies the the internal
	  editor is used.


2) MDP needs to be extended to translate CamelCase words into links 
that MDViewer can handle


3) Filesync clashing needs to be integrated into IOS with DIFF/MERGE 
option based on the synced TXT files

1a) i use "%" as marker, not camel-case. and store everything in 
file. currently i use this to add relative links to make-doc-pages

1b) a reblet could check all links, and suggest to create missing 
files.

2) i use the "%"-translator as a preprocessor, so i have not to patch 
the make-doc*.

3) Have a seperate work-folder for each user. so auto-downloads would 
not overwrite it. and then you can use your prefered merger if there 
is a clash. its all files then.

3) one public folder and one for work. if files clashes, both have 
their original working version and can merge.

you edit in work-folder and when done publish to the public folder. 
with some reblet which shows you which files you changed, and maybe 
checks links.

I'm getting ready to make some changes to the make-doc spec for my 
own use to include some extra formatting for bible verses.  I want 
to be able to put in some specs that allow for wrapping of verses 
and a horizontally wrapped contents spec to go to a specific verse 
in the Book title.  I haven't looked at the code yet so I thought 
I would jump here and post this and hope for some quick pointers 
on how I should approach the code before I begin.  Specifically what 
parts of the code will need to be altered or what I should look out 
for and maybe what kinds html tags should I implement for the wrapping 
of verses etc..

Paul, One thing to keep in mind is that you should want to leverage 
html stylesheets. 

In your make-doc version add the reference to the class then let 
a .css determine most of the presentation parameters.

For example, I wanted to be able to add a question and have it presented 
with a heading very similar to a note box

but to have a different label i.e. "Question" and a distinct look.
This change was required to parse it 

 ["=q" | "q:" | "question:"] text-line (emit-text 'question) |

from the input stream. This emitted the html 


 question [emit [{<p><div class="question"> Question: &nbsp;&nbsp; 
  } doc/2 {</div>}]]


Change the make-doc script you are using to emit a reference to your 
stylesheet instead of inlining it.

I put this in my css to present a question in box that stands out 
(for me)
  div.question {
     	padding: 10px;
        background-color: linen;
      	font-size: 14px;       
     	font-family: Helvetica;
        border: 6px groove gold;
		width: 90%;
  }  

The reason for .css is that now you can change the stylesheet and 
don't have to change the html or 

re-generate it. If you want your question box to tan instead of linen 
then you just change your .css

If you have something you feel strongly about you can create a soapbox 
style.
For more on this see http://www.csszengarden.com/

p.s. when you change make-doc, clearly identify the lines that you 
change with comments so that when 

you get a new version you can retrofit it and get the benefit of 
the upgrades.

Thanks guys I will give it a shot and let you know how it goes.

I'm close to have ended the MDP-Browser software. Lots of improvements 
have been done and makes it a tool a step forward MDP-GUI.

what is MDP-Browser ? MDP-Browser is a software designed to work 
with IOS server  in a wiki like way. MDP-browser is a merge betwin 
MD-Viewer and  MDP-GUI some kind of nutural son of those two programs. 
It's similar to his parents but entends truelly the capabilities 
of both program.  First of all VID rendering have been improved (bullet 
points  are drawn using effect/Draw and not any more ascii chars), 
Viewed text resizing exist

it handle the window resize too, Toc area is inserted into the same 
window and the entry clicking now scroll allways on the top the viewing 
area, MDP-Browser can produce HTML docs by just clicking one button 
the HTML  is stored localy and can be published back to the IOS server 
using the IOS REBOL/link client plublishing system. Editing of a 
document is possible existing on the IOS server or new we can store 
locally or publish it back (if the fileset yet exist on the IOS server).

you have builting doc history that allows you to browse several files 
and get back to them...

Paul, 


For what you have described, you may want to use navigation like 
that provided 

by a java script outline tree. One example is http://www.treemenu.net/
  


My plan is to soon make a make-doc revision that takes as input the 
NoteREB data from the
script by Alain Goye.   http://alain.goye.free.fr/rebol/NoteReb.r

Then generate an html site using the same tree structure as the NoteREB 
source file. 

Each page from the NoteREB data file is to be make-doc'ed into a 
separate HTML page.


NoteREB uses a very simple REBOL block structure to hold the content 
and sub-blocks.


If you want to change a page, change the source page, save the file, 
and click the new

reGEN button.  Alain's tree makes the management of the source much 
easier than methods
I had been using before.


I have used this approach for taking easy vid format and making an 
easy vid presentation 

format.  That means that it makes VID faces for each page and allows 
the execution of sample

code by clicking on it. Seems to work well and I plan to put it on 
the script library 
after View 1.3 is released and I can verify it works OK there.

Hi Robert, That is a VERY nice site.  I am continuing this look at 
NoteREB because it manages the source and the tree structure for 
me. For what I want, a tree structure is important.  This approach 
can use makedoc2 or any other variation to make-doc the page.  The 
recursive tree approach combined with any already written make-doc 
function makes it work well so I'll  be done soon  then will have 
a longer look at your site and approach. Thanks.

The make-site approach is based on a directory tree on your disk. 
All path's you see are actually directories, and each dir has only 
one file, an index.html That's why you don't have to hack in any 
document name.

Mike, that Treemenu looks like the same one a site that I now frequent 
uses at http://www.peshitta.org/Which is good but I need something 
that might be a building block to a full blown viewer at some point 
in the future.  For example there are other bible viewers such as 
e-sword but I want something that can support additional book names 
and might make the makedoc extended to support a format as that and 
maybe make a conversion tool that will take some of the popular bible 
formats and output them to text and rthen back in through a tool 
and output the makedoc format so that the output is still compatible 
with makedoc.

I have been inspired by the make-doc line.  Robert's rendition is 
fantastic.  Love the whole site in one file thing.  Keeping the CSS 
out of the rendered html is good, using classes.


MDP-Browser sounds really cool.   a makedoc/spec browser for makedoc 
formatted scripts.


I have been playing with a document format that I call nulldoc, which 
is mostly a set of generaly rules about how plain text documents 
have been formatted traditionally, or how plain text copied from 
a web browser can look, and I started developing a set of broad regular 
expressions to markup plaintext.


based more on what I wanted than what I actually had, the rules I 
came up with go something like:

two blank lines begin a new nulldoc document (segment)
spaces/numbers/letters/symbols represent lists.

tabs/spaces at the beginning of the line denotes code/hierarchy. 
 

tabs that are trapped by non-space on both sides means tabular data.


I differentiate between code and hierarchy indentation by short-circuiting 
code switch with #:


	code section

#	numbered section


I wrote a web page that reads the KJV aloud using an MS Agent character. 
  Used a control from MS for a menu   I had it voice-activated, but 
that was a drag so I used "web navigator control"  stupid name for 
a menu.  I think it's still up at http://members.cox.net/rovingcowboy/kjv/
 probably won't speak unless you have sapi 4 voice installed, though.

I'm using a new emit-verse function I created but want to for example 
change the line to display multiple colors and formatted text on 
one line

For example if I post a verse such as John 1:1 "In the beginning 
was the Word......"  - I want to be able to format the book and verse 
separately from the verse text but still group it together in a \verse 
/verse type output

Paul

If you want to stay with some minor changes to makedoc2, then just 
copy what is provided for NOTE.
Add your verse to the data

\verse author verse
content text
/verse


This is assuming author and verse will be text strings (no spaces). 
Unlike NOTE you need to parse the text after \verse to get the two 
parts so that you can plug them into the output where you like.

Note uses text-line:  [any space copy text thru newline]

which puts everything on the line from the identifier tag \NOTE into 
the variable 'text


One direct way to get the values author & verse from the line is 
by reparsing what text gives you 
that is you let the \verse processing work the same as \NOTE


  | "note" text-line (emit note-in text)   ; this is an existing line

  | "verse" text-line (emit verse-in text) ; this will be added to 
  support verse
		
		note-in     [emit-note doc/2]    ; this is an existing line

  verse-in   [emit-verse doc/2]    ; this will be added to support 
  verse

emit-note then has an emit-verse parallel

emit-verse: func [text] [

 words: parse text none   ; Because text-line was in the rule for 
 verse it contains author and verse

 emit [<div class=verse-box><p class=author> words/1 </p> "&nbsp; 
 " <p class=verse> words/2 </p>]
]


and because you should handle the /verse tag similar to /NOTE which 
should close the html table and the div.

In the above that author and verse are defined as classes so you 
can leverage stylesheet independently of makedoc.

I see, and I understand and accept your position regarding the "low-level-ness" 
of the dialect.

Sorry for the confusion, but I left the line setting the default 
position commented so you could uncomment it *if* you already had 
a "current layout position" variable handy. I thought any position 
would be better than no position.

note, of course you are free to do these changes and distribute them. 
v1 is public domain actually :) (not even bsd)

well, i always output pdf from programs, and the default size does 
not help much there, but i'm not saying it does harm either. if everyone 
else wants that, then go for it.

On balance, (and since I discovered the resuling PDF was a bit large), 
I think it's not worth me forking and complicating the dialect.

there's also the issue, that if we allow specifying a binary! instead 
of image! and interpert it as a jpeg file, then the dialect will 
have no default to use for the size, unless we go on and parse the 
jpeg header, or load the jpeg into a image! temporarily just to get 
its size. (binary! would have the added benefit to work also in Core, 
however that would only be for jpeg images)

Those are details. Any default is still better than an error (if 
trying to make the dialect forgiving and friendly). At least the 
user will see something appear, even if it has the wrong size and 
in the wrong position.

the pdf format only supports adobe encoding, windows encoding and 
mac encoding. the pdf maker only uses windows encoding (which is 
basically latin1).

and which windows encoding? Maybe can janeks just set some flag or 
something which specifies his encoding in the file.

oldes: unfortunately, no. he has to specify the encoding in the font 
description. the only "built-in" encodings are Adobe, WinANSI (latin1) 
and Mac. I think adobe is a variant of latin1.

to support unicode you have to create a multibyte encoding for the 
fonts, and the spec does not give any detail on how this works.

that is, if you are using "Times", and you use more than 256 different 
characters, openoffice creates a pdf with two fonts, "Times1" and 
"Times2", each with at most 256 characters.

so i will either need to figure out how to create a font encoding 
description that works for utf-16 (but i guess it would require a 
huge table, and so would make the documents big), or i'll need to 
use the same technique as OO

I've just downloaded pdf-maker.r and I'd really appreciate some help 
to get going quickly. I've rotated a page +90 to get into landscape, 
but the texbox still  renders the text in the same way as portrait. 
Do I have to rotate each textbox too?


I also downloaded pdf-tables.r too. Does a  table handle a page break 
itself?


Talking of page breaks, in a long table which spans many pages, I'd 
like to render the column headings on each new page. Is there a variable 
I can track or an event I can listen for that lets me know that the 
text is about to flow to the next page.

Thanks a lot.

pdf-tables lets you provide a function to create the pages, and you 
can still modify the output. so, you can create the headings separate 
from the table itself.

also, since the result is a block of pages, you can modify the result 
and add anything after the layout process.

Before I look into it, I thought I'd just ask.  We (the graphic desgner 
actually) got sent a logo graphic inside a PDF (and that is all that's 
in the PDF).  Is there an easy way of extracting the image?  I'm 
not a huge fan of selecting and cut'n'paste as it may lose sizing 
etc...  More curious than worried.

Well, I hacked it...and have no clue if what I did would work the 
next time :)

postscript and pdf are similar formats and store images as either 
binary or as text.

Depends on the PDF editor and how it was saved.
Yes, it can be compressed.  Yes, it can be protected (encrypted).
It can also be just PostScript at its core.

Reichart PDF was created in the way no executable postript code could 
be possible (no if no jumps no execute AND no write to disc) That 
is main advatage of PDF. Anyway it is possible to PDF contains tons 
of shit never would be imaged on page (old versions of documents 
for example).

Graham, Thanks for the reply...I've been working on the house so 
my computer has been down for a few days...anyway:

I have found some utilites to extract images and text but I'm building 
a tool in rebol to coordinate the conversion of pdf's to text and 
extracted images, to edit them, and to upload. I was hopig for a 
rebol solution to incorporate it all into one app. The tool will 
be used by non-tech so I wanted it simple as possible.

How do these extaction utilities work? Are they no parsing out the 
image data?

depending on how the PDF file is built, extracting text and images 
could be trivial, or very difficult.

Looking at the files in a text editor I believe I can see were image 
data but where it exactly starts and ends I'm not sure. I tried to 
cut and past the data for a small image but I could not load it in 
rebol...just took a shot to  see if it were in some staight forward 
binary format.

I haven't spent any time on formulas. I don't have a need for that, 
and since it's quite time consuming to do it as good as TeX, I never 
really planned doing it.

it's not hard to render math. it's just that TeX is very well tuned 
(uses the correct spacing between things), which is just a long list 
of rules and parameters. One could get that out from the TeX source... 
otherwise it just takes a long time to tweak all the parameters to 
get a nice looking result.

then, there's the problem of the fonts. TeX has its own fonts which 
are designed correctly. TTF is not even close to what MetaFont can 
do, and the standard symbol font is not as good as the TeX fonts. 
Even if I added a good formula renderer to the pdf maker, without 
a good font it wouldn't look very good anyway.

I am looking at that and trying to learn how to do things, but it's 
quite complex.. well I got some of the basics out already and am 
slowly forming my own pdf

uh, I tried cell-decor and decor probably not on the beginning ... 
ah I only got it now cell-decor is name of word that defines 'decor 
as a rure

unfortunately the PDF format does not have direct support for encodings 
except for the default windows encoding, the default mac encoding, 
and an adobe encoding; they are all variations of latin1.

( about decor I tried in table cell  decor [ set-fill 50.50.50 ] 
and there were no errors  -- but I don't see any background .. )

do you think that /Encoding /Differences [
200 /Ccaron
232 /ccaron
] 

doesn't work because it's PDF-1.3  and in that example it's PDF 1.6, 
maybe this is more recent feature?

you could change the header though and just try to set it to 1.6 
- though i don't know if everything else will work then. (going from 
1.3 to 1.4 didn't require any changes iirc)

I tried that and nothing happened then I changed the encoding object 
headers to <<
/Type /Encoding
/BaseEncoding /WinAnsiEncoding
/Differences [
and got error while opening (18)

in the pdf file ... I discovered one good news now ... I need csz 
( like ch sh zh in eng) .. I saw  that zh that I thought before doesn't 
have a glyph in standard fonts didn't make it to the generated pdf 
and if I add it by hand and update length of stream Zh works ... 
so now only Ch is the problem .. (because it's not represented in 
win1252 , the character with same code 200 in 1252 is E (arrow) È

so if  that differences would work and exchange 200 with Ccaron it 
would all work

I found an example of PDF from Haru library which uses all ISO8859 
encoding 1 - 20 ... it is version PDF-1.3 , it does use the /Differences 
for each encoding, it also defines widths for them, I intend to look 
at it and somehow transfer it to pdf-maker .. but I am not sure how 
successfull I will be as pdf-maker seems quite complex beast

I think not, and it's not a simple problem to solve.. PDF looks very 
horrible in this regard to me

it's very nice, but because of 1 letter that I can't generate in 
it Ch .. you have it too probably .. I need to find another solution 
.. and I have invoice nicely made in pdf-maker already

I need it today .. I have most stuff done and wanted to release app 
this week , so I can't afford to be stuck on this for days or weeks

let me know if you find out that a new version of the format supports 
unicode or that there is a simple way to implement it. to me it looks 
like the only way would be to create your own 1 or 2 byte encoding 
with the glyphs you use, or to do like OpenOffice does - it creates 
a separate font for each set of 256 different characters and then 
selects the correct font for each character.

I think solution for other encodings is by using that /Differences 
and defininf the glyph names . I looked at how Haru PDF library does 
it and it uses this method, but I wasn't able to make it work in 
my example ( but pdf-s are very complex so there is a bunch of parts 
that I didn't understand ). At the end I started writing binding 
to Haru, because having those characters is cruicial for that app. 
I can't make app for my country where invoices aren't able to display 
those characters.

I had a quick look at the source code for the demo pdf .. and decided 
that it's too hard to grok.  We need some clues and from that someone 
can write something for users.

ahh... well, I just assumed it was like PS and View

and all measurements are in mm ?

the x and y for images are there so that you don't have to use a 
translation each time :)

that does both left and right justification?

so if you have a dictionary, you can preprocess your text and just 
output that.

what you can do is create a stream of text, and then flow it across 
multiple text boxes, or multiple pages.

so that means you must have headers and footers too?

so, it gets rendered inside the first textbox, any text that does 
not fit goes to the second textbox, if there is still more text, 
a new page is created and so on.

you can have different templates for even and odd pages.

as you see, it determines the image size, then sets the text margins 
so that you can make it flow around the image. it's a "trick" but 
it works if the image is not fixed within the page but moves around 
with the text, and you know it won't be split across pages.

you can use a vbox [ ... ] and put any graphic command inside it.

I tried this 

			append new-page compose/deep [
				textbox 10 10 100 100 [
					image 0 0 40 40 (load %247logo.png)
				]
			]
and not seeing any image in the pdf ..

graphic commands such as image are separate from text commands. inside 
a text "context", you can use box or vbox to enter a graphic "context". 
(also, you don't need the compose, as the dialect will try to evaluate 
arguments anyway.)

So:

    textbox 10 10 100 100 [
        box [image 0 0 40 40 load %247logo.png]
    ]


The difference between BOX and VBOX is that the former is treated 
like a character, while the latter is treated like a paragraph. (So 
you can have the former in the middle of a text line.)

When I use this command, I don't get an image, and my 13 page pdf 
stops at the first page

right... i don't do a coordinate transformation, that's the reason 
for xbl and ybl in the above snippet

v2 was done between 8-Aug-2006 and 17-Nov-2006

no. v1 does not flow text automatically across pages, does not allow 
putting graphics within text, does not have the TeX engine, and so 
on.

so Cheyenne already had v1 loaded and didn't load v2 for me !

I think the main reason is that v2 was never really "finished" and 
published as such. it's missing many little things (though, it should 
do all that v1 does and more... it is slower though as it's missing 
optimization and the ability to turn off the TeX engine when you 
don't need it)

text and bezier curves :)