AltME groups: search

I've spent a lot of time with MDP, written a whole distributed application 
with pages based upon the principles of MDP.  The biggest mess in 
MDP is the need to make HTML pages, which is a fossil and pretty 
awful, but widespread.  People need HTML so we output that.  People 
may want PDF, or RTF or Postscript or MarkDown, or whatever.  Those 
parts will always be a mess because the formats of all those outputs 
are a mess.

By the way... Is there any news on the Right Text Formatting inside 
Rebol? Will it be in? or is there a special project for RTF ?

AFAIK RTF is ready, but I'm afraid we have to wait for R3 :/

(by the way, RTF = *Rich* Text Format)

I have done some text placement calculation for my RT-style (rich 
text). Result is 99% Draw code.

Graham, you should have a copy of in on your HD as lecture-forum 
use it to show the posts (search "rtd-styles.r" or maybe "rtf-styles.r" 
if it's too old).

RTF (Rich Text Format) seem to use the hierarchical datamodel too, 
but RTF solve the problem in an interesting way. My above example 
would in RTF be something like:


{\i0\b This text is bold. {\i This is bold and italic. {\b0 This 
is  just italic.}}}


\i0 means setting italic off, \i set it on. \b0 set bold off, \b 
set it on. A problem here seems to be, that you have to tell the 
condition of bold and italic for all text, and I don't like that.

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

Is there any RTF (Rich Text Format) parser  for Rebol?

hm, maybe this one: http://www.codeconscious.com/rebol/scripts/rtf-tools.r
:-)

Hi all,    Have any of you written a parser to handle .rtf files?


I am trying create a simple template file that I can parse against 
to identify Underlined, Bold, Italic, or Regular field values.


Example:  (Since I cannot Bold, Italic, or underline within Altme, 
please pretend to see what I'm saying).

 Config File: (when I typed the following using WordPad) looks like 
 this


Default Arial font 10 * Regular Courier New font 11 * Italic * Bold
Bold Italic * Regular Underline * Regular Strikeout
Regular Underline Strikeout
Bold Italic Underline Strikeout

	Same file when using Notepad to view:


{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fswiss\fcharset0 
Arial;}{\f1\fmodern\fprq1\fcharset0 Courier New;}}
{\colortbl ;\red0\green0\blue0;}

{\*\generator Msftedit 5.41.15.1507;}\viewkind4\uc1\pard\f0\fs20 
Default Arial font 10 * \cf1\f1\fs22 Regular Courier New font 11 
* \i Italic * \b\i0 Bold\par

\i Bold Italic * \ul\b0\i0 Regular Underline * \ulnone\strike Regular 
Strikeout\par
\ul Regular Underline Strikeout\par
\b\i Bold Italic Underline Strikeout\par
\cf0\ulnone\b0\i0\strike0\f0\fs20\par
}


I can guess that fs20 refers to the default Arial font, while FS22 
is the Courier New font.
\i italic
\b bold
\ul underline
\par may mean newline
 

I am not sure of what I want the parser to return the results as 
and was wondering if someone has already made a generic parser of 
.rtf files, or can point me out to info regarding them?

Wow, I never realized how incredibly extensive RTF is.


The ONLY thing I need is to identify the character position and length 
of Regular, Italic, Bold, Underline, or Strikeout and the text, so 
in my above example, maybe the parser could return this:  Note: birsu 
stands for Bold, Italic, Regular, Strikeout, Underline.
Line	Pos	Len	birsu	Text
1	1	24	..r..	"Default Arial font 10 * " 
1	25	(n)	..r..	"Regular Courier New font 11 * "
1	(..)	(..)	.i...	"Italic * "		

1	(..)	(..)	b....	"Bold"(newline)			<-- note \i0 turns off itialic

2	1	14	bi...	"Bold Italic * "			<-- note \b is still in effect from 
a previous setting

2	15	(..)	..r.u	"Regular Underline * "		<-- note \i\b is turned off.
2	(..)	(..)	..rs.	"Regular Strikeout"(newline)
3	1	(..)	..rsu	"Regular Underline Strikeout"(newline)
4	1	(..)	bi.su	"Bold Italic Underline Strikeout"(newline)

Ideas on how to do this as a start?

First, you may need to spend some time with PARSE, so you're *really* 
comfortable with it. Taking on something like RTF--even just a subset--is 
going to be a sizable task. I would start by identifying the escapes 
(backslash words) and figuring out how you're going to maintain state 
as attributes are applied and removed.

Hey Gregg -- That is just what I've been doing.  I have identified 
the following:

1. That all printable \ { and } will show up in RTF as backslash 
along with the special character like \\   \{  or \}  any remaining 
\, {, or } will be RTF commands.

2.  {  }  and ; identify groupings with the open brace and terminating 
the group with close brace within the RTF.  The semicolon is used 
to terminate sub parameters for a particular command.

3.  \xxx  will always identify a particular command with an optional 
number appended to it.  Example: \b  means bold while \b0 meand bold 
off.


What I am toying with is to define simple rules to break apart a 
string of the RTF commands and embedded text into two parts, the 
command part and a parameter part.  (some parameters may be a block 
of multiple values).


I'm studying the Parse command to see what I can do simply and progress 
from there.

Ashely, Gabriele and Romano did a RTF style

problems with tooltips

 ... note that since 11-Mar these and other problems have been solved 
 in the latest RebGUI Beta 2 builds.

Isn't Ashley making a Chat widget?

 ... chat, icon (SVG) and a simple tree widget (suitable for request-dir) 
 are in development.

RTF Style ... possible to use it in Rebgui

 ... RebGUI had this initially, but it was more trouble than it was 
 worth IMHO as (a year and a half ago) TMD (Text Markup Dialect) was 
 going to make it redundant. I believe R3 includes rich-text support.

http: ...

 ... I based my %render-rich-text2.r on this code but improved upon 
 it dramatically as we (shadwolf and I) were trying to use it to render 
 MD2 and MDP documents. Remember all the MDViewer and MDP-VIewer stuff 
 that was floating around a while back? ;)

For writing a RIA research article, I've spent 10 hours studing Curl, 
that didn't make me an expert, but so far:

1. I like the content-centric programming, it's kind of like MakeDoc 
+ RSP + RTF.

2. The macro facility seems powerful, which makes homemade DSL possible, 
I guess.
3. APIs seem complete.
4. The 2D and 3D rendering engine uses hardware-acceleration.
5. It's a Functional Language.
6. Unicode, Yes, even Curl supports Unicode.

Like I said, I am not an expert, so any of the items listed above 
could be wrong. Here is a DDJ article http://www.ddj.com/dept/architect/184413224

would you consider it a good idea for 3rd party developers to make 
an RTF importer or will RT do that?

then i think ritch text is based on an old idea replaced by a more 
powerfull one....  based on area-tc way to work redoing the richt-text 
area to bring in it the write cncept is not impossible to be done. 
and what better way for a user to use a markup language not knowing 
you use it (MS word and all other advanced tet editing tools does 
that constently. from RTF to PDF)

thi sis the link http://gchiu.no-ip.biz:8000/md/creategoogledoc.rsp?gdoc=simple-letter.rtf&patientid=2832&encounter=none

this is the request


GET /md/creategoogledoc.rsp?gdoc=simple-letter.rtf&patientid=2832&encounter=none 
HTTP/1.1
Host: gchiu.no-ip.biz:8000

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.2) 
Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729)

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://gchiu.no-ip.biz:8000/md/Listgoogledocs.rsp
Cookie: RSPSID=QZPTPCZIWWMMYBKWHWRQETGM

its actualy not that complicated... in the sense that you must only 
know the coords of the boxes (something like sub gobs) and then when 
the text reaches the lower right corner of a box, a decision is made... 
either the box can stretch a little or you jump to a new box to render 
into.


implementing columns thus becomes a specific case of a generalized 
solution.  just provide two sub gobs and texts flows from one to 
the other.


note that the text boxes are independent from paragraph... these 
boxes are the actual "page" area which the rtf uses to calculate 
bounds and word-wrapping and offsets and such.