[MPEG-OTSPEC] Proposal to discontinue the AdHoc Group
Adam Twardoch (Lists)
list.adam at twardoch.com
Mon Sep 21 10:16:47 CEST 2020
1. I agree with Behdad.
I’m grateful that he’s been expressing his frustration over the process
very openly.
I also know that he’s not isolated — I think many people are frustrated
over how the system works.
2. I’be been privileged to have been part of the evolution of the common
font format for nearly 20 years now, and I’m grateful to have been invited
as an “expert” to various gremiums.
However, I think there is a distinction, one that Dave has raised pointedly
several times, between the ISO OFF standard and the vendor-specific
formats.
3. I have no problem with Microsoft, or Microsoft and Adobe, to have the
deciding vote on changes in Microsoft OpenType, or make unilateral changes
to that format.
OpenType is a Microsoft trademark, it’s a Microsoft product, and nobody has
an obligation to support it.
4. Similarly, I have no problem with Apple to have the deciding vote on
changes in Apple TrueType, or make unilateral changes to that format.
TrueType is an Apple trademark, it’s an Apple product, and nobody has an
obligation to support it.
In fact, Apple had been much more “unilateral” in how they changed TrueType
than Microsoft had been with regard to OpenType.
5. I cases of both OpenType and TrueType, I always knew who the “host of
the party” was, and that I was a “guest”.
6. I never really understood the ISO OFF process, hovewer. In fact, up
until recently I didn’t follow OFF much at all. But with OFF, I think the
“host–guest” delineation is muddled. It seems that the process of
developing the OFF standard is trying to both eat the cake and keep it.
On one hand, it tries to mirror whatever goes on in OpenType (but not
TrueType), so it “follows”. On the other hand, it occasionally tries to put
forward some changes in its own, so it tries to “lead”.
In the end, it had the appearance that it’s not clear whether ISO is really
decisive about the OFF standard or it isn’t. But I’ve never worked on any
other ISO standards, so I really don’t know what is the “ISO way”.
7. What I do know is:
Let’s say I want to propose a new SFNT table such as LABL (which I believe
addresses a really valid need):
-
https://github.com/twardoch/opentype-layout/blob/master/proposals/20200423-AdamTwardoch-LABL-table.md
- https://github.com/twardoch/opentype-layout/issues/1
Currently, I have no idea whether I should be proposing this to the ISO OFF
AHG, the ISO OFF WG, to Microsoft, or to Apple. I don’t know whether any of
those paths has any chance of succeeding, and I don’t even know how I
should go about finding that out.
I assume that some of that roots in my ignorance, but still, I’d be
surprised if anyone stepped up and to could tell me “Well, Adam, this is
the process: you do A, then B, then C, and in the end you know if your
proposal will be in the next revision of OFF or if it won’t, and if it
won’t, you’ll know why.”
8. So perhaps the reason why I haven’t pursued my LABL proposal any further
is not only because I lacked dedication, but also because I still don’t see
the correct path I should be choosing. Which is disheartening, as you may
imagine.
9. I suppose many will agree that the process *as it is today* needs
redefining, and that the remnants of past processes that are still lurking
here and there are not the best possible way to move forward.
*If* we want to move forward, that is.
10. I’d like to express my support for the notion that Behdad’s complaint
is heard by a fair and impartial group of people with authority to change
how OFF operates.
Thanks,
Adam
On Mon, 21 Sep 2020 at 08:54, Behdad Esfahbod <behdad at behdad.org> wrote:
> Can EVERYONE who agrees that my complaint should be heard by a fair and
> impartial group of people with authority to change how OFF operates
> please express their agreement via a reply please?
>
> behdad
> http://behdad.org/
>
>
> On Mon, Sep 21, 2020 at 12:38 AM Behdad Esfahbod <behdad at behdad.org>
> wrote:
>
>> On Wed, Sep 16, 2020 at 3:41 PM Levantovsky, Vladimir <
>> Vladimir.Levantovsky at monotype.com> wrote:
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Behdad,
>>>
>>>
>>>
>>>
>>>
>>> Asking the ISO/IEC SC29 Working Group
>>>
>>>
>>> >
>>>
>>> to acknowledge that the AdHoc model has NOT worked for many in the
>>> industry
>>>
>>>
>>> is a strong request, one that cannot be made without providing any
>>> substance to support it.
>>>
>>
>> Great. Where can I submit the evidence? My allegations involve you,
>> Peter, Sairus, and Greg. So the party hearing my complaints cannot include
>> any of you four because conflict of interest.
>>
>> I've been asking you since June or July about how to file a complaint and
>> you have refused to give me an answer. At the last video meeting you said
>> "I don't know", but you didn't say that when I first asked you in writing.
>> Instead you asked to video-call and just told me to NOT file a complaint
>> because it will threaten the existence of the AHG. The existence of the AHG
>> benefits you personally.
>>
>>
>>>
>>>
>>> This is especially important when there is a strong evidence to the
>>> contrary, that this work has been successfully conducted since 2004, that
>>> the OFF standard
>>>
>>> (ISO/IEC 14496-22) has undergone four editions (in 2007, 2009, 2015, and
>>> 2019) and numerous amendments,
>>>
>>
>> Seriously? You, as the chair of this MOFF / AHG whatever, are so
>> blatantly dismissing my allegations that there are problems? I'm a *very*
>> well-established expert and prolific member of this community and I've been
>> alleging for three months now that THERE IS A PROBLEM.
>>
>>
>>
>>> and is widely adopted in the industry (see References below). While the
>>> WG has been responsible for this work item, the actual work has been done
>>> by the
>>>
>>> AHG.
>>>
>>>
>>>
>>>
>>>
>>> Can you please elaborate on what, in your opinion, “has NOT worked”? Can
>>> you point out to any instance of a technical discussion conducted in this
>>> Ad-Hoc Group
>>>
>>> where a technical objection has been raised that did not receive due
>>> consideration and has not been properly reflected in an AHG proposal or
>>> recommendation?
>>>
>>
>> I will to a fair and impartial group of people who have authority to make
>> changes.
>>
>> b
>>
>>
>>
>>>
>>>
>>> Thank you,
>>>
>>>
>>> Vladimir
>>>
>>>
>>>
>>>
>>>
>>> References (list of industry standards normatively referencing ISO/IEC
>>> 14496-22):
>>>
>>>
>>> CE / TV standards:
>>>
>>>
>>> 1) DCI Digital Cinema Systems Specification since 2008 by errata (most
>>> recent is v. 1.3:
>>>
>>> https://www.dcimovies.com/specification/DCI_DCSS_Ver1-3_2018-0627.pdf)
>>> – mandates ISO/IEC 14496-22 support.
>>>
>>>
>>> 2)
>>>
>>> ETSI TS 103 285 V1.1.1 (2015)
>>> <http://www.etsi.org/deliver/etsi_ts/103200_103299/103285/01.01.01_60/ts_103285v010101p.pdf>
>>> Digital Video Broadcasting (DVB); MPEG-DASH Profile for Transport of ISO
>>> BMFF Based DVB Services
>>>
>>> over IP Based Networks (mandates both ISO/IEC 14496-22 “OFF” and WOFF)
>>>
>>>
>>> 3) ATSC 3.0 Interactive Content (A/344:2017,
>>>
>>>
>>>
>>>
>>> https://www.atsc.org/wp-content/uploads/2017/12/A344-2017-Interactive-Content.pdf)
>>> – mandates both ISO/IEC 14496-22 and WOFF (normative references [20] and
>>> [35])
>>>
>>>
>>> 4) Digital Video Broadcasting (DVB); Globally Executable MHP (GEM)
>>> Specification 1.3 (including OTT and hybrid broadcast/broadband) DVB
>>> Document A153:
>>>
>>> https://dvb.org/wp-content/uploads/2019/12/A153_GEM_v1_3.pdf
>>> (normatively references OpenType via ISO/IEC14496-18, the predecessor of
>>> ISO/IEC 14496-22). Also,
>>>
>>>
>>>
>>>
>>> https://www.etsi.org/deliver/etsi_ts/102700_102799/102728/01.01.01_60/ts_102728v010101p.pdf
>>>
>>>
>>> 5) Digital Video Broadcasting (DVB); Multimedia Home Platform (MHP)
>>> Specification 1.2 (http://wiki.commres.org/pds/MHP/a107.MHP1.2.pdf,
>>> normatively references OpenType via ISO/IEC14496-18,
>>>
>>> the predecessor of ISO/IEC 14496-22).
>>>
>>>
>>> 6) OC-SP-OCAP 1.0-I16-050803 OpenCable Application Platform
>>> Specification (mandates support for OpenType, based on DVB GEM
>>> specification)
>>>
>>>
>>> 7) Hybrid Broadcast Broadband TV (mandates OFF and WOFF support for TTML
>>> subtitles with downloadable fonts via DVB A168 MPEG-DASH profile [45], and
>>> also via OIPF Web Standards TV Profile [i.6]):
>>>
>>>
>>>
>>>
>>> https://www.etsi.org/deliver/etsi_ts/102700_102799/102796/01.04.01_60/ts_102796v010401p.pdf
>>>
>>>
>>> 8) DVB TTML subtitling systems (ETSI EN 303 560 V1.1.1 (2018-05),
>>> mandates both ISO/IEC 14496-22 “OFF” [19] and WOFF [18]):
>>>
>>>
>>>
>>>
>>> https://www.etsi.org/deliver/etsi_en/303500_303599/303560/01.01.01_60/en_303560v010101p.pdf
>>>
>>>
>>>
>>>
>>>
>>> Web font standards:
>>>
>>>
>>> Both WOFF 1.0 (https://www.w3.org/TR/WOFF/) and WOFF 2.0 (
>>> https://www.w3.org/TR/WOFF2/) Recommendations normatively reference OFF
>>> (ISO/IEC 14496-22).
>>>
>>>
>>>
>>>
>>>
>>>
>>> Other standards:
>>>
>>>
>>> 1) DICOM Standard (specifies the set of Information Object Definitions
>>> (IODs) that provide an abstract definition of real-world objects applicable
>>> to communication of digital medical information, normatively references
>>>
>>> ISO/IEC 14496-22):
>>>
>>>
>>> http://dicom.nema.org/medical/Dicom/2016c/output/chtml/part03/chapter_2.html
>>>
>>>
>>> 2) Dynamic and Interactive Multimedia Scenes (DIMS) (3GPP TS 26.142
>>> version 7.3.0 Release 7; ETSI TS 126 142 V7.3.0 (2009-06) – mandates
>>> support for ISO/IEC 14496-22, normative reference [4]):
>>>
>>>
>>>
>>>
>>> https://www.etsi.org/deliver/etsi_ts/126100_126199/126142/07.03.00_60/ts_126142v070300p.pdf
>>>
>>>
>>> 3) OMA Rich Media Environment Technical Specification
>>> (OMA-TS-RME-V1_0-20110329-A, mandates support for ISO/IEC 14496-22 -
>>> normative reference [OFF]):
>>>
>>>
>>>
>>>
>>> https://www.openmobilealliance.org/release/RME/V1_0-20110329-A/OMA-TS-RME-V1_0-20110329-A.pdf
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From:* mpeg-otspec <mpeg-otspec-bounces at lists.aau.at>
>>>
>>> *On Behalf Of *Behdad Esfahbod
>>>
>>>
>>> *Sent:* Wednesday, September 16, 2020 4:16 PM
>>>
>>>
>>> *To:* mpeg-otspec <mpeg-otspec at lists.aau.at>
>>>
>>>
>>> *Subject:* [MPEG-OTSPEC] Proposal to discontinue the AdHoc Group
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hi,
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> I like to propose to the ISO WG overseeing this group to acknowledge
>>> that the AdHoc model has NOT worked for many in the industry and
>>> discontinue this model.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Vlad, can you please add this to agenda for the next meeting of the WG?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> behdad
>>>
>>>
>>> http://behdad.org/
>>> <https://protect-us.mimecast.com/s/LXgFC5yrxRh0ZjxYhzjORk/>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
> _______________________________________________
>
> 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/20200921/f3fd768b/attachment-0001.html>
More information about the mpeg-otspec
mailing list