T1ManagerM is a mock-up of a new GUI design for T1Manager from
util/libs/Type1Engine. It is a MUI application written in ARexx, developed on an
A4000/040 with AmigaOS 3.9, MUI 3.8, RxMUI 42.6, and RoyalBridge 1.1.
I have some criticisms of T1Manager, and although the source code is available,
my programming experience is more with ARexx than with C. As this package
apparently has been out of development for many years, I appeal to the Amiga
community for an interested developer to consider my input. I offer this mock-up
and the accompanying suggestions in the spirit of improving software on the
Amiga.
My mock-up script illustrates many of my suggestions. It reads the installed
font files but doesn't change them, so you can play with it all you want. To
open the modify window you must have installed at least one Type 1 font using
the real T1Manager.
Bugs
The drawer cycle shows only 10 drawers from the Fonts: assign. It should show
all of them, no matter how many. Better yet, use a PopASL to specify any drawer,
not just assigned Fonts: targets (see Feature Requests below).
Fonts often fail to install and the error messages I've seen are cryptic and
unhelpful. One says "Error 4, Can't build SpaceWidth & YSizeFactor for type1
file:" followed by the file name. Why can't T1Manager install the font? A
programming error? Is the font file broken? If so, how? The user needs to know.
Update: This problem seems to be a program error; some fonts fail to install on
one occasion, and then succeed on another.
Renaming a font fails when the changes are only letter case.
Changing the encoding sometimes fails: e.g. unchecking Internal on Adobe's
ZapfDingbats 1.4 complains "Error reading font - perhaps it needs to be modified
or removed and reinstalled?".
When a file can't be processed during any action, the program should give the
DOS error message: e.g. "object not found", "file is read protected".
About type1.library rather than T1Manager: When ObtainInfoA() OT_GlyphMap fails
because the Type 1 file can't be read, the result code is the undocumented value
-4. According to the diskfont/oterrors.h include file, the value should be 6.
Processing Errors
Installing, modifying, renaming, and deleting fonts unnecessarily reload the
font list. These actions should just insert and/or remove entries as necessary.
Renaming fonts should sleep the application so the busy pointer appears, as it
does for installing fonts.
Closing/canceling the Install file requester unnecessarily reloads the list.
I've found that renaming a font that has no sizes drawer unnecessarily creates
one.
GUI Cosmetic Errors
An input listview should have an input (raised) frame rather than a read-only
(recessed) frame, e.g. the font listview.
An empty input listview should be disabled.
An action button that opens a window or requester should have a label that ends
with an ellipsis, e.g. "Install...".
Boolean values should be shown as checkboxes instead of cycle gadgets, e.g.
Serifs.
GUI Visual Improvements
In my judgment the main window looks better with the drawer gadget under the
listview and the buttons at the bottom.
The Install file requester's OK button label should be "Install" and the title
should include that word.
I reordered the attribute cycle gadgets to match the usual order in font names.
I relabeled some gadgets with more user-friendly names, e.g. "YSizeFactor" to
"Height Factor", and with more specific and accurate names, e.g. "Delete Size"
to "Remove Sizes". In my view "remove" is more appropriate for taking entries
and values off a list; "delete" is normally used for erasing an object from
existence.
In my redesign I prevent the cycles and numeric strings from uselessly expanding
horizontally.
Processing Improvements
My mock-up sets the SingleTask attribute: A tool that manages fonts, which are
global resources, probably shouldn't run as multiple copies.
Load the font list initially before opening the main window.
I've found that when loading a list, inserting list entries at the bottom and
then sorting is faster than inserting sorted.
Loading and multiple changes to lists should use quiet mode for better speed and
less visual activity.
Input listviews should have a control character and indicate it in a label.
The multiple-selection listviews Fonts and Sizes should have pop-up selection
menus containing All, Toggle, and None items. Of course, each item should be
disabled when it has nothing to do.
The fonts listview should be the main window's default object so it can be
controlled from the keyboard when no object is active. For the modify window it
should be the sizes listview.
Installing fonts shouldn't show the totals requester; instead, because the
process can be slow, show a progress window with a gauge. (To see my example,
simulate installing multiple files - and stopping - with the mock-up.) Insert
the font entries individually as they are installed, perhaps using quiet mode.
When installing a font that already exists in the drawer, it seems rude to
refuse to install it. It would be more helpful to present a string requester
for entering a new name and provide the options Rename, Replace, Replace All,
Skip, Skip All, and Stop.
When installing a font that already exists in another drawer, it seems
presumptuous to arbitrarily rename the font. Present a string requester with the
options Rename, Skip, Skip All, and Stop. If you implement my request to
support drawers not in the Fonts: path (see below under Feature Requests), this
situation wouldn't apply - unless you decide to determine whether the drawer is
in the path and if it is, to test for cross-drawer duplicates.
Removing fonts shouldn't show a total requester; removing the entries from the
list is enough confirmation. I've reordered the buttons so the positive ones are
at the left. I've renamed Cancel to Stop because stopping the process doesn't
reverse the removals already done. As for install use quiet mode.
I reorganized the Modify window using register pages to facilitate adding new
values to modify and to alleviate the shortage of control characters. The window
is resizable in both directions. Whichever of the members or sizes listview is
exposed is the window's default object.
The gadgets for maintaining font sizes behave strangely: for example, activating
a listview entry loads the string; it shouldn't.
When I enter a new font size, press Add Size, and activate the size I just
added, Delete Size disables; it shouldn't.
The string accepts values as small as 2; this doesn't seem useful. I changed the
lower limit to 4, as this appears to be the value used by the ASL font
requester.
When sizes without bitmaps are selected, setting the string to a non-existing
value disables Add Bitmaps; it shouldn't.
Entering a new size greater than 124 disables Add Size. Unless there are reasons
I don't know about to reject large sizes, T1Manager should be able to create
large (e.g. 400-pixel-high) bitmaps.
Adding and removing bitmaps changes the select states of the list entries; it
shouldn't.
Creating bitmaps can take time. It should show a progress window similar to that
for installing fonts, but saying "Creating bitmap" and e.g. "30". (This is done
during the saving of changes, which my script doesn't implement or simulate.)
Feature Requests
The history log has a 3/27/94 note about a desire to save the install source
drawer. My mock-up does this by adding a text gadget at the bottom of the
window's root group with a ShowMe value of false. I update the requester's
drawer when I drop an icon and at quit time set the text and save it.
Support maintaining fonts in any drawer, not just in drawers already in the
assigned Fonts: path. TTFLib does this.
Include Full Name in the modify window for display and updating. My script gets
it from the Type 1 file at modify time, but T1Manager would add it to the .otag
file at install time.
As shown on the Styles page, the Family name should be modifiable to fix bad
names and to reorganize families.
Also, please support the use of style variants in preference to algorithmic
styles. I assume the variants would come from the same drawer as the font being
modified. The member list shows the family's member fonts that were read when
loading the Fonts listview. Variants can be loaded by dragging members into
them. Renaming a font, and installing and removing fonts would update the family
lists. Changing the font's family would remove the font from the current family
and add it to the new. Canceling the modify would remove the font from the new
family and restore it to family it had when it was loaded.
My mock-up doesn't implement the renaming of fonts, and my simulation of
installing them doesn't update the family lists, but removing fonts, changing
the family, and canceling modify demonstrate the processing I describe.
Finally, I'd like to specify algorithmically generated styles to be inhibited.
These values would apply when a variant wasn't specified or found.
History
1.9 Fixed bug: Install file requester processes selected files even if file
string is empty.
1.8 Redesigned Styles page to replace multiple variant pop-up lists with a
single list of family members for dragging into variants.
Fixed bugs: Sets members or sizes listview as default object.
1.7 Updated Processing Errors section of criticisms.
Changing family is faster.
Fixed bug: Rejects null family.
1.6 Last history was wrong.
1.5 Updated Bugs section of criticisms.
Reordered attribute cycles.
1.4 Added some criticisms and reorganized them.
Reworked Remove Fonts requester and changed that and Install Rename
requesters to use Stop rather than Cancel.
Fixed bug: Loads style variants and inhibited styles from .otag file.
Fixed bug: Showed wrong Slant setting.
Fixed bug: Fixed width fonts disabled AFM file string but not pop-up
button.
Fixed bug: Potential problems with tag retrieval.
1.3 Fixed bug: Last fix was broken.
1.2 Fixed bug: Mishandled 32-bit memory address values.
1.1 Fixed bug: Style variant pop-up list used family string contents when value
hadn't been finalized by pressing return.
Fixed bug: Font list didn't respond to cursor keys in font string.
1.0 First Aminet release.
If you find errors or problems in this mock-up, please let me know, but
preferably I hope you'll improve T1Manager by incorporating corrections in your
new release of this important tool for the Amiga.
|
aminet net>