The original PDF can be found at:
FCG TS61804-4 EDD Interpretation
It is difficult for FDI package developers to develop 1 package that renders the desired user interface similarly on all host applications. This is partially due to the EDD specification allowing for variation in user interface rendering. EDD specification supports host applications that render an item’s LABEL above the item field (using more vertical space to allow for wider label space). EDD specification also supports host applications that render an item’s label next to the item field (uses less vertical space, at the expense of having less space reserved for labels). And then the EDDL specification now also adds 2 different LAYOUT types (optimized vs. equal column width), but no application even supports both layout types to allow package developers to evaluate their user interface in both layout types.
How can FDI package developers design and validate a single device package that is rendered in a desired way on all host applications?
The current EDD specifications were created to balance the trade-offs od specifying exactly how every EDD host application should render its interface with being generic enough to support a wide variety of EDD applications. Some EDD applications have more screen space available than others. Some EDD applications are fit-for-purpose (e.g. a device calibrator), while others are more generic (e.g. an asset management PC application). Because different applications have varying levels of control over their displays, the EDD specification should not prescribe exact details such as pixel count, font size, control field renderings and other low-level details.
FCG TS61804-4, clause 126.96.36.199 currently states:
In order not to disturb the layout of the EDD application, for example, with oversized buttons for methods, the EDD developer should not use very long strings for LABELs. For this reason, some EDD applications may truncate these labels. However, there shall be some methodology, such as a "tool tip", "pop- up window", “expanding window”, etc, to display the entire string to the user.
While this statement in the spec is meant to allow an end user to view the entire label of an item, even if the label consumes more space than is available on the normal display of the menu, it does not give much guidance to the EDD developer as to how short they should keep their labels.
In order to help provide a way for EDD developers to provide more uniform rendering of their DDs across all EDD applications, a minimum of 32 characters is determined to be a satisfactory label size that all EDD applications could fit on a user interface without needing to truncate the label. EDD developers can choose to keep their labels to 32 characters or fewer if they want to avoid an application from truncating their labels as described above. EDD developers may still choose to use wider than 32 characters for their labels, with the understanding that some applications may truncate (but will still provide some methodology to display the entire string to the user as described above.
EDD specification will be updated to include the guidance to use labels that are 32 characters or less if the DD developer wants to avoid applications from truncating their labels.
Some host applications may need to have their implementations updated if they currently cannot display 32 (of the widest) characters without truncation.