[MPEG-OTSPEC] kanou's proposal to resolve 64k GID issue without introduction of 24-bit GID.

[suzuki toshiya]

Dear Ken,

Thanks, I had almost same impression.

However, some experts in this list want to
discuss in GitHub repository, not in here.

kanou-san, if you post something in there,
please inform. I (and maybe Ken) would go
to there for further discussion.

Regards,
mpsuzuki

On 2023/07/14 21:42, Ken Lunde wrote:
> And, of course, CFR is explicitly mentioned in the proposal.
> 
>> On Jul 14, 2023, at 05:35, Ken Lunde <lunde at unicode.org> wrote:
>>
>> Suzuki-san and others,
>>
>> This sounds a lot like ISO/IEC 14496-28 (aka Composite Font Representation), but instead of explicit deploying XML that describes how the component fonts function together, their relationship is implicit in the naming of the component fonts. This ISO standard is among those that are freely available:
>>
>> http://standards.iso.org/ittf/PubliclyAvailableStandards/
>>
>> This group developed that standard over 10 years ago, which was published in 2012, and for which Technical Corrigendums were published in 2013 and 2014.
>>
>> Regards...
>>
>> -- Ken
>>
>>> On Jul 13, 2023, at 22:29, suzuki toshiya <mpsuzuki at hiroshima-u.ac.jp> wrote:
>>>
>>> Dear Kanou-san,
>>>
>>> I'm interested in the CITPC's evaluation of your proposal.
>>>
>>> My understanding of your proposal is something like below;
>>>
>>> * Propose no change in the file format itself.
>>> * Propose the "better" behavior of the text input method
>>> software about the font fallback mechanisms.
>>> * Propose the convention(?) to design a TTC/OTC to help
>>> the "better" font fallback mechanism.
>>>
>>> If I'm misunderstanding, please correct me.
>>>
>>> --
>>>
>>> I want to know more about the assumed software which should
>>> be modified to support your proposal. I guess your motivation
>>> is that "even if new font format supporting 24-bit gid is
>>> agreed and amended to the future version of 14496-22,
>>> there might be some delay of the major software to catch it
>>> up, therefore, some alternative is expected for the software
>>> without the support for new font file format".
>>>
>>> But, for the software, which is hard to catch up with the
>>> new spec, is it easy for them to catch up with your proposal?
>>>
>>> Regards,
>>> mpsuzuki
>>>
>>> On 2023/07/05 19:34, kanou wrote:
>>>> Dear Sir,
>>>> I welcome the proposal of >64K expansion in Boring Expansion proposal as an engineer
>>>> of a Japanese font vender, but I need a quick and backward-compatible solution for my friends
>>>> working on Chinese classics and handling >64K text every day.
>>>> I propose a temporary solution that a font collection file including fonts with names like
>>>> BaseFontName#1
>>>> BaseFontName#2
>>>> ...
>>>> which shares the common base font name and each font in the collection has numbered suffix
>>>> can be treated as if there is a single font file named BaseFontName and application programs
>>>> aware of this convention can display a single BaseFontName instead of suffixed font names.
>>>> The full text of my proposal is here:
>>>> https://1drv.ms/b/s!AmmL2QlEO2bqgRnSjsUQM1vhjKcY?e=ylfh3J
>>>> Regards,
>>>> --
>>>> Hiroki Kanou <kanou at iwatafont.co.jp<mailto:kanou at iwatafont.co.jp>>
>>>> Iwata Corporation
>>> _______________________________________________
>>> mpeg-otspec mailing list
>>> mpeg-otspec at lists.aau.at
>>> https://lists.aau.at/mailman/listinfo/mpeg-otspec
>>
>