Steve has written about the: "Epidata alignment problem"

The basic difference to remember from Epi Info v6 to EpiData and other windows based interface programmes is the change from character based to pixel based interface. The Epi Info screen V6 has 80 characters on aline which can either contain a space or some letter.

Therefore what from simple logic could be phrased: (Quoted from Steve's mail:)

"What EI does is remove the left bracket in field A and shift the REST OF THE LINE one space to the left. It then removes the right bracket from A and again shifts the REST OF THE LINE one space to the left. It then does exactly the same thing for field B. Everything would now be out of alignment with the next line, except that EI then adds two spaces IMMEDIATELY to the right of EACH field from which the brackets have been removed."

is not simple in the Windows environment, because the width of a space is not easily attainable. The basic choice in developing EpiData could then be:

a. We skip the rec file format altogether and create a new variant where alignments are measured in pixels instead of in characters. We develop a "drawing interface" where placements of fields are freely floatable.

b. We maintain the rec file standard which has as a consequence that all sizes for the screen are measured in characters of variable width. The problem is that the header only allows for small numbers to describe placement of entry fields etc.

c. We try to fiddle with a combination of calculations to estimate the length of "one space" and based on this use the REC file format as a basis of creating a "usually nice looking" entry screen.

d. We add a new file type defining the exact positions of fields.

e. We restrict choice of fonts to known types where alignment is possible.

The point C is actually what we have done. The problem being that even with fixed size fonts the width of a space or a given letter is not very easy to calculate on a given screen. Many aspects of this is also bound to language. Some solutions are very good for one language, but not for other languages with special letters. EpiData Software is typically downloaded from nearly 100 countries every month, so to do development and accomplish only one or a few is not fair. Already basing all on the english language (and now website also in Spanish) is a restricted policy. E.g. obviously I would prefer that everything was written in my native language Danish, but only about 5 mio people speak that language.

Users who have been along since 1999 will remember that in the beginning there were many problems of combinations of fields and texts which ended messed up/overlapped or hidden from the interface. So the current principle is a "parsimoneous" balance of different tests and principles creating exactly the alignment problems pointed out.

So what are the solutions to the problem a. Someone find or develop very good algoritms which can in a standardised way replicate alignment properties and submit them to us. b. Persons who are very keen on this uses other software which is not tied to the limitations of the rec file format. There are plenty of commercial solutions to choose among. c. We find another solution.

Option A: Anyone keen to experiment and spent time on this can find freeware tools at http://www.freepascal.org/

So the statement "If ED is indeed legacy EI then the face presented to the world should work properly." obviously is a very nice goal, but as mentioned not easy to attain. Focus is on the data entered NOT on the visual quality of the interface.

The fact is that interface handling is a whole different story than:

But if there are resources for doing things like import/export, pack, codebook, validate, consistency, compress, archive

which can all be handled by standard logic, and which tends not to be included in other software. What we have done with the EpiData development is to accomplish needs which we found possible and desirable within the time frame we had for this project. Data quality has the main driving priority - quality of alignment on screens has not.

My suggestion is to add the issue "enhancements of data entry screen and design" to the development list for the plan 2006-2010. If someone are willing to find funding for this on top of the already planned activities it can be added, but otherwise it will not be added.

Whether the patience of users of the software is sufficiently large for this approach or they decide on option B above is not up to me to decide.

Kind regards

Jens Lauritsen Initiator and Coordinator of development. EpiData Association