[MPEG-OTSPEC] Removal of the CFF and CF2 from OFF standard (was: Proposal to make OFF complete)
Behdad Esfahbod
behdad at behdad.org
Thu Oct 8 17:57:23 CEST 2020
You seem more focused on objecting than to reason about my proposal or why
your objection is legitimate. You did NOT even reply to the main issue:
> Sooooooo either CFF/CFF2 should be removed, *or* it be added as a work
item that CFF/CFF2 hinting be documented as part of OFF.
> Separately part of the same proposal was to document script-shaping as
part of OFF; so I expect that to be added as a new work item proposal as
well.
behdad
http://behdad.org/
On Wed, Oct 7, 2020 at 5:13 PM Dave Crossland <dcrossland at google.com> wrote:
>
>
> On Wed, Oct 7, 2020, 6:55 PM Behdad Esfahbod <behdad at behdad.org> wrote:
>
>> On Wed, Oct 7, 2020 at 4:48 PM Dave Crossland <dcrossland at google.com>
>> wrote:
>>
>>> On Wed, Oct 7, 2020 at 6:45 PM Behdad Esfahbod <behdad at behdad.org>
>>> wrote:
>>>
>>>> On Wed, Oct 7, 2020 at 4:37 PM Dave Crossland <dcrossland at google.com>
>>>> wrote:
>>>>
>>>>> On Wed, Oct 7, 2020 at 5:51 PM Behdad Esfahbod <behdad at behdad.org>
>>>>> wrote:
>>>>>
>>>>>> On Wed, Oct 7, 2020 at 3:35 PM Levantovsky, Vladimir <
>>>>>> Vladimir.Levantovsky at monotype.com> wrote:
>>>>>>
>>>>>>> On Wednesday, August 19, 2020 12:40 AM Behdad Esfahbod wrote:
>>>>>>>
>>>>>>> Moreover, I suggest CFF and CFF2 be removed from OFF. The
>>>>>>> claim-to-superiority of CFF format is: 1. better hinting, and 2. better
>>>>>>> compression. Re better-hinting, the interpretation of CFF hints is NOT
>>>>>>> specified anywhere. Adobe's code in FreeType is what we have. Re better
>>>>>>> compression, the existence of CFF in OpenType / OFF is partly why adding
>>>>>>> quadratic beziers to glyf table has continually not happened.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> In reality, CFF only serves Adobe, who sells their rasterizer to MS
>>>>>>> / Apple platforms and serves only Adobe. Another example of Adobe abusing
>>>>>>> the "open" ideology / terminology is the Noto CJK / Adobe-equivalent. It's
>>>>>>> NOT open-source by any means. The sources are not available. That's
>>>>>>> something that I pointed out directly to Ken Lunde at one of his Unicode
>>>>>>> Conference presentations. Adobe is clearly aware of it. And I couldn't fix
>>>>>>> when I was at Google.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Rip the bandaid. Make open standards truly open.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> With my SC29/WG3 member representative hat on (and _*not*_ serving
>>>>>>> in my capacity as a chair of this AHG) I object to this proposal. With many
>>>>>>> thousands of fonts currently deployed, and at least two (or more) different
>>>>>>> implementations available – this proposal, if considered, would do more
>>>>>>> harm than good.
>>>>>>>
>>>>>>
>>>>>> Okay let me narrow down the proposal to removing CFF2 only.
>>>>>>
>>>>>
>>>>> I object to the proposal to remove CFF2, because while few CFF2 VF
>>>>> fonts are available, CFF2 is now widely implemented by font engines
>>>>>
>>>>
>>>> It's in OpenType. I don't see why it needs to be in OFF from a
>>>> forward-looking point of view.
>>>>
>>>
>>> CFF2 needs to be in OFF because then it is definitively clear of
>>> rightholder friction, allowing it to be widely adopted.
>>>
>>
>> No one has suggested *why* it needs to be widely adopted. You can't just
>> say "no". I argued that OFF is *incomplete* currently.
>>
>
> Vlad brought up the counter argument that much existing usage depends on
> CFF being in OFF. You accepted this but then argue that not many cff2 fonts
> exist compared to cff1, or to TTF VF. But I don't think this is relevant,
> because fonts themselves are only one piece of the puzzle.
>
> Sooooooo either CFF/CFF2 should be removed, *or* it be added as a work
>> item that CFF/CFF2 hinting be documented as part of OFF.
>>
>> Separately part of the same proposal was to document script-shaping as
>> part of OFF; so I expect that to be added as a new work item proposal as
>> well.
>>
>>
>>> The many users of harfbuzz, that you tout, are doing so because OFF has
>>> cleared a path for that adoption.
>>>
>>
>> I don't see how that argument holds. HarfBuzz implements ...
>>
>
> It's an argument about adoption, not implementation.
>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20201008/792f5d85/attachment.html>
More information about the mpeg-otspec
mailing list