[mpeg-OTspec] AHG Kick-off and new draft to review

[Sairus Patel]

Hello Chris, Cameron, Vlad,

<<
"It is not a requirement that an OFF engine support this table."

Since this is true for any table not marked as mandatory, this
sentence is redundant and should be removed.

(I'm aware the original submission is the origin of this phrase.
Still, it should be removed).
>>

Agreed. The phrase probably came from some initial proposal that emphasized that existing engines won’t suddenly be made non-conformant.

<<
5.7 Optional tables

Add SVG table
>>

I was looking at the organization of sec 5 in OFF and it looks like it’s broken down like this:
5.2. Required common tables (cmap, OS/2, etc)
5.3. TT-related tables
5.4. CFF-related tables (both required and optional, e.g. CFF and VORG)
5.5. SVG table (optional)
5.6. Bitmap tables (optional, including the new color ones)
5.7. Optional tables (including gasp, which is a TT-only table, and should perhaps be in 5.3? Also including COLR and CPAL)

It seems like 5.5., 5.6, and 5.7 are all optional tables, and that at least one other optional table, VORG, is in the CFF section, but gasp, which is TT-only, is not in the TT secetion.
I’m not sure how OFF should organize all this, but I agree mandatory/optional should be an attribute clearly visible when scanning the table of contents. It seems useful that CFF-only and TT-only tables are clearly grouped together or indicated as such in some other way.

<<
"With SVG, the CPAL table is optional, and contains the values of any
color variables used by the SVG glyph descriptions in the SVG table.
The SVG glyph descriptions are able to express their own explicit or
“hard-coded” colors as well; these do not vary by palette selection."
and then
"When used with an SVG table, the default palette’s colors must be set
to the same values as the default values for the color variables in
the SVG glyph descriptions; this is for text engines that support the
SVG table but not color palettes."

The second quoted section suggests that when using a non-default
palette, the hard-coded colors will be overidden (which is desirable);
the first quoted section seems to indicate that they will not. This
conflict should be clarified.

My suggested wording to resolve this:

"... explicit or “hard-coded” colors as well; these colors will be
used if there is no CPAL table in the font.”
>>

The explicit or “hard-coded” colors in the quote from the spec refers to colors not related to color variables at all. They are simply colors that are always to be used when rendering the SVG, regardless of color palette selection or color palette support of the engine. For example, a font designer may want the teardrop on a crying emoji always to be blue (this is “hard-coded”) but the rest of the emoji is regulated by color variables, with the skin of the face having a default value of the standard smiley-face yellow (default both in the SVG glyph description itself and in the default color palette).

The spec draft example shows:
<path fill="var(--color0)" d="...”/>
But doesn’t show how to code a default value if --color0 isn’t defined in the stylesheet. I thought we had it there in some previous draft. Cameron: does this ring a bell?

Best,
Sairus

From: <'Levantovsky>, "Vladimir' vladimir.levantovsky at monotype.com<mailto:vladimir.levantovsky at monotype.com> [mpeg-OTspec]" <mpeg-OTspec-noreply at yahoogroups.com<mailto:mpeg-OTspec-noreply at yahoogroups.com>>
Organization: W3C
Reply-To: Chris Lilley <chris at w3.org<mailto:chris at w3.org>>
Date: Wednesday, November 5, 2014 at 6:23 AM
To: "'Levantovsky, Vladimir' vladimir.levantovsky at monotype.com<mailto:vladimir.levantovsky at monotype.com> [mpeg-OTspec]" <mpeg-OTspec-noreply at yahoogroups.com<mailto:mpeg-OTspec-noreply at yahoogroups.com>>
Cc: "mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com>" <mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com>>, Vladimir Levantovsky <Vladimir.Levantovsky at monotype.com<mailto:Vladimir.Levantovsky at monotype.com>>
Subject: Re: [mpeg-OTspec] AHG Kick-off and new draft to review



Hello Vladimir',

Tuesday, November 4, 2014, 6:41:46 PM, you wrote:

>
> [Attachment(s) from Levantovsky, Vladimir included below]

>
>
> Dear AHG members,

> This is a red-line revision of the original document with all
> changes tracked – please review and provide any additional comments.
> Just to remind you – the original DIS document is still under open
> ballot and the comments should be submitted no later than early
> December 2014 – we still have about a month of time to discuss and
> suggest additional clarifications and text corrections.

2. Normative references
"Unicode 6.1, <http://www.unicode.org/versions/Unicode6.1.0/>"

As Unicode 7.0.0 was published on October 8, 2014 this should be updated
to Unicode 7.0.0 <http://www.unicode.org/versions/Unicode7.0.0/>

"Scalable Vector Graphics (SVG) 1.1 (2nd edition), W3C Recommendation,
16 August 2011"
please append the URL
<http://www.w3.org/TR/SVG11/>

5.5 Table for SVG glyph outlines
"It is not a requirement that an OFF engine support this table."

Since this is true for any table not marked as mandatory, this
sentence is redundant and should be removed.

(I'm aware the original submission is the origin of this phrase.
Still, it should be removed).

5.5.1 SVG – The SVG (Scalable Vector Graphics) table
"This table contains SVG [16] descriptions"

The references in section 2 are not numbered, so the [16] should be
removed. The normative references section has an entry for SVG.

5.5.2 Color Palettes
"CSS custom properties [18] in a User Agent style sheet"
and
"CSS Custom Properties for Cascading Variables specification [18], as
this is required "

The references in section 2 are not numbered, so the [18] should be
removed. There is no entry under Normative references for CSS custom
properties. As this is not yet a W3C Recommendation I would suggest,
if ISO rules allow, adding the following to a new 2.1 Informative
references section.

CSS Custom Properties for Cascading Variables Module Level 1, W3C
Working Draft, 6 May 2014
<http://www.w3.org/TR/css-variables-1/>

5.5.5 Glyph Rendering
"as described in the latest version of the SVG Integration
specification [17]. "

The references in section 2 are not numbered, so the [17] should be
removed. In the Informative references section, please add

SVG Integration, W3C Working Draft, 17 April 2014
<http://www.w3.org/TR/svg-integration/>

"at least version 1.1 of the SVG specification [16]. "

The references in section 2 are not numbered, so the [16] should be
removed.

"according to the definitions found in SVG 2 [19], as these
definitions"

The references in section 2 are not numbered, so the [19] should be
removed. In the Informative references section, please add

Scalable Vector Graphics 2 (SVG2), W3C Working Draft, 11 February
2014. <http://www.w3.org/TR/SVG2/>

"requirements in the latest version of the SVG Integration
specification for "font documents" be followed. [17]"

remove the [17]

5.7 Optional tables

Add SVG table

5.7.11 CPAL – Palette Table
"The color space for these values is sRGB."

Please add to Normative References

IEC 61966-2-1/Amd 1:2003 : Multimedia systems and equipment — Colour
measurement and management — Part 2-1: Colour management — Default RGB
colour space — sRGB, International Electrotechnical Commission, 2003.

"With SVG, the CPAL table is optional, and contains the values of any
color variables used by the SVG glyph descriptions in the SVG table.
The SVG glyph descriptions are able to express their own explicit or
“hard-coded” colors as well; these do not vary by palette selection."
and then
"When used with an SVG table, the default palette’s colors must be set
to the same values as the default values for the color variables in
the SVG glyph descriptions; this is for text engines that support the
SVG table but not color palettes."

The second quoted section suggests that when using a non-default
palette, the hard-coded colors will be overidden (which is desirable);
the first quoted section seems to indicate that they will not. This
conflict should be clarified.

My suggested wording to resolve this:

"... explicit or “hard-coded” colors as well; these colors will be
used if there is no CPAL table in the font."

(I have only reviewed the references, SVG, and CPAL sections).

--
Best regards,
Chris Lilley, Technical Director, W3C Interaction Domain



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20141105/19aa9279/attachment.html>