There are many problems that can arise; this section deals with just a few of them.

Problems in !Edit and in Text File Transfer to !Draw

!Edit crashes on startup

If you're "into DTP" you may well end up by becoming a "font collector". Fonts are only recognised by the outline font manager if they are stored in the application directory !Fonts.

!Edit checks the contents of IFonts when it starts up. If the number of fonts, including the System Font, is too large !Edit crashes with the error message: "Edit has suffered a fatal internal error (type=5) and must exit immediately".

The solution is to store all your fonts in an innocuously named directory such as "Fontstore" and to store the ones you use most often in !Fonts. If you need an unusual font for a certain job, temporarily transfer it into !Fonts before starting up !Draw.

Of course, a more elegant solution, afont management software such as FontFS or EasyFont Pro from APDL.

Text file won't load into !Draw.

!Draw. will only accept plain text files. These can be produced by !Edit or any other text editor.

The text file must also terminate with a carriage return.

Bad font number error

Sooner or later you will get the dreaded "Bad Font Number" error message as you attempt to load a text file into !Draw. When this happens the transfer of the text file is aborted. Sometimes the cause can be very difficult to find. The error can arise even though there are no font changes in the text. The error message is misleading-"Bad font number or unrecognised command" would be more appropriate.

One common cause is a bad new line. To force a new line in your text area, you must end the previous line with "\<CR>", since !Draw interprets a <CR> on its own as a space. Sometimes a space may be introduced between the "\" and the <CR>. This is especially likely if you have inserted the new line into the middle of an old one. You probably inserted the <CR> before the first character of the new line, then you remembered that you needed a "\" at the end of the previous line, so you placed the caret immediately after the last visible character in the line forgetting that a space, invisible on the screen, follows it. So in the text file !Draw encounters the sequence "\<space><CR>" instead of "\<CR>" and regards the <space> as a bad font number. Eliminate this problem by searching your document for "\" at the end of a line. When found, place the caret on that line and press Ctrl-[right] to move the caret to the end of the line. If it stops immediately to the right of the "\", keep searching. If it stops one or more spaces to the right of the "\" you have located a problem so delete the space(s).

Another possible cause of the "Bad Font Number" error is a simple typing error. You can change fonts whenever you wish, provided you define your font numbers correctly. If you define font 0 as Trinity Medium and font 1 as Trinity Medium Italic you can put the single word "Typeface" in italics in a roman environment thus:

  \lTypeface\0

But if you typed very quickly and carelessly interchanged the "\" and the "T" thus: \Tlypeface\0, !Draw will interpret the \T as a bad font number.

Another cause is in the header. Remember that in "\" commands characters are case sensitive. If you ignore this and include in the header the line:

  \F0 Trinity Medium 12

the "f" will be regarded as a bad font number.

Wrong font used in text area object

Sometimes font changes are ignored. This may happen if a number follows immediately after a font change command. Thus to change to font 1 and print "1990" your text might read "M1990". But this is ambiguous-!Draw does not know whether this is font 1 followed by "1990" or font 11 followed by "990". The "fix" is to terminate the font change command with a "/": \1/1990.

Unable to load font

Sometimes when transferring a text area file into !Draw you may get the error message "Unable to load the font <font name>". Unlike the bad font number error, this does not prevent the transfer of the file. The text area is still created, but sections of it that were supposed to be in the font that could not be loaded will be reproduced in another font, usually the one that was in use before the intended font change. There are two possible explanations of this error. One is that the font name was mis-spelt in the header. The following line in the header, for instance, will cause this error:

  \F2 Trinity.Bodl 12

Clearly "Trinity.Bold" was intended, but the computer will faithfully search for a directory called "Trinity.BodI" which it will not find.

Make certain that you spell font names correctly. If you are unsure about the spelling of a font name you can get a list of the current contents of /Fonts while in !Edit by selecting "Display" from the main menu.

The same error is generated, of course, if you deliberately specify a font name that does not exist. For instance, if you delete a font from !Fonts and later attempt to reload a !Draw file that uses it in a text area object.

Line numbers in text files

The line numbers given in error messages relating to text files can be useful in locating the cause of the error. In !Edit a "line" is a string of any number of characters terminated by <CR>; it may occupy many lines on the screen. In fact it is often useful to think of it as a paragraph. The first line in the text file (the one which generally reads "\! 1") is line 0.

Problems in !Draw

Wrong font used in text object

If an item in a text object appears in the system font rather than the originally chosen font, check that the original font is still in !Fonts. If a font is deleted from !Fonts or its name changed, !Draw will default to the system font in the affected text object.

Text wrong shape in text object

If, in a text object, the text appears to be very condensed, that is, very tall and narrow, almost certainly you set the text height in mistake for the text size. By default the text size is 6.4 pt with the outline font manager. If you wanted 14 pt text but, by an easily made mistake, selected this from the Text height sub-menu rather than the text size sub-menu, you will get characters which have 14 pt height combined with 6.4 pt width. The solution is to enter the Text size sub-menu and set the size to 14 pt before you complete the object.

Rules print out crooked, although straight on display

Since the printer is capable of a higher resolution display than the screen, it sometimes shows up faults which the screen is not capable of displaying. When you use the path object procedures to create vertical and horizontal rules, always use the "Grid Lock" facility. This will ensure that all rules are exactly vertical or horizontal. If you create your rules "free-hand" judging them from the screen display, they may end up slightly out of true-so slightly that the screen cannot display it. The printer, however, may have the resolution to show it as an unsightly series of "steps" in the rule. This can be corrected by selecting "Grid Lock" and Select mode and using the "Snap to Grid" facility.

Transferred object is missing

To transfer an object from one !Draw window to another (unless they relate to the same sheet) it is necessary to select the object concerned and save it into the other window. Unfortunately objects transferred in this way are often hard to locate in their new window. This is because '.Draw places the imported object at the current pointer position offset by the object's original position; this may well be outside the paper limits.

The way to find such a missing object is as follows. In the window which received the object enter Select mode and from the Select sub- menu choose "Select all". Next, from the "Paper limits" sub-menu (attained from "Misc") choose AO. From the main menu slide off

"Zoom" and reduce the magnification until the screen displays the errant object neatly highlighted by its boundary box. Clear the selection and then select just the offending object. Then, drag it into the main drawing area and restore the page size and magnification to normal.

Scrolling and/or printing is slow

Scrolling gets slower as you put more objects or text on the page, but if you find it excessive (eg over a minute from top to bottom of a page of A4) check the size of the font cache using the Task Display. This should be at least 64K and if you are using many fonts make it larger than that, as large as possible. Too small a font cache will have a devastating effect on scrolling (and printing) speed as the computer will need to repeatedly access the disc for font data in order to write the text.

If you have a hard disc, put your ! Fonts application on it, in the root directory. Access is faster from a hard disc than from floppies. Moreover on a hard disc you can put many more fonts in the /Fonts directory.

Avoid using the "zoom" facility to get an enlarged view of text. It is fine with graphics but with text it can easily quadruple scrolling times! But by all means open a "New view" window with a reduced-scale zoom so you can see the whole document; this will not need to scroll and adds little to the time burden.

It also helps if you lay out your "body text", ie the main bulk of the document in a smallish typeface, first. This will probably only use one, two or perhaps three fonts. When satisfied with its layout, put in larger titles, headings, captions and by-lines using text objects.

Printing is a slow process at the best of times. (Incidentally !Draw is no slower than the "proper" DTP packages, all of which print using very similar procedures.) The computer divides the sheet into "strips" of bitmap which are sent to the printer for printing as graphics.

Clearly, the higher the resolution of the printer, the greater the amount of data that must be sent and the higher the number of calculations that the computer must perform to derive them. A page of well utilised A4 at 300 dpi involves the calculation and transmission to the printer of nearly 1 Megabyte of data.

If there is not enough memory available for even one such "strip" to be compiled, obviously printing cannot begin and the computer gives a suitable error message.

If there is enough memory for one strip, every object on the sheet will be examined to see if it affects the strip about to be printed. If it does, the object is plotted on to the strip as though it were a virtual screen having the same resolution as the printer. When all objects have been examined, the strip is printed and the entire process is repeated for the next strip. The cycle continues until the sheet has been printed.

Printing also takes longer if your page layout is "landscape" (horizontal) rather than "portrait" (vertical). This is because the font manager assumes portrait orientation and the data concerning character outlines must be converted to landscape format.

Cannot "select" an object (1)

The "select" facility in !Draw does not work as well as the User Manual suggests, especially when you have a large number of overlapping objects including portions of text area. A useful trick when you simply cannot select that deeply nested portion of text area is to take the pointer to a nearby position on the edge of the page (so that it is not actually over any object), hold the "select" button down and "pull out" a selected area which embraces the object you wish to select. All objects overlapping the pulled-out area become selected. You can then cancel those you do not wish to select.

Alternatively, use the "Select" sub-menu's "Select All" option and then cancel all the unwanted objects by clicking ADJUST on them. It's time consuming but it never fails!

Cannot "select" an object (2)

Sometimes it can be apparently impossible to select a certain object even in a relatively uncluttered !Draw window and even using the method described above. Probably, when you attempt to select the object in question, a different object overlapping it is becoming selected, although you may not notice this at first. When this happens, check to see if the two objects concerned have become "grouped". Leaving the "wrong" object selected, call up the "Select" sub-menu and see if "Ungroup" is one of the options available. If so, select it and then de-select the "wrong" object. You should now find that the object you originally wished to select is selected. It is quite easy for selected objects to become grouped unintentionally. Most often this is caused by the pointer moving by accident over the "Group" option of the "Select" sub-menu just before you click the mouse intending to perform some other operation.

Cannot edit path object

You cannot edit a path object that has been grouped. Clicking ADJUST on the object will have no effect until it has been ungrouped.

Words missing

You may sometimes find that the first word or first few words are omitted from a text area, both on screen and in printout. This happens if you have specified a larger font than will fit the line spacing-such as a 24 pt font in a heading while the line spacing is only 12 pt. !Draw will decide it has no room and will omit all or part of the offending text. It is easiest to leave headings out of text areas and insert them "by hand" into !Draw as text objects when the body text is in place.

Problems with Printing

Printer delivers gobbledegook

If your printer delivers strings of carriage returns interspersed with seemingly random characters, check first that you have loaded the correct printer driver and, if so, that you have chosen a graphics mode appropriate to your printer. The graphics mode is chosen by clicking SELECT on the printer driver icon and then clicking SELECT or ADJUST in the graphics mode window until the appropriate mode is displayed. Bv clicking MENU on the printer driver and then selecting "Save options" you can save your choice. The printer driver will thereafter start up with your chosen graphics mode selected.

Lines of text missing from printout

Sometimes large chunks of body text may be missing from a printout. On several occasions all the body text was missing from one of my documents! Graphics and headings were faithfully printed in the right places-only the text was missing, though it appeared quite normally on the screen. On another occasion, the last four lines of body text in each column were missing. This appears to be a "bug" possibly caused by interference from other software. The "fix" is to save any unsaved material, switch off the machine, leave it for 10 seconds, then switch on and start again from scratch. Chances are your printout will now be normal. It is always advisable to switch off your computer to clear its memory before a !Draw/!Edit session.

Descenders not printed

The descenders (below-the-line parts of such characters as "p" and "g") are sometimes missing from some lines of text when you use outline fonts in conjunction with the earlier printer drivers. The earlier printer drivers were not fully compatible with outline fonts. The fix is to obtain a more recent printer driver such as version 1.12 on the RISC OS 2.00 extras disc.

Dot matrix printout is distorted

On a dot matrix printer at high graphics resolution (such as an FX-80 at 240 x 216 dpi) the right-hand edges of the characters may appear slightly "ragged". Examine, for instance, the letter y printed with the paper in "portrait" orientation. This is an inevitable consequence of the way in which the printer works and is explained in Chapter 10. In "landscape" printing the distortion is forced into the top edge of the characters, where, though still visible, it is much less noticeable. Examine, for instance, a "T" printed this way.