Enhancement: Display Size and Type of field in Print View

[GoogleCodeExporter]

Suggested Enhancement:

Similar to issue id:114

Optionally, enable display of field [size] and [type] in the design view.

Alternatively, it would be nice to display a Key (somewhere at the bottom of 
the printed page (like the minimap)) that indicates the field type of a given 
colour.

It would also be nice to have the option to insert a Heading, and perhaps some 
summary text to help an end-user understand the schema.

Original issue reported on code.google.com by schli...@gmail.com on 2 Mar 2011 at 6:41

[GoogleCodeExporter]

Implementing additional information to the Print view is somehow problematic, 
due to the way how printing works: the browser prints exactly what is seen on 
the screen, with the only difference of applying different (specialy crafted) 
style sheet.

This means that the only technological means of specifying different content 
for print/view modes are CSS files. This being said:

1) adding size and type to field could be done, but doing so would probably 
enlarge the table and brake the alignment;

2) alternative key display is hard to manage, as there is no way to guarantee 
its position withing the printed page;

3) adding any additional information is kind of confusing process, as the user 
is required to input some text which cannot be visible (since we are displaying 
on monitor screen), but will become visible once we start printing.

Overall, I am not sure whether this actually brings any improvement, or rather 
more confusion for a casual user...

Original comment by ondrej.zara on 2 Mar 2011 at 7:10

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Ondrej,

1. Yes I agree.

2. It could appear similar to the minimap, pinned to the bottom of the screen. 
(Perhaps it is hidden from view during normal operation and displayed only at 
print - via css)

** Another option for the key, is to create a separate table (to act as a key), 
with the appropriate fields: ie Numeric, Text, Date, Logical etc. The problem 
with this approach is that it pollutes the true schema. But the idea of being 
able to use the current functionality of the tool (perhaps with a flag to not 
include the object in the true schema) might be a simpler workaround ** See 
attached.

3. The additional information could be added to the schema xml file, as two 
additional fields, perhaps heading and notes. I am not sure the best way to 
prompt for creation / edit/update of the information via the browser interface. 
Perhaps it can just be added manually (in a text editor) and if present used in 
the print preview output ?

Original comment by schli...@gmail.com on 3 Mar 2011 at 4:29

• Added labels: ****
• Removed labels: ****

Attachments:

• schema_sample.png