Support Multimedia TADS, AKA HTML TADS

[GoogleCodeExporter]

Gargoyle does not currently support Multimedia TADS, also known as HTML
TADS.  While TADS games using the HTML extensions work, they work in a
degraded way with no graphics, no sound, and limited formatting.

For example, start up Lydia's Heart
(http://ifdb.tads.org/viewgame?id=7t22wbllftv7nuiw ).  Ideally, you would
see a big graphic, similar to the thumbnail shown here:
http://emshort.wordpress.com/2009/02/03/html-tads-for-the-mac/ .  Instead
you just get the text.

Of course, this is likely hard, otherwise we wouldn't have been without a
Linux HTML TADS intepreter since forever, and without a Mac OS interpreter
for many years.  (Someone is only just working on one now:
http://groups.google.com/group/rec.arts.int-fiction/browse_frm/thread/631145b8eb
1d9ed7#
.  There is an older interpreter, HyperTADS, but it's Mac OS 9 and earlier
only. http://www.hypertads.org/ )

Some possibly helpful links:

Explanation of the differences: http://www.tads.org/html_vs_text.htm
Introduction: http://www.tads.org/t3doc/doc/htmltads/intro.htm
Notes on porting: http://www.tads.org/t3doc/doc/htmltads/porting.htm

Original issue reported on code.google.com by Alan.A.D...@gmail.com on 4 Feb 2009 at 2:41

[GoogleCodeExporter]

I'm not sure if this is the best project to tackle HTML TADS, but I've at least
thought about working on it.  Before I do, I'd like to see about porting 
Gargoyle to
the Mac.  That way the result could be used on all three dominant desktop 
platforms.

Original comment by bcressey@gmail.com on 11 Feb 2009 at 10:10

• Changed state: Accepted
• Added labels: Component-Logic, OpSys-All, Priority-Low, Type-Enhancement, Usability
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Linux is the only platform which has absolutely no support for Multimedia TADS. 
 The
next best thing is to run HTML TADS under wine.  It would be ideal if Linux 
finally
had an interpreter capable of parsing and displaying HTML content too, and I 
think
it's something needed to have Linux catch up with the rest.  Seeing 1893 AWFM in
Gargoyle's beautiful text rendering with images alongside it would bring a 
whole new
quality to the experience.

Original comment by thombr...@gmail.com on 12 May 2009 at 10:50

[GoogleCodeExporter]

QTads 2 now has support for Multimedia TADS: http://qtads.sourceforge.net/

It's still undergoing work, but I got 1893: A World's Fair Mystery working 
perfectly in 
it (unless I went to the help menu and returned to the game where it didn't 
display 
correctly anymore).

Original comment by thombr...@gmail.com on 2 May 2010 at 1:41

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I know only enough about aoftware engineering to be "dangerous", so the 
following idea may not be helpful at all. But after successfully compiling 
Gargoyle 2010.2 on Linux with support for graphics in Scare, might a similarly 
"inelegant" solution for TADS graphics be possible?

Speaking for myself, I'd rather have Gargoyle-TADS be able to display pics in 
separate windows in the short-term than wait for a full HTML-TADS 
implementation that may never come.

Original comment by ethanher...@gmail.com on 5 Feb 2011 at 2:30

[GoogleCodeExporter]

TADS is fairly careful about only using certain functions - HTML output, 
images, sounds - if the interpreter actually supports them. The trouble is that 
all of the multimedia output depends on HTML support. So for instance there's 
no way to advertise interpreter support for graphics without also claiming a 
full HTML implementation.

Once you turn on HTML, all of the output is marked up with HTML tags, and you 
can't simply filter out the tags because all of the regular formatting (bold 
and italic, paragraph breaks, etc) now comes through the tags instead.

I do plan to add support for HTML, and I've done some preliminary planning in 
that regard. I hope to have it out in the second half of the year. Some of it 
is waiting on the Glk CSS / HTML spec. If I can create an implementation that 
works with any compliant Glk library, rather than being wedded to Gargoyle, 
that would be much more valuable to the community.

Original comment by bcressey@gmail.com on 5 Feb 2011 at 4:23

[GoogleCodeExporter]

Even though I didn't take a thorough look at Glk myself, I remember a 
discussion Mike Roberts had with Andrew Plotkin on RAIF some years ago (2004).  
I was thinking about a Glk implementation of HTML TADS back then, but Mike 
mentioned that HTML TADS doesn't map that well to Glk, which is targeted mainly 
towards Z/Glulx/Inform:

http://groups.google.com/group/rec.arts.int-fiction/msg/322d13d3293c3548

This was the reason I didn't attempt a Glk port six years later. I didn't want 
any missing functionality or games that look different when compared to Windows 
HTML TADS (I consider this to be more serious than missing functionality; 
authors want their games to look the way they designed them.) So I went for a 
stand-alone interpreter instead, replacing Glk with something that was just as 
portable.

Here's the full discussion thread:

http://groups.google.com/group/rec.arts.int-fiction/browse_thread/thread/d7df215
f5abfc4b7/322d13d3293c3548

But that was in 2004.  I've no idea if Glk has changed enough to allow for a 
1:1 implementation these days.  So take all this with a gain of salt.

Original comment by rea...@gmail.com on 12 Feb 2011 at 10:31

[GoogleCodeExporter]

Glk hasn't changed, yet. But the forthcoming CSS spec will add a new HTML 
window type, which with some extra work should be usable for the TADS HTML 
output as well.

It should wind up being much closer to a 1:1 fit, excluding tables (which will 
require a more careful approach) and windows (which are mostly covered by the 
recent banner API implementation.)

I'll know more when the preliminary spec comes out. Worst case, I'll have to 
implement two new window types instead of one.

Original comment by bcressey@gmail.com on 14 Feb 2011 at 7:34