- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 14 Jun 2018 16:25:45 +0000
- To: "public-tt@w3.org" <public-tt@w3.org>
- Message-ID: <D7485560.5E9D2%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/2018/06/14-tt-minutes.html
In text format:
[1]W3C
[1] http://www.w3.org/
Timed Text Working Group Teleconference
14 Jun 2018
See also: [2]IRC log
[2] https://www.w3.org/2018/06/14-tt-irc
Attendees
Present
Philippe, Cyril, Nigel, Glenn, Thierry
Regrets
Andreas
Chair
Nigel
Scribe
nigel
Contents
* [3]Topics
1. [4]This meeting
2. [5]TPAC 2018
3. [6]TTML2 CR2 publication
4. [7]Applicability of tts:rubyPosition when
tts:ruby="text". ttml2#832
5. [8]TTML2 open issues for wide review
6. [9]Incorporate CSS advances into TTML vertical text
handling ttml2#277
7. [10]TTML2 CR2 wrap-up
8. [11]IMSC v1.1 Requirements
9. [12]Consider adding support for "before" and "after"
annotation position imsc-vnext-reqs#23
10. [13]Update tts:rubyReserve values imsc-vnext-reqs#25
11. [14]Consider adding support for
tts:rubyAlign="spaceAround" imsc-vnext-reqs#30
12. [15]tts:fontShear should be tts:shear
imsc-vnext-reqs#24
13. [16]Exclude support for blur radius in tts:textShadow
imsc-vnext-reqs#27
14. [17]Miscellaneous editorial fixes imsc#388
15. [18]IMSC 1.1 schedule
16. [19]Meeting Close
* [20]Summary of Action Items
* [21]Summary of Resolutions
__________________________________________________________
<scribe> scribe: nigel
This meeting
Nigel: I think we need to talk about TTML2 CR2 publication,
dates etc. as well as one or two
... agenda-marked items on the repo.
... We also have some IMSC 1.1 agenda topics
Pierre: Start with requirements issues.
Nigel: Yes.
... AOB or particular other points to raise? I have TPAC to
mention
group: [no other business]
TPAC 2018
Nigel: You'll have in your inboxes a message about registration
which has just been opened today.
... My request to resolve the clash between Media and
Entertainment IG and TTWG seems to
... have had no action taken and I've received no response, and
the clash remains on the
... published schedule for the Monday.
Pierre: FYI My attendance later in the week has become
impossible now so I have a strong
... preference for being done by Wednesday.
Nigel: I also talked to one of the Chairs of the M&E IG who
told me that their meeting on
... the Monday is the traditional day but there's no other
reason for it.
Pierre: We should focus on specific topics to cover in a joint
meeting since moving the
... meetings might not happen now.
Nigel: +1
<inserted> .. let's take that offline for now.
TTML2 CR2 publication
Nigel: I sent the CfC out yesterday - a little later than
agreed last week, but our discussion
... last week did not cover the additional pull requests that
came along after the meeting,
... which took a bit of extra processing.
... The next question is, given the CfC end date, when can we
make the transition request
... and publish CR2.
Philippe: If you want to publish on the 28th the trick is to
send the transition request on
... the 21st, with a note that the decision will be finalised
on [date]. I used that trick before.
Glenn: Why do we need a transition request if we're already in
CR?
Philippe: Because you're making substantive changes and the
Director has to approve it.
... Only CR updates with substantive changes need a transition
request.
... Based on that I'd like to target the 28th June for
publishing. Is that a feasible date?
... If you send a transition request on 21st then yes it is.
Glenn: Then that puts PR on August 9.
... And the final Rec is sometime in September.
Philippe: Yes, the 13th to be exact.
Nigel: Who can take the action to draft the Transition Request?
Thierry: I can do that.
Nigel: Thank you
... If we can have a draft for me to look at say on Monday that
would be great.
Thierry: Okay
Nigel: Thanks for your flexibility there Philippe.
<plh> [22]https://www.w3.org/2018/06/ttml2-cr-diff.html
[22] https://www.w3.org/2018/06/ttml2-cr-diff.html
Glenn: I just sent out a link to a diff listing - thank you
Philippe for sorting that manually (the diff service is not
working)
... It is actually between the branch where I'm tweaking the
CfC that has a pending pull request,
... with some minor editorial stuff there like the date on the
document and a couple of other
... little things. It's useful for doing a comparison.
Nigel: Thank you. I also want to make sure we have agreement on
the earliest CR exit date.
Glenn: I made it August 9 for entering PR.
... I'm not sure what the July date is - on your tool it listed
August 9 as PR entry.
Philippe: It also says deadline for comment July 26th.
<plh>
[23]https://w3c.github.io/spec-releases/milestones/?cr=2018-06-
28&noFPWD=true
[23] https://w3c.github.io/spec-releases/milestones/?cr=2018-06-28&noFPWD=true
Nigel: We need to put that deadline for comments in the SOTD.
Philippe: The deadline needs to be before you request
transition otherwise it doesn't make
... sense, and you need to request transition a week before you
publish.
Glenn: We didn't write deadline for comments in the SOTD
Nigel: We need to.
Philippe: Yes you need to make it clear otherwise if you
receive a comment a day after
... then you're in trouble.
Glenn: Okay I'll add that deadline if that's ok
PROPOSAL: Set TTML2 CR2 deadline for comments at July 26th 2018
Nigel: Any objections?
RESOLUTION: Set TTML2 CR2 deadline for comments at July 26th
2018
Nigel: I also asked if anyone has any features to add to the at
risk list, and since I've had
... no responses, I assume there will not be any more at risk
features.
... Note that we have already added lineShear and shear
Glenn: I don't anticipate any problem with those because we've
already implemented them
... in TTPE in private, for presentation and validation and I
think that maybe Pierre has done
... something in that regard, maybe for IMSC. I anticipate
something from Netflix as well.
... I don't think either will be thrown out.
Nigel: Ok, sounds good.
... I think it's worth mentioning that the main change in your
as-yet-unmerged pull request
... is to add details of the changes since CR1.
Glenn: Yes, I made some progress with that last night so that
should be completed by
... next week's meeting.
Nigel: Anything else for transition to CR2 that I may not have
thought of?
Philippe: No, I don't think so for a CR2 transition. It should
be a pretty simple transition.
... You don't have to demonstrate that you addressed all of the
issues at this point.
Nigel: Thank you that's helpful.
Glenn: We have deferred some editorial changes to PR.
Philippe: Yes, you can do that.
Glenn: As I've mentioned to Nigel I will be strongly opposed to
any substantive change.
... Anything that looks like it is substantive has to be put
into a Note and made informative
... unless it is completely broken. I don't know of anything
that is hopelessly broken that
... we have to get into the text as normative text at this
point. Of course I can't anticipate
... what comments will come out of CR2.
Nigel: That's a good segue into the agenda item.
Glenn: There's just one.
Applicability of tts:rubyPosition when tts:ruby="text". ttml2#832
github: [24]https://github.com/w3c/ttml2/issues/832
[24] https://github.com/w3c/ttml2/issues/832
Nigel: This is a request for a substantive change concerning
rubyPosition.
Glenn: It is minimally substantive but I think we can call it
that. It's a change in normative
... text that could impact conformance so it satisfies the
criteria.
Nigel: Pierre raised the issue, Glenn opened a pull request,
#833
Pierre: It looks right to me. It makes it invalid to specify
position on a ruby text that is
... within an explicit textContainer?
Glenn: Exactly, which covers the previous case that was
documented.
Pierre: I will approve.
Cyril: I haven't looked at it yet.
... I will do that.
Nigel: Glenn please hold off merging until Cyril has had a look
a it?
Glenn: Sure I'll do that.
Nigel: I will treat this as review feedback during the CfC
period so I don't intend to extend
... the CfC deadline based on this.
SUMMARY: PR Open, to merge early as a CfC feedback comment when
@cconcolato's review is complete
github-bot, end topic
Cyril: I've just approved it.
Glenn: Great, I'll go ahead and merge it.
TTML2 open issues for wide review
<glenn> [25]https://github.com/w3c/ttml2/milestone/3
[25] https://github.com/w3c/ttml2/milestone/3
Nigel: I believe all those are with me for action.
Glenn: What's holding those up?
Nigel: Me being snowed under with other things, is the answer.
... I need to send a disposition to SMPTE and another to Glenn
Goldtein.
... For issue #277 that's one for us to discuss.
Incorporate CSS advances into TTML vertical text handling ttml2#277
github: [26]https://github.com/w3c/ttml2/issues/277
[26] https://github.com/w3c/ttml2/issues/277
Nigel: The status of this is that we could mark sideways as at
risk but do not have a
... feature designator for it.
... Any views?
Cyril: I vaguely remember we decided not to mark as at risk
because it was implemented.
Nigel: OK I didn't recall that.
Cyril: Maybe Glenn mentioned it was implemented.
Glenn: Yes, we have all the current values implemented.
Cyril: Is there a risk to marking it as risk?
Glenn: No
Nigel: Two downsides:
... 1. Suggests non-implementation
... 2. Editorial work to add the feature designator
Cyril: I don't think the argument for not inviting
implementation is a practical problem
... given the current implementation status.
Glenn: I think it's unnecessary work and we should not mark
sideways as at risk.
... It's implemented.
Nigel: You have one implementation for it?
Glenn: I have a presentation implementation and another member
has a validation implementation
... so it satisfies the criteria.
Nigel: Ok then we don't need to mark it as at risk.
Glenn: As a general comment I'm worried about proliferation of
feature designators. We
... went from around 114 to about 250, so we've doubled the
designators but we haven't
... doubled the number of features. Compared to TTML1.
Nigel: Can we resolve to close this with no further change?
Glenn: No objection
Nigel: Anyone else?
RESOLUTION: Close without marking sideways as at risk
github-bot, end topic
TTML2 CR2 wrap-up
Nigel: I think that's all for TTML2, barring the open editorial
branch to complete the changes
... etc.
Glenn: I'll leave that open for a while to deal with other
editorial points.
... [need to drop off now]
Nigel: Thank you
IMSC v1.1 Requirements
Nigel: Pierre, I see we have a few issues open.
Consider adding support for "before" and "after" annotation position
imsc-vnext-reqs#23
github: [27]https://github.com/w3c/imsc-vnext-reqs/issues/23
[27] https://github.com/w3c/imsc-vnext-reqs/issues/23
Pierre: Note that #25 may need to change depending on what we
decide for #23 here.
... Today IMSC 1.1 has requirement only for
rubyPosition="outside".
... After some digging, I think that's optimised for 2 line
presentations.
... My understanding is sometimes there are 3 lines, depending
on the authorial style.
... If they are anything other than 2 lines the author will
need more control than outside,
... and will need to position rubys before or after, so my
suggestion is simply to support
... before and after as well as outside for rubyPosition.
... From an implementation perspective there's more syntax but
in terms of layout it's
... kind of a no-op because before and after need to be
supported for outside anyway.
... This reflects feedback I have received.
Cyril: I have no objection. We were proponents for outside but
we don't have a problem
... with people using before and after if they want to. It's
not exactly a no-op for implementation
... but the cost is minimal.
Pierre: The risk is too great to not include.
Nigel: I think that's right, and also would note that whatever
syntax we accept for
... rubyPosition we also permit in rubyReserve.
Pierre: Yes.
RESOLUTION: Support `"before"` and `"after"` values for
`tts:rubyPosition`.
github-bot, end topic
Update tts:rubyReserve values imsc-vnext-reqs#25
github: [28]https://github.com/w3c/imsc-vnext-reqs/issues/25
[28] https://github.com/w3c/imsc-vnext-reqs/issues/25
Nigel: Now we resolved in #23 to support `before` and `after`
we need to do that here.
Pierre: Yes, that removes the restrictions.
PROPOSAL: Support `#rubyReserve` without additional constraints
Nigel: Any objections?
RESOLUTION: Support `#rubyReserve` without additional
constraints
github-bot, end topic
Consider adding support for tts:rubyAlign="spaceAround"
imsc-vnext-reqs#30
github: [29]https://github.com/w3c/imsc-vnext-reqs/issues/30
[29] https://github.com/w3c/imsc-vnext-reqs/issues/30
Pierre: I just opened this after working on it for a couple of
days.
... The illustration is the best thing to look at.
... Today the only thing that's allowed is center, which is the
bottom illustration.
... The feedback I received is that it doesn't work when the
ruby base is very long, because
... bunching up the ruby text makes it less easy to read.
... The space around example (top example) is preferred.
Cyril: No objection, but the examples .. are they from a real
example?
Pierre: I'm told this happens in real subtitles.
Cyril: Ok, I have no objection.
Pierre: I'd like more information before finalising my own
opinion. Cyril, I'll try to get as
... many real examples as possible.
Cyril: I'll check with Netflix if we have any opinions and
examples too.
Pierre: Thank you. Also there's a subtle difference between
spaceAround and spaceBetween.
... Right now my research says adding spaceAround would address
most of the concerns.
... What I hear this morning is there are no immediate concerns
to allowing it.
Cyril: To be on the safe side we should maybe implement all
values.
... Once you've implemented spaceAround and spaceBetween then
adding withBase is not
... that difficult.
Pierre: Yes, I don't know what CSS supports other than
spaceAround, which is the initial value,
... so seems pretty safe.
Cyril: Do you prefer restricting IMSC 1.1 to a limited set of
values and then increasing them
... later if there is CSS support.
Pierre: I'd rather go down that path, it avoids misuse. It's
not an easy question.
... Do please ask the question Cyril about supporting all of
them. If CSS supports all of them
... then that makes it a lot easier in my mind.
SUMMARY: Research continuing, consider adding all values if CSS
supports them.
tts:fontShear should be tts:shear imsc-vnext-reqs#24
github: [30]https://github.com/w3c/imsc-vnext-reqs/issues/24
[30] https://github.com/w3c/imsc-vnext-reqs/issues/24
Cyril: I think it should be lineShear. I know it is not
supported in CSS, because it requires
... breaking lines into separate paragraphs, but lineShear is
what people expect in terms of
... rendering, in all the examples.
Pierre: The author can do that by creating two `p`s.
Cyril: The implementation can do it by breaking into `p`s.
Pierre: It's not simple, and it means if you ever want block
shear then you can't - you can't
... have the flexibility to shear each `p`.
... I did ask about line breaks in Japanese subtitles and my
understanding is it is not acceptable
... to let line wrap wrap lines.
Cyril: That's not the case, we use that all the time.
Pierre: The feedback I received is that authors want to control
line breaks and you cannot
... just break anywhere in Japanese.
Cyril: My concern is that using multiple `p`s can mess up the
timing. It makes the document
... much simpler if you have one `p` per region or per event.
Nigel: How are we going to figure this out?
Cyril: I think we need to gather more feedback.
... Would it be an option so support both shear and lineShear?
Pierre: Supporting lineShear is going to be extremely
difficult.
Nigel: Because we're missing something in CSS?
Pierre: Yes it only allows shearing of blocks.
Nigel: Yes, I found that in my research too.
Pierre: The overall challenge is turning a bunch of lines into
a bunch of `p`s requires
... restructuring the entire span tree. With rubys on top of
that it's going to be hard to
... implement and also I suspect brittle. I don't want us to
underestimate the complexity
... of doing this correctly.
Nigel: I have a suggestion that we raise this requirement with
the CSS WG.
... I think the requirement is to be able to apply shear to
line areas.
Pierre: Yes, like many of our requests, CSS does not deal with
lines, but we need to.
Nigel: Do we ever need to shear spans within a line?
Pierre: I'm not aware of that requirement
Cyril: Me neither - normally it is the entire line.
Pierre: I'm fairly certain that tts:fontShear is not needed for
subtitles and captions.
... Ideally both lineShear and shear would be supported, but
lineShear is challenging to implement.
... Is IMSC 1.1 broken if lineShear is not supported?
Nigel: My proposal is to support shear for now, raise an issue
with CSS WG for lineshear
... with the intent of adding support for it to a future
version of IMSC 1.1.
Pierre: I like that approach for now.
... Also Glenn filed another issue recently with CSS recently
too, which we should track.
Nigel: I have a list in the agenda actually.
Cyril: One concern about shear is what if the user changes the
font size and suddenly you
... have line wrapping, then the alignment is not desired.
Pierre: If you shear as the entire `p` is the result completely
objectionable?
... For 2 lines there's a very subtle difference, but with 4
lines you see a pretty big difference.
... Not being Japanese, I don't know if the result is
unacceptable or just a bit strange or
... annoying.
Cyril: I'll come back to you on this one.
Pierre: Thank you, I will continue to dig on this too.
<scribe> ACTION: Pierre to raise an issue with CSS WG
requesting support for lineShear [recorded in
[31]https://www.w3.org/2018/06/14-tt-irc]
[31] https://www.w3.org/2018/06/14-tt-irc
<trackbot> Created ACTION-512 - Raise an issue with css wg
requesting support for lineshear [on Pierre-Anthony Lemieux -
due 2018-06-21].
Pierre: I think it is clear that we will replace fontShear with
shear, and deal with lineShear
... separately?
Cyril: I'd rather make one pull request for the shear part.
Pierre: We know fontShear is bad so we need to address that
now.
Cyril: Just add an editor's note to the pull request that we're
considering adding lineShear
Pierre: Sounds like a good solution.
SUMMARY: @palemieux to raise an issue with CSS WG, and to add
an ed note to the pull request to note ongoing query re
lineShear.
PROPOSAL: Drop fontShear support and add shear support, with
continuing consideration for lineShear
Cyril: We would prefer support for lineShear but not shear. We
don't think we are going to
... use shear at all.
Nigel: OK I won't record a resolution for that.
SUMMARY: Continue to investigate options for using shear and
lineShear
Cyril: I would suggest adding both shear and lineShear and add
a note to lineShear to say
... we are investigating implementation difficulties given CSS,
and add a note to shear
... saying we are investigating line alignment issues. Then we
can add both and remove one
... or the other [or neither] later.
Pierre: That's fine with me
SUMMARY: Temporarily add shear and lineShear with editorial
notes against both, pending a later resolution.
Exclude support for blur radius in tts:textShadow imsc-vnext-reqs#27
github: [32]https://github.com/w3c/imsc-vnext-reqs/issues/27
[32] https://github.com/w3c/imsc-vnext-reqs/issues/27
Nigel: Looking at this, it seems like there's good CSS support
already for blur and some of
... the examples of using a large diffuse shadow really need
blur to look good.
Pierre: The motivation here is that 708 does not support blur.
Nigel: Are you asserting that the requirement for subtitles is
only derived from 708?
Pierre: Yes. For traditional subtitles text outline is used not
text shadow.
Nigel: It would help if I could dig out an example here but I
am pretty sure I have seen
... examples that do use shadow. Requesting more time!
Pierre: Absolutely, that would help us make the right decision.
Nigel: In the meantime I assume that the implementation cost is
very low because you
... can just pass the blur value to CSS.
Pierre: I'm not worried about CSS implementation here but I am
worried about other
... implementation techniques, given why we support textShadow,
i.e. 708.
Nigel: We're not overall constrained by 708 for
implementability.
Pierre: Right. If you could find examples that would be really
good evidence.
Nigel: Okay I'll have a look.
SUMMARY: Continue to look for supporting use cases
github-bot, end topic
Miscellaneous editorial fixes imsc#388
github: [33]https://github.com/w3c/imsc/pull/388
[33] https://github.com/w3c/imsc/pull/388
Nigel: Given that Stefan and I have given feedback, what do we
need to discuss in the meeting?
Pierre: I'd like to walk through your feedback Nigel so we can
close this and move on.
... It's important to merge this pull request to allow other
work to proceed.
... You've requested that features link back to constraints.
Nigel: Yes, based on whether there are conformance keywords,
rather than just limiting
... to SHALLs and SHALL NOTs.
Pierre: Okay, I can deal with that.
... There a bunch of things that you and Stefan noted that are
related to changes in TTML2
... but this pull request is not intended to address those. I
want to deal with the TTML2
... feature refactoring separately, and not address
[34]https://github.com/w3c/imsc/pull/388#discussion_r195347251
... here.
[34] https://github.com/w3c/imsc/pull/388#discussion_r195347251
Nigel: Okay, have we got an issue open for it?
Pierre: We can open an omnibus issue - it's next on my list.
Nigel: Sure, I don't mind taking that approach to allow this to
continue.
Pierre: [colour contrast question]
Nigel: If the answer is "no" you haven't checked then fine, put
that on and raise an issue
... to deal with it, then we can proceed.
Pierre: Okay, I can do that.
Nigel: [TTML2 prohibition comment] I think you mean introduced
rather than specified?
Pierre: No, really everything in TTML2. I think we should omit
prohibited things. It's been
... a source of errors when we tried to track features in TTML2
so it makes it easier to
... maintain if we just include features with some support, and
easier to read.
<inserted> Nigel: [TTML2 features comment]
Nigel: I think we need to include all dependent features that
are potential parts or related
... to bigger "group" features even if they are in fact
prohibited, just for clarity. The
... `#extent-auto-version-2` comment above is a good example.
Pierre: That makes sense, that will be done.
Nigel: We can move that into the TTML2 feature change mop-up
issue?
Pierre: Yes, absolutely.
... I wanted to make sure that we didn't think that excluding
prohibited features is a
... bad idea. That is the major substantial change in this pull
request.
Nigel: Just testing the idea. Is it clear and unambiguous? Yes.
... Is it helpful for implementers? Not sure.
Pierre: That's not clear to me either.
... For authors it's much easier.
Cyril: It's easier from an editor's point of view.
... I think I'm fine with that.
Nigel: One more point - the deprecation warning on
ittp:progressivelyDecodable.
Pierre: I'll add that.
... If I make those changes we discussed will you be able to
approve them early tomorrow your time Nigel?
Nigel: Yes, I don't see why not.
SUMMARY: Pierre to make changes as discussed.
github-bot, end topic
IMSC 1.1 schedule
Pierre: The moratorium is not at a perfect time, so it'll be
hard to do a CR2 by June 28.
Nigel: We should stagger after TTML2 so that we aren't hit in
IMSC 1.1 by late substantive
... changes to TTML2.
Pierre: Given the moratorium we should plan for CR2 to be ready
on July 17 when publications
... resume.
Nigel: To request the transition then?
Pierre: No we should have on the Directors desk on July 17 the
transition request.
Nigel: Then publication will be July 24
Pierre: Another moratorium begins July 25
Nigel: So we want publication in that window.
Pierre: Yes
Nigel: Thierry, what would you recommend to expedite this?
Thierry: I think we should get it to the Director ahead of the
"geek week" moratorium,
... during which there is poor availability for the team.
... We need both the transition request accepted and then the
publication in that window.
Nigel: Can we do a CfC on June 21 and make the transition
request on July 5 to ensure
... we are good to publish in that window? Is that feasible?
Pierre: If the CfC starts on June 28 then it ends July 12 and
the transition request could
... be made on July 16.
Nigel: [concern about staff availability to draft transition
request]
Thierry: I can help draft it ahead of geek week, and we can use
the trick that Philippe
... mentioned for TTML2 earlier.
... Why don't I draft it for the 5th, then Nigel you and I can
talk through any issues on the 6th,
... then it can be submitted and be ready for the Director on
the 16th, and be published
... by the 26th (the last permitted date before the summer
moratorium).
Nigel: Okay, sounds like it would work.
Pierre: Ok
Thierry: So we should have a response on the 23rd and I can
request publication on the 26th.
Pierre: Sounds like a good plan.
Thierry: Can you provide an ED close to the CR by the 5th?
Pierre: Yes, based on this plan the goal is to get CR2 ready by
June 28
Nigel: +1
Pierre: Editorially that can work, I think we have those issues
regarding rubyAlign and
... shear and I think that we will try to make progress
quickly. In the worst case we can
... add features and mark them as at risk. So it is possible.
Nigel: Putting shear and lineShear at risk would be an
excellent way to give us time to
... deal with those issues.
Pierre: Yes, and for rubyAlign too, we could put some values at
risk.
... Okay, that gives me good confidence.
Meeting Close
Nigel: We've completed our agenda, thank you.
Pierre: Thanks for the great input on the issues.
Nigel: Great, let's adjourn! See you next week. [adjourns
meeting]
Summary of Action Items
[NEW] ACTION: Pierre to raise an issue with CSS WG requesting
support for lineShear [recorded in
https://www.w3.org/2018/06/14-tt-irc ]
Summary of Resolutions
1. [35]Set TTML2 CR2 deadline for comments at July 26th 2018
2. [36]Close without marking sideways as at risk
3. [37]Support `"before"` and `"after"` values for
`tts:rubyPosition`.
4. [38]Support `#rubyReserve` without additional constraints
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [39]scribe.perl version
1.152 ([40]CVS log)
$Date: 2018/06/14 16:21:47 $
[39] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[40] http://dev.w3.org/cvsweb/2002/scribe/
----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
---------------------
Received on Thursday, 14 June 2018 16:26:14 UTC