!PRELIMINARY! UNDER CONSTRUCTION.
More remote-access experimenting is to be done
in trying to find ways to implement web browser 'helper apps'
for ALL these 3D file types, when the 3D files are on a 'remote' web server,
along with this web page on that remote server.
About half work and half fail (2011 Feb).

This is a page of notes on 'web experiments' with 3D file types.
The intended purpose is to find a way to setup a 3D viewer as a
'helper application', in a web browser, for each of many
3D file types --- when the 3D files, and the web page giving access
to those files, is on a *REMOTE* web server --- separate from
the computer on which the web browser (and the 3D viewers) is running.

The scenario is 'link' statements on this web page --- for each of
about 15 different 3D file types. On this page, there will be 'links'
to several representative 3D files for each 3D format type ---
a total of about 50 links.

The experiments, for a given 3D file type, may include

trying various file suffixes on the filenames, of the files
stored on a remote web server

trying various 'type=' parameters in link statements, on
this web page, when the web page is on the remote web server

editing an underlying 'mime-types' file of the web browser, a file
that resides on the local machine that is running the web browser.

The intent of these experiments is to get the web browser
(in concert with the web server) to
pass the 3D file to an appropriate viewer,
running on the local machine.

A
parent page of this page (3D test files for Linux viewers and
converters) showed that you CAN successfully
set up 3D viewers in a web browser,
for about 15 different 3D file types, IF you are satisfied
to setup the web page and 3D files in a local 'kiosk' mode
--- that is, if the 3D files, the web page providing access to them,
and the web browser (and the 3D file viewers)
are ALL installed on the same computer.

That web page was used to confirm that the following 3D file viewers
--- which are easily installed on Linux (at least, on Ubuntu Linux) ---
are capable of serving as 'helper applications', in a web browser,
for about 15 different 3D file types. These viewers were easily
installed thanks to the Ubuntu Software Center, apt-get, and Gdebi.

g3Dviewer which is said to read-and-show the many 3D file formats
supported by the LibG3D library, which includes
'.3ds', '.lwo', '.obj', '.dxf', '.md2', '.md3',
'.wrl', '.vrml', '.dae' (COLLADA),
'.ase' (ASCII Scene Exporter), '.ac' (AC3D) --- but I have not
tried 'g3dviewer' on all of these formats yet.
The viewer capabilities seem
to be rather minimal compared to 'glc_player' or 'paraview'.

The
mm3d modeller loads quickly and is said to read-and-show '.obj'
and '.dxf' (3D) files as well as about 7 others including
'.md2', '.md3', and '.lwo'.

The
Blender modeller will read '.blend' files and several
other 3D file types.

The
wings3D modeller will read-and-show '.obj' and '.3ds' files
and several other 3D file types.

That page also pointed out that the process works fine if you
keep the 3D files, the web page accessing them, and the web browser
TOGETHER on the same computer.

But when you move the web page and the 3D files to a remote web server
--- a computer different from the one running the web browser program
and the 'helper applications' --- then one starts to have
problems viewing some of the file types.

the 3D file is shown as alphanumeric characters and other
characters, in a new (cleared) web browser window

(If the file is 'ascii', the text is readable. If the file is
'binary', the characters look like a bunch of gobbledy-gook.
If we wanted to look at the characters/bytes in the file,
we could have downloaded the file and looked at it with a text
editor like 'gedit' or a binary editor like 'bless'.

We want the file to be passed to the helper app we set up.
The natural response of the user is 'What the fah?
How do I get the file to show up in my helper app?'

The web browser developers blame the web server administrators.
This is a bunch of BS. Getting a web server admin to
change a 'mime-type' definition in some web server config file
is not a proper solution. The admins have more important
things to do than maintain a config file of more than a
thousand file types --- and more file-types being added
every week, often with a suffix already used for another
file type.

The web browser (and the web server)
should be paying attention to the 'type='
statement in the web page developer's web page link
--- BEFORE deciding on the file type according to some
web server config file that cannot know
the file type better than the web page developer.

And the web server should be passing the file to the
web browser as a data stream that preserves all the
data in the file --- without deciding to change the
data according to the type the web server THINKS the file
is. For example, a web developer should not have to try
to fool the web server into sending a file as binary data
to work around the fact that the web server thinks that
the file contains ascii-only data. I have encountered this
situation, in a couple of different file-type cases.

If this IS a problem that requires protocol changes by
BOTH the web browser developers (e.g. Mozilla) and
the web server developers (e.g. Apache), then someone
needs to clarify or change the protocol specifications
that they are following in their development processes.

Another way of looking at it: The current system was
designed to support web developers who are developing
pages to be 'pushed down' from the web server --- especially
'active' pages that use CGI and PHP scripts that have control
on what happens on the server side.
The specifications writers have not done a good job of thinking
about the web developers who upload their web pages
and other files to the web server --- web page developers
whose pages work almost totally from the client side.)

the web browser pops open a 'Save file' dialog window

(We could have done that by rightclicking on the link and
choosing 'Save Link Target As ...' from the popup window.
So that's no help at all.

Again, the user response is 'How the f**k do I get the file
passed to my helper app?' I don't have an answer for you, yet
--- other than download the file on your local file storage
and use the appropriate viewer. I.e. fagedabout putting
the web browser or the web server in the mix. It's just too
frustrating. And it should not be that way.)

the web browser pops open an 'Open-with-OR-Save-file' dialog window

(That's a heck of a lot better than response 2 or 3. In fact, it's
as good or better than response 1. In fact, I would be glad if
the web browser that I use, Mozilla Seamonkey, would always
respond this way, when I click on ANY media file links other than
'.html', '.htm', '.php' ... and several other file types in
'anchor' statement href's that the browser should render
automatically, ordinarily, in its own window.)

It turns out that if you would download this web page, AND its 3D files,
onto your local computer, you could see all these 3D files
with no problem (in most GUI web browsers),
simply by clicking on the links --- if you set up the helper
applications as I described on the
3D test files for Linux viewers and converters web page.

That is, you would get response 1 or 4 above.

BUT, it turns out that if you try to view some of these 3D files via
this web page, as the 3D files and this web page are now
(i.e as you access the 3D files remotely, on this remote web server),
many of these files will not be passed into your helper apps.

That is, you would get response 2 or 3 above.

This web page is intended to collect notes on trying to work around
getting responses 2 or 3 --- as I try various experiments
with different HTML link statements --- file suffixes and 'type='
statements --- experiments
done with the Seamonkey2 or Firefox (or other) web browsers.

Perhaps I can find a 'work-around' so that most (or all) of the
3D file types can be displayed in helper apps of the user's choosing
--- from almost any web server --- or, at least, from this web server.

'Kiosk' mode :

Be consoled that you CAN get the helper apps working OK --- IF you resign
yourself to working in a 'kiosk' mode. That is, let us say that you want
to 'publish' your 3D files on a machine that you install at a store or
a conference exhibition hall or wherever. Then you can install your
3D files --- and the web page(s) and web browser and 3D viewers
for viewing those files --- on a stand-alone machine.

I installed applications on Ubuntu Linux (9.10) that work as viewers
for most of the 3D file types listed above.

When I first made links to the 3D files on this web page,
I did not put a 'type=' specifier in the HTML 'anchor' statements.
They looked like

<a href="... file-path-and-name-here ..."> ... filename-here ...</a>

When I clicked on '.obj' and '.ply' file links,
their text contents were simply shown in the web browser window
--- instead of offering me a chance to setup a 'helper app'
for these file types --- such as 'glc_player' for '.obj' files
and 'paraview' for '.ply' files.

To try to deal with this 'text-display' problem,
I added 'MIME' qualifiers like

type="application/wobj"

and

type="application/ply"

to the 'anchor-href' statements for the '.obj' and '.ply' files.

Example:

<a href="./obj/archer.obj" type="application/wobj">archer.obj</a>

(See the section below for info on 'mime-types'.)

Then, when I clicked on the file link to a locally stored
'.obj' file, instead of getting text-display, I got the Seamonkey
'Open-with-OR-Save-as' prompting popup window.

I chose 'Open-with', and I was able to set 'glc_player' as the
viewer (helper) for ALL the '.obj' files --- referred to in the
HTML 'anchor' link statements on the web page.

I just needed to click a check-box on the 'Open-with'
prompting window. The checkbox was labelled
'Do this automatically for files like this from now on'.

You need to get to that 'Open-with' prompting popup window
in order to define helper applications for files referenced
in web pages. At least, that's how
it is done in the Mozilla Seamonkey2 web browser.
In other words, you need to avoid responses 2 and 3 above.

It is my intent to use this web page
to perform experiments with
remotely stored 3D files --- and with this web page
remotely stored with those files. THE GOAL is to get
the 'Open-with' prompting popup window, so that we can
define a 3D viewer --- that will run on the local machine,
with the web browser --- for each 3D file type, for which
we have several (remote) sample files referenced
in HTML 'link' statments on this page.

MIME = Multipurpose Internet Mail Extensions --- a
messaging standard that allows Internet users to
exchange e-mail messages enhanced with graphics, video, and voice as
attachments to the body of the text.

Paraphrasing some text at htmlquick.com :
"MIME is a standard that classifies resources and provides information
to programs about how to handle them. It is recommended to provide
MIME type information everywhere possible --- for example, with the
'type=' attribute in HTML link tags --- in HTML documents.
This may help with browser compatibility and facilitate the correct
functionality of the document."

(A natural question is 'What does mail have to do with
web pages?' Apparently, when HTML came along, the
MIME standard was applied to web pages.
Note: I use the word 'standard' loosely here. It's not so
much a standard as a cobbled-up mess, when you get away from
some commonly used media types.)

Note that even though there do not seem to be sanctioned mime-type
indicators for '.obj' and '.ply' files, my attempt at using
'application/wobj' and 'application/ply' proved to be successful
(at least when the files were stored locally; NOT when on a
remote web server, as I found out later).

At least one 3D file type was viewable both in local mode
and the remote mode. So we have a mixed bag here --- some
3D files are viewable remotely using the same set of parameters
that worked in local mode. But some 3D files are NOT viewable
remotely using a set of parameters that worked in local mode.

It MAY be the case that when a web server 'has doubts' about
the mime-type of a file that it is being requested to deliver,
the web server assigns it a mime-type of 'application/octet-stream'
--- or perhaps, in some cases, 'text/plain' or 'application/plain'.

If that is the case, I hope to find a way to get to the
'Open-with' prompt of my web browser, and establish a 3D
viewer for the file, if the the 'ghosts in the machine' can
be forced (or tricked) into downloading the file
in a way that makes it available to the 3D viewer.

With respect to VRML file formats (and the suffixes '.wrl',
'.vrml', '.vrm'), there seems to be a lot of confusion (and resulting
complications) within the systems in web browsers that set
'helper applications' for the VRML1 and VRML2 file types.

As a consequence, in this web page,

for VRML1 files, I will start by using the suffix '.vr1' in
their filenames and, in the HTML 'anchor' statement
for these files, I will start by using
type="application/vr1".

for VRML2 files, I will start by using the suffix '.vr2' in
their filenames and, in the HTML 'anchor' statement
for these files, I will start by using
type="application/vr2".

There is a little more detail on the sad VRML situation, in
the 'further aside' section below.

A further aside on the sad state of helper application management in web browsers :

The web browser developers do not seem to want to give the users better
control (and better flexibility) over setting the 'helper applications'
for various file suffixes.

They could solve most of the problems we encounter with setting helper apps,
if they would devise a system for 'opening' files like the system used in
GUI file managers, like Gnome-Nautilus.

In Gnome Nautilus, if you double-click on a file, it is 'opened' in a default
application. BUT, IF YOU WANT TO OPEN THE FILE IN ANOTHER APPLICATION, you
can right-click on the file and there is an 'Open-with' option.

Here is a screenshot of a Nautilus 'right-click Open-with' popup window.

Note that Firefox is the default open-with application for the '.fonts.conf'
file on which I right-clicked. That is a heavy-handed default app, but
note that I can use a different app by using the 'Open with' option.

Similarly, web browsers should allow for a 'right-click Open-with' option,
for web page links.
Then we users could specify one (or more) apps per file suffix ---
and per file type in the 'type=' statment of the web page,
if the 'type=' parameter is there.

In fact, we should even be able to right-click on a link to a
'.html' or '.htm' or '.php' file and choose to open it in
a web browser other than the one we are currently using.
This is the kind of freedom we should have, and there is no
technical reason why that cannot be done.

For example, the user should be able to specify a default open-with
app for file suffix '.obj' --- and for file suffix '.obj' and
type='application/wobj' or type='model/obj' or whatever one might
encounter as a 'type=' parameter
in a web page (or from a web server) on any given day.

In fact, the use of the slash ( / ) in the 'type=' statement is
rather lame. I should be able to use almost any string, of
reasonable length, such as 'Wavefront-obj'.

Even if a default app has been defined for a file type, the
web browser should allow the user to select which of several apps
to use when the user right-clicks on a media file 'anchor-href'
link. That is, the web browser should always offer an
'Open-with' dialog as an option.

In fact, here is a screenshot showing that 21 apps (and more)
are being offered by Nautilus, to open the '.fonts.conf' file.
That's a bit of overkill --- but it's certainly better than not
being able to view the file in an appropriate viewer at all.

Of course, in addition to the very flexible Open-with dialog,
the web browser developers should allow the users an option
to reset the default 'open-with' app.

Basically, we Seamonkey2 users need an 'Open-with' option added to
the following 'right-click-on-a-link' popup menu.

We can specify where to 'Save' the file, with
'Save Link Target As ...', but we have no option to specify
how to 'Open' the file. The Open options that are there now are
lame. They open the file in the 'New Window' or 'New Tab' according
to the currently screwed-up 'dance' between web server and web browser.
Those Open options do not allow the user to override a stupid 'Open-with'
choice made by the brain-damaged 'partnership' of the web-server and
the web-browser.

One other case of web-browser inflexibility: Once you have defined
a new suffix and helper app, you cannot delete that suffix and helper
definition from the 'Helper Applications' window.
(Not in Seamonkey2 anyway. And probably not in Firefox.)
You presumably would have to resort to editing the
underlying 'mimeTypes.rdf' file.

The developers (and testers) seem to have sadly neglected the
'Helper Application' area of web browsers --- except to hard-code
in the helpers they want to provide.

If you want to get an idea of the confusing state of things in the
'helper application' area, and if you use the Firefox or Seamonkey web browsers,
look at the file named 'mimeTypes.rdf', in the directory
$HOME/.mozilla/firefox/random8chars.default or
$HOME/.mozilla/seamonkey/random8chars.default .

For example, they put 'vrm' suffixes in the file, in addition to
'wrl' and 'vrml', whether we want them or not --- and essentially
made them all equivalent, with respect to which viewer to use for those
file suffixes.

In a more perfect world,
we wouldn't have any of those three suffixes in our mime types file(s).
We would be providing those suffixes if we were going to use them --- and
we would be using suffixes that clearly indicate whether the file is a
VRML1 or a VRML2 file --- such as '.vr1' or '.vr2'.

Each of the 3D viewers has a different way of doing the 3 basic viewing
operations --- rotate, pan, and zoom --- and different ways (if any)
of quickly restoring the model to the center of the viewport, filling
the viewport.

Someday, I may put a link to a page of those view methods,
for each 3D viewer, here.

But the main goal of this page is to simply
be able to start up a viewer
on a sample 3D file, for each of the 15 or so 3D file types below.

We only want to be able to move the model
(or move around the model) to make sure we are not
just imagining that we have finally found a successful
way to view the REMOTE file, for a given 3D file type.

And now, on to the test/demo files :

I made this page so that I could access these files (and these notes)
on any of my computers --- whether at home or away.
But others may find these files (and notes) useful.

You can use the Table of Contents, below, to jump to
a particular group of 3D files --- about two to four sample files of
each file type. (If there are both binary and ascii files of a
given type available, I include at least one of each.)

Or, to see the links, simply scroll down this page.
You can click on them to see what happens with
your web browser, and this web server --- and compare to my
results, reported below.

Most of my testing will be done with the Mozilla Seamonkey2 web browser,
running on Ubuntu Linux --- 9.04 or above --- mostly on 9.10.

I will be recording the results of my tests below --- in the Table
of Contents section. I will provide more details --- on 'workaround'
attempts --- in each of the 3D-file-type sections.

Table of Contents :

(These links take you to groups of 3D file links, further down this page.)

'.igs' sample files (IGES, 2D CAD)
( WORKS?? May be tested later --- if I can find a reader for
these test IGES files.
If the [ASCII] IGES files are at fault, I plan to fix them
or replace them.
'varicad-view' starts successfully but fails to show these
IGES files. )

'.iv' sample files (SGI Inventor)
( ASCII FAILED. Clicked on an ASCII '.iv' file and it was shown
as text in
the browser window. Need to try to get the 'Open-with'
dialog.
The ASCII '.iv' file was NOT downloaded to /tmp.
'ivview' was the viewer that I successfully defined in
'local' mode.

BINARY WORKED. Clicked a Binary '.iv' file and the
'Open-with/Save-file' dialog
popped up --- but without 'ivview' as the default viewer.
I used the 'Browse...' button
to select '/usr/bin/ivview' as the viewer and the binary '.iv'
file was shown.
The Binary '.iv' file WAS downloaded to /tmp. )

'.md2' sample files (MD2 Quake)
( WORKED. Clicked a [BINARY] '.md2' file and the
'Open-with/Save-file' dialog
popped up --- but without 'mm3d' as the default viewer,
which I had defined in the
local development mode. I used the 'Browse...' button to
select
'/usr/bin/mm3d' as the viewer and the binary '.md2' file
was shown.

BUT, even though I had checked 'Do this automatically for
files like this from now on',
I always get the 'Open-with' dialog when I click on another,
or the same, '.md2' file.
In spite of 'mm3d' not showing as the default Open option
(the 'Browse...' prompt showed
instead), when I clicked Open, the clicked-on '.md2' file
was shown with 'mm3d'.
That is, I did not have to use the 'Browse...' button to
specify 'mm3d' as the viewer.

The [binary] '.md2' files were downloaded to /tmp. If I open
the same file twice,
it is downloaded a second time and the suffix '-1' is added
to the midname of the file. )

'.obj' sample files (Wavefront OBJ format)
( FAILED. Clicked on an [ASCII] '.obj' file and it was shown
as text in
the browser window. Need to try to get the 'Open-with'
dialog.
None of the [ASCII] '.obj' files were downloaded to /tmp.
'glc_player' was the viewer that I successfully defined in
'local' mode. )

'.off' sample files (Object File Format)
( FAILED. Clicked on an [ASCII] '.off' file and it was shown
as text in
the browser window. Need to try to get the 'Open-with'
dialog.
None of the [ASCII] '.off' files were downloaded to /tmp.
'geomview' was the viewer that I successfully defined in
'local' mode. )

'.ply' sample files
( FAILED. Clicked on an [ASCII] '.ply' file and it was shown
as text in
the browser window. Need to try to get the 'Open-with'
dialog.
None of the [ASCII] '.ply' files were downloaded to /tmp.
'paraview_wrapper.sh' was the viewer that I successfully
defined in 'local' mode. )

'.pov' sample files
( FAILED. Clicked on an [ASCII] '.pov' file and it was shown
as text in
the browser window. Need to try to get the 'Open-with'
dialog.
None of the [ASCII] '.pov' files were downloaded to /tmp.
'povray_wrapper.sh' was the viewer that I successfully
defined in 'local' mode. )

'.stl' sample files (STereoLithography)
( ASCII WORKED. Clicked on an ASCII '.stl' file and it was shown
with 'glc_player'.
I did not get the 'Open-with' dialog, so I did not have to
're-define' the viewer.
The ASCII '.stl' files were downloaded to /tmp.

BINARY WORKED. Clicked a Binary '.stl' file and it was shown
with 'glc_player'.
I did not get the 'Open-with' dialog, so I did not have to
're-define' the viewer.
The Binary '.iv' files were downloaded to /tmp. )

'.stp' sample files (STEP)
( FAILED. Clicked on an [ASCII] '.stp' file and it was shown
as text in
the browser window. Need to try to get the 'Open-with'
dialog.
None of the [ASCII] '.stp' files were downloaded to /tmp.
'varicad-view' was the viewer that I defined in 'local' mode. )

'.vtk' sample files (Kitware's Virtual Tool Kit)
( FAILED. Clicked on an [ASCII] '.vtk' file and it was shown
as text in
the browser window. Need to try to get the 'Open-with'
dialog.
None of the [ASCII] '.vtk' files were downloaded to /tmp.
'paraview_wrapper.sh' was the viewer that I successfully
defined in 'local' mode. )

'.vr1' sample files (VRML1 - a subset of the SGI
Inventor 2 format)
( FAILED. Clicked on an [ASCII] '.vr1' file and it was shown
as text in
the browser window. Need to try to get the 'Open-with'
dialog.
None of the [ASCII] '.vr1' files were downloaded to /tmp.
'ivview' was the viewer that I successfully
defined in 'local' mode. )

'.vr2' sample files (VRML2, a.k.a. VRML97)
( FAILED. Clicked on an [ASCII] '.vr2' file and it was shown
as text in
the browser window. Need to try to get the 'Open-with'
dialog.
None of the [ASCII] '.vr2' files were downloaded to /tmp.
'whitedune' was the viewer that I successfully
defined in 'local' mode. )

Start of the Links to 3D files :

In the following 'anchor' link statments for sample '.3ds' files,
I started with application/3ds for the 'type=' parameter value.

After setting up the 'helper application' for these (local) '.3ds' files,
using the 'Open-with' dialog of the Seamonkey2 web browser, I had
the following 3ds-related statments in my 'mimeTypes.rdf' file :

When I click on one of these '.3ds' file links, in local 'kiosk' mode,
the 'glc_player' program starts up and shows the '.3ds' file.

At the top right of the 'glc_player' viewing window are three icons
for pan, rotate, and zoom. Click on any one of these icons and
then click in the viewing window and drag the mouse around,
to perform the chosen function.

NOTE: The following fish and flower '.3ds' files (and their accompanying
'.bmp' texture files), were found at
toucan.co.jp. Many more such files can be found there.

I found that running 'glc_player' in my web browser (Seamonkey) caused
the texture files to be ignored (not found?) --- when I access the '.3ds'
files remotely. Instead of a colored image,
like the glc_player screenshot at the top of this page, I ended up with
silver (or light gray) fish and flowers. This is no doubt happening because only
the '.3ds' file is copied locally (in /tmp) for viewing --- but not
the associated '.bmp' file.

When I start my Seamonkey web browser on the locally stored web page
and click on the link to '.3ds' files (stored locally, with the
'.bmp' files in the same directory), the 'glc_player' helper application
DOES show the texture-mapped model.

Also, when I run 'glc_player' on these files without the web browser
(for example, by using Nautilus to navigate to the directory containing
the files, and right-clicking on the '.3ds' file to open the file with
'glc_player'), the '.bmp' texture file IS 'mapped' onto the 3D model.
The only requirement is that the '.bmp' file has to be in the same directory
with the [binary] '.3ds' file.

If your web browser downloads the '.3ds' file to the '/tmp' directory before
starting up the helper app to view the file, you could probably see the
texture mapping if you would download the associated '.bmp' file into
your '/tmp' directory.

In spite of no 'type=' qualifier in the '.blend' anchor-link statements
of this web page and no 'NC:path=' statement for
'application/x-blender' in the 'mimeTypes.rdf' file,
when I click on these '.blend' links, in local 'kiosk' mode,
the Blender program is started and the model is displayed.

What the .... ? Is Seamonkey2 using the default 'player' for '.blend'
files as defined in the Nautilus file manager on my development computer?
I will have to try more experiments, perhaps on some of my other
computers, to experiment with this web page and these '.blend' files.

At least the files are being 'played'. So this situation is not
a problem. It's a mystery.

These '.dwg' files (2D) are showable (when 'local') with 'varicad-view'.

In the following 'anchor' link statments for sample '.dwg' files,
I started by using application/acad for the 'type=' parameter value.

After setting the 'helper application' for these (local) '.dwg' files
to be 'varicad-view', using
the 'Open-with' dialog of the Seamonkey2 web browser, I ended up with
the following dwg-related and acad-related statements
in my 'mimeTypes.rdf' file :

These '.dxf' files (2D) are showable (when 'local') with 'varicad-view'.

In the following 'anchor' link statments for sample '.dxf' files,
I started by using application/dxf for the 'type=' parameter value.

After setting the 'helper application' for these (local) '.dxf' files
to be 'varicad-view', using
the 'Open-with' dialog of the Seamonkey2 web browser, I ended up with
the following dxf-related statements
in my 'mimeTypes.rdf' file :

IGES files are said to be showable by 'varicad-view',
but I was not able to show the following IGES files with
version 3.03 of 'varicad-view' that I installed on Ubuntu 9.10 using
a '.deb' file from 'ftp.varicad.com' --- even if I tried using 'varicad-view'
without going through this web page.

I get a 'Translation from IGES failed' popup window from 'varicad-view',
when trying to read any of these '.igs' files.

The files look like typical IGES files when I look at them in a
text file viewer.

In any case, I set up 'varicad-view'
as the Seamonkey2 viewer for '.igs' files, as follows.

In the following 'anchor' link statments for sample '.igs' files,
I have used application/iges for the 'type=' parameter value.

After setting the 'helper application' for these '.igs' files
to be 'varicad-view', using
the 'Open-with' dialog of the Seamonkey2 web browser, I ended up with
the following igs-related and iges-related statements
in my 'mimeTypes.rdf' file :

If I find a viewer that works on these IGES files, I will try re-setting
the Seamonkey2 viewer for these files. Clicking on these '.igs' file links,
I DO startup the 'varicad-view' program, but it shows the 'Translation from IGES
failed' popup message window, on each file.

In the following 'anchor' link statments for sample '.iv' files,
I have started this page
by using application/iv for the 'type=' parameter value.

After setting the 'helper application' for these (local) '.iv' files
to be 'ivview', using
the 'Open-with' dialog of the Seamonkey2 web browser, I ended up with
the following iv/ivview/inventor-related statements
in my 'mimeTypes.rdf' file :

When I click on one of these '.iv' file links, in local 'kiosk' mode,
the 'ivview' program starts up and shows the '.iv' file.

For some reason unbeknownst to me, even though the type
'application/iv' does not appear in the 'mimeTypes.rdf' file,
the following '.iv' files are shown successfully with 'ivview'.

The file extension 'iv' IS registered --- but under
'application/x-inventor'.

I may try this setup on a different computer someday, to make sure of
the steps that I went through to use type 'application/iv' to setup
'ivview' as the viewer of the '.iv' files. I will check the contents
of the 'mimeTypes.rdf' file on that computer.

Since the '.iv' files are shown successfully, this is not really a problem.
But it IS a mystery, to me. The 'helper application' logic in
web browsers should be documented. It might force the developers to
take more care in the implementation of the 'helper application' logic.

The following '.md2' Quake game files can be shown (when 'local')
with 'mm3d'.

In the following 'anchor' link statments for sample '.md2' files,
I started this page using
application/md2 for the 'type=' parameter value.

After setting the 'helper application' for these (local) '.md2' files
to be 'mm3d', using
the 'Open-with' dialog of the Seamonkey2 web browser, I ended up with
the following md2-related statements
in my 'mimeTypes.rdf' file :

The following Wavefront '.obj' files are showable (when 'local')
with 'glc_player'.

In the following 'anchor' link statments for sample '.obj' files,
I started this page
using application/wobj for the 'type=' parameter value.

After setting the 'helper application' for these (local) '.obj' files
to be 'glc_player', using
the 'Open-with' dialog of the Seamonkey2 web browser, I ended up with
the following obj/wobj-related statements
in my 'mimeTypes.rdf' file :

When I click on one of the following '.obj' file links,
in local 'kiosk' mode,
the 'glc_player' program starts up and shows the '.obj' file.

Note that I also set up 'gedit' as an alternate helper
application for 'application/wobj' files, as seen in one of
the statements, above, in the 'mimeTypes.rdf' file.
I can use the 'Edit > Preferences > Helper Applications'
window of Seamonkey2 to access and execute this alternate helper app
--- AND I can also specify 'Always ask' there, instead of
defaulting to opening with 'glc_player'.

The following '.off' files are showable (when 'local')
with 'geomview'.

In the following 'anchor' link statments for sample '.off' files,
I started this web page
using application/goff for the 'type=' parameter value.

After setting the 'helper application' for these (local) '.off' files
to be 'geomview', using
the 'Open-with' dialog of the Seamonkey2 web browser, I ended up with
the following off/goff-related statements
in my 'mimeTypes.rdf' file :

The following '.ply' files are showable (when 'local')
with 'paraview --data='.

In the following 'anchor' link statments for sample '.ply' files,
I started this web page
using application/ply for the 'type=' parameter value.

After setting the 'helper application' for these (local) '.ply' files
to be a wrapper-script for 'paraview --data=', using
the 'Open-with' dialog of the Seamonkey2 web browser, I ended up with
the following ply-related statements
in my 'mimeTypes.rdf' file :

The wrapper script, paraview_wrapper.sh, that I put in a directory called
$HOME/apps/paraview, simply calls the command

/usr/bin/paraview --data="$1"

When I click on one of these '.ply' file links, in local 'kiosk' mode,
the 'paraview_wrapper.sh' script starts the 'paraview' program, which
shows the '.ply' file --- after I click on the 'Apply' button to apply
the loaded file whose name shows in the paraview 'Pipeline browser' window.

The following '.pov' files (when 'local')
are renderable to high-quality 2D images,
with shadows and reflections, using the 'povray' program.

In the following 'anchor' link statments for sample '.pov' files,
I started this web page
using application/pov for the 'type=' parameter value.

After setting up the 'helper application' for these (local) '.pov' files
to be a wrapper-script for 'povray', using
the 'Open-with' dialog of the Seamonkey2 web browser, I ended up with
the following pov-related statements
in my 'mimeTypes.rdf' file :

We are depending here on povray to make a png file, by default,
using the midname of the input file to build the name of the
png file.

Of course, we could change this script to use the many command
line parameters available with povray.

When I click on one of the '.pov' file links, below, in local 'kiosk' mode,
the 'povray_wrapper.sh' script starts the 'povray' program, and shows
the resulting '.png' file --- with the 'eog' (Eye of Gnome) viewer program.

The following '.stl' files are showable (when 'local')
with 'glc_player'.

In the following 'anchor' link statments for sample '.stl' files,
I started this web page
using application/stl for the 'type=' parameter value.

After setting up the 'helper application' for these (local)
'.stl' files, using the 'Open-with' dialog of the Seamonkey2
web browser, I ended up with the following stl-related statements
in my 'mimeTypes.rdf' file :

In the following 'anchor' link statments for sample '.stp' files,
I started this web page
using application/step for the 'type=' parameter value.

After setting up 'varicad-view' as the 'helper application'
for these (local) '.stp' files,
using the 'Open-with' dialog of the Seamonkey2 web browser,
I ended up with the following stp/step-related statements
in my 'mimeTypes.rdf' file :

In the following 'anchor' link statments for sample '.vtk' files,
I started this web page
using application/vtk for the 'type=' parameter value.

After setting up the 'helper application' for these (local) '.vtk' files
to be a wrapper-script for 'paraview --data=', using
the 'Open-with' dialog of the Seamonkey2 web browser, I ended up with
the following vtk-related statements
in my 'mimeTypes.rdf' file :

The wrapper script, paraview_wrapper.sh, that I put in a directory called
$HOME/apps/paraview, simply calls the command

/usr/bin/paraview --data="$1"

When I click on one of these '.vtk' file links, in local 'kiosk' mode,
the 'paraview_wrapper.sh' script starts the 'paraview' program, which
shows the '.vtk' file --- after I click on the 'Apply' button to apply
the loaded file whose name shows in the paraview 'Pipeline browser' window.

In 'paraview', in 3D mode, you can move the model with the mouse as follows

In the following 'anchor' link statments for sample '.vr1' files,
I started this web page
using application/vr1 for the 'type=' parameter value.

After setting up the 'helper application' for these '.vr1' files
to be 'ivview', using
the 'Open-with' dialog of the Seamonkey2 web browser, I ended up with
the following vr1-related statements
in my 'mimeTypes.rdf' file :

In the following 'anchor' link statments for sample '.vr2' files,
I started this web page
using application/vr2 for the 'type=' parameter value.

After setting up the 'helper application' for these (local) '.vr2' files
to be 'whitedune', using
the 'Open-with' dialog of the Seamonkey2 web browser, I ended up with
the following vr2-related statements
in my 'mimeTypes.rdf' file :

Ask the Web3D Consortium. They've had 10 years to come up with
a good viewer --- easily installable on Ubuntu Linux, or any other OS.
They have pissed away the good foundation that SGI laid for them.
Disgusting.

They don't seem to understand that the PDF document
format became ubiquitous because Adobe
provided a free reader, cross-platform.

For 10 years now, the x3d format has been languishing.
It is actually easier to find old VRML files than X3D files.

It is time the consortium made the 'Xj3D'
Java-based X3D reader available across major platforms and
easily installable and functional --- or devise a C++-based reader.
Or go back to VRML2, and provide a cross-platform reader for that
format --- and its enhancements.

I guess this is what happens when a decent format is put in the
hands of a committee of strict, anally-retentive XML enthusiasts,
who have more interest in syntax than in graphical viewers.