AW: [EpiData-list] Alignment Problem----Last Time

epidata-list at epidata-list at
Wed Aug 9 13:22:20 CDT 2006

Dear Steve

Usually I just follow the discussions on the Epidata-list and try to learn what there is to learn.

But his time, it is me who can not keep "my mouth shut".

Your statement is just such a wonderful advertisement for EpiData that I really would like to quote you on this (I myself can not claim to have used "the EpiData / EpiInfo system" for 20 years).

If you do not object, I actually will use your laudatio in meetings and tutorials.

With best wishes

Marcel Zwahlen, PhD
Department of Social and Preventive Medicine
University Berne
Finkenhubelweg 11
CH-3012 Bern
phone     ++41-31-631.3554
facsimile ++41-31-631.3520 

-----Ursprüngliche Nachricht-----
Von: epidata-list at [mailto:epidata-list at] 
Gesendet: Mittwoch, 9. August 2006 17:05
An: epidata-list at
Betreff: [EpiData-list] Alignment Problem----Last Time

Dear Jens,
      Thanks so much for the time you took to respond to my concerns
re alignment in ED.  Now that I understand the technical problems
you face in modifying the 'look' of the data entry screens, I will  keep my
mouth shut.  I did not mean to give the impression in my original message that I
will not continue to use ED.  There are so many wonderful features you guys
have developed on top of the EI features that you carried over that I will mess 
with the QES files to get the alignment I want.
     I have been using EI/ED for almost 20 years and have no intention of
switching to anything else on earth, despite the fact that I have the resources
to do so!  There is simply nothing better, in my opinion, for epidemiologic
studies and data.   Thanks again

Steve Blum


[EpiData-list] Aligning of fields and development priorities
epidata-list at epidata-list at 
Fri Aug 4 16:27:42 CDT 2006 

Previous message: [EpiData-list] Epidata alignment problem 
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] 

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 

"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:

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.

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.

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.

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

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

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

Previous message: [EpiData-list] Epidata alignment problem 
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] 
More information about the EpiData-list mailing list


More information about the EpiData-list mailing list