Most clients obtain from Tina Kay the latest readme.txt file on a periodic basis to see what is new in Unibase by DMAC. Now the ability to download the file as a pdf has been added to the support page of the website.
The readme file was created to give a quick overview of what has changed in the latest version of Unibase. Tina still keeps the listing as short as possible. Her goal is to let users utilize the new features without anything more than the readme file.
This may make the readme file cryptic to non Unibase clients. In addition as Unibase is changed to coexist with Microsofti??s Operating systems it may appear that DMAC is unduly harsh in criticizing Microsoft for constantly changing how its operating systems and compilers work. In fact, Microsoft seems to constantly be moving towards a more rigorous interpretation of standards which allows tighter code and makes the code more secure.
DMAC’s developers must keep up with the changes Microsoft makes. A significant amount of time is spent doing this. Of course it is DMAC’s policy to move forward in a heuristic fashion. DMAC makes it possible for the past user effort, programs, formats, and jobs to still work in the latest Unibase environment. This gives rise to a lot of challenges which other products do not have. These challenges keep DMAC’s developers young at heart.
Keying data from images requires zooming, zoning, and manipulation of images during the process of setting up a keying job. In the past, Unibase Imaging had developed many features and special approaches for manipulating TIFFs.
As PDFs and JPEGs have become more popular, the need to extend these features to them has increased. So DMAC added every feature it had for TIFFs to the processing of PDFs and JPEGs to Wrfmouse.
The Client Support group at DMAC said almost everyone was now using Wrfmouse not Rfmouse, so the enhancements were only added to the Wrfmouse zoning program.
While this sounds simple, users should remember that PDFs and JPEGs can be full 32 bit color documents or black and white images and almost everything in between. Zooming and cutting these images on the fly took special effort to make it work.
Sometimes clients run into speed problems because of the way they are using Unibase Imaging. In both the case where there is very little data entered into a record before the image is changed and in the case where only OCR data is automatically fed into a record, the speed of the graphics display process was slowing Unibase Imaging.
DMAC’s development team studied the data and the code then made improvements. In the comparison batch of OCR work being put to a batch after field editing, the speed of the process was improved from 87 seconds to 45 seconds.
If DMAC users look carefully at the graphics display while a batch is being created in either of the cases mentioned, they will notice that now DMAC paints the background of the image window around the image being displayed rather than clearing the image window then displaying the image.
This change probably makes such a difference because of the relative speed of the processing cpu with its multiple processors and the graphics display and its heavy buffering.
DMAC just doubled the speed and thus the efficiency of processing this type of work.
One of the questions DMAC is asked frequently is how important is the speed of the server when compared to the speed of the workstation.
This fall DMAC conducted an experiment to see the effect of changing the server speed, network interconnection speed, and the workstation speed.
Benchmark: For measuring the relative speed of the processor, The Windows Experience Index is used. Both a 4.4 calc/sec workstation and a 7.1 calc / sec workstation required 27 minutes to perform a quality assurance test, called mtest, in Unibase which uses many of the features in Unibase by DMAC.
First Experiment: The older unmanaged 10/100 switch, or sometimes called TCP hub, was replaced with a new managed Gigabit 10/100/1000 Switch. This made no difference on the time it took either workstation to perform mtest.
Second Experiment: The memory on the server was upgraded to 2.5 gigabytes from 2 gigabytes. This made no difference on the time it took either workstation to perform mtest.
Third Experiment: The server was upgraded to a dual core processor of about the same gigahertz and memory was increased to 4 gigabytes from 2.5 gigabytes. This made a difference. The 27 minutes for the 4.4 calc/sec workstation stayed the same. The 7.1 calc/sec workstation time dropped to 10 minutes.
Analysis: What does this say about the load on the server compared to the load on the workstation. If a simple resistor network is used to model the results, then the following is true: Let RworkstationOne, RworkstationTwo and Rserver represent the three resistances of the workstation one, workstation two and the server. Then RworkstationOne /RworkstationTwo = (7.1/4.4) = 1.61.
Rserver + RworkstationOne = 27.
Rserver + RworksttionTwo = 10.
Rserver + 1.61*RworkstationTwo = 27.
Rserver = 27 – 1.61*RworkstationTwo.
Rserver + RworkstationTwo = 10.
RworkstationTwo = 10 -Rserver.
Rserver = 27 -1.61*(10 – Rserver).
Rserver = 27 -16.1 – 1.61*Rserver.
2.61Rserver = 10.9.
Rserver = 10.9/2.61 = 4.2.
RworkstationOne = 27 – 4.2. = 23.
RworkstationTwo = 10 – 4.2 = 5.8.
So in this rough calculation if you increase the workstation speed by 1.61 you get about a 2.7 increase in speed. Another way of saying this is that the workstation speed is about twice as important as the server speed.
A user panning an image in Unibase Imaging up, down, left or right sounds like a straight forward application. When the user adds zooming in and out it gets more complicated. A user’s expectations as to what happens when a new record is chosen make the entire process one with a multitude of possible solutions.
So DMAC collected all user requests for the past few years and built a matrix of what the user was expecting in each case. The first noticed correlation was that user expectations were changing over time. DMAC’s development team figures that this is because of other popular software products working in a particular way.
Armed with the results of the study, DMAC made changes to the process.
Hopefully now users will like what happens when they pan or zoom an image and move to a new image
Many Unibase clients utilize Macro Procedures and Keystroke Macros to automate their repetitive work flow processes. A DMAC client came up with a need for using data stored in some global variables of a group of batches used by an operator. So DMAC added a new Keystroke Macro variable.
Keystroke Macros are enhanced with a new op_code of ‘GV’. ‘GV’ stands for Global Variable. In the keystroke Macro the next two characters have to be the number of the global variable. Global variables range from $var00 to $var99.
The processing of the ‘GV’ variable allows the work flow process to ask the current operator’s process for information from a global variable in that process; perhaps the name of a file to be output.
This request would be in the Macro Procedure that will call the Keystroke Macro. The global variable has to be of type alphanumeric, NOT NUMERIC. Then, when the keystroke macro encounters the GV op_code, Unibase uses the characters stored in the specified global variable and processes them as if those characters were stored in the keystroke macro.
When all the characters in the global variable have been processed, Unibase picks up executing the op_code char combinations in the remainder of the keystroke macro.
