[MPEG-OTSPEC] Updates to specification

Dave Crossland dcrossland at google.com
Fri Aug 14 19:10:25 CEST 2020


On Fri, Aug 14, 2020 at 12:38 PM Levantovsky, Vladimir <
Vladimir.Levantovsky at monotype.com> wrote:

> On Friday, August 14, 2020 1:12 AM Dave Crossland wrote:
>
> You'll have to forgive me for sounding rather partisan,
>
> Forgiven! You should prioritize your sleep too! J
>

Sadly my 8 month old manager decides when that can happen, not me ;)


>  but emailing around docx files seems to me rather inefficient :)
>
>
>
> Yes, it is, but there are realities we can’t change.
>

Hmm :) If ISO requires a DOCX file as input, that is still compatible with
the more efficient repo-based authoring process I am proposing, as it is
possible to have such files generated in a programmatic way.


> On top of that, the ISO SC29 have been undergoing some major org changes
> lately, so things are a little bit out of hands because of all the
> transitions happening now. It was relatively easy to find a public link for
> the output document of the previous meeting, not so much (yet) for the
> latest one, which I emailed a copy of.
>

Got it, thanks for the context.


> Where are the documents referenced in (1)?
>
>
>
> Input documents (as is the case here) are produced by their contributing
> members and it’s up to them whether they decide to make them public. In
> this particular case, the liaison letter from SC34 isn’t public and is only
> accessible to accredited members of the SC29 behind the login,
>

I see. That is disappointing. Is a summary available?


> but the liaison from CSS WG is public (
> https://lists.w3.org/Archives/Public/www-archive/2020Feb/att-0005/CSS-SC29-20200113.pdf),
> and I made it available as part of the original announcement back in
> February this year (
> https://lists.aau.at/pipermail/mpeg-otspec/2020-February/001770.html)
>

Excellent!


> My suggestion about a github repo seems to fall within (3), too? :)
>
>
>
> The discussions we are conducting on this list as part of the AHG
> activities definitely fall within mandate 3.
>
> However, when it comes to creating a GitHub repo - it may not be as easy
> as we might hope. Ideally, having the whole text of OFF in public GitHub
> repo would be a good thing, and each proposed change would have an
> associated set of issues attached, but I am not sure how to get around
> copyrights issue – I am trying to get guidance on this. Even though ISO/IEC
> 14406-22 “Open Font Format” is a publicly available document (
> https://standards.iso.org/ittf/PubliclyAvailableStandards/) and anyone
> can get their own free copy of it – you do have to click through the
> copyright disclaimer before ISO allows you to download a copy. In essence,
> every user gets a copy that is directly licensed to him/her, it’s free to
> use but not free for all.
>

Understood. Well, it seems per David Singer's later (amazing! Thank you
David!) comments on this list that a issue-only repo like
https://github.com/MPEGGroup/FileFormat (and indeed, a twin with
https://github.com/MicrosoftDocs/typography-issues that avoids the issues
with single-vendor no-policy spaces) would still be useful, as it could
move more concrete discussions off this list to a place where they can be
better tagged, sorted, segmented into milestones, tied to resolution
actions, and so on - and this list could return to a lower level of traffic
for discussions that are more meta or free wheeling.

Cheers
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200814/003c85ab/attachment-0001.html>


More information about the mpeg-otspec mailing list