- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 18 Mar 2021 17:17:38 +0000
- To: TTWG <public-tt@w3.org>
- Message-ID: <VE1PR01MB6143F73B2123B5B9C23EB864CA699@VE1PR01MB6143.eurprd01.prod.exchangelabs>
Thanks all for attending today's TTWG meeting. I understand that there was some confusion about the time, for which apologies. I thought I'd updated all the information but forgot the .ics files.
Minutes can be found in HTML format at https://www.w3.org/2021/03/18-tt-minutes.html
In text format:
[1]W3C
[1] https://www.w3.org/
Timed Text Working Group Teleconference
18 March 2021
[2]Previous meeting. [3]Agenda. [4]IRC log.
[2] https://www.w3.org/2021/03/04-tt-minutes.html
[3] https://github.com/w3c/ttwg/issues/176
[4] https://www.w3.org/2021/03/18-tt-irc
Attendees
Present
Cyril, Glenn, Nigel, Pierre
Regrets
Atsushi, Gary
Chair
Nigel
Scribe
nigel
Contents
1. [5]This meeting
2. [6]Publication of updated CR
3. [7]Unresolved horizontal review issues
4. [8]Shear calculations and origin of coordinate system.
w3c/ttml2#1199
5. [9]Meeting close
Meeting minutes
This meeting
Nigel: Today's a TTML2 focused call.
… For the agenda I have CR2 publication, and unresolved HR
issues
… Is there any other business?
group: [no other business]
Cyril: If we have time to talk about shear calculation?
Nigel: We can add that to the agenda
Publication of updated CR
Nigel: Good news - we got there with CR2, at [10]https://
www.w3.org/TR/2021/CR-ttml2-20210309/
… I noticed too late that we forgot to put a history link in at
the top.
… That can go in later, at PR or a CRD if we do one.
[10] https://www.w3.org/TR/2021/CR-ttml2-20210309/
Unresolved horizontal review issues
Nigel: Ralph, in reviewing the CR transition request, noted
that there are open HR issues.
Glenn: I closed one of the HR issues after publication had
occurred, which was just some clean up work I was doing
… to create the release entries in GitHub, and clean up any of
the milestones for TTML2 CR2.
… I noticed that there was one review issue that was still
logged against that milestone,
… that seemed to be covered by material we added under the
privacy section on fonts,
… and I see that Nigel reached out to the original commenters
to see if they want to add anything further.
… Are there others?
… There may be some that were not associated with that
milestone.
Nigel: Yes there are. I added them to the agenda.
… #1211 was split into #1212 and #1213, about writingMode,
direction and unicodeBidi on the p element.
… We tried to resolve that before, and it didn't go well.
… But it remains open.
… The other one just to complete the list is #1201 which is
above security and privacy risks of insecure transport / mixed
content.
… I have a feeling that is only editorial and is asking to
replace any http:// URLs in examples with https:// ones.
… I think we may have a hard time going to PR if we haven't at
least tried to address these in some way.
Glenn: On the first, #1211, it will depend on whether the
proposed resolution entails a substantive change or not,
… as to whether it applies in 2nd Ed. Particularly if there is
a change that breaks backwards compatibility.
… I still have some TBDs to progress some PRs on these after we
finished our last round of in-depth discussion on these.
… I guess the ball is in my court to get some PRs out on them.
Nigel: That would be great if you could. Pierre tried before
but we didn't have consensus to merge.
Glenn: It could be that a substantive change needs to go to
TTML3.
Nigel: Yes, if it's a breaking change, but I think where we go
to is we didn't need that.
Glenn: Okay, I will try to devote some time to opening PRs on
this topic.
Nigel: Thank you, I really appreciate that.
… On #1201, the proposed resolutions are to note
non-normatively the risks to confidentiality and integrity, and
to change the scheme to https in the examples.
… Those things both seem achievable.
… Any volunteers to open a pull request to address that?
Glenn: It would be an easy editorial change to use https in the
examples throughout the spec.
Nigel: I may try to pick up this as a PR, but not until the end
of next week.
… If anyone else can, that'd be great too.
… To me, the non-normative note about risks is the appropriate
fix here because we don't talk about transport protocols at
all.
Glenn: Yes, agreed.
Nigel: The tool linked below is really helpful - when I
reviewed, those issues are the only ones we have to deal with
in TTML2 2nd Ed,
… but if there are any listed as for a later version that we
can solve that's okay too of course.
[11]TTML horizontal review issues (all versions)
[11] https://www.w3.org/PM/horizontal/review.html?shortname=ttml
Shear calculations and origin of coordinate system. w3c/ttml2#1199
github: [12]https://github.com/w3c/ttml2/issues/1199
[12] https://github.com/w3c/ttml2/issues/1199
Cyril: To explain what happened, on this issue I opened a year
ago (and then forgot about):
… We are now implementing support for TTML2 / IMSC 1.1 on
Android came to me independently with the same questions.
… One question: Is the behaviour of shear influenced by the
inline progression direction or the block progression
direction?
… You can ask the question in different ways. Another is: what
is a +ve or -ve angle in different writing modes?
… So 2 days ago I updated the issue with the same question in
more details.
… My conclusion is that we should clarify what is the intention
of the shear.
… It can be done visually with examples for different writing
modes if that has an impact.
… Or we could be more precise mathematically and provide the
centre of the orientation and the angle.
Nigel: Note Pierre's useful comment about CSS.
Glenn: What CSS does is irrelevant in this case - it's a skew
transformation, so forget about that.
… I started looking at it and made some progress on drafting an
answer to Cyril but I haven't finished it
… because I wanted to study in detail more the various
combinatorics involved.
… To your question on block shear or paragraph level shear,
i.e. tts:shear, at least the origin here was intended
… to be the origin of the block areas generated by the
paragraph.
… Normally the paragraph will generate one or more outer block
areas with line area children.
… In some implementations it might forgo the intermediate outer
block area and just have line area block children.
… In any case the overall intent, reflected in the sample image
that is included in the definition of that property,
… was that the origin of the generated block area be the origin
of the shear transformation, not the centre.
Cyril: Where would the origin be?
… The top left, the top right corner?
Glenn: In horizontal writing modes and it's left to right as
the paragraph level bidi assignment then it would be the top
left.
… If it's horizontal writing mode with right to left as the
paragraph level bidi (or an odd number by the bidi algo for the
outer p embedding level)
… then it would be the top right of the block area since you're
filling from right to left. At least that was my intention.
… Then for tblr it would be top left corner, and tbrl it would
be top right corner.
… Does that makes sense or not?
Cyril: I just care about it being clear in the spec.
Glenn: I understand that clarifying the spec is your main goal
and I agree with that.
… But we also probably ought to agree what the correct answer
would be as well.
… I'm open to other possible definitions than the one I just
gave.
… That's the one I happen to have implemented. Others might
feel like it's better to argue for a different definition.
Cyril: Another clarifying q. For tbrl, you said the origin
would be the top right corner?
Glenn: Correct
Cyril: And the spec says if the ipd corresponds to the y axis
then the 2d shear matrix is [...]
… What would be the x axis in this case, the ipd or as usual
pointing to the right?
Glenn: The answer I just gave would have it match the bpd, so
if it is right to left then it would be the top right corner.
Cyril: That makes sense because the +ve angle goes from the y
axis to the x axis so it looks consistent to me.
Glenn: That's how most implementations would tend to lay out
block areas and I believe (haven't verified it) that if we were
to go back
… to look at the definitions of placement of block areas in
XSL-FO that would correspond to its model of the origin of
those block areas as well.
Nigel: Glenn you dismissed CSS very quickly earlier, but it's
surely an important data point.
Glenn: Not really, in CSS there's a post-processing mapping
from shear to skew, and the skew transformation could be used
to implement it
… but as we define the semantics.
Pierre: I'm shocked by this; The spec says the semantic basis
for tts:shear is CSS skew, so you can't say that wasn't
intended.
Glenn: You have a good point. I don't have the text of the spec
in front of me right now.
Pierre: It's under semantic basis for shear derivation it
points to skew-x and skew-y.
Glenn: That's something Nigel did, I never looked at that.
Pierre: That's what the spec says and what people implemented.
Glenn: If we inadvertently wrote that then we need to clarify
what the derivation means, it could mean "can be mapped to".
Nigel: I don't believe credit or blame is due my way for the
mapping from shear to skew. I rearranged the semantic
derivation but I don't
… recall inventing any mappings.
Pierre: I think the spec is actually quite clear, whether it is
right or not.
… It says semantic derivation and points to skew-x and skew-y
Cyril: I agree with Glenn here, the semantic derivation gives a
link, but if you ignore it altogether you can't implement
anything!
Pierre: Exactly
Nigel: I think the question here is what should the spec say,
and does it say it?
Cyril: The key question is whether the shear direction depends
on writing mode. At the moment the spec doesn't say that at
all.
… Since it was not clear, it is unlikely that the
implementations are interoperable. We may want to make it match
CSS or not.
Glenn: I agree. I think I would try to oppose employing the CSS
definition which would be the centre of the block area.
… It is clear that one can map a semantic that is based on an
origin that is not centre based to a semantic derivation of
skew in CSS that
… is based on centre. But I view that as part of the
implementation process of mapping our semantics to CSS in this
regard.
… In my mind, the question, and what I read between the lines
is Pierre's suggestion to adopt the CSS semantic of a block
centre skew transformation
… then that would be problematic in my opinion.
Pierre: I plan to object strongly to changing the origin to
anything other than centre.
Glenn: Until we define it, it is currently undefined.
Pierre: I don't agree with that assessment and I think it is
clear what it says in the spec today.
Glenn: You think it is the centre of the block?
Pierre: Yes absolutely. For the record, unless using centre for
skew cannot be used in the context of timed text in general my
… position is that it should be used in general.
Cyril: If you look at the tts:shear example image, I don't know
how the centre of the block could be the centre of the
transformation
… in that example.
… If you take the right side of the image and apply the
transformation around the centre without doing any translation,
then the right hand
… kanji would be outside of the region.
Pierre: It's not possible to tell where the origin was in that
illustration.
Cyril: I agree there's some ambiguity, but it's not clear.
Pierre: That's why I go back to the semantic derivation.
… My question is why is centre wrong? It seems to work. Unless
there is an argument why it is not good then we should stick
with it.
Cyril: To get the example image you'd have to apply some
translation (or padding)
Pierre: You'd have to do that regardless to avoid overflowing
(loosely) the region.
Nigel: There are two questions: first is the origin of
transformation, but the other is the direction of
transformation.
… Do we have any info from CSS on direction?
Pierre: No, on that one, it is much more ambiguous.
Glenn: Another issue: while it is feasible to define the shear
in terms of centre for p or line shear, it cannot be used for
font shear.
… You're intent is going to break down at that point, to define
a centre based shear model based on skew in CSS. The origin
cannot be
… the centre of the glyph. One could take the semantics we need
to define, which is an origin based on its placement on the
baseline,
… and translate that to a centre based skew transformation by
appropriate matrix multiplication, but it will make the
explanation of it
… more complicated if we define it in those terms and at that
point we're instructing on how to implement based on CSS which
we have
… not tried to do in general.
Pierre: Ideally here the solution is to get a discussion with
CSS and find a common acceptable solution.
Glenn: Unless we have nailed down our intended semantics and
have a way of documenting that first it will muddy the waters
to
… get involved with CSS. They're not defining shear semantics
as far as we know. Are they?
Nigel: I haven't checked JLReq and all the gap documents
published by the internationalisation activity, but I would
speculate that
… this would be one of the gaps that would need solving across
the web platform, so they likely do want to solve it.
Cyril: I think we should identify what we want for how shear
should work and then how to map it onto CSS.
… One problem I see is we have one way to do block, font or
line shear, but to map onto CSS you cannot use the same
mechanism for each.
… For fonts you have to use font-style: oblique; I'm not sure
it behaves the same.
Glenn: Does it take an angle?
Cyril: Yes oblique takes an angle parameter
Glenn: Ok I wasn't aware of that
Cyril: That's implemented in Chrome and Firefox and is in CSS,
not sure if it is level 3 or 4.
Glenn: I think it's nice to have for people who are basing
implementation on CSS, but it's not a necessary part of our
semantics as
… far as I'm concerned, in terms of defining our intentions.
Pierre: My interest is in interoperability and compatibility
with the web platform.
Nigel: If we think about this from an authorial and user
perspective, rather than a spec-partisan perspective, then we
should surely come
… to the same conclusion.
Glenn: I agree, and did offer to consider other options.
Cyril: In the comments on the issue, the image at the bottom
shows a possibility for defining shear not in consistent
mathematical terms,
… depending on the writing mode, another approach is to say
"here is what we want to achieve", which could be like italics,
where
… positive shear behaves like italics in horizontal modes, and
we can do what we want for vertical, then we can derive the
math.
… Can we agree, forgetting for the time being about tbrl, that
the three images are what we want?
… tbrl has positive shear pointing to bottom left.
… lr has positive shear pointing to top right
… rl has positive shear pointing to top left.
… If we can agree on that then we can decide if we need
translation or scaling or padding or whatever.
Nigel: My assumption is that shear line layout occurs
post-shear not pre-shear. Is that controversial?
Glenn: I think that's an implementation issue. We should
review.
… The semantics of laying out the line areas in XSL-FO, close
to CSS 2.1, is based on a non-shear model, so the packing or
stacking of
… blocks and inline areas with glyph areas assume a certain
model but different implementations can take different
approaches.
… For example one implementation might compute and create state
information for laying out the glyphs in a line area based on
advances
… alone possibly in association with baseline shifts.
… But when they actually paint those glyphs they might paint
them from one or the other direction by recalculating those
advances.
… For example if you're painting a paragraph that's rtl you
might output the glyphs in rtl display order which might match
reading order
… or you might output them in ltr order opposite to reading
order. As long as the eventual position of the glyphs match up.
… This has an impact on how things like PDF files store
information for accessibility purposes, when those glyphs are
recombined for
… operations like find. It is implementation dependent.
Cyril: Implementations can certainly do different things. The
question is the interoperability. How do we achieve it?
… We should specify something but the question Nigel raised is
important because if you apply layout first and then shear you
might have
… overlap in terms of glyphs. So Nigel I think we should agree
on the visual aspects of the transformation, how it should
look, then agree
… on the layout, how is it placed with respect to other text or
objects, and then translate that into specification math.
… For example in terms of layout one big difference between
using the centre vs a corner for transformation, unless you
apply padding or
… scaling, if you use the centre of the block you may have
glyphs moving outside the original box. And that affects
layout.
Glenn: Even if you use a corner, if you do not reduce your line
measure and adjust accordingly then you may overflow on one
side or the other
… of the line areas.
Nigel: I was about to say that
Cyril: Only on one edge, right?
Glenn: In the implementation I did I take the shear into
account of the length of the original line area, and reduce it
in order to keep the
… aligned measure within the outer block area, without
overflowing. I don't take into account any other consideration
at that point.
… Then I lay out without shear, mark the line area as having
shear applied, and then apply the skew transformation when
rendering the line.
… In my case I apply the skew not based on the centre.
SUMMARY: We need to work out what we want it to do before any
detailed specification.
Glenn: It gets more complicated if different segments on a line
have different shear direction. To prevent them from colliding
you need to
… temporarily increase the space between them in order to avoid
collision. Since we can specify font-shear on a character by
character basis
… that means that different characters on a line may have
different shears and spacing.
Meeting close
Nigel: Thanks everyone, apologies if there was some confusion
about the timing of this meeting. We're out of time so I'll
adjourn now.
… [adjourns meeting]
<atsushi> ahhhh, sorry I forgot that!
Minutes manually created (not a transcript), formatted by
[13]scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).
[13] https://w3c.github.io/scribe2/scribedoc.html
Received on Thursday, 18 March 2021 17:17:57 UTC