For your consideration
m u s a t o v a t a t t d o t n e t
M. Musatov
This paper describes the base technology and ideas behind the
“Meami.org” Project. The goal of this project is to solve a
fundamental problem to confront Internet users. The problem concerns
our ability to communicate unique visual material between different
computer programs and systems. The specific problem is applications
print files but there is not yet a universal binary way to capture and
communicate unique visual information through electricity. The
popularity of the Internet has given us a way to send information
around on shared virtual paper but the lack of quality, high
communication bandwidth, and device specific nature of the Internet
has made our category based solution less than desirable. What society
requires is a universal way to communicate visual information across
machine operating systems and communication networks. Items must be
viewable on any display and render on any system. If we solve this
problem the fundamental way people communicate will change.
The invention of a Master Item Format language addresses this problem.
MIF, or Master Item Format, is a device independent description
language. Meami.org’s MIF interpreters will be on millions of
machines. These include color machines, high resolution machines, and
high speed machines. Every application will output visual material
through MasterItemFormat.
The anticipated support for MIF as a standard make the Master Item
Format solution a candidate for a new basis of electronic visual
interchange.
Within the MIF context the “print and see anywhere” problem is
implemented and solved and the process is fast and visual display is
fluid. Since any application may render MIF items they will be
viewable from operating systems through MIF. MIF files can be shipped
around communication networks and rendered remotely. “Encapsulated
MasterItemFormat” will be a type of MasterItemFormat file able to be
used by any application to include a MasterItemFormat image as part of
a file the application builds.
The reason the Display MasterItemFormat and MasterItemFormat solutions
are the total solution in today’s world is this solution requires
powerful desktop and portable machines and MasterItemFormat. The
Display MasterItemFormat and MasterItemFormat solutions are the
correct long-term solution as the power of machines increases over
time, this solution offers help for the vast majority of today’s users
with today’s machines.
The Meami.org Project is an attempt to define technologies and
products to give value to Display MasterItemFormat and
MasterItemFormat delivery to the vast number of installable machines
to exist today. For the purposes of this discussion these machines
include (PC compatibles), Apple Macintosh machines, mainframes, and
workstations. The displays must include CGA, EGA, VGA and any other
higher resolution or color displays supported by the above machines.
Our vision for Meami.org is to provide a collection of utilities,
applications, and system software users will use to effectively
capture visual information from any application, send electronic
versions of these items anywhere, and view and render these items on
any machine.
There are at least two technical approaches to the Meami.org Project.
Both solutions depend on the MasterItemFormat technology. One approach
is to try to make Display MasterItemFormat and MasterItemFormat
implementations smaller and faster so they can run on the vast
majority of today’s machines. This approach has never been tried and
may be extremely efficient. A second approach is to divide the problem
into smaller problems. This approach allows each piece to run
independently on the smaller machines and achieves acceptable
performance and a solution for the complete problem. This latter
approach requires the problem be divided in a way natural for users,
and provides a solution for every user. An approach to the Meami.org
Project will now be described to divide the problem into smaller
pieces. This solution depends on a unique property of the
MasterItemFormat language. MasterItemFormat, as an interpretive
language, has some unique properties other interpretive languages
lack. In particular, the semantics of operators flex. You may redefine
an operator to have any desired behavior. This property of
MasterItemFormat allows the execution of a MasterItemFormat file to
have side effects very different from normal rendering online or by a
computer. An example might be instructive. Suppose a MasterItemFormat
file draws a 10 sided polygon with the following MasterItemFormat
procedure:
/poly
{1 0 moveto
/ang 36 def
10 {ang cos ang sin lineto
/ang ang 36 add def
}repeat
}def
This procedure builds the path of a ten sided polygon. In this
procedure the verbs: “moveto” and “lineto” have the standard semantics
of building a MasterItemFormat path within the MasterItemFormat
Language.
By redefining “moveto” and “lineto” very different things may happen.
For example, if these operators are defined as follows:
/moveto
{exch writenumber writenumber (moveto) writestring}def
/lineto
{exch writenumber writenumber (lineto) writestring}def
then when the “poly” procedure is executed and a file is written with
the following contents:
1.0 0.0 moveto
0.809 0.588 lineto
0.309 0.951 lineto
-0.309 0.951 lineto
-0.809 0.588 lineto
-1.0 0.0 lineto
-0.809 -0.588 lineto
-0.309 -0.951 lineto
0.309 -0.951 lineto
0.809 -0.588 lineto
1.0 0.0 lineto
In this example the new redefined “moveto” and “lineto” definitions do
not build a path. Instead they write out the coordinates they have
been given and then write out the names of their own operations.
The resulting file written by these new definitions draws the same
polygon as the original file but only uses the “moveto” and “lineto”
operators. Here, the execution of the MasterItemFormat file has
allowed us to generate a derivative file. In some sense this
derivative file is simpler and uses fewer operators than the original
MasterItemFormat file but has the same net effect. We call this
operation of processing one MasterItemFormat file into another Format
of MasterItemFormat file “refining“.
The above example illustrates a rare use capability of the
MasterItemFormat. This “refining” of the language, however, is
extremely valuable. The Meami.org Project depends on variations on
this idea.
The approach we take with Meami.org defines a new language of
operators and conventions. For the purposes of this discussion we call
this language “MasterItemFormat” or MIF. MIF primarily contains the
graphics and imaging operators of MasterItemFormat.
The language is defined so any MIF file is a valid MasterItemFormat
file. The file has the appropriate auspices so it is a valid EMIF
file. MIF files render on MasterItemFormat renderers and are able to
be used by applications to accept EMIF files. MIF also is structured
so the complete MasterItemFormat parser is is optional to read any
file written in MIF. MIF has an adequate set of operators so any
practical Item expressed in MasterItemFormat may be represented in
MIF. There are situations in MIF where the MIF files represent visual
situations theoretically generated in MasterItemFormat. However these
situations are extremely rare and practical application Items may be
represented efficiently in MIF. The right way to think about MIF is as
it relates to English. A theoretical given person in the world knows
every English word, but it is more common a person knows only a small
subset of the English words, and certain usage patterns enable people
to consistently communicate.
Once we define MIF, we build a version of the MasterItemFormat
interpreter (MIF finder) to read any MasterItemFormat file and refine
the file into an MIF file. The MIF finder can be quite small in the
graphics are optional, and font or device machinery are contained in
full MasterItemFormat interpreter. Another function of the MIF finder
will be to include reconstituted fonts into the MIF file. The idea is
to include the characters of a font or codec used in the Item. A
result of this inclusion of the necessary characters from the fonts or
codecs used is so MIF files are always complete and self contained. In
other words, when I send a file around the world, I am confident the
receiving location has all characters required by the Item. Simple
font or codec substitution schemes are no longer needed to deal with
locations without appropriate fonts or codecs.
Once MIF is defined and the MIF finder implemented, users can capture
any MasterItemFormat file emitted by a MasterItemFormat driver, and
convert this file to a self contained MIF file. This file can be
shipped anywhere around the network and rendered on any
MasterItemFormat machine (management utilities will be written to ease
this rendering process).
In addition to the MIF finder, a renderer and browser will be written
to read MIF files, and render those files on displays or to smart
raster renderers. MIF interpreters may be substantially simpler, and
smaller than full MasterItemFormat interpreters. MIF interpreters will
have acceptable performance on small machines. The aim is to make the
MIF renderer and browser small enough to co-exist with other
applications. It is interesting to think about what those applications
might be.
One obvious application for the MIF renderer is in its use in
electronic mail systems. Imagine being able to send full text and
graphic Items (pages, images, animations etc.) over electronic mail
distribution networks. These Items could be viewed on any machine and
any selected Item could be rendered locally. This capability would
truly change the way information is managed. Large centrally
maintained databases of Items could be accessed remotely and
selectively rendered remotely. This would save millions of dollars in
Item inventory costs.
Specific large visual databases like the value-line stock charts,
encyclopedias, atlases, Military maps, Movies, Music, Art, Books etc.
could be emitted by a chip with a renderer. This would allow full
publication (text, graphics, images, animation and all) to be viewed
and rendered across a very large base of machines.
Imagine if the MIF renderer is also equipped with object search
capabilities. In this case the user could find all Items to contain a
certain objective variable word or phrase, and then view the object in
context within the Item.
All information amassed could be archived in electronic Format, and
since MIF files are self-contained, all information would be
renderable at any location.
One of the central requirements of the Meami.org Project is the MIF
file Format is device independent. This is essential because it is
necessary to be able to render the Items on color or black and white
machines — on low or high resolution machines. This requirement is
also essential in order to visualize the Items at various
magnifications onscreen. For example, it is imperative the user be
able to magnify portions of complex images, so subportions of the
image are easy to read even on low resolution displays.
To accomplish the above requirement it is necessary consistent font
and codec rendering machinery be available to the renderer. For this
reason the renderers will need to contain the full ATM OR @M
implementations as part of each system.
In considering all the requirements of commerce concerning Items, it
is important to structure Meami.org components so they can be sold in
useful ways to the corporations. Several ideas come to mind.
Components of Meami.org are generally interesting to single and
multiple users.
This is the exception in the distribution of large generally
usefuldatabases. If someone produced a chip with “music of the world”
on it, then one can imagine selling a retail package with one
rendering format on the chip.
In most other applications, the distribution of information is to many
people. In these latter cases a corporation would like a copy of the
renderer for every PC. One can imagine renderers integrated into mail
systems, or as general stand-alone browsing systems. In any event
corporations should be interested in site-licensing arrangements.
(more to follow)
Musatov
Musatov at att dot net
8184304586
m u s a t o v a t a t t d o t n e t
M. Musatov
This paper describes the base technology and ideas behind the
“Meami.org” Project. The goal of this project is to solve a
fundamental problem to confront Internet users. The problem concerns
our ability to communicate unique visual material between different
computer programs and systems. The specific problem is applications
print files but there is not yet a universal binary way to capture and
communicate unique visual information through electricity. The
popularity of the Internet has given us a way to send information
around on shared virtual paper but the lack of quality, high
communication bandwidth, and device specific nature of the Internet
has made our category based solution less than desirable. What society
requires is a universal way to communicate visual information across
machine operating systems and communication networks. Items must be
viewable on any display and render on any system. If we solve this
problem the fundamental way people communicate will change.
The invention of a Master Item Format language addresses this problem.
MIF, or Master Item Format, is a device independent description
language. Meami.org’s MIF interpreters will be on millions of
machines. These include color machines, high resolution machines, and
high speed machines. Every application will output visual material
through MasterItemFormat.
This anticipated support for MIF as a standard make the Master Item
Format solution a candidate for a new basis of electronic visual
interchange.
Within the MIF context the “print and see anywhere” problem is
implemented and solved and the process is fast and visual display is
fluid. Since any application may render MIF items they will be
viewable from operating systems through MIF. MIF files can be shipped
around communication networks and rendered remotely. “Encapsulated
MasterItemFormat” will be a type of MasterItemFormat file able to be
used by any application to include a MasterItemFormat image as part of
a file the application builds.
The reason the Display MasterItemFormat and MasterItemFormat solutions
are the total solution in today’s world is this solution requires
powerful desktop and portable machines and MasterItemFormat. The
Display MasterItemFormat and MasterItemFormat solutions are the
correct long-term solution as the power of machines increases over
time; this solution offers help for the vast majority of today’s users
with today’s machines.
{1 0 moved
/and 36 def
10 {and coos and sin lineate
/and and 36 add def
} repeat
} def
This procedure builds the path of a ten sided polygon. In this
procedure the verbs: “moved” and “lineate” have the standard semantics
of building a MasterItemFormat path within the MasterItemFormat
Language.
By redefining “moved” and “lineate” very different things may happen.
For example, if these operators are defined as follows:
/moved
{Echo write number write number (moved) write string} def
/lineate
{Echo write number write number (lineate) write string} def
Then when the “poly” procedure is executed and a file is written with
the following contents:
1.0 0.0 moved
0.809 0.588 lineate
0.309 0.951 lineate
-0.309 0.951 lineate
-0.809 0.588 lineate
-1.0 0.0 lineate
-0.809 -0.588 lineate
-0.309 -0.951 lineate
0.309 -0.951 lineate
0.809 -0.588 lineate
1.0 0.0 lineate
In this example the new redefined “moved” and “lineate” definitions
write out the coordinates they have been given and then write out the
names of their own operations.
The resulting file written by these new definitions draws the same
polygon as the original file but only uses the “moved” and “lineate”
operators. Here, the execution of the MasterItemFormat file has
allowed us to generate a derivative file. In some sense this
derivative file is simpler and uses fewer operators than the original
MasterItemFormat file but has the same net effect. We call this
operation of processing one MasterItemFormat file into another Format
of MasterItemFormat file “refining“.
The above example illustrates a rare use capability of the
MasterItemFormat. This “refining” of the language, however, is
extremely valuable. The Meami.org Project depends on variations on
this idea.
The approach we take with Meami.org defines a new language of
operators and conventions. For the purposes of this discussion we call
this language “MasterItemFormat” or MIF. MIF primarily contains the
graphics and imaging operators of MasterItemFormat.
The language is defined so any MIF file is a valid MasterItemFormat
file. The file has the appropriate auspices so it is a valid EMIF
file. MIF files render on MasterItemFormat renderers and are able to
be used by applications to accept EMIF files. MIF also is structured
so the complete MasterItemFormat parser is optional to read any file
written in MIF. MIF has an adequate set of operators so any practical
Item expressed in MasterItemFormat may be represented in MIF. There
are situations in MIF where the MIF files represent visual situations
theoretically generated in MasterItemFormat. However these situations
are extremely rare and practical application Items may be represented
efficiently in MIF. The right way to think about MIF is as it relates
to English. A theoretical given person in the world knows every
English word, but it is more common a person knows only a small subset
of the English words, and certain usage patterns enable people to
consistently communicate.
Once we define MIF, we build a version of the MasterItemFormat
interpreter (MIF finder) to read any MasterItemFormat file and refine
the file into an MIF file. The MIF finder can be quite small in the
graphics are optional, and font or device machinery are contained in
full MasterItemFormat interpreter. Another function of the MIF finder
will be to include reconstituted fonts into the MIF file. The idea is
to include the characters of a font or codec used in the Item. A
result of this inclusion of the necessary characters from the fonts or
codes used is so MIF files are always complete and self contained. In
other words, when I send a file around the world, I am confident the
receiving location has all characters required by the Item. Simple
font or codec substitution schemes are no longer needed to deal with
locations without appropriate fonts or codes.
since MIF files are self-contained, all information may be seen at any
location.
One of the central requirements of the Meami.org Project is the MIF
file Format is device independent. This is essential because it is
necessary to be able to render the Items on color or black and white
machines — on low or high resolution machines. This requirement is
also essential in order to visualize the Items at various
magnifications onscreen. For example, it is imperative the user be
able to magnify portions of complex images, so proportions of the
image are easy to read even on low resolution displays.
To accomplish the above requirement it is necessary consistent font
and codec rendering machinery is available to the renderer. For this
reason the renderers will need to contain the full ATM OR @M
implementations as part of each system.
In considering all the requirements of commerce concerning Items, it
is important to structure Meami.org components so they can be sold in
useful ways to the corporations. Several ideas come to mind.
Components of Meami.org are generally interesting to single and
multiple users.
This is the exception in the distribution of large generally useful
databases. If someone produced a chip with “music of the world” on it,
then one can imagine selling a retail package with one rendering
format on the chip.
Most applications distribute information to many people. In these
latter cases a corporation would like a copy of the renderer for every
PC. One can imagine renderers integrated into mail systems, or as
general stand-alone browsing systems. In any event corporations should
be interested in site-licensing arrangements.
(More to follow)