Re: Any FrameMaker & Ventura Experts?

[Ken d'Albenas <kendal -at- AUTOTROL -dot- CUC -dot- AB -dot- CA>]

This is a long one, friends.  Real long.  If you're not interested

in FrameMaker or Ventura Publisher, hit the DELETE button now.


===================================================================


I've received about a dozen requests today for reprints of the old

article written by an ex-PC Ventura user cutting his teeth on

Macintosh FrameMaker.  He has kindly given me his permission

to rerun it for techwr-L, so here it is.  Some of his problems

were addressed by other contributors in the framers e-mail group,

so I've included them as well for completeness.  His current opinion,

a year or so after switching, is... mixed feelings.  On one hand, he

has more grumbles that he hasn't assembled into a new list; on the

other hand, he feels that Frame is still better than Ventura overall.



========================= Digression... =============================


BTW:

1.  For those interested, you can reach Frame Technical Support by

e-mail at comments -at- frame -dot- com if you have a support contract.

There are also newsgroups for FrameMaker and Interleaf users:

comp.text.frame and comp.text.interleaf

And there's a FrameMaker users' Internet e-mail group:

framers -at- engrg -dot- uwo -dot- ca



2.  If you'd like the latest copy of the FrameMaker FAQ (Frequently

Asked Questions), send e-mail to mail-server -at- rtfm -dot- mit -dot- edu with the

following line in the body:

                send usenet/news.answers/frame-faq




3.  Here's how to subscribe to "framers" (I _think_): send e-mail to

majordomo -at- drd -dot- com, leave "Subject" line blank, and type these three

commands in the Body section:

              subscribe framers
              info framers
              end

(I'm deducing this from the framers list documentation, so of

course it ought to be correct  >:->

I joined under an earlier regime, so it's all theoretical to me.)

If any problems, write to majordomo -at- drd -dot- com and the human volunteer

administrator will reply when time permits.


======================== ...End Digression ============================



And now, on to our main feature...


   (Reprinted from an earlier posting to comp.text.frame)

>   From: sstark -at- Ingres -dot- COM (Scott Stark)
>   Subject: Re: Framemaker Gripes
>   Date: Fri, 24 Apr 92 12:58:42 EDT
>   Reply-To: sstark -at- Ingres -dot- COM (Scott Stark)
>   Organization: Ask Computer Systems Inc., Ingres Division, Alameda CA 94501


>   The following is an opinionated listing of various problems, gripes
>   and inadequacies discovered using Framemaker 3.0 for the Macintosh.
>   As an introductory caveat, the users are a part of a technical
>   communications department that is in the process of converting its
>   entire doc set of 60+ technical manuals from Ventura Publisher on the
>   PC to Framemaker on the Mac.  Comparisons between the two programs are
>   inevitable, and the problems encountered with Frame are coloured by a
>   familiarity with functions that Ventura can perform and Frame should
>   be able to perform.  There is no attempt here to list the glowing
>   advantages of Frame over Ventura.  The general feeling by myself and
>   others in our department is that while Frame offers some distinct
>   advantages, it is a younger program and has major weaknesses in many
>   areas.

>   The bulk of our problems surfaced when we tried to attach tables of
>   contents to every chapter, something which is next-to-impossible to do
>   in Frame.  Other problems arose as we tried to adapt Frame to our
>   desired format, which I think is fairly common and should be fairly
>   simple:  our average publication is a technical manual of 10 to 30
>   chapters, plus a master TOC and index.  All chapters begin with page 1
>   (chapter 3, e.g., begins with page 3-1).  All page numbers, figure
>   captions, TOC/index references and other references use the page
>   numbering convention of chapter#-page# or chapter#-figure#.  All
>   chapters begin on the right-hand page, and the first text also begins
>   on the right page, sometimes requiring a blank page after the TOC and
>   at the end of the chapter.  Blank pages have footers, but no headers
>   (most other pages have headers).

>   1.   Book building and TOC/Index generation.  This process is highest
>        on my list of gripes.  This is probably the most complicated,
>        user-unfriendly process I have encountered in any software,
>        requiring eye-blurring visual coordination and enough mouse
>        movements to give carpal tunnel syndrome to Gumby.  Specific
>        gripes include:

>        a.   Adding chapters to a book.  Only one chapter can be added at
>             a time, requiring you to pull down "Add File" from the File
>             menu, scroll through a list of files to add, and select both
>             its name and position in the book, at which point you are
>             dumped back to the edit mode.  Some of our manuals have as
>             many as 20 or 30 chapters, with a TOC for each one,
>             requiring the user to go through this laborious process as
>             many as 60 times.  It would be helpful to have a
>             "Move/Include/Don't Include" function here similar to
>             selecting tags for TOCs.  The only faster way to select a
>             group of files for a book is to select All, which presents
>             its own set of problems:

>        b.   Rearranging files in a book.  Even if you have been smart
>             enough beforehand to keep only those files in your working
>             folder that will appear in the book, if you select All under
>             Add File, the files are dumped into the book in no
>             particular order.  Deleting chapters from a book is fairly
>             simple, but moving them requires highlighting one chapter
>             and clicking as many times as necessary on the Move Up or
>             Move Down buttons until it is in the exact position.  With
>             50 or 60 files in a book this quickly becomes a nightmare.
>             You can't even hold down the Up and Down buttons to repeat
>             the movement -- you must click once for each position
>             change.  Ideally, I would like to see a resizable window so
>             I could see the whole list at once, and be able to grab and
>             drag the files to the correct position.  Repeatable Up and
>             Down buttons would also be helpful for those still wishing
>             to use them.


>        c.   Set up file.  Once you have gotten all of the chapters and
>             chapter TOCs into the book in the proper order, you must
>             click on Set Up File under the File menu for each and every
>             one, adding prefixes, changing the first page to Start on
>             Right, and changing Page and Paragraph numbering to restart
>             where necessary.  This is another long and nightmarish
>             process, especially when working with 2 or 3 types of files
>             (TOCs, chapters, appendixes) which require different
>             settings -- it's easy to lose track of where you are and put
>             in wrong information.  It would be helpful, since many
>             chapters require the same settings, to be able to apply the
>             same setup features to a number of chapters at once, or to
>             be able to set a different default group of settings.  It
>             would also be helpful to avoid having to use prefixes at all
>             (see below).

>        d.   Prefixes.  In an automated world, it seems quite backward to
>             have to type in a numbered prefix for each chapter.  Frame
>             allows you to define variables within each chapter for the
>             chapter number, and this number will change automatically if
>             another chapter is added or deleted before it.  Why can't
>             Frame pull that variable and use it as a prefix?  If the
>             chapter number does change for some reason, you won't then
>             have to go into Setup in each file and retype a new prefix.

>        [We have found a workaround for much of a-d above:  with the help
>        of someone in our department who has some programming background,
>        we have developed a simple program that generates MIF files using
>        a text editor on the PC side.  With MIF you can specify all of
>        the files you want in a book in the correct order, with the
>        correct setup options and prefixes for each, and all of the tags
>        you want to appear in the TOC.  MIF files are fairly simple and
>        easily copied, and Frame reads them beautifully as book files.]

>        e.   Table of Contents and Index generation.  Another cumbersome
>             process requiring as many as 10 or 15 steps.  Every time you
>             create a new TOC, you must select/deselect the same tags to
>             include -- Frame won't remember what you selected last time.
>             You must also set up the page numbering, startup side, etc.
>             -- there is no way to set the default.  And you shouldn't
>             have to generate the TOC twice -- generate once, open
>             template, use formats from the template, then generate
>             again.  On a large book, generating a TOC can take 20
>             minutes or more each time on a fast machine.

>             (It would be helpful, incidentally, to be able to specify
>             the name of the TOC/index when first generating it, so you
>             could direct the output to a file that already exists,
>             rather than guessing what it would be.  See note following.)

>             There is also no way to select unusual tags to include in a
>             TOC unless the chapter containing those tags is active, even
>             if that chapter is included in the book.

>        [Two workarounds we have discovered here to circumvent Frame's
>        clumsiness:  again, specifying the required tags in the MIF file
>        lets you avoid having to select them manually; and in the MIF
>        file you can also specify the name of the TOC.  If you copy an
>        already-existing TOC (and/or Index) and give it that name (or if
>        you're not using MIF, give it the name you know Frame will create
>        when it generates the TOC (such as "Bookname TOC")), Frame will
>        simply dump the new data into that TOC and you won't have to Use
>        Formats From or regenerate.]

>   2.   Building an individual chapter.  As long as a chapter contains
>        only one file, with no TOC, building an individual chapter is
>        fairly simple.  But as mentioned above, attaching a TOC to each
>        chapter opens up a Pandora's Box of problems, and other problems
>        arise if you need to break up a chapter into subfiles.

>        a.   Chapter TOCs.  While Frame allows you to generate TOCs from
>             within a chapter, it's pretty clear the developers never
>             expected anybody to do it.  To get the chapter#-page# to
>             appear by each TOC entry, we tried putting a <$paranum>
>             variable on the reference page before the <$pagenumber>
>             variable, the <$paranum> pulling an invisible automatic
>             number we had to create for each tag that the TOC pulled.
>             This actually worked, until we ran the Book TOC, at which
>             point Frame turned all of the chapter numbers to zero.
>             After much discussion with Frame tech support, we were told
>             to make a separate book for each chapter, including only one
>             TOC and chapter file in each, and, again, to type in
>             manually prefixes for each (see gripes 1.c through 1.e
>             above).  This not only more than doubled the already
>             cumbersome book building process and created more files that
>             we don't want included in our master book, if the chapter
>             numbers should change for any reason, that is one more place
>             we'll have to remember to manually change the chapter
>             number.

>             We also discovered that when this chapter TOC is generated,
>             the chapter number variable is initialized.  Chapter 7, for
>             example, becomes chapter 1.  The only way to get it back to
>             7 is to regenerate the book TOC.  This means every time the
>             chapter TOC is rerun, we will also have to rerun the book
>             TOC, a process which can take 20 minutes or more.  The only
>             workaround for this problem is to give up on Frame variables
>             altogether, and type the chapter number in manually; but if
>             the chapter number changes somewhere down the line, this
>             would require us to manually change the number in the
>             chapter number tag, the chapter TOC setup file, the book TOC
>             setup file, and probably other places as well (would that
>             number be pulled into footers, frame captions, table
>             headings, cross references, etc.?) for that chapter and all
>             subsequent chapters.

>        b.   Chapter titles, numbers, footers.  There is a strong
>             disadvantage to Frame's requirement that the TOC be a
>             separate file from the text file.  In order for the title
>             and number to appear in the footer or header of every page,
>             it must pull them from a tag within the chapter.  But the
>             chapter title and number appear at the beginning of the
>             chapter, which is, you guessed it, on the TOC page.  Since
>             this is a separate file, the chapter file footers can't make
>             reference to them (except by using cross-references, but you
>             can't make reproducible templates with cross-references in
>             them -- they'd all refer to the same file).  And you don't
>             want the title and chapter number to appear again on the
>             first text page.

>             Our solution was rather complicated -- we created a second
>             frame on the first text page in an area above the text
>             column, and tagged the chapter number and title paragraphs
>             to print in a colour we'll have to turn off when printing.
>             This frame will unfortunately cover up any header that runs
>             into it, and we had to readjust our first-level heading tags
>             so that the first one would stay on the same page (by
>             telling the tag to start "top of column" rather than "top of
>             page" -- fortunately we only have one column in our
>             chapters).  Developing this somewhat clunky system took a
>             lot of time and trial and error, and was much more
>             complicated than I feel it should have been.

>             [Incidentally, Ventura allows you to put the TOC in the same
>             chapter as the text, in a separate flow that is
>             automatically updated whenever the TOC is regenerated.

>        c.   Multi-file chapters.  Frame tech support recommends not
>             having chapters that are broken up into separate files.
>             However, large chapters -- 200+ pages -- are very slow to
>             work with, and Frame does have memory limitations.  But to
>             break up chapters into 2 or more files requires that each
>             subchapter have its own chapter title and number frame, as
>             described in b above; otherwise the footers will not be able
>             to refer to this information.  Since the page containing
>             this extra frame must be a "first page" master page, it must
>             necessarily be a left or right page, which may be incorrect
>             depending on the left or right position of the last page of
>             the previous chapter.  Also, when you generate the chapter
>             and book TOCs, the chapter title and number will be pulled
>             from each subchapter, and therefore will be repeated for
>             each.

>        d.   Blank page no header.  In our publications, blank pages --
>             such as an extra left page at the end of a chapter -- have
>             the headers turned off.  This is easy enough to do by
>             applying a no-header master page; but if the text in the
>             chapter expands or contracts, text may eventually appear on
>             that page, at which point it should have a header.  It also
>             seems possible that if enough text is added at the end of a
>             chapter, that no-header page may end up somewhere in the
>             middle of the chapter.

>   3.   Formatting.  In general, the "Use Formats From" is a burdensome
>        extra step, and can create some problems.  [Ventura uses a single
>        style sheet which can be used by any number of chapters.  When
>        the style sheet is changed, it is changed for all chapters that
>        use it automatically.]

>        a.   In Frame you have to keep a master template with the proper
>             formats and remember to apply it to every chapter.  If you
>             make a change to your master style sheet, such as changing a
>             typeface or something as simple as changing an indent, you
>             would have to apply the new formats to every chapter of
>             every book, which in our case would be hundreds of chapters.

>             [Ventura allows you to replace the old style sheet with the
>             new one, and all chapter would then automatically access
>             that new style sheet.]

>             If page layouts are changed, this would also require
>             manually changing any header/footer text in the master FOR
>             EACH BOOK before applying formats, since the footer contains
>             information specific to that book (such as the book's
>             title).  This would multiply the format application process
>             by the number of books involved and more.

>             Further, in setting up books, we have found it necessary to
>             use as many as 8 different templates:  one for chapters, and
>             different ones for appendixes, prefaces, title pages, book
>             TOCs, chapter TOCs, indexes, glossaries, etc.  Applying
>             separate formats to each type of chapter to 60+ manuals
>             elevates this already cumbersome process to nightmarish
>             proportions.  And since Frame is new to us, once we start
>             working with it on a day-to-day basis, we may need to make
>             further changes to the templates, requiring us to repeat the
>             process any number of times.

>        b.   If you have made any changes to a specific paragraph without
>             creating a new tag, applying formats wipes out your changes.

>        c.   It's a minor annoyance that you must have the template file
>             open to use the formats from it.  It would be nice to be
>             able to use the formats from any file on the disk without
>             having to open it.

>        d.   There is no way to tell which format has been used in a
>             file.  You run the risk of later applying the wrong format
>             to a file.  [Ventura displays the name of the style sheet
>             used in the chapter.]

>        e.   There is no way to change the page size in a file, except by
>             copying the text into a newly created document of the right
>             size; doing this is not only cumbersome, but you lose all
>             page formats in the process.  If you then apply the page
>             formats from the old document, your new file reverts to the
>             old page size.

>        f.   There is no way to delete unnecessary tags en masse from
>             several chapters at once.  Applying formats to a chapter
>             only adds new tags to those already there.

>        g.   Page layout and header/footer information should be two
>             separate selections on the Use Formats From menu.

>   4.   Word Processing.  Frame's word processing capability is a strong
>        selling point; however, there are a few problems.

>        a.   Spell Checker.  The Spelling Checker is pretty good, but it
>             would be useful to have a "skip once" as well as "allow in
>             document" button.  Also, it should correct every instance of
>             a misspelled word.

>        b.   Find/Replace.  When using Find, Frame searches through the
>             entire document and then starts again at the top without
>             telling you it's done so.  Unless you're watching the page
>             numbers below, you might not realize that you've already
>             found the string or code you're searching once before.  It
>             would be helpful if Frame told you when it had reached the
>             end of the document and asked you if you wanted to continue
>             from the top, and then shut down when it reached the point
>             where you began the Find.  I can't think of any reason why
>             you'd want to find the same string twice.

>        c.   "No insertion point."  This annoying message appears if you
>             choose Find and haven't clicked on the text in the active
>             file.  I can't think of any reason why you'd want to search
>             for something without first inserting the cursor.  Frame
>             should assume you want to search the active window without
>             requiring you to click on the text.

>        d.   Change & Find.  Going through a document and selectively
>             changing found text requires you to move the mouse cursor
>             back and forth between the Change & Find buttons and the
>             Find button (if you elect not to change).  This makes the
>             process tedious.  Most word processors allow you to select Y
>             or N from the keyboard.

>        e.   Block functions.  Block functions are generally excellent,
>             but it would be useful to be able to anchor the cursor,
>             search for a character string, and block from your anchored
>             position to the found string.  Any word processor can do
>             this.

>        f.   You cannot select alternate paragraphs.  This would be
>             useful when, say, every other paragraph required an
>             automatic number.

>        g.   Page breaks.  There doesn't seem to be any way to force a
>             page break, except to make a blank paragraph with negative
>             leading; but the value necessary for this leading will vary
>             depending on the size of the type in the following
>             paragraph.  If you tell the next paragraph to start "top of
>             page" in the paragraph format menu, applying formats to the
>             chapter will wipe out that change.  Perhaps a "bottom of
>             page" or "page break after" option would be useful here.

>        h.   Side-by-side text.  There is no way to make text appear side
>             by side in a single column, without either creating a table,
>             or creating an anchored text frame, neither of which is tag-
>             dependent; both require extra steps.  [Ventura allows you to
>             start a second paragraph on the same line as the first.]

>        i.   Smart quotes.  This is a useful function, but it is
>             document-specific rather than tag specific.  In some of our
>             paragraph tags we do want smart quotes, and in some we
>             don't.  There is no way to make them tag-specific.

>        j.   It would be useful to be able to open windows for different
>             parts of the same document simultaneously, allowing you to
>             move/copy text easily within a chapter.

>        k.   Copying to the clipboard doesn't always work, especially
>             after first starting Frame.

>        l.   Hyphenation.  When Frame doesn't recognize a word, it will
>             hyphenate it arbitrarily, e.g. PROGRAM/ESQL might hyphenate
>             PROGRAM/E-
>             SQL.

>        m.   Variables -- the <$paranum>-type variables are useful, but
>             they are rather cryptic -- you practically have to be a
>             programmer to use them.  It would also be nice to be able to
>             use them anywhere -- in paragraph tags, on reference pages,
>             etc.

>   5.   File management.

>        a.   Copying a book.  There is no way to copy or move all of the
>             files in a book to another folder or diskette without losing
>             the "pointers" to files/graphics imported by reference,
>             unless it's to another disk with the exact same path struc-
>             ture.  This is especially a problem if you wish to move or
>             copy a book to a new folder on the same disk.  There is no
>             way to copy a book to diskette if the book is bigger than
>             one diskette, other than manually moving individual files
>             over using the Mac Finder.  References to import-by-
>             reference files/graphics are lost.  [Ventura has a COPY ALL
>             command which copies the entire publication to diskette,
>             prompting you to replace diskettes when full, and changing
>             all of the reference pointers -- a very useful function.]

>        b.   There is no list of graphics files that are referred to by a
>             chapter, or where they are located.  You must click on each
>             frame and select Properties to display this information.  If
>             graphics were imported from several different
>             sources/folders, they might be overlooked when copying the
>             book to another folder or disk.  You might also
>             inadvertently copy graphics files that were unnecessary,
>             since there is no way of knowing which were used.

>   6.   Tables.

>        a.   When converting text to tables, and also when applying
>             formats to tables, any character formatting in the first
>             column is lost.

>        b.   There is no way to make a table format with customized
>             attributes, such as an invisible column or straddled
>             columns.

>        c.   Minor custom changes made to a table format, such as
>             resizing the columns, will only affect subsequent tables
>             created using that format.  Applying the new format to
>             previously created tables using the same format name are not
>             changed.

>   7.   General usability.  I have been accused of being a PC bigot, but
>        I believe that for many functions it is faster, easier, and more
>        efficient to enter commands from the keyboard than to use the
>        mouse.  The keyboard requires less eye strain and hand movement.
>        Simply typing "Y" to a prompt is certainly easier than locating
>        the Yes button, locating the pointer, moving it to the button and
>        clicking, and you don't even have to look at the screen to do so.
>        I would like to have the option to use the keyboard whenever
>        possible.  This would include answering yes/no prompts as well as
>        selecting files, tags, format-from files, etc. from scrolling and
>        pull-down lists.  (You can, for example, select a file name from
>        the Open File dialogue box, but only if you type very quickly and
>        accurately.)  Some specific things:

>        a.   When closing a file, you can press "Y" to say yes, "N" to
>             say no to save the file.  But when you select Save As and
>             the file name already exists, you should also be able to
>             press "R" to replace.

>        b.   Dialogue boxes pop up in different places around the screen,
>             requiring you to keep moving the mouse around.  Each "OK"
>             button should appear in the same position for each box.  An
>             example is the series of dialogue boxes that appear when
>             generating a TOC.

>        c.   It would be useful to be able to select items from the
>             keyboard from pull-down lists, such as when applying master
>             pages or using formats from a list of files.

>        d.   It would be useful to have the option to use "drop-down"
>             menus as well as "pull-down" menus -- menus that pop up when
>             the pointer moves over the selection, without pressing the
>             mouse button.

>       - Scott Stark
>         ASK/Ingres Tech Comm




==============================

>  To: framers -at- engrg -dot- uwo -dot- ca
>  From: sei -dot- cmu -dot- edu!ask -at- auto-trol -dot- com (Alan Koch)
>  Subject: Re: Framemaker Gripes
>  Date: 10 Apr 92 13:18:34 GMT
>  Organization: The Software Engineering Institute


>  In article <1992Apr9 -dot- 221223 -dot- 16518 -at- pony -dot- Ingres -dot- COM>, sstark -at- Ingres -dot- COM (Scott
>  |>
>  |>      The following is an opinionated listing of various problems, gripes
>  |>      and inadequacies discovered using Framemaker 3.0 for the Macintosh.

>  I MUST commend Scott for his gripes!  They are an EXCELLENT example of
>    1. Researching the topic -- except for my notes below, he was exactly right
>       in his statement of how Frame works,
>    2. Not flaming, but giving useful comments and information.
>  If only more gripes took this form!

>  Frame; are you listening?  Read his gripes carefully!


>  |>      4.   Word Processing.  Frame's word processing capability is a strong
>  |>       selling point; however, there are a few problems.
>  |>
>  |>       a.   Spell Checker.  The Spelling Checker is pretty good, but it
>  |>            would be useful to have a "skip once" as well as "allow in
>  |>            document" button.  Also, it should correct every instance of
>  |>            a misspelled word.

>    In the Spell Checker window, there is a check-box you can turn on which
>    says, " Correct Future Occurrances Also".

>  |>       c.   "No insertion point."  This annoying message appears if you
>  |>            choose Find and haven't clicked on the text in the active
>  |>            file.  I can't think of any reason why you'd want to search
>  |>            for something without first inserting the cursor.  Frame
>  |>            should assume you want to search the active window without
>  |>            requiring you to click on the text.

>    Since you can have many documents open at once, FrameMaker needs to know
>    which one to check.  I agree with their requirement for you to explicitly
>    tell the system where to look.

>  |>
>  |>       d.   Change & Find.  Going through a document and selectively
>  |>            changing found text requires you to move the mouse cursor
>  |>            back and forth between the Change & Find buttons and the
>  |>            Find button (if you elect not to change).  This makes the
>  |>            process tedious.  Most word processors allow you to select Y
>  |>            or N from the keyboard.

>    Frame gives you keyboard ways to do EVERYTHING!  In the Search window, tab
>    until the Change & Search Again button is the active button.  (Note that
>    Search is the default button.)  Now the space bar will activate Change &
>    Search and the Return key will activate Search.  (At least this is true in
>    the X version.)

>  |>       f.   You cannot select alternate paragraphs.  This would be
>  |>            useful when, say, every other paragraph required an
>  |>            automatic number.

>    Basic Property Sheet: Next Paragraph  You can specify that Paragraph tag A
>    should be followed by B and B should be followed by A.  (If I understand yo
>    properly.)

>  |>       k.   Copying to the clipboard doesn't always work, especially
>  |>            after first starting Frame.

>    Known bug.

>  |>      7.   General usability.  I have been accused of being a PC bigot, but
>  |>       I believe that for many functions it is faster, easier, and more
>  |>       efficient to enter commands from the keyboard than to use the
>  |>       mouse.  The keyboard requires less eye strain and hand movement.
>  |>       Simply typing "Y" to a prompt is certainly easier than locating
>  |>       the Yes button, locating the pointer, moving it to the button and
>  |>       clicking, and you don't even have to look at the screen to do so.
>  |>       I would like to have the option to use the keyboard whenever
>  |>       possible.  This would include answering yes/no prompts as well as
>  |>       selecting files, tags, format-from files, etc. from scrolling and
>  |>       pull-down lists.  (You can, for example, select a file name from
>  |>       the Open File dialogue box, but only if you type very quickly and
>  |>       accurately.)  Some specific things:

>    There are keyboard ways to do almost EVERYTHING.  Look at your Shortcuts
>    document.  I believe everthing you mentioned is in there (except "Drop-down
>    menus -- I've never seen such a thing.)



===========================

>  To: framers -at- engrg -dot- uwo -dot- ca
>  From: erg -dot- sri -dot- com!bigmac -at- auto-trol -dot- com (Bryan McDonald)
>  Subject: Re: Framemaker Gripes
>  Date: 23 Apr 92 19:57:55 GMT
>  Organization: CHAOS - SRI International, Menlo Park, CA, USA

>  >>      e.   There is no way to change the page size in a file, except by
>  >>           copying the text into a newly created document of the right
>  >>           size; doing this is not only cumbersome, but you lose all
>  >>           page formats in the process.  If you then apply the page
>  >>           formats from the old document, your new file reverts to the
>  >>           old page size.
>  >
>  >Before anybody says "why would you ever want to do that?" let me point
>  >out that we are entering the era of electronic publishing, where you
>  >are quite likely to have to put the same book out for both print and
>  >CD-ROM or other on-line viewing.
>  >
>  >The page size that's best for paper is almost never the best for on-line
>  >reading.  So you are extremely likely to want to change the page size
>  >of an existing print book when publishing to another medium.

>  There is another way.  Save the file to MIF, use your favorite ascii
>  editor (or Frame for that matter) to edit the ascii mif file and
>  alter the page dimensions, then re-open it.  Worked for me when I was taught
>  it at the Frame Training class.



=================================



>  From: kendal -at- autotrol -dot- cuc -dot- ab -dot- ca (Ken d'Albenas)
>  From kendal Thu Apr 30 02:33:12 1992
>  To: sstark -at- Ingres -dot- COM
>  Subject: Re: Framemaker Gripes

>  A couple of tips, possibly helpful, possibly old news:

>   Re  4 (i): Leave smart quotes on.  Train people to use the keystrokes
>       that force straight quotes (see Frame documentation).

>       Re  4 (l): It's not hard to train people to type the hyphenation-suppres
>       keystrokes (Meta-Shift-minus on my platform) at the beginning of
>       computerese words like PROGRAM/ESQL.  You can also put them in your
>       dictionary with hyphenation defined.  Myself, I prefer to turn
>       these things into variables to prevent typos, and you CAN type
>       the hyphenation-suppression keystrokes in a variable.  Although
>       the symbol doesn't show up in the variable definition box (a small
>       nuisance in itself), it does in the document.

>       Re  7 (b): The first time a window pops up (dialogue box, character
>       format catalogue, confirmation window, etc.), move it where you want
>       it to be.  From then on, that's where it'll appear for the duration
>       of your session or until you move it again.  By this method I've been
>       able to spare my carpal tunnel during long, repetitive editing
>       operations that use one window which generates another needing
>       acknowledgment.



=============================



Th-th-that's all, folks!


Cheers,

Ken d'Albenas
STC Alberta Chapter
(-::
kendal -at- autotrol -dot- cuc -dot- ab -dot- ca


*****************************