Displaying the submitted values in a table
You don't need to redirect the form like that: a form submission handler can pass data to the form builder using $form_state; in this way, you don't have any limit for what you can pass back to the form builder.

It's enough the form submission handler uses the following line.

$form_state['rebuild'] = TRUE;


Then it saves in $form_state the values to pass back to the form build, being careful not to use the same index used for other purposes, from Drupal, or your module. Usually, $form_state['storage'] is used for that purpose, as explained in $form_state keys.


  $form_state['storage']
      When building complex forms that require multiple steps for completion (for example, a three-page survey), it's necessary to preserve the data from all steps so that they can be processed together at the end. (And, on occasion, to vary the contents of one step based on the input from the previous one). Any data placed in the 'storage' bin of the $form_state collection will automatically be cached and re-loaded when the form is next submitted, allowing your code to accumulate data from step to step and process it in the final stage without any additional code. Developers who want more control can use their own caching mechanisms to store temporary form data (the user session and hidden form fields are two popular alternatives), but the 'storage' bin is automatically handled for you by the form API.


That is for Drupal 6; for Drupal 7, see drupal_build_form().


  storage: $form_state['storage'] is not a special key, and no specific support is provided for it in the Form API. By tradition it was the location where application-specific data was stored for communication between the submit, validation, and form builder functions, especially in a multi-step-style form. Form implementations may use any key(s) within $form_state (other than the keys listed here and other reserved ones used by Form API internals) for this kind of storage. The recommended way to ensure that the chosen key doesn't conflict with ones used by the Form API or other modules is to use the module name as the key name or a prefix for the key name. For example, the Node module uses $form_state['node'] in node editing forms to store information about the node being edited, and this information stays available across successive clicks of the "Preview" button as well as when the "Save" button is finally clicked.


If you really need to print the data in another page, then save the data in $_SESSION, instead of passing that as GET data.