[mgp-users 01215] Bugs in mgp -D and -g

[Tim Maher <tim@consultix-inc.com>]

Magicpointers,

I'm back from giving four talks at last week's Perl conference,
and now trying to make my slides available to the clamoring
throngs! 8-}  And it ain't easy!  I find it hard to believe
that I'm unique in having these problems, so I'm wondering if
nobody has seen fit to report them or try to get them resolved.

By way of background, I have a lot of experience in developing
and presenting talks with MGP, and I may in fact have the most
complex presentations of *any* Magicpointer, in terms of font
and color changes, and the size of my files, which range from
2,000 to 5,000 lines (luckily, my preprocessor generates 60% of
those lines on its own).

On the other hand, I have relatively little experience with
making printouts of MGP presentations, and I've run into several
problems, most of which cannot be blamed on my presentations
being complex or large.

First of all, I've found it impossible to make PostScript
(or PDF) versions that work, because it seems no matter what I
do about minimizing font and color variations, loading extra
*.pfa files, or trying to identify and eliminate material
that upsets the viewer, something always goes wrong when I run
GhostView (as gv on Linux) that causes my viewing session to
bomb out.  (Interesting, when my presentations were smaller,
they *worked,* but once each of them crossed the threshold of
about 30 pages or so, they started blowing up, and never worked
again.)

And to make matters worse, the error messages from GhostView
aren't at all helpful, generally being something like "Error:
/undefined in Charter", followed by a stack trace.  What good
is that? 8-{

So I've turned my attention to the HTML option, which has the
advantage of not needing printer fonts to work correctly, but
it's not exactly easy to use either.

The first problem was that the JPEG images of my slides
(produced via mgp -D dir) came out too big! They're 1024x768,
same as my (fixed, laptop) screen, and naturally that means
they can't be entirely displayed within a browser whose borders
take up part of that screen space.

So I tried shrinking the size using

	mgp -g 717x538 -D directory,

and found two problems with that.  One is that the images
on the pages did *not* get proportionately rescaled (like
the text did), so a large image that fit nicely within the
1024x768 frame would only partially fit within the smaller
frame.	That behavior effectively makes the -g resizing option
only usable for text-only presentations! 8-{

The other problem is that, despite the fact that this smaller
size has the same aspect ratio (1.33:1) as the larger one,
some lines that fit correctly within the screen width in the
big form wrap around in the smaller form, making the lines
look ragged and causing the last lines on the page to be
pushed past the visible region. (This could conceivably be a
bug in something as simple as the number-rounding algorithm used
to rescale the text; haven't peeked at the source).

To work around these problems, I first tried changing the

	<IMG SRC=... WIDTH=1024 HEIGHT=768>

lines in all the HTML files to 717x538, but I found that the
(undoubtedly cheapo) rescaling algorithm being used by the
browser was distorting the images too much.  So I then
shrank the original (overly large) 1024x768 JPEGS down to
70% of that size (717x538) using ImageMagick, and they now
fit nicely within the browser's frame.

With that result, I had finally come up with a way to print
and distribute my presentation, but it took a lot of trial
and error.  I happen to be very stubborn and armed with plenty
of free time at the moment, so I was able to work around these
problems eventually, but I have to wonder how others would react
to a series of setbacks like this.  My guess is that many would
throw up their hands in despair and look for a software package
that's easier to use, and has been more thoroughly tested and
debugged.  And that would be a shame, because I'm a fan of the
Magicpoint model, and I'd like to see it in wider use.

As you will have guessed, my recommendation is that we address
these difficulties (at least the HTML ones) in the next version,
so nobody will have to grapple with them again. 

It would seem to be easy enough to change the default JPEG size
used by "mgp -D" to 717x538 instead of 1024x768 (although I
can't see where that figure is derived in the source code), or
even better let the user specify the desired size as an option.

Fixing the line-wrapping on -g YxZ rescaling problem might be
easy too, depending on what's causing that.

Rescaling images in addition to text would seem to be as
easy as grabbing the -zoom argument, or the default of 100%,
and applying a proportionate adjustment to rescale the image
according to -g's values.

I hasten to add that the small patch I submitted earlier today,
which causes mgp.c to take notice when xwintoppm and pnmscale
*blow up*, is the most extensive C-language coding I've done
since 1983 8-}, so I'm not the best guy to be going through the
source trying to fix these problems 8-}  (I'm a Perl guy.)

So what have the rest of you been doing to deal with these
problems?  Any workarounds I haven't stumbled on yet that you'd
care to share with the rest of us?  Or have you just been
using MGP for live presentations only, with no distribution
of the slides?

-Tim
*------------------------------------------------------------*
| Tim Maher (206) 781-UNIX  (866) DOC-PERL  (866) DOC-UNIX   |
| CEO, JAWCAR ("Just Another White Camel Award Recipient")   |
| tim(AT)Consultix-Inc.Com  TeachMeUnix.Com  TeachMePerl.Com |
*+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-*
|  Watch for my Book: "Minimal Perl for Shell Programmers"   |
*------------------------------------------------------------*