Pat said it briefly. Guus, I've seen you around for a while and think it very likely that you understand the need for normalization, so I won't go there. I'll address structural and procedural issues instead.
A single record can have up to 400 fields.
No it can't, not if Access is involved. You are looking at limits of no more than 255 fields and no more than (about) 4000 total bytes in the record split among all integers, reals, and text. You can't even exceed those limits with a query because the limits are on recordsets, not just on tables.
With some judicious formatting, you MIGHT be able to have a parent record nearest the top of the page and several child records below it, with each child record being captured in a sub-report. Pick some things that are the most important part of the record to define the parent and then build a one/many relationship with the other parts. Even though it seems like it should be one/one, remember that with relational integrity, one/one tables can get in a deadly embrace if you try to add records to one of those tables first.
That table split would also take away some of the pressure associated with having so many controls on a given report, since there is a limit of (I think) 768 controls per report. If you really had 400 fields, you start over halfway to the limit and that leaves you in a precarious position for growth or "special features" that might need to be added. You also need to watch out for any of those elements having associated labels that you use for captioning since labels are controls too.
As to the grid, though... that's just a matter of being sure that in design mode you have "Snap to Grid" set and then make the controls have solid borders. Then drag-n-drop them to the desired alignment. You can also do a bulk sizing by drawing a box around the controls, showing the Properties panel, and putting some appropriate number in the Height property while your multi-control group is selected. All of them will snap to that size at the same time. If you pick a height that comes out even with respect to twips, you can do this with no apparent overlap or blurring of the text boxes.
This is going to be a "divide and conquer" situation. Divide your report data into groups that then are moved to child tables. Divide your report into various blocks on the page to allow for the parent fields and sub-reports for the child fields.
If it happens that some of the information you want to display is "boilerplate" for which many fields are instantly specified when you know one item (say, the total displacement of the engine in cu.in. or cc), then you might be able to move some of the engine information out to a table of standard info for engines of a particular size. OK, it might not be size that defines the choice of common elements, but perhaps you see what I mean, and that commonality would contribute to reduction of the table size to fewer than 400 fields.
