Bug, or ER
224774
This is my personal wish and bug list for FrameMaker. You will note that within this page you find a mix of you might call a "bug" and what you might call a "wish." While I have my own personal definition of a bug and a wish, I'm not going to spend a lot of time delineating between the two. This list, then, could be called "this is the way I wish Frame did it..." Things that I personally think are bugs are at the bottom of the page.
Also, I want to add that when possible, some features should be external code . . . I don't want Frame to be bogged down in the same mire of Word's bloatedness.
Text in red indicates items that, in my opinion, are hindrances to Frame making advances into certain aspects of business (in other words, taking over Word or QuarkXPress, financial publishing, etc.).
Samples are included for some of these. These are MIFs saved from version 7, then zipped.
There is a lot of complaining about Frame's interface: It's not graphical, it's not intuitive, and so on. Personally, I couldn't care less, because I am of the opinion that the "intuitiveness" of an interface is only useful during the learning curve. In other words, once you've got it down, you don't care how the menus are organized. I'm tired of hearing how the fonts list doesn't show enough fonts (you shouldn't be using it anyway) or how the ruler isn't cool enough (same reason).
But assuming for the moment that Adobe will do something with the interface one of these days, I hope they don't make it so "pretty" that it becomes a resource hog. (Some Illustrator palettes can soak up some serious resources.)
Wider fields and dialogs. The width of some dialog fields is too narrow; numeric values get chopped off at one end or the other. The field for the width of a table cell, as an example, is just plain ridiculous. The dialogs for things like an index and cross-ref markers are miserable. When the world was full of 14-inch monitors we had to have small dialogs, but those days, and those monitors, are gone. The good news: A fellow named Klaus Daube has created a modified fmdlg.dll for Windows that has nice wide fields for the Resize Selected Column dialog box. You can download it at http://www.daube.ch/docu/fmaker20.html.
Show us the path. Some dialogs that show paths to files chop the path down to next to nothing. Show us the whole path, start to finish, and let it wrap when needed.
More keyboard support in dialog box lists; Shift+ and Ctrl+click. In the "Set Up Table of Contents" for example, pressing a letter should jump you to an item in the list. Some dialogs do, some to not. Further, you can't Shift+click or Ctrl+click either, and the up/down arrow keys don't work.
More keyboard support for Mac. I've never liked the mouse at all, and, on a Mac, I'd like to use Tab and other keys to do my work, or press the first letter of a button (like many Microsoft programs). Some dialogs and alert boxes support this, most do not.
Do dialog tabs differently. For example, in the Numbering Properties dialog, you can change tabs by clicking the tab itself or by using the little pull-down field. The pull-down field is unnecessary (more code, more clutter, lost real estate, more RAM). But guess what you can't do? You can't change tabs by pressing Ctrl+Tab!
Combine a few dialogs. Some of the dialogs dealing with page size, pagination, etc., can be combined.
Screen refresh. We all know about that.
Navigation with open dialogs. Many Frame dialogs float, such that you can navigate around while they are open. However, some that probably should do not, such as the cross-reference, table's Resize Selected Column dialog, and the numbering and pagination dialog of a book.
Show overrides, both paragraph and character, in some special way so one can skim thru a doc and find them quickly.
Redo last action F4, as in Word. The "repeat last character command" and "repeat last paragraph command" are okay, but a generic F4 could be used for other actions.
Quick outline view. I use the TOC for that now, but a separate view would be nice. The ability to adjust levels, like Word, would be frigging' awesome, dude!
Pop-up information:
Book-in-a-book. Drop a book file within another book file, and you can operate upon it in several ways: (1) A generate could skip over it, or could include it; (2) a double-click expands it as though it were a part of the main book.
Skip-a-file feature, which is the same, really, as removing a file from a book for temporary reasons, only it's easier, and it has options. Application: You have a training guide, and you are using conditional text to identify leader material and student material. These kinds of books typically have a preface or introductory material that is for the leader only, and when you print your student guide, you don't want the file mentioned at all (TOC, index, blanks, etc.). The skip-a-file feature would tell Frame to completely ignore the file during TOC and index creation, pagination, and so on. (One solution that does not work is to turn the whole chapter into a condition, but the problem with that is that you get a blank page.)
If...then cross-refs. Dealing with cross-refs that point to the same page is one example. Imagine how cool it would be to have one cross-ref definition do:
Object-counting building blocks. For example, a building block to count the pages between the reference and the marker, as in "as described in the next 12 pages". Other more complex examples count specific paragraphs, as in "the next 15 steps" and "the last four figures". For that last one, the counter could do spelled-out numbers according to rules like "for nine and under".
Start numbering at an ASCII value, which then gives us a way to use dingbat fonts in numbering. Zapf Dingbats, for instance, has several sets of circled numbers. One of these sets starts at ASCII value 0202, and counts up for the next nine. The idea, then, is to be able to start the numbering at n=0202. Frame could not be responsible for the specific glyphs, of course, or for fonts that skip around.
Number of digits. Tell Frame you want three digits, and you get 001, 002, etc.
Count by x. Count by n+3, for instance.
Count in reverse as in by n-3.
Inline numbering that lets you number within a paragraph (a) like this, (b) as an example. This could work similar to Word's SEQ field.
Line numbering. 'Nuff said.
Style inheritance. The usual "based-on" stuff.
Percent size. Character tags based on a percent or +/- value of the surrounding text. This would be particularly handy for using dingbats as bullets, where you want the dingbat to be, say, 110% of the size of the rest of the text in the paragraph.
Add a vertical shift field. Funny thing: You can manually edit a MIF to shift a character up or down, but you can't do it from a dialog! And if you do add a shift to a tag and then later change something using the designer dialog, the shift you added previously is history.
Delete character tag resets character. Say you have tagged some words with a character tag. If you delete that tag, the text remains "tagged" and still retains the appearance. An option to reset the text to its native state would be ideal.
Remove local overrides part 1: Implement Word's Ctrl+space and Ctrl+q. In Word, Ctrl+space resets selected text to the character specifications defined in the assigned style; Ctrl+q resets a paragraph to to its specifications. I find it odd that Frame, which really likes to adhere to specific definitions, makes it so difficult to remove deviations from those definitions.
At the same time, Frame could improve on how Word does it: Say that you have used a character style called Bold and applied to a single word in a paragraph. In Word, if you select the paragraph then press Ctrl+space, the Bold is removed. Frame could add an additional command, thus giving users the choice of removing all overrides including local character formatting that used tags, or remove all local overrides except those that use tags.
Remove local overrides part 2: A tougher approach to importing tags. When you import formats, you have the option to select "Other Format/Layout Overrides." This check box implies that overrides will be ... Well, "overridden" ... But it's not strong enough: You can easily end up with a document full of those plus signs that indicate an override is detected. The wish, then, is to offer an option to really clean the doc as described above.
Add an "inside" and "outside" justification to the paragraph tags. For example, an outside-justified paragraph would be the usual left-justified on a verso (left) page and appear right-justified on a recto (right) page.
Add a right tab whose position is defined at the right margin, regardless of the width of the column.
Allow a tab to reside to the right of the right
margin so that text in a table of contents can wrap
like this when the line gets real long ................................................23
Show cumulative character formatting. Say you have a character tag called Bold and one called Italic, defined to be only bold and italic. If you apply Bold to text, the status bar reflects Bold. However, if you then apply Italic, the status bar reflects only Italic. But not only does the status bar reflect only Italic, Frame will seem to have forgotten that it's also Bold: If you search for Bold (the tag), Frame won't find it, but it will find Italic.
Add another superscript-type setting, like QuarkXPress (Format > Document > Text options). This is important when setting material that has both math superscripts and footnote superscripts. Presently, the size and the default offset of a regular superscript is different than the default size and offset of a math superscript. That may be indeed what you want, but it presents a hassle: You must always use the equation editor for even a simple x-squared.
Fix the table border implementation. Here are some steps to can take to see what's wrong: Create a table tag with a thick rule (there is no dependency on this, it's just easier to see) on the outside top and bottom rules, and very thin rules for all body rows. Insert sufficient rows so that some rows jump to the next page. If you choose "Draw Bottom Ruling on Last Sheet Only", the bottom-most rule of the first page gets no rule at all. I can live with it, but I rather think it should get the thin rule, while the thick rule waits until the actual last row. Additionally, the top row of the second page gets the outside rule. Since it's not really the outside -- only the first row on the first page is -- it should have a thin rule.
Decent conversion of tables to tab-delimited text. Not just that row-by-row or column-by-column stuff.
Floating table dialogs. Some table dialogs must be closed before you can get back to the table. It's a pain in the rear for things like working with column widths.
The column-width dialog needs a button to move to the next column, or, at least, let it float.
More borders. Namely, pattern lines (dashes, dots).
Quick command to change top n rows to header(s). And, vice versa. Presently, you must take several steps to add a header, copy the text into it, then remove the old first row. This is particularly a pain when importing files from Word, because a table heading row in Word comes in as a table body row in Frame.
Table in table. Using an anchored frame works okay, but I'd like to just put a table anchor in a cell.
A footnote on the same page as the cell that references it. Presently, all table footnotes appear at the end of the table.
Revision bars for table cells. Presently, a change to the contents of a cell marks the whole table as changed.
Revision tracking. I added this because it's asked for a lot, but I hope to God it doesn't bog Frame down.
Controlled revision backups. For example, back up File001, File002, etc., and allow the backup to be placed in different folder than the one you're working in.
Cleaner update when graphics are relocated. In Quark, for example, you can tell it that once it has located a graphic in a folder, it's okay to look for the rest of them there, too. Frame does this only if it does not have to jump to another folder as it processes the list.
Headers/footers that stay put. If you change the margins of the main flow, the header and footer frames move as well. I can live with the width automatically changing -- 99% of the time it's what I would do anyway -- but I don't like to have to shift the headers and footers up and down.
Linking of dissimilar frames Frame won't let you use a combination of master pages that use (for instance) a sidehead appearance on the regular pages and no sidehead on a custom master (not linked, anyway).
Support for MathML, the Mathematical Markup Language, a seemingly logical extension to the other markup languages Frame supports. This would allow the import of MathType equations, because they support it.
Book-level variable management. It's a mighty nasty little process to delete unneeded variables from multiple files in a book. Frame could create a composite list of all variables in all files (similar to the way the TOC setup lists paragraphs) and allow editing, merging, and deletion.
A "partnum" variable should be added to accompany the volnum and chapnum variables added in FM6.
A total pages variable for the whole book.
A variable can pull the tag from a previous page. The algorithm would work like, "if the first paragraph on a page is NOT a heading of interest, get the heading from its previous instance."
A variable can pull the tag from the previous file. Extremely handy when you have to break a file into pieces to account for different paper, for instance.
A few more defaults. For example, default arrow configurations, corner radiuses, runaround on/off, etc.
Additional file types. Corel, Visio, SVG, native PS, HTML import, beef up CAD import, some others.
Fix some Word import issues. After all these years, Frame still turns Word table heading rows into body rows.
In some cases, samples are provided.
| Zip | Incident, Bug, or ER |
Description |
|---|---|---|
|
711228 224774 |
Certain combinations of lengths of running heads, follow-on body text, and column width will look terrible. Three distinct bugs are identified and screen shots provided. You will need Times and Helvetica. |
|
A footnote to a table is allowed to exist alone on a page if the table ends up at the bottom. | |
| none | In a Frame Find dialog, \f is supposed to be the end of a cell or flow. However, it seems to find anything; in other words, it's ignored. And yes, I've tried it with Wildcard selected and not selected. (You can get around it using \x0b.) Adobe should either fix it, or remove it from literature. | |
|
This zip includes EPS and WMF files that have a problem with the enclosing frame. The problem with the WMF is that the entire graphic shows past the edge of the frame. The EPS looks okay on screen, but if you print or PDF it, the graphic also shows through. |