[MPEG-OTSPEC] Updates to specification

[Adam Twardoch (Lists)]

Ps. the "reference implementation" that’s part of ISO OFF actually shows
that there are two very different natures of OT/OFF:

One is a file format, which has a specification, where the reference
implementation can be something like fontTools/TTX.

One is a "typographic process", where a reference implementation might
looks more like a combo of HarfBuzz and FreeType.

As noted by others, the OT/OFF documentation currently kind of mixes both
natures.

A.

On Fri, Aug 14, 2020 at 8:10 PM Adam Twardoch (Lists) <
list.adam at twardoch.com> wrote:

> 1. docx can easily be generated via pandoc from Markdown files. I have
> dome some work on integrating this process (for purpose of FontLab help
> system authoring), I’ll happily bring it up to date.
>
> 2. On https://standards.iso.org/ittf/PubliclyAvailableStandards/ ISO OFF
> has "Open Font Format reference software":
>
>
> https://standards.iso.org/ittf/PubliclyAvailableStandards/c054375_ISO_IEC_14496-5_2001_Amd_14_2009_Cor_1_2010_Reference_Software.zip
>
> It’s a small program for SFNT table checksum validation authored by
> Monotype plus a zipped copy of fontTools :)
>
> A.
>
> On Fri, Aug 14, 2020 at 7:11 PM Dave Crossland <dcrossland at google.com>
> wrote:
>
>>
>>
>> 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
>> _______________________________________________
>> mpeg-otspec mailing list
>> mpeg-otspec at lists.aau.at
>> https://lists.aau.at/mailman/listinfo/mpeg-otspec
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200814/dd549e3b/attachment-0001.html>