Generic Pdf Template and Pdf (abstract)

From UG

(Difference between revisions)
Jump to: navigation, search
(Questions and RFC)
(Classification of widgets on pdf template and How each widget must be defined in spec)
Line 24: Line 24:
-
Pdf Template serves several purposes (and have related classification of widgets):
+
Pdf Template serves several purposes (and have related classification of widgets). Respectively to 3 cases above we have 3 cases of what should be specified in the design.
-
* 1) to show EXISTING fields from the system (CT record mostly) that would appear on pdf (Examples: Shipper, CBM)
+
==== EXISTING fields from the system (CT record mostly) that would appear on pdf (Examples: Shipper, CBM)
-
* 2) to let user add some NEW fields (that we do not have in the system) that would appear on pdf (Examples: pick up time; comments )
+
Since these fields has been defined already in the system as a rule (with just minor number of exceptions) these fields are to be considered (by default) on template to be identical (UI control type, UI control attributes, etc.)
-
* 3) to manipulate data (Examples: convert CBM into CFT; insert new lines into "pdf commodity table")
+
Example: Import Ref is a alphanumeric textbox, max length 30 chars defined on Gen Tab. On Pdf template where it appears it will be have same characteristics therefore '''on wiki spec we shall not repeat that it is alphanumeric textbox, max .... '''
-
 
+
-
Respectively to 3 cases above we have 3 cases of what should be specified in the design:
+
-
 
+
-
* 1) since these fields has been defined already in the system as a rule (with just minor number of exceptions) these fields are to be considered (by default) on template to be identical (UI control type, UI control attributes, etc.). Example: Import Ref is a alphanumeric textbox, max length 30 chars defined on Gen Tab. On Pdf template where it appears it will be have same characteristics therefore '''on wiki spec we shall not repeat that it is alphanumeric textbox, max .... '''
+
Known exceptions:
Known exceptions:
Line 42: Line 38:
*** in this case there must be a full definition
*** in this case there must be a full definition
-
* 2) in this case there must be a full definition
+
==== NEW fields (that we do not have in the system) that would appear on pdf (Examples: pick up time; comments ) ====
 +
 
 +
In this case there must be a full definition
 +
 
 +
==== Data manipulation (Examples: convert CBM into CFT; insert new lines into "pdf commodity table") ====
-
* 3) full definition required
+
Full definition required
=== Validation feature (How to predict in advance if specific value can fit on pdf and warn user) ===
=== Validation feature (How to predict in advance if specific value can fit on pdf and warn user) ===

Revision as of 08:31, 2 February 2010


Contents

Classified As and Parent Mantis

  • Classified As: (abstract) component
  • Parent Mantis: tbd

Business Needs and Requirements

Core Requirements

Additional / Detailed Requirements

Technical Specification

Summary

Every pdf has a pdf template. See Introduction into Ops Pdfs Module#3 step process.

See Figure ...


Classification of widgets on pdf template and How each widget must be defined in spec

Pdf Template serves several purposes (and have related classification of widgets). Respectively to 3 cases above we have 3 cases of what should be specified in the design.

==== EXISTING fields from the system (CT record mostly) that would appear on pdf (Examples: Shipper, CBM)

Since these fields has been defined already in the system as a rule (with just minor number of exceptions) these fields are to be considered (by default) on template to be identical (UI control type, UI control attributes, etc.)

Example: Import Ref is a alphanumeric textbox, max length 30 chars defined on Gen Tab. On Pdf template where it appears it will be have same characteristics therefore on wiki spec we shall not repeat that it is alphanumeric textbox, max ....

Known exceptions:

    • 1a) value from more complex UI control (combobox or date) is displayed inside more simple UI control (textbox)
    • 2a) values from 2 controls are combined in one
      • in this case there must be a full definition

NEW fields (that we do not have in the system) that would appear on pdf (Examples: pick up time; comments )

In this case there must be a full definition

Data manipulation (Examples: convert CBM into CFT; insert new lines into "pdf commodity table")

Full definition required

Validation feature (How to predict in advance if specific value can fit on pdf and warn user)

To est' zadacha sostoit v tom chtob predupredit' usera chto skagem znachenie "AIRMARK OCEAN & AIR LOGISTICS" polya Trucker ne pomestitsya na pdf i kakim to obrazom dat' mehanizm chtob user mog podkorektirovat' i ponyat' skol'ko vlezet.

This feature has not been implemented yet. See suggested designs below.

1) this can not be predicted easily in advance (before pdf generation) because characters have different width. Or we can calculate this based on specific font and known width of each symbol?

2) kogda poyavlyaetsya template, podsvetit' polya kotorye imeut znacheniya kotorye slishkom dlinnye i User by pri pomoshi Backspace udalyal odin za drugim chars s hvosta i v kakoi to moment pole by perestalo byt' podsvechenym oznachaya chto ono uge vlazit i togda user by ostanovilsya.

3) Eshe odno reshenie, veroyatno bolee prostoe sostoit v tom chtob podsvetit' nepomestivshiesya polya odin raz (kagdyi raz) posle togo kak uzer nagal "genrate report" - togda user znaet kakie polya ne vlezli i podpravit

User Interface and Functionality

Entities and Attributes

Special Cases and Misc

Look And Feel

Layout of fields on template should mimic same on pdf as much as possible.

Figures

Figure: XXX

Questions and RFC

  • "Continue to the next page" - where to place ? Marc suggested: every page bottom right and last line of commod table.

Known Non Critical Bugs

History

DB

Personal tools