RE: [LC Review]

As the simplest and most expedient solution to the problem identified in my
previous message, I propose simply doubling the byte limit for both
graphical and non-graphical text strings. Note that the latter has two
subclasses, one dealing with standalone strings and one for strings within a
data record (type D). Also note that ISO/IEC 8632-1:1999/Cor.2:2007(E)
specifies that the latter subclass also includes the structured data record
(type SDR). Both table cells in T.14.5 should be changed to reflect that
corrigendum.

Summary:

Maximum string length (bytes) for type S: 508 (T.14.4)
Maximum string length (bytes) for type SF: 508 (T.14.5)
Maximum string length (bytes) for type SF within type D and within type SDR:
2048

This solution addresses the specific use case that I mentioned (Metafile
Description).

Regards,

Rob

Rob Orosz
Senior Software Engineer
Auto-trol Technology
11030 CirclePoint Road
Suite 450
Westminster, CO. 80020
(303) 252-2262
http://www.auto-trol.com


>  -----Original Message-----
> From: 	Robert Orosz  
> Sent:	Thursday, September 18, 2008 5:20 PM
> To:	'public-webcgm@w3.org'
> Subject:	[LC Review]
> 
> T.14.4 and T.14.5 of the WebCGM 2.1 profile specify the maximum lengths of
> graphical and non-graphical text strings respectively. Unfortunately, the
> limits are given in bytes. This unfairly penalizes users who choose UTF-16
> character encoding for their text strings. Their limit is half the number
> of characters that a user choosing ISO Latin1 gets.
> 
> An example of the impact this has is in the Metafile Description. Our
> software does not output a Date substring if the user chooses UTF-16
> character encoding for non-graphical text strings because doing so would
> violate the (byte) limit specified in T.14.5.
> 
> Regards,
> 
> Rob
> 
> Rob Orosz
> Senior Software Engineer
> Auto-trol Technology
> 11030 CirclePoint Road
> Suite 450
> Westminster, CO. 80020
> (303) 252-2262
> http://www.auto-trol.com
>

Received on Wednesday, 8 October 2008 17:41:55 UTC