More GIF/JPEG/PNG Discussion

[Tom Regner <tom_regner@xxxxxxx>]

Donna & Jeremy,

It has always been my understanding that it was Compuserve who came
up with the 8-bit Graphics Interchange Format (GIF), long before their
use became vogue on the WWW.  There has never been a licensing issue,
and I'd like to see solid evidence that a.) Unisys does in fact now own
the rights to the format and have established a copyright for something
that has been a de facto (if not de jure) standard on the Web since its
inception.  It might be true... but for the sake of these discussions I
will resolutely claim my origins as Missouri (the "Show Me" state, for
those abroad who might not get the reference).

The reference to PNG format is interesting, but there are not a lot of
tools out there for making these odd beasts. (I'd like to see some
examples of how they work with FrameMaker, btw.)  PNG files are
perhaps the very best in terms of quality-to-file size (they don't
look nearly as lossy as JPEGs for the same compression factor), but
we still don't see many of these files out there despite the fact that
most common browsers support the format.

As a rule, GIF files are the better choice for graphics composed of
line art and fills of solid colors because a GIF file can contain only
256 colors, as opposed to JPEGs that can contain millions or even
billions.  You can obtain a smaller file with JPEG for this type of
line art, but kilobyte for kilobyte, the GIF will look crisper and be
free from artifacts ("ghosting") at the high-contrast edges.

For photographic or fine-art material, JPEG is the better common
choice since it does have a much broader color palette and therefore
smoother transitions and gradients.  JPEGs created from TIFF files
(Tagged Image File Format) tend to be the better choice for going
to multiple platforms as opposed to those made from PICT (Apple)
files.  I have no authoritative data on this, but have found it to be
the case quite often, and surmise that it has to do with PICT being
equally happy with both vector and rasterized graphics, which might
put a header or preamble in the file that throws some filters off.
(Mac users might already be aware of this when sending JPEG'd
images to non-Mac users via email, depending on the mail client
being used on the receiving end.  Convert to TIFF (IBM format),
then to JPEG for more consistent results.)

For technical manuals with plenty of line art, many of us are still
waiting for PGML (Precision Graphics Markup Language) to make
its web debut, since it allows the line art to be stored as vector
art (much smaller than GIF or JPEG) that can then be scaled
(zoomed) in the browser to yield PostScript-like detail at high
magnification factors (which is what makes PDF much more
desireable for things like interconnect diagrams or schematics).

And that's my two (non-vintage) cents worth!

Tom Regner
Manager, Information Development
Network Equipment Technologies, Inc.
Fremont, CA
http://www.net.com/

>
> From: jeremy@omsys.com (Jeremy H. Griffith)
> Subject: Re: Screenshots to HTML
>
> On Tue, 21 Sep 1999 14:23:00 +0200, "Donna Taragin" <donna.t@sapiens.com> wrote:
>
> >The trouble is you are letting Frame convert the images to GIF.  Frame's
> >conversion is a very poor conversion.  Instead, do the conversion yourself
> >with a better program (e.g. PaintShopPro) and then copy the GIF image as a
> >referenced image into the Frame file.  When you save as HTML within Frame,
> >the GIF images stay as referenced files in the HTML code.  The last step is
> >to copy all the GIFs into the directory with the Frame-produced HTML files.
> >The images are quite nice via Netscape or Explorer.
> >
> >All sounds fine.  When I got to this stage a few months ago, I thought I had
> >it "all together": one source that could go to print, to pdf and to html.
> >However, the problem is the one that was discussed here recently:  A license
> >to use GIFs on web sites from Unisys which costs lots of money.
>
> I'm really glad to see you take this seriously.  IMHO, "due diligence"
> now requires that anyone with GIFs on a commercial site consult with a
> patent attorney to determine whether they need a Unisys license.  The
> information on the Unisys site is *not* sufficient to answer this...
> deliberately.  Enough said.
>
> >The choice is then to do the same procedure with PNGs instead of GIFs.
>
> Or with JPEGs.  Contrary to weel-establishe rumors, we've found that all
> the JPEGs we've used to replace GIFs directly look just fine.  See our
> Web site for yourself; the graphics are all line art, and type, and look
> good.  We used our own mif2go HTML converter, which in turn uses Frame's
> export filters to make the JPEGs.  We got around the nasty problem of
> shrinkage when using Frame's own HTML export by setting the DPI to 96
> instead of 75; you can make it what you please in our .ini file.
>
> >However, Frame seems to convert referenced PNG images into its own version
> >of PNGs.  This is bad because the Frame PNG images aren't even visible via
> >Netscape or Explorer.  When I go into the HTML code and change the Frame
> >PNG-referenced file to my own PNG image, all is fine.  I don't want to have
> >to change each Frame PNG to my own PNG, but there is no choice.
>
> With mif2go, you can specify the image to use, and the graphic attributes,
> in the mif2htm.ini on a frame-by-frame basis.  It uses the ones you name.
>
> >That is where I am now.  If anyone can offer any ideas of where to go from
> >here, I would appreciate it.
>
> Well, mif2go would certainly solve the problem, at $295 for both HTML and
> RTF outputs... and it solves lots of other problems you may not have seen
> yet.  Have a look at our newly-redesigned and expanded Web pages for it:
>   http://www.omsys.com/dcl/mif2go.htm
>
> If you want to stick with the Frame native HTML, one possibility is to put
> your <IMG...> tags in HTML General Macros on the reference pages, then use
> HTML Macro markers in the body.  You could use conditional text to select
> either the real anchored frame for print, or your macro for HTML.  At least
> then you wouldn't have to edit the HTML every time...
>
> - -- Jeremy H. Griffith, at Omni Systems Inc.
>   (jeremy@omsys.com)  http://www.omsys.com/
>


** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **