RE: AW: XForms-processor as applet

As a point of fact, in the legal area "court forms" may have to have "graphical
integrity" to be used.

To get a feel for it, a good group may be found at
http://www.courtinfo.ca.gov/forms/

Best Wishes,

Bruce Williams

> -----Original Message-----
> From: www-forms-request@w3.org [mailto:www-forms-request@w3.org]On
> Behalf Of Price, Kathryn
> Sent: Wednesday, June 14, 2000 10:10 AM
> To: 'Rob McDougall'; www-forms@w3.org
> Subject: RE: AW: XForms-processor as applet
>
>
> I agree that there are numerous variables to consider in electronic forms
> design. However, to contemplate "graphical integrity" (i.e. how accurately
> the electronic form prints compared to a paper original)or user preferences
> in considering development of an internet standard is absurd. The focus
> needs to stay on developing and transporting accurate, valid form data.
> "Repurposing" of information should be handled by other applications. This
> will be facilitated by a robust non-proprietary format for data.
> -Kathryn Price
>
> -----Original Message-----
> From: Rob McDougall [mailto:RMcDouga@JetForm.com]
> Sent: Wednesday, June 14, 2000 11:08 AM
> To: www-forms@w3.org
> Subject: RE: AW: XForms-processor as applet
>
>
> Aha, now we have hit upon one of the most common arguments in the forms
> world.  Should the form be immutable in all presentations or should it be
> altered to best utilize the medium it's presented through?  The
> (unfortunate) answer is that it varies from form to form and application to
> application.  There is no one right answer.
>
> In adhoc workflow forms, the presentation of the form is less important than
> ease of use.  This is very analogous to the way HTML works.  You typically
> want the form to take advantage of whatever screen real estate is available
> and you probably want to allow the user alter the look of the form to suit
> their individual needs/tastes (increasing font size, etc.).
>
> In legal forms, the presentation of the form is more important than ease of
> use.  You typically want the text presented in a certain fixed and
> determinate manner.  This is analogous to the way PDF works.  You make the
> medium (i.e. the screen) conform to the way you want the form presented.
>
> Then, there's all the in-between cases.  Maybe you've got a bunch of legal
> text and you don't really care how it's presented as long as it's legible
> (size < 6pts) and text appears on the same page as the signature (to ensure
> the signer has read it).  There's an innumerable number of in between cases
> that run the gamut from "form can only change a little in this one specific
> way" to "the form can do whatever it wants except that this one thing must
> be true".
>
> For V1.0 we are assuming that the user will have access to XHTML + CSS2 and
> we will be incrementally improving these in the context of forms.  We won't
> be tackling the printing of perfect paper forms until later (as is stated in
> the "Future Considerations" of the XForms Requirements Document).
>
> Rob
>
> -----Original Message-----
> From: Neil Walker [mailto:neil.walker@mrc-bsu.cam.ac.uk]
> Sent: June 14, 2000 6:15 AM
> To: www-forms@w3.org; ashutosh.galande@tatainfotech.com
> Subject: Re: AW: XForms-processor as applet
>
>
> > It would be highly beneficial to have a perfect rendering engine
> > (independent of a browser) that will felicitate coexisting of
> > pre-printed paper forms and client-printed paper forms (printed from
> > within the browser etc). I feel it should be possible to print a form
> > from within a browser that looks exactly the same as its paper based
> > counterpart and a plugin based approach is better in this regard.
>
> Agreed a perfect rendering engine would be a Good Thing, I feel
> technology should be used appropriately.  On paper, I might say "please
> circle the answer that best applies", while on a web form I might use a
> checkbutton or pull-down list, and on a fax-back form a tickbox.
>
> Like most of us on this list I'm working on a forms generator, and my
> view on this is that there could be an extra button marked "Print" to
> print out either a pre-prepared paper form, or something suitable
> generated on the fly from the XML. The question then becomes, whether
> XForms is required AT ALL, or whether we go straight for
> HTML4+Javascript generation from a yet higher level metadata standard.
>
> Yours
> Neil Walker
> --------------------------------------------------------------------
> Neil Walker                     tel:   +44 (0) 1223 330379
> MRC Biostatistics Unit          fax:   +44 (0) 1223 330388
> Cambridge, UK                   email: neil.walker@mrc-bsu.cam.ac.uk
>                                 web:   http://www.mrc-bsu.cam.ac.uk
> --------------------------------------------------------------------
>

Received on Wednesday, 14 June 2000 14:37:06 UTC