13:59:33 RRSAgent has joined #tt 13:59:33 logging to https://www.w3.org/2018/07/12-tt-irc 13:59:35 RRSAgent, make logs public 13:59:35 Zakim has joined #tt 13:59:37 Meeting: Timed Text Working Group Teleconference 13:59:38 Date: 12 July 2018 14:00:04 Log: https://www.w3.org/2018/07/12-tt-irc 14:00:19 scribe: nigel 14:00:30 Present: Andreas, Nigel 14:00:36 Regrets: Cyril, Glenn 14:00:39 Chair: Nigel 14:02:36 glenn has joined #tt 14:04:12 cyril has joined #tt 14:04:21 i'm just now trying to join, but I'm connecting from an iffy wifi from the French West Indies 14:05:50 Present+ Cyril 14:05:53 Regrets- Cyril 14:06:06 Topic: This meeting 14:06:19 Andreas: If there's time I'd like to discuss switching this meeting to be based on UTC time 14:06:21 Nigel: OK 14:07:33 atai2 has joined #tt 14:08:38 Present+ Glenn 14:08:41 Regrets- Glenn 14:09:02 Nigel: I think we have limited W3 staff availability so probably that means regrets from Thierry. 14:09:29 .. For the agenda today, we have the usual TTML1, TTML2, IMSC 1.1. 14:09:41 .. Any particular points that anyone wants us to make sure we cover, or other business? 14:09:56 .. (noting Andreas already raised another business agenda item) 14:10:08 group: [silence] 14:10:30 Nigel: Okay, we'll handle the Other Business at the end. 14:10:42 Topic: TTML1 14:10:47 action-513? 14:10:48 action-513 -- Pierre-Anthony Lemieux to Look at ttml2 backporting to ttml1 3rd ed to see if we can change the ref from ttml2 to point to 3rd ed. -- due 2018-07-05 -- OPEN 14:10:48 https://www.w3.org/AudioVideo/TT/tracker/actions/513 14:11:41 Nigel: Just a quick update that earlier today I managed to ask Philippe about if it would 14:12:31 .. be possible to make an update to TTML1 3rd Edition CR that incorporates text 14:12:56 .. already subject to an exclusion request from TTML2 without causing the TTML1 14:13:07 .. 3rd Edition Rec date to be pushed out beyond TTML2 Rec. 14:14:19 Pierre: All the outstanding backport changes are in pull requests on TTML1 3rd Ed. 14:14:22 .. I couldn't find any others. 14:14:26 Nigel: Okay, thank you. 14:15:00 Action-513: Pierre reports All the outstanding backport changes are in pull requests on TTML1 3rd Ed. 14:15:00 Notes added to Action-513 Look at ttml2 backporting to ttml1 3rd ed to see if we can change the ref from ttml2 to point to 3rd ed.. 14:15:41 Cyril: Q: Why are we considering the change to TTML1 3rd ed ref to be substantive? 14:15:53 Nigel: We're not - the concern is that the TTML2 Rec publication could be delayed if we 14:16:01 .. have to wait for TTML1 3rd Ed to be at Rec. 14:16:20 .. I'm hoping for a response early next week. 14:16:36 Cyril: What are the options? 14:16:50 Nigel: In an ideal world we would be able to publish both TTML1 3rd Ed and TTML2 Rec at the same time. 14:16:54 Cyril: That'd be great. 14:17:13 Glenn: The question is when - at the same time as TTML2 Rec is currently on track for publication, or with some delay? 14:17:17 Nigel: Exactly. 14:17:29 Glenn: As a reminder, due to a question I had fielded, TTML2 now normatively references 14:17:47 .. TTML1 because we reference it in 117 places normatively, 3 places for DFXP profiles 14:17:59 .. and 114 places where we refer to TTML1 feature definitions. 14:18:10 Cyril: We're doing that for convenience, right, not because we need to. 14:18:24 Glenn: The problem is it was hard to define the feature designators in TTML1 without 14:18:36 .. incorporating the whole text of TTML1 so we had to resort to referring to them directly. 14:18:48 .. We don't copy the DFXP profiles into TTML2, but refer to the normative definition in TTML1. 14:18:58 close action-513 14:18:58 Closed action-513. 14:20:00 Nigel: Looking at TTML1 pull requests, there's one for lineHeight="normal" text and 14:20:11 .. I see that Andreas a concern. 14:20:24 Andreas: Yes, I've been away for a while and have now reviewed it. 14:20:35 .. I have a concern that the algorithm can not always be followed. 14:20:46 .. The algorithm might not have access to the font properties of a font file, which would 14:21:00 .. be needed. And secondly if the text is kept as is then some terms need to be clearer. 14:21:13 .. It is not unambiguous how altitude and descent are used. 14:21:31 Glenn: Text altitude and text descent are defined properties and traits in XSL-FO and 14:21:48 .. are referred to in CSS 2.1 under the behaviour for line-height so I don't think there's 14:21:51 .. any problem there. 14:22:05 .. Re font metrics, the language is based on the availability of access to those, and if they 14:22:14 .. are not available then the 125% applies, so that's also okay. 14:22:27 .. The only place where I contemplate it might not be available is with bitmap fonts which 14:22:34 .. might be restricted in what metrics are available. 14:22:48 Andreas: I recently discussed with CSS people why some calculations are not available 14:22:59 .. in the browser or developer console especially the font that is used for rendering. 14:23:09 .. They explained that it is not available to the browser stack because it is handled by 14:23:19 .. a lower level in the OS so I am not really sure that it is available. 14:23:36 .. With altitude and descent I am not happy with that. Normally ascender and descender 14:23:47 .. are used and even in XSL-FO it is not always clear what it is because in OpenType 14:24:08 .. for example there are different general properties for ascender and descender so it 14:24:22 .. is not clear which is meant. The text used here is not in XSL-FO or CSS so it is not a 14:24:28 .. reference to those specs at all. 14:24:44 Glenn: I would invite you to re-read CSS 2.2 §10.8. I don't think there's any real ambiguity. 14:24:56 .. Regarding referencing a specific font format we don't want to do that because it ties 14:25:00 .. too much to implementation specifics. 14:25:15 .. Whoever you talked to maybe didn't understand the specifics - all of the browsers do 14:25:30 .. in fact have access to low level font information. I've reviewed the code in Chrome and 14:25:35 .. Firefox and they are using them directly. 14:25:49 Andreas: Ok I don't think we will come to a conclusion here but we need someone more 14:26:04 .. familiar with browser development. The other thing is we have introduced new text, 14:26:32 .. in general the text is okay but it introduces some more complexity. Possibly it would 14:26:42 .. have been easier to just take what is in CSS than to introduce a new algorithm. 14:26:55 Glenn: One important thing is the way we crafted the language in that algorithm, in step 14:27:19 .. 5 or 6, it says "unless there is an implementation requirement ..." use 125% as a fallback 14:27:33 .. so that leaves the implementation free to decide what it wants to use, and can apply 14:27:46 .. its own rules. So there's no technical problem with the algorithm that prevents an 14:27:51 .. implementation from doing what it wants. 14:28:12 .. The CSS folks have said at least half of what is written in CSS is wrong and they have not 14:28:19 .. decided which half is wrong. 14:28:24 Andreas: Okay that does not help! 14:28:42 .. I do not want to block publication. A minor tweak is to make the algorithm or 125% 14:28:53 .. equivalent. At the moment the preference is to use the algorithm. It only gives 14:29:07 .. a fallback option if the font details are not available. It could be made clearer at the 14:29:12 .. beginning that either option can be chosen. 14:29:24 .. You can also add the constraint that in case there is no implementation specific 14:29:37 .. requirement to do otherwise then you could use the algorithm or 125%. 14:29:54 Glenn: I'm looking now, and step 5 says if the font is associated with ... then lh is set 14:30:05 .. accordingly, otherwise step 6 says implementation dependent, but in the absence 14:30:18 .. of implementation specific requirements, use 125%. The way that language is specified, 14:30:34 .. font metrics are not required, and implementations can define their own behaviour or 14:30:48 .. use 125%. I don't see any problem with the algorithm in implementing it or its intention. 14:31:05 .. By the way Pierre and I carefully reviewed this and came up with it as a compromise 14:31:18 .. to deal with another issue so I am very reluctant to tweak it any further. 14:31:58 Pierre: I think all other things being equal, my preference would be to say it is implementation 14:32:09 .. dependent, period, but doing that will result in a pretty drastic change in TTML2 so 14:32:20 .. I'm not sure that is possible right now or desirable. There's a note that says the goal 14:32:32 .. is to be consistent with CSS. If we find it is not consistent then it would be easy to 14:32:42 .. motivate a change. I think this text is an improvement to TTML1 2nd Ed for sure. 14:32:56 Andreas: I agree with Pierre, to leave it completely implementation dependent would be 14:33:10 .. the easiest because other things confuse people more. If there is not a strong 14:33:25 .. opinion or support to change it then leave it as it is. I would definitely look up the 14:33:32 .. terms and possibly change those if necessary. 14:33:44 Pierre: If you want to capture what it should be as an issue then that could be addressed 14:33:48 .. in a future edition. 14:34:02 Andreas: At least in step 5 it is a minor change to tweak the terms. Is that still feasible 14:34:12 .. or is it too late? 14:34:16 Nigel: In TTML1 and TTML2? 14:34:20 Andreas: Both 14:34:23 Cyril: I think it is too late. 14:34:37 .. I don't think it is a problem because IMSC recommends setting a specific value. 14:35:02 Nigel: Pierre didn't you feed back that setting a specific value makes nobody happy? 14:35:14 Glenn: One minor editorial change I would make in TTML2 and TTML1 maybe: 14:35:32 .. we use "altitude (A)" and "descent (D)" - we should make it more consistent by using 14:35:53 .. "ascent" instead of "altitude" to make it more consistent. In TTML2 it has a note 14:35:57 .. about the ascent and descent. 14:36:11 .. Do you think I should make that editorial change? 14:36:17 Andreas: For me, I would welcome the change. 14:36:27 Glenn: Okay that sounds good to me, I can put an editorial issue in to fix that. 14:36:32 .. I'll take care of that. 14:36:47 Cyril: I was looking at the lineHeight constraints in IMSC, and it still says that implementation 14:37:05 .. of "normal" is not consistent so should not be used. The intent is there, reading it 14:37:15 .. now I think we should probably tweak that text also because we have the initial 14:37:27 .. element in IMSC 1.1, so we could set it using initial to a value other than "normal". 14:38:01 Glenn: It turns out that there's a challenge with respect to specifying a distinct line height 14:38:44 .. value as opposed to normal. It is inherited by the inline elements of a paragraph and 14:38:54 .. used to calculate the half leading of the inline elements, but if you use normal then 14:39:24 .. the value of normal is resolved on a per inline basis but if you specify an explicit value 14:39:36 .. on p then that exact value is applied to each inline and that can cause problems if 14:39:43 .. the font size of the inline is larger than that size. 14:39:59 Cyril: Sure, but the author should know that if they set a line height value explicitly then 14:40:10 .. it should deal with the inline childrens' heights. 14:40:24 Glenn: If you have an inline whose font size is twice the p font size and you specify a 14:40:44 .. line height that is smaller then you will end up with negative half leading, but in any 14:40:55 .. case the author is in control. I'm wondering if that recommendation could potentially 14:41:07 .. cause authorial problems but maybe we don't need to deal with that right now. I just 14:41:10 .. wanted to take note of it. 14:41:53 Cyril: I will raise an issue on IMSC 1.1 so we can fix it. 14:42:02 Pierre: There's an informative note on TTML2 with similar language. 14:42:08 Cyril: Related to initial? 14:42:17 Pierre: No but to setting an explicit value for lineHeight. 14:42:29 using explicit LH on P may result in negative half-leading on child SPANs, and thus cause inline glyph areas to overlap prior or subsequent line areas 14:42:32 Nigel: That discussion related to https://github.com/w3c/ttml1/pull/355 by the way 14:44:01 Topic: Update tts:lineHeight='normal' algorithm to match TTML2 ttml1#355 14:44:06 github: https://github.com/w3c/ttml1/pull/355 14:44:20 Nigel: See discussion above in the minutes from this meeting by the way. 14:44:32 Pierre: Nigel you raised the point about the note being removed. 14:44:47 Nigel: Yes, thank you for the reminder. This is about the note that helpfully explained that 14:45:09 .. using lineHeight="125%" and fontSize="0.8c" could be used to get lines that fit in 1c 14:45:10 .. height. 14:45:23 .. The current pull request removes that note, and I wanted to put it back. 14:46:04 Pierre: As we know the actual space between line boxes is not guaranteed to be the 14:46:16 .. specified value of lineHeight. My conclusion is that for folks that expect to be able 14:46:32 .. to reproduce the exact grid they were accustomed to in old systems that cannot be 14:46:39 .. done reliably. You can get close most of the time. 14:46:55 Glenn: You can construct scenarios where it can be made so, for example by making 14:47:08 .. none of the descendant elements specify a font size at all. To try to explain in a note 14:47:22 .. this very complicated subject I would prefer to leave the note out. I'm not inclined 14:47:36 .. to add it back in. 14:48:25 Andreas: My view is similar to what Pierre said - the value "normal" interpretation is 14:48:40 .. messed up. I think it is not really necessary to repeat the note, because if you go 14:48:50 .. from a grid based layout to TTML then there may be another specification like EBU-TT 14:49:00 .. that could point out the possible use of 125% for that reason. 14:49:21 .. I still think that it could be good advice for some transformation to recommend 14:49:33 .. transforming grid based layouts to TTML and back, although you cannot guarantee 14:49:42 .. the same presentation. It is still a valid recommendation but it does not have to be in 14:49:44 .. TTML. 14:50:04 Nigel: Okay, I'm not going stick this one out and have recorded that I feel we have lost 14:50:07 .. something helpful. 14:50:22 .. Let's conclude not to add the note back in now. 14:50:42 .. Moving on to the next point about resolved computed vs computed, Glenn you had a point: 14:50:54 Glenn: We can't remove the "resolved computed value" and go back to "computed value" 14:51:06 .. because the "computed value" is the inherited value and the special inheritance semantics 14:51:20 .. dictate that the computed value is inherited. We can only talk about the algorithm 14:51:34 .. to produce the actual lineHeight to take into account the input and the output value. 14:51:47 .. I used the phrase "resolved computed value" which seemed like the best option without 14:51:58 .. adopting "used value" as per CSS which is not used in XSL-FO. 14:52:11 .. As to adding the special inheritance section note, Pierre is correct that we should have 14:52:20 .. added it in to TTML2 but failed to do that. 14:52:35 Nigel: I read it a different way, namely that the text changes removed the need for that 14:52:41 .. special inheritance semantics section. 14:52:47 Glenn: You might be right in part. 14:52:52 .. It is not entirely clear. 14:53:07 .. CSS actually explicitly says it whereas XSL-FO marginally says it, in one place but not another. 14:53:25 .. It's indirect in §4.5 under line areas. It's not bad to have the explicit section on 14:53:39 .. special inheritance here. Since we could not add it normatively in TTML2 CR2 we had 14:53:43 .. to resort to a note. 14:54:37 Nigel: Okay, I had read it a different way and Pierre and Glenn think the special inheritance 14:54:50 .. section is useful. I don't think it is harmful just that we had cleverly avoided the need 14:54:54 .. for some unnecessary spec text. 14:55:16 .. I am happy to keep it. We should have an issue on TTML2 to add it back in. 14:55:23 Glenn: I can add that issue and mark it as ttml.next. 14:55:28 Nigel: Okay that works for me. 14:56:44 SUMMARY: @skynavga to make an editorial tweak from altitude to ascent in TTML2 and @palemieux to port that back into this pull request. 14:57:36 Topic: TTML1 3rd Edition CR2 14:57:59 Nigel: I understand Pierre is requesting a CfC to publish TTML1 3rd Ed CR2 based on 14:58:22 .. the two open pull requests #355 and #356 when the edits just approved in principle 14:58:29 .. have been applied to #355. 14:58:33 Pierre: Yes 14:59:33 PROPOSAL: After the editorial tweak to #355 agreed above, merge #355 and #356 early and generate a CR2 draft for review with intent to request transition after the normal 10 working day period. 14:59:44 Pierre: That's good with me. 14:59:49 Nigel: Any objections? 14:59:56 group: [silence] 15:00:04 RESOLUTION: After the editorial tweak to #355 agreed above, merge #355 and #356 early and generate a CR2 draft for review with intent to request transition after the normal 10 working day period. 15:00:20 Nigel: Okay, when those tweaks are made Pierre please ping me and I will issue a CfC. 15:00:53 Cyril: Given the potential problem of timeline with TTML2 if it helps would it be possible 15:01:02 .. to request transition earlier than 10 working days? 15:01:14 Nigel: No, I don't believe it would be possible, but I also don't believe it would help. 15:03:10 .. The transition request cannot be executed before the group's decision is final, though 15:03:23 .. we could get those pull requests merged earlier. 15:03:32 Glenn: I agree I don't think you could squeeze those 10 days by process. 15:03:42 Pierre: [drops off the call, with apologies] 15:05:05 Nigel: Regardless of whether or not we can squeeze TTML1 3rd Ed out a week early, 15:05:33 .. we still have the exclusion period question referenced above, so I don't think it would make much difference. 15:05:58 Glenn: Regarding adopting TTML1 3rd Ed from TTML2 we could change to a generic 15:06:31 .. non-dated reference, or we could leave as is and then anyone traversing the link would 15:06:39 .. get a warning that it is not the latest version. 15:06:53 Nigel: Even so that doesn't change the semantic basis. 15:07:02 Glenn: That's true unless we change the reference to be non-specific. 15:07:11 Nigel: True but I think we decided not do that before. 15:07:24 Glenn: If you pull up TTML1 2nd Ed it says that it is outdated. 15:07:52 Nigel: We don't have to decide this right now - I propose we wait for a response from 15:07:54 .. Philippe. 15:08:03 Glenn: I agree. To reiterate for the minutes, three options: 15:08:15 .. 1. Leave as 2nd Ed ref, resulting in an out of date message 15:08:31 .. 2. Supersede it formally which we could do after publishing TTML2. 15:08:35 Nigel: That doesn't really help. 15:08:45 Glenn: If it is formally superseded that emphasises the outdated message. 15:08:57 .. 3. Change to a non-specific reference, which goes back on our previous policy. 15:09:45 Nigel: When we supersede a spec the URL changes so we would run the risk of 15:09:51 .. breaking the just-published TTML2. 15:10:02 .. You can check this with IMSC1. 15:10:52 Topic: IMSC 1.1 CR2 15:11:04 Nigel: The CfC for IMSC 1.1 CR2 ends tomorrow I believe, and I'm not aware of any 15:11:19 .. objections to proceeding with the request for transition at this time. 15:11:32 .. Since Thierry is not on the call I can't ask him now to prepare the transition request 15:11:37 .. but will do that offline. 15:11:57 .. Hopefully that transition request can be raised on Monday (if not before!). 15:12:38 Topic: Future meetings timings 15:12:51 Nigel: Andreas reminded me at the top of this call that some groups are switching to 15:13:04 .. have meeting times based on UTC instead of Boston time, to simplify (slightly) the 15:13:13 .. issue of daylight savings time changes. 15:13:28 Andreas: Yes, it was discussed at the AC meeting in May and I think everybody agreed 15:13:39 .. it would be easier not just because of DST but also if new members join the call it 15:13:51 .. is easier to find out when the call is. It is not urgent but I would propose if nobody 15:13:57 .. objects to switch to UTC instead of Boston time. 15:14:05 Nigel: You're not proposing to change the time? 15:14:14 Andreas: No, only the time zone. 15:14:17 Nigel: Okay. 15:15:18 PROPOSAL: Base the meeting time on UTC rather than Boston time for future meetings, i.e. 1400 UTC every Thursday. 15:15:30 Nigel: Any objections? 15:15:38 group: [silence] 15:15:54 Nigel: Okay what I will do is highlight this resolution in the minutes in case anyone 15:16:02 .. has later thoughts about it or has a view but is not on this call. 15:16:20 Andreas: The other proposal that is useful for new people is to include meeting invites 15:16:23 .. in your invitation. 15:17:15 Nigel: Yes that's a good idea, I think I can do that. I'll look into how to do it. Thanks 15:17:27 .. for the proposal, I will do that when the resolution to change the time zone has been 15:17:36 .. finalised. I don't think I need a special resolution for that decision. 15:17:48 .. Good ideas, thank you. 15:18:36 Topic: TTML2 15:19:00 Nigel: I wonder if we can get to a resolution on ttml2#867? 15:19:11 Glenn: We should have a private conversation because we're not on the same page. 15:19:24 Nigel: Good idea, your audio is breaking up a little so probably better than doing it now. 15:19:32 Glenn: Let's try to do it soon, maybe early next week? 15:19:35 Nigel: Yes. 15:19:55 Glenn: Maybe 18th-20th I will have better connectivity. 15:20:03 s/0th/2nd 15:21:02 Nigel: I'll send you an invite. 15:21:45 Topic: Unicode bidi should probably not be animatable. ttml2#881 15:21:51 github: https://github.com/w3c/ttml2/issues/881 15:22:05 Nigel: Quick update - I have asked Philippe, and hope to hear back from him perhaps 15:22:15 .. early next week - I think W3 staff availability is currently limited. 15:22:30 SUMMARY: Request sent by @nigelmegitt to @plehegar 15:23:10 Topic: Clarify that construct effective {content,processor} profile is performed only once. ttml2#860 15:23:17 github: https://github.com/w3c/ttml2/issues/860 15:23:30 SUMMARY: @skynavga and @nigelmegitt to discuss offline 15:23:34 github-bot, end topic 15:24:07 Topic: Clarify that [validate document] may produce false positive results. ttml2#876 15:24:16 github: https://github.com/w3c/ttml2/issues/876 15:24:30 Glenn: I'll fix the typos. We already have a note on false positives that talks about a more 15:24:45 .. generalised value syntax in the schema than the spec, in the section on schemas. 15:25:02 .. In section 4.1, a long note. I could refer to that note here. 15:25:12 .. It wasn't so much the schema false positives I was thinking of when I wrote this 15:25:24 .. material but the more complex restrictions that are not at all expressible in a schema, 15:25:34 .. for example all the constraints about ruby, as well as many other cases. 15:25:49 .. Unless you consider your schema to include code, which I do, I define the set of 15:26:06 .. potential schemas as including programming code, then that note could make it 15:26:09 .. less abstract. 15:26:13 Nigel: Yes that would work. 15:27:40 .. More generally the reductive interpretation of this is to say that implementations might 15:28:05 .. not be complete, which is true of almost everything, so why call this one out particularly? 15:28:44 Glenn: I agree, this note and all others could be removed without changing the 15:28:49 .. normative text. 15:29:04 .. People might think that putting "prohibited" in a profile might lead a validation processor 15:29:16 .. to catch it. I want to ward off those kind of readings by pointing out that the language 15:29:33 .. on validation is based on "if something is detected" rather than requiring detection of 15:29:50 .. every possible error. It doesn't hurt to say it, unless you dispute that it is factually correct. 15:29:57 .. I would dispute that it's factually wrong. 15:30:00 Nigel: Ok 15:30:13 Glenn: We don't precisely define the behaviour of what happens when something 15:30:29 .. violates a constraint. In some cases we specify a fallback but in others we don't. We 15:30:47 .. also don't set threshold rules about when aborting should happen. 15:31:23 .. I'm just trying to help the reader out - my re-reading made me think that there was 15:31:28 .. potential for misleading the reader. 15:31:41 Glenn: I'll make those two fixes and maybe you can consider that. 15:31:44 Nigel: Okay will do. 15:32:11 SUMMARY: @skynavga to make edits discussed above and @nigelmegitt to re-review 15:32:15 github-bot, end topic 15:33:58 Topic: text profile should support anamorphic fonts imsc#419 15:34:03 github: https://github.com/w3c/imsc/issues/419 15:34:09 Cyril: I raised this issue this morning. 15:34:24 Nigel: I think this needs to go to requirements first, but we can discuss it here now. 15:35:20 Cyril: Anamorphic fonts is a feature we use quite heavily. It is a de facto practice 15:35:31 .. that was inherited from lambda cap. I suspect it is not easy to define two glyphs 15:35:46 .. that are completely distinguishable within the em box, which may be why stretching 15:35:54 .. is used instead of using specific fonts. 15:36:38 Nigel: Is there any other way to achieve the result than to use fontSize with two components? 15:37:03 Glenn: You mentioned two specific characters, distinguished by stretching. Practically 15:37:14 .. speaking, just not stretching either of them and requiring the reader to use context 15:37:23 .. to figure out which is which is not a horrible way to deal with this. 15:37:37 Cyril: Our QC team clearly told me this is not acceptable. 15:37:50 Glenn: Okay, I understand, though I think Japanese readers can fill in the blanks and 15:37:53 .. distinguish them. 15:38:10 Cyril: There's clearly ambiguity and we want to distinguish these cases. 15:38:20 Glenn: It's a really high cost for what I consider really low value. 15:38:37 Cyril: I understand that, which is why I suggested adding restrictions. I am open to any 15:38:40 .. suggestions. 15:38:54 Pierre: Before we go there, for the record, my interaction with folks other than Cyril 15:39:18 .. who work with Japanese subtitles has been consistent with what I heard from Glenn. 15:39:31 .. I think we need a separate meeting with interested parties to work out the solution. 15:39:40 Cyril: Sure, I'm concerned about the timelines. 15:39:53 Pierre: I do not think it can be implemented in CSS. 15:40:06 Cyril: We can set up this meeting. I do not want to delay the process. What I can think 15:40:15 .. of for today is to add the feature and mark it as at risk? 15:40:28 Pierre: No, it is just not implementable in CSS. If you can point to a way it could be 15:40:34 .. implemented that would address my concerns. 15:40:49 Glenn: One of the things you mentioned is different glyphs. The implementation is free 15:41:06 .. to map to whatever glyphs it wishes. One implementation approach would be to 15:41:19 .. select different glyphs with intrinsically different widths. That would not require the 15:41:34 .. general ability to specify an anamorphic font, which is a much costlier thing for 15:41:36 .. implementation. 15:41:48 Pierre: When I experimented with fonts, some of them showed a much bigger difference 15:42:07 .. between those two characters than others. Like in some Latin fonts it can be hard to 15:42:18 .. tell an O from a 0 or an l from a 1. 15:42:22 Glenn: Yes that's exactly the point. 15:42:34 Cyril: Okay I will come back to you on this issue but it might be a blocker for us to 15:42:37 .. progress IMSC. 15:42:41 Pierre: Understood. 15:42:49 Glenn: In a sense I view this as a quality of implementation issue. 15:43:03 Pierre: That's where I am but maybe there's more information to bring to the table that I don't know yet. 15:43:17 Glenn: If this is the only example then anamorphic fonts is overkill. 15:43:38 Cyril: It's not anamorphic fonts but the right restrictions to make it not overkill. 15:43:51 Glenn: If you tweak the character then you're proposing a generic property that can 15:44:03 .. apply to any character, not just the ones that have the problem. That's a more generic 15:44:14 .. solution to this problem. You have to raise the cost vs gain comparison here. 15:45:05 Nigel: I think looking for other ways to achieve an acceptable result is the way forward here. 15:45:14 .. For example in SVG you could apply a transform, and maybe in CSS? 15:45:23 Glenn: Only on block containers in CSS, not inlines. 15:45:40 Cyril: If it is not used then why is it in LambdaCap? 15:45:50 .. We ingest content with that feature in. 15:46:04 Pierre: I'm guessing here, but one possibility is there's only one font that is used in 15:46:10 .. LambdaCap. That could be a reason. 15:46:24 Glenn: Actually LambdaCap has 6-10 font families that it can select. 15:46:40 .. We implemented this in TTML2 with generic stretching. There is a pretty heavy toll 15:46:51 .. on the implementation to support anamorphic fonts. For example you have to have 15:47:04 .. anamorphic whitespace as well as anamorphic glyphs. There is a whole bunch of things 15:47:06 .. that it affects. 15:47:15 Cyril: Okay I'll come back to you on this one. 15:47:31 SUMMARY: @cconcolato to review and come back with further thoughts. 15:47:36 github-bot, end topic 15:48:19 Topic: tts:origin/tts:position constraint applies to Text profile only imsc#418 15:48:25 github: https://github.com/w3c/imsc/issues/418 15:48:35 Pierre: I think this is editorial, and was planning to address it after CR2. 15:48:42 Nigel: Okay, knowing the plan is useful. 15:48:49 Pierre: This is definitely not fatal. 15:49:25 Nigel: I think this could be considered substantive. 15:49:29 Pierre: I'll address it today. 15:49:46 Topic: lineHeight restriction should not preclude using the initial element imsc#420 15:49:52 github: https://github.com/w3c/imsc/issues/420 15:50:00 Pierre: I plan to address this today, using the same text as in TTML2. 15:50:04 Cyril: Fine 15:50:52 Topic: Address draft CR2 comments imsc#417 15:50:59 github: https://github.com/w3c/imsc/pull/417 15:51:09 Pierre: I addressed your comment Nigel 15:51:59 Nigel: That looks great, thank you! 15:52:05 .. [approves pull request] 15:52:35 github-bot, end topic 15:52:39 Topic: IMSC 1.1 CR2 15:52:53 Nigel: Just noting that we have a small flurry of last minute review comments but I'm fairly 15:53:54 .. relaxed about them, given their nature. 15:54:43 Topic: TPAC 2018 15:54:51 Nigel: Don't forget the early bird rate is still available. 15:54:58 Pierre: And to confirm we are meeting Monday and Tuesday? 15:55:00 Nigel: Yes 15:55:18 .. Note we are likely to have a significant amount of "joint meeting" with M&E IG on the 15:55:33 .. Monday. I'm still open to the idea that we in fact mainly meet with them on the Mondayu 15:55:38 s/yu/y 15:55:53 .. and conduct our TTWG only business on the Tuesday, depending on the volume of 15:55:56 .. topics we have to discuss. 15:56:34 .. Obviously as Chair I'm willing to take input on that. 15:56:56 Topic: Meeting Close 15:59:20 Nigel: Thanks everyone for joining today. See you next week! [adjourns meeting] 15:59:28 rrsagent, make minutes 15:59:28 I have made the request to generate https://www.w3.org/2018/07/12-tt-minutes.html nigel 16:04:05 Regrets: Thierry 16:04:23 s/github-bot, end topic//g 16:04:52 s/i'm just now trying to join, but I'm connecting from an iffy wifi from the French West Indies/ 16:09:13 s/.. done reliably. /Pierre: done reliably. 16:11:36 s/SUMMARY: @skynavga to make an editorial tweak from altitude to ascent in TTML2 and @palemieux to port that back into this pull request./SUMMARY: @skynavga to make an editorial tweak from altitude to ascent in TTML2 and @palemieux to port that back into this pull request; @skynavga to raise an issue to add the special inheritance semantics back into TTML2. 16:12:37 Zakim has left #tt 16:13:25 i/Topic: text profile should support/Pierre: [rejoins call] 16:14:38 rrsagent, make minutes 16:14:38 I have made the request to generate https://www.w3.org/2018/07/12-tt-minutes.html nigel 16:19:26 scribeOptions: -final -noEmbedDiagnostics 16:19:28 rrsagent, make minutes 16:19:28 I have made the request to generate https://www.w3.org/2018/07/12-tt-minutes.html nigel 16:21:39 atai2 has left #tt