Steve Mumford plans the creation of a label design package
Over the last part of this series, we've covered several different aspects of WIMP functionality, including file transfer protocols, painting fonts and sprites to the screen, and printing. With all these skills at our disposal, it's time we put them to use in a full-scale application. One task which would include all the above would be a program to set out and print labels, allowing the user to create both text-based and graphical designs before positioning them on the page and printing them out.
This exposes one area that I'd like to cover during the construction of this application. Although it's possible to produce graphics of a sort by making use of sprites, this method would not be able to provide us with a particularly high standard of output, so at this stage it would be worth spending a little of our time investigating the DrawFile module. This would allow us to include line art in the label designs, giving us an easy method of creating borders as well as allowing us to import bits of clip art into our designs.
Broadly speaking, the program should satisfy some major goals, the first of which being that it should allow users to create labels of any size and allow them to be positioned anywhere on the page. Self-adhesive label sheets compatible with either inkjet or laser printers are becoming more and more widespread; due to the large range of shapes and sizes, our application should try to make it easy for the user to set up a format for one or more particular types. Generally speaking, we'd need several parameters to describe such a format - the number of labels across and down the page, the dimensions of each cell, the margins at the top and left hand sides of the paper, and the horizontal and vertical padding between the cells. Given these values, our program should be capable of constructing a layout and automatically positioning the labels into each of the cells when printing.
Instead of displaying and editing a whole sheet of labels at one time, I envisage the user working on something resembling a stack, with a window on screen showing the current label along with icons to flick backwards and forwards through the other designs in memory.
This minimises the work we have to do to create the redrawing routines, as well as keeping things simple for the user. Although this method of editing does impose certain limitations in design, it might be possible to work around these by providing the ability to export a whole page of labels as a Draw file, so that it might be edited in another application.
At this stage, it's probably a good time to think about the interface we provide and how we allow the labels to be created and edited. If we're looking to include Draw-based clip art within our labels, a drag-and-drop interface would seem sensible. However, how do we cope with the creation of text? The ideal solution would be to allow the user to edit strings of outline fonts on the screen in real time, using a WYSIWYG approach, but simpler, less satisfactory, methods could include using writable icons to hold the text before creating a movable, scaleable Draw object. In this case, if a change had to be made, the user would have to return to the writable icon and alter the text, at which point the program could destroy the old object and create a new one.
Thinking back to import and export, a useful feature of the application might be to allow a text-based list of addresses (perhaps in CSV - comma-separated value - format) to be loaded and automatically formatted according to some simple rules - there's been many a time in the past when I've wanted to throw together a mailing list and the import facilities of the word processors I've been using have left a lot to be desired.
A more advanced feature we could try to include would be the concept of a template label, created before the label data is imported, that defines the positions and characteristics of each of the fields in the address list along with any 'standard' features such as borders or background shading.
We've got quite a few ideas to implement, but writing the above program should allow us to bring all our previous knowledge together and apply it in a way that's hopefully useful beyond the realms of this tutorial. I'll make a start next month.
|Source:||Acorn User - 193 - April 1998|