Macintosh Print Controller

Project Design Report

MetalCraft, Inc.

Mason City, IA

Dr. James Davis

Luke Bodeen

David Legge

Curt Melchert

Ryan Sinnwell

1

Team May03-08

November 19, 2002

1

Table of Contents

List of Figures

List of Tables

1Introductory Materials

1.1Abstract

1.2Acknowledgement

1.3Definition of Terms

2Project Design

2.1Introduction

2.1.1General Background

2.1.2Technical Problem

2.1.3Operating Environment

2.1.4Intended Users and Uses

2.1.5Assumptions and Limitations

2.2Design Requirements

2.2.1Design Objectives

2.2.2Functional Requirements

2.2.3Design Constraints

2.2.4Measurable Milestones

2.3End-Product Description

2.4Approach and Design

2.4.1Technical Approaches

2.4.2Technical Design

2.4.3Testing Description

2.4.4Risks and Risk Management

2.4.5Recommendation for continued work

2.5Financial Budget

2.6Personnel Effort Budget

2.7Project Schedule

3Closure Material

3.1Project Team Information

3.2Summary

3.3References

List of Figures

Figure 1 - Current Data Flow for MetalCraft Printing Process…………………………...3

Figure 2 - Proposed Data Flow for MetalCraft Printing Process………………………… 7

Figure 3 - Gantt chart of project schedule……………………………………………… 13

List of Tables

Table 1 - Financial Budget……………………………………………………………….11

Table 2 - Personnel Effort Budget……………………………………………………….12

1

1Introductory Materials

The following sections give a short introduction and background information about the project.

1.1Abstract

The Macintosh Print Controller project attempts to solve a process productivity issue for MetalCraft Inc. of Mason City, IA. The process flow for printing to a digital printing press is currently slowed by a label numbering and export problem. The solution for this issue will take a generic label layout, properly insert serial numbers and barcodes, and send the completed job to the press for printing. The solution will help the process flow in several ways. Layout time will be reduced, as the layout person will spend less time numbering and generating each label page. Postscript generation time will be reduced because only one generic layout page will have to be exported instead of hundreds or thousands of pages. Overall, this project will improve time from layout to production and help the company increase productivity.

1.2Acknowledgement

We would like to thank John Henry of MetalCraft, Inc., Mason City, IA for his assistance in gathering information and providing development equipment. We would also like to thank Dr. James Davis for his help and encouragement.

1.3Definition of Terms

CheckMate – custom software used by MetalCraft to make a file with the serial numbers required for each job

cron – Unix application to schedule system and application events

Indigo Omnius– printing press used to print labels on clear plastic material

Mac OS X – the latest version of the Macintosh operating system

Postscript – standard file format for sending pages to a printer or RIP

Quark XPress – publishing program for the Macintosh platform

RIP – this stands for raster image processor, it is software that tells the printer how to place each pixel on the paper

Xdata – an extension of Quark Xpress that facilitates incorporation of data into a Quark page from a file

2Project Design

The project design describes the problem, provides a detailed solution, and describes the steps taken to produce the end product.

2.1Introduction

The introduction section gives a general background, description of the problem, environment, assumptions, limitations, and intended users.

2.1.1General Background

MetalCraft, Inc. manufactures a large variety of labels and nameplates used for product identification and inventory purposes. Their current system experiences substantial delays in creating and sending design files from the Macintosh to the Indigo Omnius digital printing press where there can also be a delay in final printer processing. The end product of this project will interface between the design platform and the printing press with the purpose of streamlining the process.

2.1.2Technical Problem

In the current system, each page to be printed has to be designed, converted to Postscript format, and sent to the press. An issue that slows the design process is the manual linking of the labels to ensure proper numbering. Because one print job can consist of hundreds of pages, manually linking can be a time consuming and error prone process. Conversion of hundreds of pages to Postscript format is also a long process. The Macintosh design station must remain idle as the pages are converted.

2.1.3Operating Environment

The end product will be utilized in a design and printing environment. The conditions of the environment are controlled, and its cleanliness is above average as large amounts of printing are involved.

2.1.4Intended Users and Uses

When a task contains hundreds or thousands of pages, the idle time on the Power Macintosh is quite long. This prevents the Macintosh operator from moving on to a new task, drastically reducing the throughput of the system. The goal of the end product is to increase the throughput of the printing system and to increase the availability of the Macintosh design station. The end product will be integrated with the existing system, keeping as much functionality of the original setup as possible while being transparent to the designer.

2.1.5Assumptions and Limitations

Certain assumptions must be made to allow design of the project to continue without dwelling on details. There are also limitations of the equipment that is being used, as well as the software in use. These assumptions and limitations are listed below.

Assumptions:

  1. The input to the end product will be in Postscript format.
  2. The users of the end product are already familiar with the system.
  3. Any upgrades in system software will be backwards compatible.

Limitations:

  1. The design will be limited by the lack of automated execution of the software; i.e. the operator must manually run the software from the third computer.
  2. The members of the design group must be familiar with or learn Java programming.
  3. Because the design process will take place outside the final operating environment, the testing of the design will be limited.
  4. The computers being used must be available for the specified purposes. If the company purchases a replacement computer that is not compatible to the current systems, the design may fail to continue working.

2.2Design Requirements

The design requirements are a guideline for what the solution will do and how it will perform.

2.2.1Design Objectives

Upon completion of the project, there are several objectives that will have been met. Below is a list of these objectives and a brief description of them.

  1. Lower Postscript File Creation Time - The current process has to repetitively create Postscript pages that are the same except for the serial numbers. A template page will be used to build the Postscript file rather than the Quark XPress software doing repetitive processing.
  2. Reduce Manual Tasks -The linking of columns and rows of labels must be done manually for hundreds of pages. By eliminating these tasks, the design process will be faster and have fewer errors.
  3. Maximize Design Station Availability– Currently; the design computer is busycreating andtransferring large files over the network. The solution will allow the design station to be freed up quickly so that another design project can begin.

2.2.2Functional Requirements

Below is the list of functions that the solution to the problem will include.

  1. Accept input files from design station - The application needs to accept the postscript template page and the list of serial numbers from the design station.
  2. Lengthen layout file to proper length - The application should determine the number of labels needed and lengthen the Postscript file and number of labels as needed, by repeating the code that represents the existing labels.
  3. Populate serial numbers - The Postscript file will be edited and the proper serial numbers will be populated in the correct position on the labels. The user will determine the numbering scheme.
  4. Send document to RIP – The final document, after the barcodes have been populated, will be sent to the raster image processor. This device will then print the document on the required media.

2.2.3Design Constraints

  1. Network – The network equipment and cabling will limit the ability to transfer large files quickly between machines. This will slow the time that it takes to make the design station available for the next project.
  2. Sustainability of current software – The current software being used may change when new versions are released. This might introduce issues with the solution approach; therefore the solution should not depend heavily on the current software.

2.2.4Measurable Milestones

Milestones will be measured in four stages: Not started, started but not finished, finished but not acceptable, finished and acceptable.

  1. Documentation (30%) – Develop and revise project plan and design. Develop project poster.
  2. Research for Design Approach (5%) - Gather information about potential approaches to make a final design approach decision.
  3. Develop Progress Report/Presentation (10%) - Based on the project plan and design, prepare oral report for client and industrial review board.
  4. Implement Design (30%) - Develop software based on project design.
  5. Test (10%) - Go through testing phases: component testing, integration testing, user acceptance testing, and performance testing.
  6. Develop Final Report/Presentation (10%) - Write and prepare for final written report and oral presentation for client and review board.
  7. Delivery (5%) - Deliver final tested production code. Run final tests on system and do any installation and configuration needed onsite.

2.3End-Product Description

The Macintosh Print Controller end-product will be integrated onto a Macintosh G4 desktop system. This desktop will be on the same network as the Omnius printing press and the design workstation. The end-product software will be a Java desktop application. Input to this software will be a generic label layout in Postscript format and a text file with a list of serial numbers generated by CheckMate. The Java application will take the postscript file, add the desired number of pages, properly insert serial numbers and barcodes, and send the completed job to the press for printing. It will reduce layout system downtime and increase overall productivity.

2.4Approach and Design

The approach and design section describes several solutions to the problem, possible risks to the project, and projected budgets.

2.4.1Technical Approaches

Numerous technical approaches were considered because of the complexity and modular nature of the current process. The current process employs two separate platforms and multiple software programs. This fact allows a solution to be inserted in many locations in the process flow. Each allowed solution location has its own constraints on the form and functions of the solution.

The first approach considered was a software solution on only one of the platforms. This approach uses currently installed hardware with custom software to alleviate any issues that can be solved from only one side of the data flow. A distributed software approach that would operate across both platforms has also been discussed.

Using a separate and intermediate platform has also been considered. Software on this system would take postscript and text files from the design station and be able to work with them independent of any current software on either platform. It would then be able to send the final output to the printing press.

An examination of the network structure connecting the design station to the printing press has also been considered as a way to improve transfer times between platforms.

2.4.2Technical Design

The design that will be pursued involves a separate platform that uses custom software to build the final postscript file to send to the printing press. It was chosen because it eliminates manual operations performed during design using Quark while at the same time decreasing the time needed to build the entire postscript file. The other design approaches considered are not able to do both of these functions. This design approach also allows for the upgrade of software and hardware at either platform without affecting the effectiveness of the solution.

The separate platform will be a Macintosh G4 computer that will fit between the design station and the printing process in the data flow. The custom software on this system will accept a postscript template and a text file from the design station. The postscript template will be a single page of labels with a uniquely identifiable serial number and barcode. The text file will include all of the serial numbers that need to be incorporated into the final postscript file. A final postscript file will be made using these two inputs and will then be sent to the printing press.

The approach of using software on only one of the platforms was rejected because it would have been unable to fulfill as many client requirements as the chosen approach. Additionally, it would have been more difficult to insulate the solution from the effects of upgrading software or hardware. The distributed software approach was also rejected because of the same reasons.

2.4.3Testing Description

Testing is important in evaluating project development and final adherence to design requirements. With these ideas in mind, the following testing activities will be used.

  1. Component testing – As the project progresses, the application will be designed with an object oriented approach. This approach will require that each function will be developed and tested independent of the rest of the application. Each function can be tested using the specific inputs that it requires to complete the tasks it is designed to do. Component testing is done to find and reduce problems that may otherwise appear in system integration testing and hence be more difficult to locate and fix.
  2. System integration testing – Once all components are tested, the final system will be tested in one piece. This will test all functional requirements.
  3. User acceptance testing – Regular users will be trained in how to use the system with the modifications made by our project. Both design users and production users will then operate the system for a period of time to be determined. After this they will provide any information regarding problems encountered or suggestions for improvements.
  4. Performance testing – Testing will be done to compare the performance of the system after modificationsof the new process to the original system.

2.4.4Risks and Risk Management

Possible risks are listed with the activities designed to minimize their impact on the project timeline and quality.

  1. Loss of team member: All documents will be kept in a centralized location so that any team member may view them. Communications will be made to the entire group so that there are multiple copies of correspondence and decisions made. Two or more members will have a part in every task.
  2. Availability of client/system resources: It is possible that some of the resources of the client or the system may be unavailable to use due to the location of the client or their production schedule. To alleviate these issues, interfaces and requirements must be clearly described for each component. Development and testing may need to be done in a modeled environment locally.
  3. Ineffectiveness of technical approaches: All documentation will be turned over to the client for evaluation of project status and future work. Other suggestions of approaches will be made to the client, so if the solution does not quite fit their needs, they are able to make changes.
  4. Loss of functioning code revisions: A system will be devised to backup revisions of code so that they can be retrieved if they prove to be better solutions. Also, this will provide a safe way to store the various electronic portions of the project. Any portion of code that is known to be in working order will be backed up before any changes are made. If a piece of functioning code is modified, it could render it useless. This would cause a major setback in the development process.
  5. Availability of information on current system: The approach chosen may need more information about the interaction between the RIP and Mac OS X. Care will be taken to ensure that the technical approach taken will have sufficient knowledge of the current system to allow a functioning product to be designed and produced.

2.4.5Recommendation for continued work

The current final product will require the user to start the processing of the files. In the future, it would be beneficial if the processing station could periodically monitor a drop-box for new files to be processed. Whenever a new file arrives in the folder to be processed, the application will process and forward it to the RIP upon completion. Once all of the systems have been updated to Mac OS X and the RIP has drivers available for Mac OS X, this process should not be hard. Being based on Unix, Mac OS X has the core operating system functions such as cronwith which many Unix users are familiar. Using cron to schedule the execution of the application, the system would periodically launch the application to look for new files to process.

Another area that can be improved is the sending of files to the RIP when the Postscript modifications are complete. This could also be done via cron with the use of a small AppleScript or other scripting language. Since the RIP shows up as a mapped drive on the desktop of the processing computer, when the files are marked as done, they could be copied to this drive where they would automatically show up as ready for printing.

2.5Financial Budget

With a solution that includes a customized software application, there are not many incurred costs. Those that have been encountered are listed below in Table 1 and a short description of some of the funds follow.

Table 1 – Financial Budget

Budget Item / Original Estimated Cost / Revised Estimated Cost / Actual Cost to Date
Software / $100 / $100 / $0
Poster/Printing / $40 / $90 / $87
Phone Calls / $25 / $0 / $0
Equipment & Parts / $0 / $1700 / $1700
Total / $165 / $1890 / $1787

Poster/Printing – This money is out of the pockets of the team. The printing costs include the final, bound versions of the project plan and the design document.