I was able to convert the JET documents to word. It wasn't that
difficult. It must have taken me 30 minutes. I wrote a program to
convert the raw text and write to a PETER file. Then used wintergrate
to import to DOS. Then used Word to to add fonts. Below is the program.

0002: OPEN "TW.MICHAEL" TO F.TW ELSE STOP
0003: OPEN "PETER" TO F.PETER ELSE STOP
0004: CR.LF = CHAR(13):CHAR(10)
0005: SPC = ' '
0006: STMT = \SELECT TW.MICHAEL \
0007: EXECUTE STMT
0008: LOOP
0009: READNEXT ID ELSE EXIT
0010: READ R.TW FROM F.TW, ID ELSE R.TW = ''
0011: NO.OF.ATT = DCOUNT(R.TW,CHAR(254))
0012: FOR A = 1 TO NO.OF.ATT
0013: IF R.TW<A>[1,6] = "\RULER" THEN R.TW<A> = ""
0014: NEXT A
0015: R.TW = CHANGE(R.TW, CHAR(253), SPC)
0016: R.TW = CHANGE(R.TW, CHAR(254), CR.LF)
0017: WRITE R.TW ON F.PETER, ID
0018: REPEAT
Bottom at line 18.

frosty wrote:

"mdsi2000" wrote:
Peter, please let us know how you like the formatting of those
documents when they're printed, and how long it takes to manually
reformat each document so that it looks like it's something that
resembles the original printed version.

For anyone else who is monitoring this:

- ConnectingFlight doesn't just delete the rulers. Each tab is
converted to its Word equivalent - multiple left tabs which position
columns of data, single or multiple right aligned tabs, nested hanging
indents, and centering. Blocks of text are assigned their own unique
left and right margins, and some documents make extensive use of this.
- \RULER is one of a number of codes that are present in documents.
Other primary ones include \BP, \HEADING, and \FOOTING which can all
include page numbering codes. Page numbering is reset by the use of
Sections in Word, which most people don't even know about, but
ConnectingFlight auto-generates sections and differentiates betweens
those that do and do not do page breaks. The \READ and \CHAIN codes
link other items as part of a document set. And there is the \J and
\NJ pair to turn justification on and off. More rare but still
properly converted by ConnectingFlight are columns as specified with
\BC.
- The above conversions help many documents to look even better with a
proportional font than they do in the original fixed font.
- The above code doesn't do anything about Date or Time codes so that
the current timestamp is used when printing a document - these are
used extensively in headers and footers as well as at the top of most
business letters. Rather than hardcoding the date/time of the
conversion, ConnectingFlight changes these to the proper dynamic
codes.
- Simply converting multivalue marks to spaces doesn't account for
cases where JET has lots of them inserted for no reason at all.
They're "artifacts" from JET-IN editing sessions but the above code
treats value marks as intentional data which will affect document
formatting. ConnectingFlight converts streams of value marks to a
single space.
- Embedded comments in JET are denoted with \*. ConnectingFlight will
convert these into real Word Comment objects. In a manual conversion
you're going to get comments rendered right along with all of the
other text, or you're going to remove comments which might contain
valuable information.
- The code above doesn't handle cases where sometimes users used tabs
and other times they used lots of spaces to get their column
positioning just right. ConnectingFlight recognizes sequences of
spaces which were intended for column positioning and converts them to
tabs when tabstops are present, resulting in a faithful reproduction
of what the user _wanted_ rather than just relying on the characters
they used to achieved their goal.
- The code above doesn't handle all of the various ASCII codes used to
turn font control on and off, including Bold, Underline (different
between individual characters and all words in a series), Strikeout,
DoubleUnderline, Super/Subscript, hard hyphens, and others which were
supported in JET (mind you the codes were different in various
versions of JET. When imported into Word without modification, these
codes may corrupt the Word document. ConnectingFlight converts all of
these codes into what they were supposed to be. JET also allows Start
codes to be terminated by end of line where Word assumes fonting is on
until you turn it off. (People frequently use underlines to generate
lines on a page, which would be missing in the code above.
ConnectingFlight ensures that Start codes are properly terminated by
End codes even if the original document doesn't include them, so the
visual features intended by the original document writer are present
in the Word doc no matter how the JET doc was actually coded.

I could go on about the many other things that ConnectingFlight does.
It's not perfect and there are a number of things it cannot convert
like printer escape sequences which it converts to comments or
database reads which we can handle by other means. But this is a
"connecting flight" which will help to get you from JET to your
destination - much faster than walking.

Note from the above that saving text into Windows and then opening the
text file with Word is NOT a "conversion" of JET to Word. This is but
the first step of hundreds in a major manual effort. ConnectingFlight
goes further if you wish, to auto-save documents as HTML, RTF, or PDF
after the conversion, so "Word" may be just another conversion tool
and not necessarily the actual target application. And yes, documents
converted by ConnectingFlight can be opened and used in OpenOffice, so
Windows/Word isn't even required by the end-user.

This difference between imported text and true formatted documents is
exactly the same with my other "former" product NebulAnalysis which
generates true Excel documents with multiple worksheets, charts,
unique column widths, complex cell formatting, etc.. Information
Technology isn't just about getting data from here to there. IT
people should to consider the quality of 'there', and stop feeding
end-users text files with a different extension and calling it
something different. We can and should do better.

While we're here. How much does a ConnectingFlight conversion cost?
The base conversion is only $1 per document (am I crazy or what?),
rounded down to the nearest 500 after 1000, and with major quantity
breaks to keep many thousands of documents highly affordable. A
conversion of 1000 or more documents includes 10 hours of our time to
check document formatting to ensure accuracy, tweak the code for
unusual situations, perform occasional manual tweaks to the final
documents, and other functions. Now compare the cost of manual
conversion (document tweaking after the initial text import) with the
cost of ConnectingFlight and come to your own conclusions.

Tony
TG@ clay.tablets.were.so.much.easierNebula-RnD.com

Tony Gravagno wrote:

[snip extensive ConnectingFlight featues]

Ok, so what do you think T? Maybe it will take him 40-45 minutes?

<G>

--
Kevin Powick

So Kevin, 30 minutes to 45 minutes, 45-30 = 15 minutes. THE FIRST ONE.

I am one of the "stupid" people that buy a tool for converting excel to
text. Of course you can do it inside excel saying save as txt. But you
can do it with 1,2,3 documents if you have 1000 documents?. Manage 1
document in any system is easy, even with a pencil, managing hundreds
or thousands is another thing and that is why we can work in a market
named computer science. Even when somebody do not like to pay for it.
Only 15 minutes a document!!!!!!!!!


Kevin Powick ha escrito:

jra wrote:


I must be the "stupid" one because I soooo don't understand your post
at all.

Sorry,

--
Kevin Powick

Kevin:

Don't worry... It comes and goes. :-)

Bill

"Kevin Powick" <nospam (AT) spamless (DOT) com> wrote

Bill H ha escrito:

Kevin: I only want to say that one thing is "convert a document" a
another different is "convert hundreds".
I have seen people wanting to export data they have in excel to D3. Of
course it is quite easy. Open Excel, Save as txt, read it fromm D3 with
osfi. They do not understand there is a software that:

You put all the excel files in a directory, run the software and all of
them are converted to TXT. Then you read them from D3.

It is not a tech problem in converting, the add value is to do it with
hundreds directly. That's what Tony's software does.

joseba wrote:
I think you've identified the next enhancement to the ExcelExport
freeware - a sort of combination of ExcelExport and MVExec. I'll
publish an mv.NET-enabled version that pushes all of the sheets from
all workbooks in a folder into MV items, regardless of the MV
platform. Thanks for the idea Joseba!

http:// removethisNebula-RnD.com/freeware/
See the ExcelExport and MVExec related files.
Look for MVExcelExport in about a week.

Free eval licenses of mv.NET available:
mv.NET@ remove.this.as.alwaysNebula-RnD.com