See also: IRC log
<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
<nigel> github: 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> CSS font-face src descriptor
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
<nigel> github: 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> XSL definition
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> CSS 3 Writing Modes section on Principal Writing Mode.
glenn: so it would be useful to add a note, saying it's not new and closing this issue
<nigel> +1
nigel: I agree
<nigel> github: 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
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
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
glenn: my only point is that I added one more comment
<nigel> github: 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
<nigel> github: https://github.com/w3c/ttml2/pull/1137
glenn: the PR has been opened for 27 days, I need a review
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
<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]