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.

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.

"... Other than text attributes and Style Properties, the calculation is not
affected by CGM Primitive Attribute (such as line width) or Control elements,
nor by APS
Attributes or Style
Properties ..."

Isn't that a contradiction regarding Style Properties? Do Style Properties
affect the calculations, yes or no?

Benoit.

----------------------------------------

WebCGM WG Response:
Resolution:
Replace the subject text in 5.7.6 (getObjectExtent description) with the
following: "Other than text attributes and text-related Style Properties, the
calculation is not affected by CGM Primitive Attribute (such as line width) or
Control elements, nor by APS Attributes or non-text Style Properties..." [Also
fix the link fragments in that section of text, which are all missing (empty,
"#").]

I find the draft underspecified about compressed CGM files. More
specifically, we would like to know what kind of CGM files may be
compressed?

Version 1 to 4? Can I compress a WebCGM 1.0 CGM file for example?

Is this a WebCGM 2.1 conformance feature for viewer and authoring tools? Or
is this a new WebCGM 2.1 (and only 2.1) 'encoding scheme' ... for lack of a
better word?

Thanks.

Benoit.

----------------------------------------

WebCGM WG Response:
Resolution:

remove the gzip requirement from T.13.1 in Chapter 6, by changing "Other:
the whole metafile may be GZIP compressed. WebCGM interpreters must support
GZIP-compressed metafiles." to "Other: none".

Add to the end of Section 7.1: "WebCGM 2.1 viewers, both static and
dynamic, shall correctly handle valid WebCGM 2.1 Binary-encoded metafiles
that are gzip-compressed. WebCGM 2.1 viewers that claim to correctly handle
valid WebCGM metafiles of an earlier WebCGM version (1.0 or 2.0) according
to the conformance rules of that earlier version, shall correctly handle
such metafiles when they are gzip compressed."

Comment:
"The list syntax and normalization are derived from the specifications of CSS
2.0 [CSS20]. In particular, the values and syntax of the substitutionList
attribute are derived from CSS's definition of the font-family property "

It is unclear where these rules are in CSS2, ie. whether there are more than
in the font-family section, given the use of the phrase 'in particular'. If so,
we couldn't find where.

----------------------------------------

WebCGM WG Response:
Resolution:

Clarify text by changing:
"The list syntax and normalization are derived from the specifications of CSS
2.0 [@@CSS20@@]. In particular, the values and syntax of the substitutionList
attribute are derived from CSS's definition of the @@font-family@@
property:"
to:
"The values and syntax of the substitutionList attribute, as well as the
normalization of that attribute, are derived from the definition of the
@@font-family@@ property in CSS2 2.0 [@@CSS20@@]:"

Why is the normalization for cgmFont different from that for
substitutionList?

----------------------------------------

WebCGM WG Response:
Resolution:

This was a deliberate choice. The 'cgmFont' normalization defines, before
the string-match comparison is performed, how to prepare both the font name
extracted from WebCGM instance and the parameter value of the 'cgmFont'
attribute. The rule is based on extensive real-world usage of CGM and WebCGM,
both current usage and legacy usage. The WebCGM specification itself (T.16.13
of section
6.5 [1]) has since 1999 required a core set of fonts, or their metric
equivalents, with names such as "Helvetica-BoldOblique". But the specifications
allowed no trivial variations (e.g., blanks, underscore-for-hyphen, etc), other
than "case insensitive". In reality, there is now a large legacy of files that
conform to profiles closely related to WebCGM (e.g., ATA) but that have trivial
difference in these names, or that are WebCGM instances with trivially
erroneous variations on the names. The purpose of the 'cgmFont' normalization
is to enable the application of the font substitution mechanism to this
substantial legacy of CGM instances.

On the other hand, the 'substitutionList' attribute of the WebCGM
specification defines the set of fonts from which a substitute is to be
selected. This font substitution mechanism is a new feature of WebCGM, and so
there is no legacy to consider for 'substitutionList'. The best design of
syntax and mechanism, and one that is already used by some WebCGM constituents
in other contexts, comes from the CSS 2.0 specification. This was therefore
closely adapted to the needs of WebCGM 2.1's font substitution mechanism.

For cgmFont normalization, do you mean "stripping out all whitespace" or
normalizing white-space to a single space, as per substitutionList?

----------------------------------------

WebCGM WG Response:
Resolution:

The intent is indeed "stripping out all whitespace". This enables identical
normalization results, for example, for a font name that used whitespace
instead of camel case on the one hand, and on the other hand a font name that
used only camel case (with no whitespace), or one that used hyphen or
underscore in place of whitespace. These are legacy situations that arise in
WebCGM practice. Please see the response to I18N WebCGM Comment #3 for more
detail.

"These normalization rules are applicable for font names specified using the
characters of ISOLatin1. They will likely be inapplicable for font names
specified using other non-Latin characters."

What happens in the case of Latin-2 (Eastern Europe), which is similar to
Latin1 but contains a few additional characters. Does a single non-Latin1
character cause normalization to be abandoned for the whole string?

It seems like the only thing that wouldn't apply to all non-Latin1 font
names is converting to lower-case, though that is still a relevant
consideration for many other Latin characters outside Latin1, and for Armenian,
Greek and Cyrillic. Why restrict to Latin1?

----------------------------------------

WebCGM WG Response:
Proposed resolution:

The apparent restriction to Latin 1 was unintended. As you point out, the
normalization would work the same if the same names were expressed in Latin 2.
Latin 1 got the special mention because: 1.) the default character encoding of
WebCGM is ISO 8859-1; and, 2.) the vast majority of current and legacy WebCGM
instances use this character encoding and a restricted core set of thirteen
specific font names. As pointed out in WebCGM's reply to I18N's issue #3, these
WebCGM-specific normalization rules were targeted at the substantial volume of
legacy and current metafiles that intend to invoke this restricted core set of
fonts, but that contain well-known, trivial deviations in the construction of
the names. In other words, the real target is trivially deviant usage of the 13
specific core-font names, regardless of the character encoding. (More
background: the valid character encoding for any particular WebCGM instance is
one of the three ISO 8859-1, unicode UTF-8, or unicode UTF-16.)

WebCGM will reword to clarify the useful scope of these normalization rules,
to remove the implication of a normative restriction of applicability, and
instead to be advisory about the usefulness of that normalization outside of
its primary intended scope. Replace the two quoted sentences in question (in
the 9.3.2.2 description of 'cgmFont') with:

"Note: These normalization rules are derived from and intended for the
substantial volume of existing metafiles that aim to invoke fonts from WebCGM's
restricted core set of thirteen specific fonts (see T.16.13 of @@section 6.5@@)
and that contain well-known and trivial deviations in the construction of those
font names. The rules may be less useful outside of that intended scope. The
target metafiles of these normalizations are most often, but not always,
encoded in WebCGM's default character encoding of ISO 8859-1."

Comment:
Normalization for string comparison should include conversion to a Unicode
normalization form, to eliminate issues related to precomposed vs. decomposed
characters and issues related to ordering of multiple combining characters.

----------------------------------------

WebCGM WG Response:
Proposed resolution:

WebCGM agrees that this is the consistent and reliable way to perform such
comparisons. Text to this effect will be added to the description of the
'cgmFont' value -- conversion to unicode normalization form should precede the
comparison and follow the other WebCGM-specific normalization.

In 9.3.2, add a new sentence to the end of the description of 'cgmFont':
"After this WebCGM-specific normalization, correct and consistent results when
comparing metafile font names with the 'cgmFont' value — for font names
outside of WebCGM's restricted core set of thirteen specific fonts (see T.16.13
of @@section 6.5@@) — may require that WebCGM processors convert to a
@@unicode normalization form@@ before performing the string comparison." Also
add to WebCGM Chapter 1 the references for both the Unicode Standard Annex #15
[1] and the W3C Character Model, Part 2 (Normalization) [2].

Incorporating all proposed changes, the paragraph of 'cgmFont' description
becomes:

"The name of the font in the metafile for which font substitution is
requested. Before attempting to match a font used in the metafile to the value
(string) of cgmFont, both font names are normalized by a WebCGM-specific
normalization: convert to lower-case; and strip out all whitespace, UNDERSCORE,
and HYPHEN characters. Note: These normalization rules are derived from and
intended for the substantial volume of existing metafiles that aim to invoke
fonts from WebCGM's restricted core set of thirteen specific fonts (see T.16.13
of @@section 6.5@@) and that contain well-known and trivial deviations in the
construction of those font names. The rules may be less useful outside of that
intended scope. The target metafiles of these normalizations are most often,
but not always, encoded in WebCGM's default character encoding of ISO 8859-1.
After this WebCGM-specific normalization, correct and consistent results when
comparing metafile font names to the 'cgmFont' value — for font names outside
of WebCGM's restricted core set of thirteen specific fonts — may require that
WebCGM processors convert to a @@unicode normalization form@@ before performing
the comparison."

In the text description of getObjectExtent (section 5.7.6), change
"abstract locus" to "locus", and link "locus" to a new Glossary definition
in Appendix C.

Add this definition to the Glossary (Appendix C):locus --

A general definition from the Oxford dictionary defines 'locus' as:
"Curve formed by all points satisfying particular equation of relation
between coordinates, or by point, line, or surface, moving according to
mathematically defined conditions." In the WebCGM specification, locus
refers to the set of points that comprise the path or shape of a
Graphical Primitive element, or in the appropriate context, the combined
shapes or paths collectively of all of the Graphical Primitive elements
in an Application Structure (APS). I.e., the locus of an APS comprises
the combined loci of all of the graphical primitives in the APS. Locus
does not include defining data that are not part of the shape or path of
the graphical primitive, such as control points of Bezier primitives, or
the center point of a Circular Arc Center primitive.

(Ed note. The WG closes the present issue with this resolution, anticipating
that further detailed questions of clarification will arise as implementations
progress.)

WebCGM WG Response:Resolution:

Add wording to setView() description: "The viewer shall fit the NVDC
rectangle specified by the 'viewRect' parameter into the viewer’s display
rectangle and center it, while maintaining the aspect ratio of the 'viewRect'
rectangle."

WebCGM WG Response:
Resolution:

In the IDL, change the setView return type from 'void' to 'boolean'; in the
setView() description, change the return value from "No return value." to "
boolean: TRUE if new view was set; FALSE if rectangle was invalid and the view
could not be set." In the ECMAScript in Chapter 8: change "setView(view)" to
"setView(viewRect); change the associated "This method has no return value" to
"This method returns a Boolean".

I want to spot some improvement that I wanted to be incorporated in this
version

1 == moving forward with XML Schema or Relax NG ==

Sticking to DTD to define a XML dialect is neither sufficient neither a way
to widespread the use of this XML dialect. For that, I ask the WG to consider
providing normative XML Schema and/or Relax NG schema of the XCF model. It will
help adoption especially because XCF uses Namespaces.

2 == interaction between WebCGM and CSS ==

Is it possible to consider the role that could play CSS vis à vis WebCGM
?

Regards,

Mohamed ZERGAOUI

----------------------------------------

WebCGM WG Response:
Resolution:

Thank you for your comments during the WebCGM 2nd Last Call Working Draft
(LCWD) review.

1- First comment : == moving forward with XML Schema or Relax NG ==

The WebCGM Working Group (WG) agrees that WebCGM could potentially benefit
by addition of a normative schema -- XML Schema or Relax NG. Unfortunately,
this proposal is beyond the scope of this 2nd LCWD review, and it is deemed to
be too late in the WebCGM 2.1 development cycle. Ideally, such a proposal would
have been included in the WebCGM 2.1 Requirements, or before 1st LCWD review at
latest. The implementation of such a proposal would involve major disruption of
the WebCGM 2.1 text -- removal of the DTD and complete rewriting of Chapter 4
(at least). Since it does not address an error in the specification, or a
serious defect, or violation of any W3C requirement, the WG believes that the
proposal should be postponed until a future WebCGM development cycle.

As an interim step, the WG thinks that a non-normative Technical Note,
separate from the progression of 2.1 WebCGM, might be an interesting approach.
The WG would also welcome an initial contribution, if you have interest in
making such.

2- Second comment : == interaction between WebCGM and CSS ==

Potential relationships between WebCGM and CSS were studied in some detail
[1] prior to the WebCGM 2.0 standardization. This study [1] developed a
detailed model and showed the technical feasibility for a rich application of
CSS-like styling to WebCGM.
[1] http://www.cgmopen.org/technical/stylable_cgm_submitted_0324.pdf

Despite the technical feasibility, the WebCGM 2.0 authors and constituents
agreed that the the principal WebCGM use cases did not justify the cost and
implementation effort of such a full-featured normative CSS capability in
WebCGM. Therefore normative CSS-like style sheets were not further pursued.

Nevertheless, whenever possible, applicable features and characteristics of
CSS were followed in the design of WebCGM 2.0, especially the new DOM-based
Style Properties feature. For example the inheritance model of CSS was adapted
directly into the Style Properties inheritance model (section 5.4), and there
are a number of other examples of functionality borrowed more-or-less directly
from CSS.