Final Report

Macintosh Print Controller

Final Report

Team May03-08

MetalCraft, Inc.Mason City, IA

Dr. James Davis

Luke BodeenDavid LeggeCurt MelchertRyan Sinnwell

April 8, 2003

i

Table of ContentsList of Figures....................................................................................................................iiiList of Tables......................................................................................................................ivList of Definitions................................................................................................................v1 Introductory Materials.................................................................................................1

1.1 Executive Summary.............................................................................................11.1.1 Necessity for Project....................................................................................11.1.2 Project Activities.........................................................................................11.1.3 Project Results.............................................................................................11.1.4 Recommendations for Future Work............................................................2

1.2 Acknowledgement...............................................................................................21.3 General Problem and Solution Approach Statement...........................................2

1.3.1 Problem Statement.......................................................................................21.3.2 Solution Approach Statement......................................................................3

1.4 Operating Environment.......................................................................................31.5 Intended Users and Uses......................................................................................41.6 Assumptions and Limitations..............................................................................41.7 End Product and Other Deliverables...................................................................4

2 Project Approach and Results......................................................................................52.1 End-Product Functional Requirements................................................................52.2 Resultant Design Constraints...............................................................................52.3 Approaches Considered and Approach Used......................................................62.4 Detailed Design...................................................................................................82.5 Implementation Process Description.................................................................102.6 End-Product Testing Description......................................................................112.7 Project End Results............................................................................................12

3 Resources and Schedules...........................................................................................123.1 Resource Requirements.....................................................................................12

3.1.1 Personnel Effort Requirements..................................................................123.1.2 Financial Requirements.............................................................................13

3.2 Schedules...........................................................................................................144 Closure Materials.......................................................................................................17

4.1 Project Evaluation..............................................................................................174.2 Commercialization.............................................................................................184.3 Recommendations for Additional Work............................................................184.4 Lessons Learned................................................................................................194.5 Risk and Risk Management...............................................................................19

i

4.6 Project Team Information..................................................................................214.7 Closing Summary..............................................................................................214.8 References..........................................................................................................214.9 Appendices........................................................................................................22

4.9.1 Appendix 1 – Process flow diagram page 1..............................................224.9.2 Appendix 2 – Process flow diagram page 2..............................................234.9.3 Appendix 3.................................................................................................24

ii

List of FiguresFigure 1 – Current data flow for MetalCraft printing process…………………………...3Figure 2 – Proposed data flow for MetalCraft printing process…………………………7Figure 3 – Gantt chart of project schedule page 1……………………………………… 15Figure 4 – Gantt chart of project schedule page 2 ………………………………………16

iii

List of TablesTable 1 – Personnel effort budget (original) …..………….……………………………..13Table 2 – Personnel effort budget (revised) ....…………….…………………………….13Table 3 – Personnel effort budget (actual) ….…………….………………..……………13Table 4 – Financial budget ………………………………………………………………14

iv

List of DefinitionsCheckMate – 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

QuarkXPress – 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 QuarkXPress that facilitates incorporation of data into a Quark

page from a file

v

1 Introductory MaterialsThe following sections give a short introduction and background information about the

project. It also provides information about the operating environment, users and uses,

assumptions and limitations, and the end product.

1.1 Executive Summary

The executive summary discusses the necessity for the project, the project activities and

results, and the recommended future work.

1.1.1 Necessity for ProjectThe Macintosh Print Controller project solves a process productivity issue for MetalCraft,

Inc. of Mason City, IA. MetalCraft, Inc. makes industrial labels for identification and

inventory purposes. An onsite visit was conducted to learn more about the process flow

and tools currently used. The process flow for printing pages of labels on a digital

printing press is currently slowed by a manual linking operation and file export problem.

The design person has to manually link the rows and columns of labels in the design file

so that the serial numbers are inserted in the correct order. When there are ten or even

hundreds of pages, this task can be time consuming and error prone. It can also take a

long time when the design file is exported to a Postscript format because each page has to

be converted even though they are essentially identical except for the serial numbers and

barcodes. Both of these issues reduce the productivity of the design group by tying up

their resources.

1.1.2 Project ActivitiesAfter examining a number of solution approaches, it was decided that the best approach

would be to write a Java software application to create a Postscript file that is populated

with serial numbers and barcodes. The application accepts a single page Postscript

template file, a serial number text file, and information regarding the orientation of the

serial numbers. Next the application creates the needed number of pages and inserts the

serial numbers and barcodes in the order chosen by the user. The output is a Postscript

file that can then be sent to the digital printing press for printing. Testing of the

application was done throughout the implementation and further onsite testing is planned.

1

1.1.3 Project ResultsThe project was successfully completed and a working product will be delivered to the client. The main result of the project will be an increase in productivity for MetalCraft, Inc. by reducing the manual work and redundant processing inherent in their current process.

1.1.4 Recommendations for Future WorkThe application could be changed so that less information from the user is required. This

would require the application to examine more properties of the template file. The

application could also be modified to automatically send the completed file to the printer.

The functionality provided by Checkmate could be incorporated into the application.

1.2 Acknowledgement

We would like to thank John Henry of MetalCraft, Inc., Mason City, IA for his assistance

in gathering information and providing development equipment. Thank you to Becky

Johnson of MetalCraft, Inc. for providing us with example files and clarifications

regarding the current process. We would also like to thank Dr. James Davis for his help

and encouragement.

1.3 General Problem and Solution Approach Statement

This section gives a brief explanation of the problem and the solution approach.

1.3.1 Problem StatementMetalCraft, Inc. manufactures a large variety of labels and nameplates used for product

identification and inventory purposes. Their current system requires the label layout

designer to manually link rows, columns, and pages so that the labels are numbered in the

correct order. When there are hundreds of pages, this task can take a long time. The file

of labels must then be exported to a specific format for printing. This operation also

takes a long time because the design software does not recognize that each page is the

same except for the serial numbers and barcodes and therefore does a lot of redundant

processing. Both of these issues increase the time spent on a specific job and therefore

reduce the productivity of the design group. A process flow diagram is provided in

Figure 1.

2

Figure 1 – Current data flow for MetalCraft printing process

1.3.2 Solution Approach StatementThe solution used will be a software application. Because of its placement in the process

and its functional requirements, it is able to solve both of the issues presented in the

problem statement. The design group only has to make a single page of labels and

provide it in the final printing format to the software. They will not need to do any

manual linking because the software ensures that the labels are numbered in the proper

order. Additionally, the software eliminates the need for the redundant processing of

each page because it is able to copy and use the necessary data from the single page

provided. The software solution will require that the design group start it and provide the

locations of input files, information about the file itself, and where the final product will

be placed.

1.4 Operating EnvironmentThe end product will be utilized in an office setting on a computer running Macintosh OS

9 or OS X. The conditions of the environment are controlled and neither temperature nor

3

cleanliness will affect the end product.

1.5 Intended Users and UsesUsers: The intended user for this project is the design group at MetalCraft, Inc. They

are familiar with the tasks need to complete the design and prepare it for printing.

Uses: The intended use of the project is to minimize the manual work involved in

creating the label design file. The project will be used to augment a design template with

serial numbers and eliminate redundant processing by QuarkXPress. This will reduce the

amount of time spent by the design station computer processing the file for output to the

printing press. Both of these uses will increase the productivity of the design group.

1.6 Assumptions and LimitationsThe following section lists the assumptions and limitations that are relevant to the final

version of the project.

Assumptions:

1. Input to the end product will be in Postscript format.

2. Users of the end product are already familiar with the current system and tasks to

be completed.

3. Upgrades in system software will be backwards compatible.

4. Each page of labels has the same design except for the serial number and barcode.

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 and provide input.

2. Members of the project group must be familiar with or learn Java programming.

3. The design process took place outside the final operating environment; hence the

testing of the design will be limited.

4. Group has limited knowledge of Postscript fomat.

1.7 End Product and Other DeliverablesThe Macintosh Print Controller end-product will be Java desktop application that will run

on a Macintosh G4 desktop system. 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,

4

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. A

process flow and help guide will be provided to describe the sequence of tasks to be

completed.

2 Project Approach and ResultsThis section describes the requirements of the end-product, design constraints, and

approaches explored. It also provides the actual design of the end-product, a description

of the implementation and testing, and the results of the project.

2.1 End-Product Functional Requirements

The following is a list of functions that the end-product completes.

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 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. Output final Postscript file – After all serial numbers are inserted, the file should

be output to the location determined by the user.

2.2 Resultant Design Constraints

The following list describes inherent constraints placed on the end-product.1. Postscript file format – The complexity of the file only allows the end-product to

edit the serial numbers and barcodes. It cannot change the position or properties of other items.

2. System hardware – The processing speed of the computers running the software limits the time efficiency of the end-product.

3. 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.

4. Sustainability of current software – The current software being used may

5

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.3 Approaches Considered and Approach Used

Numerous technical approaches were considered because of the complexity and modular

nature of the current process. The current process employs two separate computing

platforms and multiple software programs, therefore allowing 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 to write a Quark Xtension that would be able to

automatically do all of the linking of rows, columns, and pages. This would run on the

design station and would be used before serial numbers were inserted by XData. It would

not however be able to reduce the time that it takes to export the file to Postscript format.

It was not chosen because it only was able to solve one of the issues described in the

problem statement. Additionally, this approach did very little to free up the design

station to begin other jobs because the exporting of the design file to Postscript format

still takes a long time.

Another approach was to use a piece of software on the printing press that would take a

Postscript file that had all of the pages created but no serial numbers or barcodes inserted.

It would insert the serial numbers and barcodes into the file and then send it to the RIP.

An advantage of this approach would be that it would be able to use the printing press for

doing the insertion of the serial numbers and therefore free the design station more

quickly to begin other jobs. This option also eliminates the need to manually link the

labels in the proper order but does not help with the redundant processing and therefore

was also rejected.

6

Figure 2 – Proposed data flow for MetalCraft printing process

The approach that was chosen was one that addresses both of the time consuming tasks of

manual linking and redundant processing while exporting the design file. The proposed

data flow is shown above. It requires the design group to provide a single page of

Postscript, a file containing serial numbers, and information about the orientation. It will

be able to use this one page to create as many pages as needed and then populate them

with serial numbers and barcodes in the proper order. The only discernable

disadvantages of this approach are that it requires the user to open another program and is

susceptible to user error. However, the benefits of this approach are numerous and

greatly outweigh the disadvantages. The major benefit over other approaches is that it

cuts out all of the redundant processing because only one page is exported to Postscript

format. This eliminates the bulk of the wasted time on the design station and is therefore

the most useful option. The major reason for choosing this approach is that it provides

for the largest increase in productivity to the process.

7

2.4 Detailed Design

The design that was pursued was a custom software application to perform all of the

manual tasks that used to slow the printing process down. It was desired by the group

that this software be able to stand alone and not be reliant on the printing press or design

program. It was also important that this software be able to run anywhere. The best

choice for this was Java.

The software is to provide fast, easy execution of two tasks that used to take an extensive

amount of time. Those are numbering of the labels in the file and exporting to the

Postscript format from Quark. The numbering of the labels was mostly manual before

and now will be completely automated. The export of the Postscript file from used to

take a long time because every page was exported separately and sometimes hundreds of

pages are exported at a time. With our design, this problem is eliminated because only

one page has to be exported from Quark.

Appendix 1 and 2 can be referred to while reading the detailed design. Those appendices

show the process flow of the software. The order of operation of this software is

important because the Postscript must be written out in a sequential order. Appendix 3

can also be referred to by the reader to get a grasp on what the actual Postscript file looks

like. Appendix 3 shows the major changes that this software makes in the actual

Postscript code.

The first thing the software does is read the one page label layout file. This file is an input

from the GUI. This file will be generated by the designer and exported to Postscript

format from Quark. There are several conditions this file has to meet in order to be

processed correctly by the software. The first condition is that file is one page of

Postscript. The software will generate as many pages as needed based on the one page of

Postscript. If there is more than one page in the design file, it will not work correctly in

our software. The next condition is that the labels not be internally linked together in

Quark. If the labels are internally linked, Quark will export the file differently, affecting

the label order that our algorithms are based on. As long as the file is unlinked, it will

work correctly. The third condition is that in the place of where the serial numbers

should be, there needs to be the same number of # signs as the number of digits in the

8

serial numbers provided. The serial number will have the same number of digits

throughout. The reason for the # signs in the layout file is twofold. First, the centering of

the barcode and serial numbers is calculated in Quark and exported that way. If the

number of # signs in the exported file is different than the number of digits in the serial

number, the centering will be wrong when the serial number is put in the layout file. The

second reason for # signs is for a unique delimiter in the Postscript. The Postscript that is

read is complicated and some of it is binary. The # signs provide a unique sequence that

the software can look for and insert the serial number at that point. The final condition is

that the Postscript remains the same as all of the test and sample files that have been

encountered so far. If the Postscript standard changes, Quark’s export of the Postscript

changes, or Metalcraft’s layout process changes the software will not work. These

conditions seem extensive, but they are not hard to meet. To meet all of these conditions,

the layout designer will actually have less work to do than before. For the number of

hours that this software will save, these conditions are miniscule in comparison.

The next thing the software does is read the serial number file. The serial number file is

generated by a program called CheckMate. This file is read in and all of the serial

numbers are put into an array. This array will be used later for insertion of the serial

numbers. The conditions on the serial number file are simple, use the serial number file

that is exported from CheckMate. CheckMate is involved the current design process so

no training will be needed.

After both files are read, the program then generates the first page of the output file.

While it is generating the first page, it keeps track of the Postscript that must be copied

for additional pages.

When the first page is generated, it moves on to the rest of the pages. The number of

pages to be generated is determined based on the number of labels per page and the

number of serial numbers. The math calculation for that goes as follows:

int numLabelsPerPage = rows * columns;if(maxSerials % numLabelsPerPage > 0)//if there is more than 0 remaining labels

{lastPage = (maxSerials / numLabelsPerPage) + 1;

9

//add one extra page to the division}else//remainder is 0, so division is whole number

{lastPage = maxSerials / numLabelsPerPage;}

The number of rows and columns are passed into the software by the user. The code for

determining these numbers based on the Postscript would be extensive because of the

obscurity of the Postscript. It was determined that because these numbers can easily be

determined by the user by just looking at the layout file, that it would be useful to have

these as inputs to the software.

While generating additional pages, the software actually inserts the serial numbers as it

goes. There are three layouts that determine the order of the serial numbers in the file.

The first layout is sequentially down the column, through the entire file, then onto the

next column. The second layout is sequentially down each column per page. The final

layout is across each row. For each layout, there is a calculation to determine which index

of the serial number array to insert. These calculations are shown below.

if(layout == 1){index = ((currentPage-1) * rows) + (lastPage * rows * (currentColumn-1)) + (currentRow-1);//algorithm to go down the columns all the way through the file}

if(layout == 2){index = ((currentPage-1) * (rows * columns)) + ((currentRow-1) * columns) + (currentColumn-1);//algorithm to go across the row}

if(layout == 3){index = ((currentPage-1) * (rows * columns)) + ((currentColumn-1) * rows) + (currentRow-1);//algorithm to go down the columns on each page}

return index;

Once all of the pages are generated, some final file information is inserted and the

software is finished. The file is then ready to be inspected and dropped to the digital

printing press.

2.5 Implementation Process DescriptionThe Java development tool used to create the end-product was Borland JBuilder 7. The

coding for the graphical user interface and the main processing were split up. Basic

functions of the code were proven able to be done early on such as opening a Postscript

10

file and writing to it. After this, code for copying and inserting new pages was done.

Algorithms were developed to figure out which serial number should be placed on a label

as the code stepped through each page. Finally the code from the graphical user interface

and the main processing section were coupled. The only problem encountered was an

issue with the spatial placement of serial numbers. If only a single character was put in

the template file in place of the serial number, then when the multi-digit serial number

was inserted the spatial relations were distorted. For instance, if the serial number was

supposed to be centered, it would no longer be centered when the longer serial number

was inserted. This was solved by requiring the template file to include the same number

of place holding characters as the final serial number would have.

2.6 End-Product Testing DescriptionTesting is important in evaluating project development and final adherence to design

requirements. With these ideas in mind, the following testing activities were and will be

used.

1. Component testing – Each function was developed and tested independent of the

rest of the application. Each function was tested using the specific inputs that it

requires to complete the tasks it is designed to do. Component testing was done to

find and reduce problems that may have otherwise appeared in system integration

testing and hence be more difficult to locate and fix. The following component

tests were completed by the project group:

a. Postscript editing – A Postscript file was opened and written to, the file

was then viewed to see if the changes showed up with a Postscript viewer

such as Ghostview. This verified that serial numbers and barcodes could

be edited.

b. Page replication – A single page Postscript file was opened and used to

create a specified number of pages. The pages were viewed to ensure that

they were identical to the template page. This verified that data in the

template page could be used to create more pages.

2. System-integration testing – Once all components are tested, the final system

was tested in one piece. This tested all functional requirements and was done by

both the project group and MetalCraft, Inc. in unison. A single page template file

and serial numbers were provided by MetalCraft, Inc and then input to the

11

project’s software. The resultant Postscript file was sent to MetalCraft, Inc. and

successfully printed. This verified that the file created by the project will would

be understood by the printing press and print correctly.

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. This testing will be completed during the onsite

delivery visit.

4. Performance testing – Testing will be done to compare the performance of the

system after modifications of the new process to the original system. This testing

will be completed during the onsite delivery visit. It is believed that the

performance difference will be great. It currently can take more than an hour to

create the large file that can be a hundred pages. The end-product software can

create a hundred pages in approximately 12 seconds.

2.7 Project End ResultsThe project was successful and the end-product will be delivered to the client in working order. The end-product meets all of the functional requirements and will greatly improve the process flow for MetalCraft, Inc.

3 Resources and SchedulesThis section provides an accounting of the estimated resources for the project and actual resources used. These resources include personnel effort and the cost of completing the project. A section is also provided that shows the schedules used.

3.1 Resource Requirements

3.1.1 Personnel Effort RequirementsThe personnel budget lays out how many hours each team member spent on each

milestone, and then the total hours for the project. The effort has also been revised to

account for changes in the project.

12

Table 1 – Personnel Effort Budget (Original)

Doc

umen

tatio

n

Res

earc

h

End

of fi

rst

sem

este

r

Impl

emen

tatio

n

Test

ing

End

of se

cond

sem

este

r

Del

iver

y

Tota

l

Luke Bodeen 12 5 4 124 10 5 5 165

David Legge 13 4 4 104 5 5 5 140

Curt Melchert 15 3 4 114 5 5 5 151

Ryan Sinnwell 14 3 4 103 10 5 5 144

Total 54 15 16 445 30 20 20 600

Table 2 – Personnel Effort Budget (Revised)

Doc

umen

tatio

n

Res

earc

h

End

of fi

rst

sem

este

r

Impl

emen

tatio

n

Test

ing

End

of se

cond

sem

este

r

Del

iver

y

Tota

l

Luke Bodeen 12 3 4 94 9 5 5 132

David Legge 13 3 4 85 7 5 5 122

Curt Melchert 15 3 4 89 5 5 5 126

Ryan Sinnwell 14 3 4 86 10 5 5 127

Total 54 12 16 354 31 20 20 507

Table 3 – Personnel budget in hours (Actual)

Doc

umen

tatio

n

Res

earc

h

End

of fi

rst

sem

este

r

Impl

emen

tatio

n

Test

ing

End

of se

cond

sem

este

r

Del

iver

y

Tota

l

Luke Bodeen 14 8 8.5 45 10 4 0 89.5

David Legge 12.5 5.5 4 20 3.5 3 0 48.5

Curt Melchert 15.5 12 4 12 0 9.5 0 53.0

Ryan Sinnwell 18 10 6 12.5 1.5 2.5 0 50.5

Total 60 35.5 22.5 89.5 15 19 0 241.5

3.1.2 Financial RequirementsWith a solution that includes a customized software application, there are not many

13

incurred costs. Those that have been encountered are listed below in Table 4 and a short

description of some of the funds follow.

Table 4 – Financial BudgetBudget Item Original Estimated

CostRevised Estimated Cost

Actual Cost to Date

Software $100 $100 $0Poster/Printing $40 $90 $87Phone Calls $25 $0 $0Equipment & Parts $0 $1700 $1700Total $165 $1890 $1787Poster/Printing – This money is out of the pockets of the team. The printing costs

include the final, bound versions of the project plan, the design document, and the final

report.

Equipment & Parts – This budget item covers the purchase of a computer for

development and testing purposes. The computer was donated by MetalCraft, Inc. and

will remain their property at the end of the project.

Phone Calls – The team has found that phone calls are not going to be needed as

frequently as anticipated. There are very open lines of communication via e-mail

between the client and the team, and each party is very prompt in responding to e-mail.

3.2 SchedulesThe project schedule is shown in the next two pages in the form of a Gantt chart. The

lightest gray bars are the original schedule. The medium gray bars are the revised

schedule for the design document. The darkest gray bars are the current schedule. The

project schedule as a whole has been followed very well. There have been some changes

in the schedule as the project has progressed. Research took a little longer than expected

because of problems contacting Quark, Indigo, and Hewlett Packard. The presentation

was developed more after Christmas break than anticipated. Development started a little

late and went a week later than expected. This was because of a label centering issue that

was unexpected. Testing also took place more in correlation with development. This was

not anticipated when developing the original schedule. This was possible because

development progressed quickly. The final report was moved up because the second

semester schedule was unknown when the schedule was made. The user manual was

added as a task because that was not in the original schedule as a task. Delivery has also

14

been moved up so the software can be used before school is over. There is only one Gantt

chart provided because there is only one deliverable for this project.

Figure 3 – Gantt chart of project schedule, page 1

15

Figure 4 – Gantt chart of project schedule, page 216

4 Closure MaterialsThis section discusses the project evaluation, commercialization prospects, recommendation for additional work, lessons learned, and risk and risk management. It also provides information about the team, a final summary, references, and appendices.

4.1 Project EvaluationThe following is an evaluation of the degree of success of the project. It is broken down into the main milestones as defined in the Gantt chart on the previous page. Each milestone is given a degree of success rating based on the following scale:

0 = not attempted1 = not met2 = partially met3 = fully met4 = exceeded5 = greatly exceeded

Then the rating of each of the milestones are averaged together to obtain an overall rating for the project as a whole. The delivery rating is not included because it will be completed by the end of the semester and is not expected to cause any problems.

Documentation (3 = fully met) – All required documentation was completed and submitted on time.

Research for Design Approach (3 = fully met) – Several approaches were considered. The necessary research was done to make an informed decision about which approach would satisfy all design requirements while still being feasible.

End of Semester (3 = fully met) – Group oral presentation was successfully prepared and delivered at the time assigned to the group.

Implement Design (4 = exceeded) – Design and coding of the solution went faster than anticipated and got the project done ahead of schedule.

Testing (2 = partially met) – The fact that the design was done remotely from the operating environment limited the testing that could be done. An onsite delivery visit is planned during with testing will be completed.

End of Project (3 = fully met) – Final project report and industrial review panel presentation were completed successfully and on time.

Delivery (0 = not attempted) – The end product has yet to be delivered to the client. An onsite delivery visit is planned.

Total Project - 3.0 = fully met

17

4.2 CommercializationThe commercial value of the end product is limited due to the specific design

requirements of the project. The end product is specifically tailored to the needs of

Metalcraft, Inc. If other companies with similar printing operations had similar needs,

then there may be a market for this product. However, these companies are likely to be

limited in number, therefore reducing the need for this product. The cost of manufacture

of the end product would include the cost of labor and the cost of the storage media (i.e.

disk or CD-ROM). Since there have been about 242 hours of labor on the project to date,

the current cost of labor is approximately 242*$20 = $4840. The retail cost of the end

product would be somewhat arbitrary and dependent on the current market value of

similar software products. A reasonable value for a product could be between $100 and

$200.

4.3 Recommendations for Additional WorkThe 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 cron with 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.

The functionality of Checkmate could also be incorporated into the end-product. This

would help to reduce the number of file inputs to the end-product. It could also speed up

end-product and reduce the memory resources used by the software.

18

4.4 Lessons LearnedThe project went fairly smoothly once a technical approach was chosen. The

development and implementation of the Java coding was fairly straightforward once the

algorithms were developed. Using Java as the programming language for the project was

a good choice. Java lends itself well to string manipulation and therefore worked well for

this project.

The only problem worth noting with the development of the code was due to some lack

of clarity of the sample files sent by the client. There was some ambiguity as to how the

sample files were created (e.g. if they were already linked) and if that was an assumption

made by the client as to the type of input the final product required. It is very important

to for both the client and the group to clearly state what they want the project to do and

how it is to work.

A problem discovered in the research stage of the project was that many of the potential

technical approaches resulted in dead ends due to a lack of product support for the

software products that would form the cornerstones of those approaches. Also there was

an apparent unwillingness of some companies to give the requested technical support.

We also had difficulty in contacting some companies in the first place.

As a result of the project, the team members have gained a deeper understanding of Java

and how it can be applied in a real-world application. They have also learned enough

about the Postscript file format to be able to complete the project.

The main thing that would have been done differently if the project was to be done again

would be to more clearly define the interfaces between different parts of the process

before implementation was to be done. This would have allowed more of the software

application to be developed in parallel.

4.5 Risk and Risk ManagementPossible 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

19

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.

None of the anticipated risks were encountered. There were also no unanticipated risks

encountered and therefore the risk management strategies were not changed. Even

though no risks were encountered, the strategies should be reviewed and extended if the

group is to complete another project.

20

4.6 Project Team InformationClient: MetalCraft, Inc. Faculty Advisor: James Davis

Mason City, IA 50401 2413 Coover

John G. Henry Ames, IA 50011-3060

641-423-9460 (phone) 515-294-0659 (phone)

641-423-8898 (fax) 515-294-8432 (fax)

[email protected] [email protected]

Team: Luke Bodeen David Legge

2823 Ontario St 428 Stonehaven #6

Ames, IA 50014 Ames, IA 50010

515-292-1049 515-451-5732

[email protected] [email protected]

Curt Melchert Ryan Sinnwell

300 Stanton Ave Apt 308 3236 Frederiksen Ct

Ames, IA 50014 Ames, IA 50010

515-598-9110 515-572-7899

[email protected] [email protected]

4.7 Closing SummaryProductivity is important to companies because of the need to get the most out of the people and resources currently available. This project was needed to help MetalCraft, Inc. increase their productivity by improving the process that they use to design and print labels. By using the proposed design, process time and flow will be significantly improved and streamlined. The solution will be independent of current software, thus allowing it to adapt to updates in the system. MetalCraft, Inc. will be able to increase their productivity for each job and in turn be able to accept more business.

4.8 ReferencesThere were no references necessary.

21

4.9 Appendices

4.9.1 Appendix 1 – Process flow diagram page 1

Appendix 1: Process flow diagram page 1.

22

4.9.2 Appendix 2 – Process flow diagram page 2

Appendix 2: Process flow diagram page 2.

23

4.9.3 Appendix 3 – Postscript code example and description

Notes are provided to describe with Postscript commands should be modified and where they should appear in the file. All other commands are from a sample page and should not be altered.

%%Page: 1 1 Identifies the beginning of each page (%% Page: 2 2, etc)

%%BeginPageSetup%RBIIncludePageSlotInvocationmTSsetuppmSVsetupinitializepage(Becky; page: 1 of 1)setjob Should change for each page, may not be

necessary though%%EndPageSetupgS 0 0 878 1238 rC1 G0 0 0 0 rF0 0 :M%%QRKSequentialPageRange: 1 1 Only on first page, if 4 pages then :1 4%%QRKPageBegin: 1 Change for each page (1, 2, 3, etc)%%QRKSequentialPage: 1 Change for each page (1, 2, 3, etc)%%PlateColor: BlackQuarkXPress_4.04 beginF/ss X 1 1 pen 0 H 0 a 0 b[] 0 p0 H(-1 -1 793 613 initclip F rc u)kpxpbu 1 F 150 45 sp0 T xpscrncalcbndxpbns2qd-1000 -1000 :Mf53 sf( )S-1000 -1000 :Mxps2ps

24

xpbu0 1 F 0 F /|______Helvetica T /|______Helvetica-Bold 0 T dfntxpbn0 1 1 fs2qd-1000 -1000 :Mf90 sf( )Sxps2psxpbu1 0 [T 6 F F /|______IndigoOne 0 T dfntxpbn1 1 1 fs2qd-1000 -1000 :Mf129 sf( )Sxps2psxpbu2 0 [T 6 F F /|______IndigoEight 0 T dfntxpbn2 1 1 fg .2 o72.1 72.1 125.9 215.9 8.1 rr1 n G1 setchc bkc 0 1 put1 Hptc0 H1 17 25 f90.8843 105.4378 m 1.3311 0 7 106.4813 (*138000*)d (* is for barcode0 15.62 12.5 f115.8955 121.5608 m .4341 .8685 5 52.1164 (138000)d ( is for text, need to search

for ( and then a number, may need to use a special

characterbkc 0 0 put1 setchc bkc 0 1 put

25

1 Hptc0 H10.07 9.5 Z90.5596 83.5232 m .2798 .7277 7 55.3898 (PROPERTY)d155.3966 h .2798 .7277 5 38.6007 (OF UOP)dbkc 0 0 putend%%QRKPageEnd At the end of every pageendp At the end of every page showpage At the end of every page %%PageTrailer At the end of every page %%Trailer Only on the last page of the file end Only on the last page of the file%%EOF Only at the end of the file

26