You haven't said a lot about what your criteria are. Just using a nice
big field is easy and trivial. I assume from context that you are trying
to maximize the number of significant digits you can get in a field of
modest width. People have discussed that general issue here not too
awfully long ago. There are some definite tradeoffs in conciseness
versus clarity; I can't answer those for you. For example, is it
acceptable to omit the exponent letter as in 1.234-5 on the theory that
this is unambiguous if you know that the - can't be subtraction in
context?

Anyway, although details vary, you pretty much have to do your custom
function (or borrow one from someone else) if you want to do a very good
job of maximizing this. The standard doesn't have anything very good in
that regard. I think I recall that you can get by with E12.6 or
equivalent scalings up or down, with the number of guaranteed
significant digits 6 less than the field width. Actually, the case I
most recall was E10.4, trying to squeeze a barely acceptable (to my app)
4 significant digits into a field of 10 columns, back in punched card
days. You might think that E10.3 (or E12.5) was the best case, but the
compiler is required to drop optional characters if that's what it takes
to fit in a field; I'm pretty sure I recall that made E10.4 work.

You can do a lot better than the width-6 significant digits in most
cases if you do a custom function.

Note that using 1P with G looses a significant digit. I went around on
this with Glenn some time ago. I'm not having the argument again about
whether it makes sense, etc. (I still think it was just plain an
off-by-one typo in the standard, but I'm not arguing that any more).
Regardless of the reason, the fact is that you can't guarantee as many
significant digits in a give field width with 1PG as you can without the
1P.

If you do a custom function, be wary of the recently discussed
prohibition against recursive I/O. A function to do something like this
is one example of where recursive I/O to an internal file is useful (and
there's one more reference to that subject for Bob's count. :-)). You
are really likely to want to use internal I/O in your function. That
probably means you'll have to always do things like (ignore my non-f77
names)

   temp_char_var = your_function(whatever)
   write (lun,...) ..., temp_char_var, ...

instead of

   write (lun,...) ..., your_function(whatever), ...

Also, since you are stuck with f77, recall that list-directed internal
I/O isn't allowed in standard f77.