- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 29 Aug 2019 16:36:00 +0000
- To: Timed Text Working Group <public-tt@w3.org>
- Message-ID: <D98DBD39.4C76E%nigel.megitt@bbc.co.uk>
Thanks all for attending today’s TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2019/08/29-tt-minutes.html.
In text format:
[1]W3C
[1] http://www.w3.org/
Timed Text Working Group Teleconference
29 Aug 2019
[2]Agenda
[2] https://github.com/w3c/ttwg/issues/57
See also: [3]IRC log
[3] https://www.w3.org/2019/08/29-tt-irc
Attendees
Present
Cyril, Nigel, Gary, Glenn, Andreas, Pierre, atsushi
Regrets
Chair
Nigel
Scribe
Cyril, nigel
Contents
* [4]Topics
1. [5]this meeting
2. [6]support for font in IMSC
3. [7]TTML2 issues
4. [8]Add #direction-version-2 feature designator.
w3c/ttml2#1024
5. [9]Constrain maximum value of @length on data element.
ttml2#1023
6. [10]TPAC
7. [11]360 subtitles
8. [12]TTML2 issue 950
9. [13]Constrain ttp:profile's @use attribute (#1029).
ttml2#1137
10. [14]Fonts
11. [15]meeting close
* [16]Summary of Action Items
* [17]Summary of Resolutions
__________________________________________________________
this meeting
<atsushi> (will join after i18n WG call ends, sorry)
<cyril> scribe: Cyril
nigel: today I did not put any Webvtt topic
... do you need anything?
gkatsev: no
nigel: I pulled out 1 dusty IMSC issue
... I don't know if we can get anything on the charter
... TPAC planning, we should spend at least 10min at the end
because it's coming up quickly
... is there any AOB?
atai2: I would like to give an update on the 360 activity
glenn: I added an agenda label on some TTML2 issues
... issue 950 and PR 1137
support for font in IMSC
<nigel> github: [18]https://github.com/w3c/imsc/pull/485
[18] https://github.com/w3c/imsc/pull/485
nigel: this PR was opened 22 days ago
... there was some comment on it
... there was a comment about choosing the compatibility with
font
... the reference to 14496-22
pal: the reason I referenced 14496-22
... is because in an IMF forum this the reference that has been
suggested
... this is a reference to Open Type
... that's the first that came to mind
... because that's what's used in existing applications of IMSC
... when downloadable fonts are used
glenn: I don't like refering to a content type format
specification directly
... we should be referring to MIME media type values
... and refer to the definitions, like font/off
... I would like to see it changed
... rather than referring to the ISO specification
pal: I'm comfortable with that
... I want to use font/otf
glenn: fine for me
nigel: Open Type fonts can be wrapped into WOFF
... is it the intention that WOFF or WOFF2 are not permitted?
pal: on practical experience, font/otf will work
... people have been using it
... so mandating support for it is not an issue
... there are some politics/drama about WOFF
... I don't know what it means exactly
<nigel> [19]CSS font-face src descriptor
[19] https://drafts.csswg.org/css-fonts-3/#src-desc
pal: but I'm uncomfortable with adding WOFF
glenn: WOFF can take multiple types of fonts than OTF
... you would have to restrict WOFF
... I think I agree with Pierre on this
nigel: the font-face src property lists many types of possible
font faces
... CSS would allow other options that are being prevented here
... including SVG fonts
... which is interesting for the use case that we are trying to
support (icons)
cyril: I'm not sure there is widespread support for SVG fonts
glenn: agree with Cyril
... unless there is a strong support for a given font format it
is fine to limit it to OTF for now
... we can add more later
pal: until there is concrete explanation of why WOFF is
necessary, I suggest sticking with OTF for now
nigel: so the proposal is to adopt initially only OTF
... do we have consensus?
cyril: I agree
nigel: no objection
RESOLUTION: IMSC font support will initially only support OTF
cyril: I would like to make sure that we have the right
restrictions on the different elements and attributes
nigel: there are similar comments in the issue
... about how the font element sources are defined and there
seems to be a bit of ambiguity
... is it ok to have no sources for the font element or more
than one
... my reading was that you needed 1 and may have more than one
... glenn suggested to have an src attribute
pal: the reason I went the children way was to enable
alternatives
... it wasn't clear to me that you could use multiple font
elements
glenn: you cannot have multiple font elements with the same
family name
pal: that's my guess but it was not clear in the spec
glenn: the font family attribute can be a list of font family
cyril: exactly
pal: you could have different font elements, each with an src
attribute, and call them font1, font2, font3 and use these
values in the fontstyle attribute
... I did consider that but thought it wasn't clear
... that's why I ended up where we are
nigel: I agree that the most elegant way to have alternative is
to use multiple source elements
... but having zero elements does not make sense
pal: I agree
... my proposal is to say that TTML2 requires one source
element to be present if the src attribute is not specified
<inserted> nigel: that works for me, thank you, and a note in
the IMSC spec pointing out that at least one is required would
help.
cyril: what is the use case for specifying alternatives?
pal: if one source is broken, you have a choice for another one
... or a backup online vs embedded in the multiplex
glenn: also switching between different types
cyril: I would hate to have 2 ways to do the same thing
nigel: it's not clear that the fall back algorithms are the
same for alternate sources vs alternate fontFamily
glenn: using the range attribute you may have multiple fonts
cyril: I'd like to keep it simple for the simple use case
pal: the basic use case is a font element 2 children, one for
the multiplex and one for the online version, no glyph subset,
etc.
cyril: not even sure that this is the basic use case for
Netflix, it could be even simpler
... I'm not saying the Netflix use case should be the only use
case
glenn: we don't have enough information about the use cases but
we need an initial proposal
nigel: the main question is do we allow a single source (with
src attribute) or multiple sources (children and no src)
... at the moment we don't support multiple formats
... but supporting multiple source elements seems future
looking
pal: I did not want to have support for src attribute and
source elements
cyril: what about data?
pal: the term external resource excludes using data
glenn: external means not in the document
pal: right, so no data
cyril: I'm confused with "Partially supported via
<code>#embedded-data</code>"
nigel: I made a similar comment in the thread
... and made some suggestion
TTML2 issues
Add #direction-version-2 feature designator. w3c/ttml2#1024
<nigel> github: [20]https://github.com/w3c/ttml2/issues/1024
[20] https://github.com/w3c/ttml2/issues/1024
nigel: this PR covers special inheritance semantics
... adding direction to p is not a change as this was in TTML1
... Pierre do you think the new feature designator is not
needed
pal: I don't think we need a new designator, because it was
clear in XSL before
... to the extent that you have to look at XSL, and it is
unambiguous
cyril: are you saying this behavior applies to TTML1 already?
pal: I think so and I think IMSC.js supports that
<nigel> [21]XSL definition
[21] https://www.w3.org/TR/2006/REC-xsl11-20061205/#direction
nigel: I can see your point Pierre
... you might argue that TTML2 might benefit from a note about
that
... the XSL specification says it is a modification compared to
the CSS specification
glenn: in TTML1, it says that it is based on XSL 1.1
pal: IMSC.js code mentions XSL
... so this was already specified in TTML1
<nigel> [22]CSS 3 Writing Modes section on Principal Writing
Mode.
[22] https://www.w3.org/TR/css-writing-modes-3/#principal-flow
glenn: so it would be useful to add a note, saying it's not new
and closing this issue
<nigel> +1
nigel: I agree
Constrain maximum value of @length on data element. ttml2#1023
<nigel> github: [23]https://github.com/w3c/ttml2/issues/1023
[23] https://github.com/w3c/ttml2/issues/1023
glenn: the only place where it might be useful to have a
constraint is when you have base64 data
... you could have an infinitely long document
... so I was proposing to limit that to 4GB
cyril: Isn't this an application-level constraint
nigel: yes
glenn: application can do that so probably no need to put a
constraint in the spec
... there is a difference in code
... if you are writing a validator, you cannot use a 32 bit
integer for the size
nigel: I propose to close the issue with no change
... any objection
RESOLUTION: we close issue 1023 with no change
TPAC
nigel: there is a proposed time at 9:30 am to have a joint
meeting with CSS
... I've requested a meeting with the Chinese IG
... but had no response yet
<atsushi> +1
nigel: if you have an issue with that 9:30 time, send me a
message otherwise I'll reply that we agree
... the wiki page has had some updates with topics
... we need to look at the schedule
... the week before TPAC I'll be travelling
... so next week is the last time when we could discuss this
cyril: should we have a 2h meeting next week
nigel: yes
pal: I'll be available only for 2nd hour
nigel: anything else on TPAC?
pal: I've changed my schedule and will be attending the IG from
Monday
360 subtitles
atai2: I've drafted an explainer for this activity with
requirements
... sent it to the incubator
... will be discussed on monday at TPAC
nigel: if this is not on the wiki page of TPAC, please add it
TTML2 issue 950
glenn: my only point is that I added one more comment
<nigel> github: [24]https://github.com/w3c/ttml2/issues/950
[24] https://github.com/w3c/ttml2/issues/950
glenn: we cannot remove the set element, my explanation is
there
... I verified that the algorithm needs it
Constrain ttp:profile's @use attribute (#1029). ttml2#1137
<nigel> github: [25]https://github.com/w3c/ttml2/pull/1137
[25] https://github.com/w3c/ttml2/pull/1137
glenn: the PR has been opened for 27 days, I need a review
Fonts
pal: I ran into a problem in practice and wanted to know if
people had it
... in Digital Cinema subs, you can do manual kerning at the
markup level, specifying positive/negative spacing
glenn: letter spacing can be used for that, including negative
pal: is there a reason to do that in the markup vs in the font?
... I've seen fonts with no embedded kerning at all
glenn: many CJK fonts have fixed width for all glyphs and no
kerning
... it's not unusual
... if it's an open type font you can use a gpos table
... to fine tune the position based on context
... it can be done in the fonts
... TTPE supports gpos and gsub
pal: that's my understanding
... is there any reason why someone would not want to do it at
the font level?
glenn: lack of access to changing the font, IPR reasons for
example
pal: the font that I saw was a subset so the font had been
modified, so the IPR argument does not hold
nigel: glenn said you can put a single character in a span and
apply letter spacing, where would the spacing apply: before or
after?
glenn: you'd have to put it around a pair of characters
... with some limitation that you cannot overlap the markup
meeting close
<nigel> scribe: nigel
Nigel: Thanks everyone, we're over time, so I'll adjourn now.
Thank you Cyril for scribing. 2 hour meeting next week so we'll
begin an hour earlier. [adjourns meeting]
Summary of Action Items
Summary of Resolutions
1. [26]IMSC font support will initially only support OTF
2. [27]we close issue 1023 with no change
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [28]scribe.perl version 1.154 ([29]CVS log)
$Date: 2019/08/29 16:32:40 $
[28] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[29] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 29 August 2019 16:36:26 UTC