DynaText Tables (was: Online help for SGIs?)

[Glenda Jeffrey <jeffrey -at- HKS -dot- COM>]

Mysti Rubert <Mysti -at- SYBASE -dot- COM> wrote:
> We use DynaText in our online docs.  The biggest "gotcha" we have is the
> handling of tables (can't be inline, I think) and especially graphics.  I
> don't
> know if its a clash between DynaText and Frame, or our particular
> implementation
> or what, but we have TWO versions of every frame graphic in each doc--one
> for print, and one for online.

Must be DynaText+Frame. We're writing directly in SGML and we have no
problems putting tables and figures inline.

Well, that's not quite true.

There's a bug in the hardcopy renderer (that produces printed output)
which causes the tables to come out completely screwed up UNLESS they
are at the top of a page. We've temporarily solved this by insisting
that a page break occurs before each table. I know, this is a lousy
solution, but they are supposedly rewriting the print renderer,
so the problem should be fixed in the next release. (Famous last
words... ;-)

Regarding graphics -- there are a couple of problems, one of which is
DynaText's, and one of which is the nature of the beast.

The DynaText problem is that for some reason, both the online and the
print renderers insist on placing carriage returns before and after
all graphics, whether they are inline or not. This results in small
inline graphics (like icon screenshots, for example) ending up on
a separate line. Yuk. Again, this is supposed to be fixed in the next
release.

The other problem is just that some figures that look great online
look lousy in print because the color scheme does not translate well
to black and white. Obviously, this can be solved by providing two
different figures for online and print (and DynaText will let you do
that); however, this solution GREATLY increases the size of your
distribution because graphics files tend to be huge. We've elected
to just sacrifice the quality of the printed figures.

> Icky.

Yes, but hopefully things will improve shortly. I'd encourage you
to complain to EBT about any problems you're having, so that the
problems get fixed in the next release. The squeaky wheel definitely
seems to get the grease.

> What does SGI author in, especially the graphics?

They currently use Frame. Here's a summary
of what they do, direct from the horse's mouth (Victor Riley
at SGI):

"...we author in Frame and use a translator
to convert from MIF to SGML.  Our Frame files reference the images directly
on disk, so they have all been captured by hand.  Unfortunatly there is no
automatic means to capture pictures, the writers do it all by hand using
various versions of imgsnap and wrappers to imgsnap that allow us to position
the window menu items first before the snap is taken.

"All these images are in RGB format and referenced by Frame.  Then the
writers use the tools within Frame to add any callouts, or compositing
in the images.  In those cases we use a tool from Carberry
Technologies to convert the images with callouts, composites, and
Frame line art images into CGM files.  Those that contain rasters are
then converted back to GIF.

"We have an entire process devoted to converting figures from one format into
GIF or some other format viewable by DynaText.  We convert from Postscript,
XWD, RGB, into GIF.

"Except for the Carberry tools and the PBMPlus tools, the rest are internal
SGI tools.  Unfortunately none of these tools are available as a product
from SGI."

Hope this is helpful...
--
Glenda Jeffrey                                     Email: jeffrey -at- hks -dot- com
Hibbitt, Karlsson & Sorensen, Inc                  Phone: 401-727-4200
1080 Main St.                                      Fax:   401-727-4208
Pawtucket, RI 02860