From vladimir.levantovsky at gmail.com  Wed Sep 11 19:04:25 2024
From: vladimir.levantovsky at gmail.com (Vladimir Levantovsky)
Date: Wed, 11 Sep 2024 13:04:25 -0400
Subject: [MPEG-OTSPEC] Text of ISO/IEC 14496-22/CD is now available for
 review
In-Reply-To: <CACJZqjAMUbpkyTy5rh7eip5e8o1TB7TXchp4KBf0UaUqy0FJmQ@mail.gmail.com>
References: <CACJZqjBD-CXvEQLbb4uRi+2dNgpiaDKxX1wjpyQ8L+OP_OBT4g@mail.gmail.com>
 <CACJZqjA18xjoR9RJixOQwPAwRO9bdJOdtSaBQXWZTAs7PdSoOA@mail.gmail.com>
 <CALvn5EDGB70Coxe6pcyPuux9fAXnxErdyJO2nNMjHj32-=85qQ@mail.gmail.com>
 <CACJZqjAMUbpkyTy5rh7eip5e8o1TB7TXchp4KBf0UaUqy0FJmQ@mail.gmail.com>
Message-ID: <CACJZqjBwtuCmMdM=ku6G-EOxSEpr_s5aM0N77PSk0ncyR5gQyA@mail.gmail.com>

Dear all,

This email is just a friendly reminder that the text of the ISO/IEC
14496-22/CD (5th ed.) is currently under ballot and would benefit from your
review / comments The official ISO deadline for NB comments submission is
Oct. 29, 2024, but individual National Bodies can establish their own
earlier deadlines to allow time for comments collection/approval and
submission.
You do not have to bring your comments up for AHG discussion and can submit
them directly, but, as our prior collective experience demonstrates, open
discussion of issues found with the spec (which is provisioned by our only
AHG mandate for this period) is to our collective benefit.

Thank you,
Vladimir


On Thu, Aug 15, 2024 at 10:19?PM Vladimir Levantovsky <
vladimir.levantovsky at gmail.com> wrote:

> Apologies for a delayed reply.
> The consultation period started on Aug. 7th, and the ISO SC29 due date for
> comments is Oct. 29, 2024. National Bodies may impose their own earlier
> deadlines to accommodate comments approval and submission process time (for
> example, the USNB deadline is Oct. 15).
>
> Vladimir
>
>
> On Tue, Aug 6, 2024 at 2:38?AM MURATA <eb2mmrt at gmail.com> wrote:
>
>> Vladimir,
>>
>> Thanks for the reminder.  When did the CD consultation start and when
>> will it be closed?
>>
>> Regards,
>> Makoto
>>
>> 2024?8?6?(?) 1:35 Vladimir Levantovsky via mpeg-otspec <
>> mpeg-otspec at lists.aau.at>:
>>
>>> Dear all,
>>>
>>> This is just a nudge and gentle reminder that the opportunity to submit
>>> ballot comments is time-limited - please make sure to review the CD text
>>> and submit your comments (sooner is better!) using the template I shared
>>> with you in my previous email.
>>>
>>> Thank you,
>>> Vladimir
>>>
>>>
>>> On Thu, Jul 11, 2024 at 4:09?PM Vladimir Levantovsky <
>>> vladimir.levantovsky at gmail.com> wrote:
>>>
>>>> Dear all,
>>>>
>>>> The text of the Committee Draft of the 5th edition ISO/IEC 14496-22/CD
>>>> "Open Font Format" is now available for download and review:
>>>>
>>>> https://www.mpeg.org/wp-content/uploads/mpeg_meetings/146_Rennes/w23797.zip
>>>>
>>>> Once the ballot is open, any changes you wish to make in the current
>>>> text need to be submitted via your respective National Bodies as comments,
>>>> using the following ISO commenting template
>>>> <https://www.iso.org/resources/publicly-available-resources.html?t=MGTmD5TwK496A_y6JsbrKdnDBmIZ6L0rvjNNXYvKmXhIpfLuCJx5JQWQqL5GcGPw&view=documents#section-isodocuments-top>.
>>>> The CD text is available for download as both "tracked changes" and "clean"
>>>> versions - when submitting comments, please reference the clean version of
>>>> the text for clarity and correct page number references.
>>>>
>>>> Please note that if the proposed change requires a substantial amount
>>>> of text to be replaced, it is allowed to submit a comment referencing a
>>>> future input contribution document with detailed proposed changes. Any such
>>>> document would have to be registered and uploaded in advance - to reserve
>>>> the document number and provide comments prior to ballot closing date
>>>> (which is yet to be announced).
>>>> Please also note that different National Bodies have their own
>>>> additional processes for comments submission and may impose earlier
>>>> deadlines than the ballot closing date.
>>>>
>>>> Thank you for your contributions and hard work!
>>>> Vladimir
>>>>
>>>>
>>> _______________________________________________
>>> 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/20240911/1f344bc2/attachment.htm>

From liam at fromoldbooks.org  Wed Sep 11 19:22:35 2024
From: liam at fromoldbooks.org (Liam R. E. Quin)
Date: Wed, 11 Sep 2024 13:22:35 -0400
Subject: [MPEG-OTSPEC] Text of ISO/IEC 14496-22/CD is now available for
 review
In-Reply-To: <CACJZqjBwtuCmMdM=ku6G-EOxSEpr_s5aM0N77PSk0ncyR5gQyA@mail.gmail.com>
References: <CACJZqjBD-CXvEQLbb4uRi+2dNgpiaDKxX1wjpyQ8L+OP_OBT4g@mail.gmail.com>
 <CACJZqjA18xjoR9RJixOQwPAwRO9bdJOdtSaBQXWZTAs7PdSoOA@mail.gmail.com>
 <CALvn5EDGB70Coxe6pcyPuux9fAXnxErdyJO2nNMjHj32-=85qQ@mail.gmail.com>
 <CACJZqjAMUbpkyTy5rh7eip5e8o1TB7TXchp4KBf0UaUqy0FJmQ@mail.gmail.com>
 <CACJZqjBwtuCmMdM=ku6G-EOxSEpr_s5aM0N77PSk0ncyR5gQyA@mail.gmail.com>
Message-ID: <c6d8b909f9a542eaa89f79e19b4bfa4e7438db65.camel@fromoldbooks.org>

On Wed, 2024-09-11 at 13:04 -0400, Vladimir Levantovsky via mpeg-otspec
wrote:
> Dear all,
> 
> This email is just a friendly reminder that the text of the ISO/IEC
> 14496-22/CD (5th ed.) is currently under ballot and would benefit
> from your review / comments

Just a note that i did submit some editorial comments to the Candian
?mirror committee? for this work; in theory i?m a member but there seem
to be some technical problems with access. The comments were received
by the chair, though. In theory they are public, but i can't get to the
Web site hosting them.

I?ve enclosed them here; a small missing table (oops, probably my
fault), a small new table to avoid an overflow, some minor renamings
and stuff.

liam


-- 
Liam Quin,?https://www.delightfulcomputing.com/
Available for XML/Document/Information Architecture/XSLT/
XSL/XQuery/Web/Text Processing/A11Y training, work & consulting.
Barefoot Web-slave, antique illustrations: ?http://www.fromoldbooks.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240911/09be246f/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Comments.pdf
Type: application/pdf
Size: 102379 bytes
Desc: not available
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240911/09be246f/attachment-0001.pdf>

From eb2mmrt at gmail.com  Sun Sep 15 04:56:56 2024
From: eb2mmrt at gmail.com (MURATA)
Date: Sun, 15 Sep 2024 11:56:56 +0900
Subject: [MPEG-OTSPEC] Proposed Adoption of the Online Standards Development
 Platform
Message-ID: <CALvn5ECOAG9RCT2zS21wN1a_9vdswxsRUDq9TWyhH3a22Ftk3A@mail.gmail.com>

Dear colleagues,

I would like to propose that we transition from using Word to the Online
Standards Development (OSD) platform provided by ISO and IEC.

For more information, please visit:
https://www.iso.org/OSD

Several projects, such as the upcoming version of Schematron (ISO/IEC
19757-3), have successfully adopted the OSD platform and are finding it
highly effective.

While some may suggest that we continue using Word, generating PDF
documents, and submitting them to the ISO Central Secretariat (ISO/CS), it
is my understanding that ISO/CS is increasingly reluctant to accept PDF
submissions.

In exceptional cases, such as with ISO/IEC 29500-1 (a document nearly 4000
pages long), there may be valid reasons to persuade ISO/CS to accept PDFs.
The sheer size of such documents can overwhelm their current toolchain
(eXtyles and Typefi), which struggles with large files. However, unless we
have a similarly compelling reason, ISO/CS is likely to refuse any PDF
submissions and decline to publish standards.

Another option is to submit Word files and request ISO/CS to generate PDFs.
However, this approach has led to numerous issues, with project editors
frequently encountering significant discrepancies between their expected
layouts and the final PDFs generated by ISO/CS. Many editors within JTC1
have shared frustrating experiences due to these problems.

ISO/CS does not directly convert Word documents into PDFs. Instead, they
transform Word files into STS (XML) format, which discards much of the
original formatting. They then generate PDFs from these STS documents. I?ve
attached a diagram illustrating this process, which is based on discussions
with an ISO/CS Editorial Program Manager.

I understand any hesitation about this transition, but I have not heard of
any serious complaints regarding the OSD platform.
Regards,
Makoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240915/1043be6a/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Toolchain (1).png
Type: image/png
Size: 13364 bytes
Desc: not available
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240915/1043be6a/attachment.png>

From eb2mmrt at gmail.com  Sun Sep 15 07:29:52 2024
From: eb2mmrt at gmail.com (MURATA)
Date: Sun, 15 Sep 2024 14:29:52 +0900
Subject: [MPEG-OTSPEC] Proposed Adoption of the Online Standards
 Development Platform
In-Reply-To: <CALvn5ECOAG9RCT2zS21wN1a_9vdswxsRUDq9TWyhH3a22Ftk3A@mail.gmail.com>
References: <CALvn5ECOAG9RCT2zS21wN1a_9vdswxsRUDq9TWyhH3a22Ftk3A@mail.gmail.com>
Message-ID: <CALvn5EBMd3RUPc+7VbvrirBLh3-r86XdXLrA924NJKiOM=k2Mw@mail.gmail.com>

The latest CD has 1000 pages.  Can the toolchain of ISO/CS handle 1000
pages?  We should ask them.  If it cannot, they might be willing to accept
a Word document and a PDF.

Regards,
Makoto

2024?9?15?(?) 11:56 MURATA <eb2mmrt at gmail.com>:

> Dear colleagues,
>
> I would like to propose that we transition from using Word to the Online
> Standards Development (OSD) platform provided by ISO and IEC.
>
> For more information, please visit:
> https://www.iso.org/OSD
>
> Several projects, such as the upcoming version of Schematron (ISO/IEC
> 19757-3), have successfully adopted the OSD platform and are finding it
> highly effective.
>
> While some may suggest that we continue using Word, generating PDF
> documents, and submitting them to the ISO Central Secretariat (ISO/CS), it
> is my understanding that ISO/CS is increasingly reluctant to accept PDF
> submissions.
>
> In exceptional cases, such as with ISO/IEC 29500-1 (a document nearly 4000
> pages long), there may be valid reasons to persuade ISO/CS to accept PDFs.
> The sheer size of such documents can overwhelm their current toolchain
> (eXtyles and Typefi), which struggles with large files. However, unless we
> have a similarly compelling reason, ISO/CS is likely to refuse any PDF
> submissions and decline to publish standards.
>
> Another option is to submit Word files and request ISO/CS to generate
> PDFs. However, this approach has led to numerous issues, with project
> editors frequently encountering significant discrepancies between their
> expected layouts and the final PDFs generated by ISO/CS. Many editors
> within JTC1 have shared frustrating experiences due to these problems.
>
> ISO/CS does not directly convert Word documents into PDFs. Instead, they
> transform Word files into STS (XML) format, which discards much of the
> original formatting. They then generate PDFs from these STS documents. I?ve
> attached a diagram illustrating this process, which is based on discussions
> with an ISO/CS Editorial Program Manager.
>
> I understand any hesitation about this transition, but I have not heard of
> any serious complaints regarding the OSD platform.
> Regards,
> Makoto
>


-- 
 --
????????????????????
?? ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240915/8150a5b0/attachment-0001.htm>

From lunde at unicode.org  Mon Sep 16 05:23:38 2024
From: lunde at unicode.org (Ken Lunde)
Date: Sun, 15 Sep 2024 20:23:38 -0700
Subject: [MPEG-OTSPEC] Proposed Adoption of the Online Standards
 Development Platform
In-Reply-To: <CALvn5EBMd3RUPc+7VbvrirBLh3-r86XdXLrA924NJKiOM=k2Mw@mail.gmail.com>
References: <CALvn5ECOAG9RCT2zS21wN1a_9vdswxsRUDq9TWyhH3a22Ftk3A@mail.gmail.com>
 <CALvn5EBMd3RUPc+7VbvrirBLh3-r86XdXLrA924NJKiOM=k2Mw@mail.gmail.com>
Message-ID: <3769D020-4534-41CE-91C3-798E61FA427A@unicode.org>

Murata-san,

Another consideration is the extent to which the toolchain of ISO/CS can handle characters outside of basic Latin. I suspect that it cannot handle arbitrary characters in the ISO/IEC 10646 standard, and as of Unicode Version 16.0 that was released less than a week ago, there are now 154,998 characters. While I cannot speak about MS Word, mainly because I use the app only when necessary, PDF has an advantage in that it can embed the glyphs from the fonts that are referenced in the authoring app.

Regards...

-- Ken

> On Sep 14, 2024, at 22:29, MURATA via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:
> 
> The latest CD has 1000 pages.  Can the toolchain of ISO/CS handle 1000 pages?  We should ask them.  If it cannot, they might be willing to accept a Word document and a PDF.
> 
> Regards,
> Makoto 
> 
> 2024?9?15?(?) 11:56 MURATA <eb2mmrt at gmail.com>:
> Dear colleagues,
> I would like to propose that we transition from using Word to the Online Standards Development (OSD) platform provided by ISO and IEC.
> For more information, please visit:
> https://www.iso.org/OSD
> Several projects, such as the upcoming version of Schematron (ISO/IEC 19757-3), have successfully adopted the OSD platform and are finding it highly effective.
> While some may suggest that we continue using Word, generating PDF documents, and submitting them to the ISO Central Secretariat (ISO/CS), it is my understanding that ISO/CS is increasingly reluctant to accept PDF submissions.
> In exceptional cases, such as with ISO/IEC 29500-1 (a document nearly 4000 pages long), there may be valid reasons to persuade ISO/CS to accept PDFs. The sheer size of such documents can overwhelm their current toolchain (eXtyles and Typefi), which struggles with large files. However, unless we have a similarly compelling reason, ISO/CS is likely to refuse any PDF submissions and decline to publish standards.
> Another option is to submit Word files and request ISO/CS to generate PDFs. However, this approach has led to numerous issues, with project editors frequently encountering significant discrepancies between their expected layouts and the final PDFs generated by ISO/CS. Many editors within JTC1 have shared frustrating experiences due to these problems.
> ISO/CS does not directly convert Word documents into PDFs. Instead, they transform Word files into STS (XML) format, which discards much of the original formatting. They then generate PDFs from these STS documents. I?ve attached a diagram illustrating this process, which is based on discussions with an ISO/CS Editorial Program Manager.
> I understand any hesitation about this transition, but I have not heard of any serious complaints regarding the OSD platform.
> Regards,
> Makoto
> 
> 
> -- 
>  --
> ????????????????????
> ????
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec



From eb2mmrt at gmail.com  Mon Sep 16 06:59:55 2024
From: eb2mmrt at gmail.com (MURATA)
Date: Mon, 16 Sep 2024 13:59:55 +0900
Subject: [MPEG-OTSPEC] Proposed Adoption of the Online Standards
 Development Platform
In-Reply-To: <3769D020-4534-41CE-91C3-798E61FA427A@unicode.org>
References: <CALvn5ECOAG9RCT2zS21wN1a_9vdswxsRUDq9TWyhH3a22Ftk3A@mail.gmail.com>
 <CALvn5EBMd3RUPc+7VbvrirBLh3-r86XdXLrA924NJKiOM=k2Mw@mail.gmail.com>
 <3769D020-4534-41CE-91C3-798E61FA427A@unicode.org>
Message-ID: <CALvn5EBswhhSgOUNt_DaEdNc8owj1zHjcVqiDXduZaKC3gm2fg@mail.gmail.com>

Ken,

Are such characters used in the CD?

regards,
Makoto


2024?9?16?(?) 12:23 Ken Lunde <lunde at unicode.org>:

> Murata-san,
>
> Another consideration is the extent to which the toolchain of ISO/CS can
> handle characters outside of basic Latin. I suspect that it cannot handle
> arbitrary characters in the ISO/IEC 10646 standard, and as of Unicode
> Version 16.0 that was released less than a week ago, there are now 154,998
> characters. While I cannot speak about MS Word, mainly because I use the
> app only when necessary, PDF has an advantage in that it can embed the
> glyphs from the fonts that are referenced in the authoring app.
>
> Regards...
>
> -- Ken
>
> > On Sep 14, 2024, at 22:29, MURATA via mpeg-otspec <
> mpeg-otspec at lists.aau.at> wrote:
> >
> > The latest CD has 1000 pages.  Can the toolchain of ISO/CS handle 1000
> pages?  We should ask them.  If it cannot, they might be willing to accept
> a Word document and a PDF.
> >
> > Regards,
> > Makoto
> >
> > 2024?9?15?(?) 11:56 MURATA <eb2mmrt at gmail.com>:
> > Dear colleagues,
> > I would like to propose that we transition from using Word to the Online
> Standards Development (OSD) platform provided by ISO and IEC.
> > For more information, please visit:
> > https://www.iso.org/OSD
> > Several projects, such as the upcoming version of Schematron (ISO/IEC
> 19757-3), have successfully adopted the OSD platform and are finding it
> highly effective.
> > While some may suggest that we continue using Word, generating PDF
> documents, and submitting them to the ISO Central Secretariat (ISO/CS), it
> is my understanding that ISO/CS is increasingly reluctant to accept PDF
> submissions.
> > In exceptional cases, such as with ISO/IEC 29500-1 (a document nearly
> 4000 pages long), there may be valid reasons to persuade ISO/CS to accept
> PDFs. The sheer size of such documents can overwhelm their current
> toolchain (eXtyles and Typefi), which struggles with large files. However,
> unless we have a similarly compelling reason, ISO/CS is likely to refuse
> any PDF submissions and decline to publish standards.
> > Another option is to submit Word files and request ISO/CS to generate
> PDFs. However, this approach has led to numerous issues, with project
> editors frequently encountering significant discrepancies between their
> expected layouts and the final PDFs generated by ISO/CS. Many editors
> within JTC1 have shared frustrating experiences due to these problems.
> > ISO/CS does not directly convert Word documents into PDFs. Instead, they
> transform Word files into STS (XML) format, which discards much of the
> original formatting. They then generate PDFs from these STS documents. I?ve
> attached a diagram illustrating this process, which is based on discussions
> with an ISO/CS Editorial Program Manager.
> > I understand any hesitation about this transition, but I have not heard
> of any serious complaints regarding the OSD platform.
> > Regards,
> > Makoto
> >
> >
> > --
> >  --
> > ????????????????????
> > ?? ?
> > _______________________________________________
> > 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/20240916/ad50c702/attachment.htm>

From lunde at unicode.org  Mon Sep 16 14:19:32 2024
From: lunde at unicode.org (Ken Lunde)
Date: Mon, 16 Sep 2024 05:19:32 -0700
Subject: [MPEG-OTSPEC] Proposed Adoption of the Online Standards
 Development Platform
In-Reply-To: <CALvn5EBswhhSgOUNt_DaEdNc8owj1zHjcVqiDXduZaKC3gm2fg@mail.gmail.com>
References: <CALvn5ECOAG9RCT2zS21wN1a_9vdswxsRUDq9TWyhH3a22Ftk3A@mail.gmail.com>
 <CALvn5EBMd3RUPc+7VbvrirBLh3-r86XdXLrA924NJKiOM=k2Mw@mail.gmail.com>
 <3769D020-4534-41CE-91C3-798E61FA427A@unicode.org>
 <CALvn5EBswhhSgOUNt_DaEdNc8owj1zHjcVqiDXduZaKC3gm2fg@mail.gmail.com>
Message-ID: <EE816C23-BB9E-40FD-8C38-ED6D64CC3A8F@unicode.org>

Murata-san,

Yes, in some of the descriptions of layout features, such as for 'vchw' and 'vert'. In other parts of the document, such characters are images in figures.

Regards...

-- Ken

> On Sep 15, 2024, at 21:59, MURATA <eb2mmrt at gmail.com> wrote:
> 
> Ken,
> 
> Are such characters used in the CD?  
> 
> regards,
> Makoto
> 
> 
> 2024?9?16?(?) 12:23 Ken Lunde <lunde at unicode.org>:
> Murata-san,
> 
> Another consideration is the extent to which the toolchain of ISO/CS can handle characters outside of basic Latin. I suspect that it cannot handle arbitrary characters in the ISO/IEC 10646 standard, and as of Unicode Version 16.0 that was released less than a week ago, there are now 154,998 characters. While I cannot speak about MS Word, mainly because I use the app only when necessary, PDF has an advantage in that it can embed the glyphs from the fonts that are referenced in the authoring app.
> 
> Regards...
> 
> -- Ken
> 
> > On Sep 14, 2024, at 22:29, MURATA via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:
> > 
> > The latest CD has 1000 pages.  Can the toolchain of ISO/CS handle 1000 pages?  We should ask them.  If it cannot, they might be willing to accept a Word document and a PDF.
> > 
> > Regards,
> > Makoto 
> > 
> > 2024?9?15?(?) 11:56 MURATA <eb2mmrt at gmail.com>:
> > Dear colleagues,
> > I would like to propose that we transition from using Word to the Online Standards Development (OSD) platform provided by ISO and IEC.
> > For more information, please visit:
> > https://www.iso.org/OSD
> > Several projects, such as the upcoming version of Schematron (ISO/IEC 19757-3), have successfully adopted the OSD platform and are finding it highly effective.
> > While some may suggest that we continue using Word, generating PDF documents, and submitting them to the ISO Central Secretariat (ISO/CS), it is my understanding that ISO/CS is increasingly reluctant to accept PDF submissions.
> > In exceptional cases, such as with ISO/IEC 29500-1 (a document nearly 4000 pages long), there may be valid reasons to persuade ISO/CS to accept PDFs. The sheer size of such documents can overwhelm their current toolchain (eXtyles and Typefi), which struggles with large files. However, unless we have a similarly compelling reason, ISO/CS is likely to refuse any PDF submissions and decline to publish standards.
> > Another option is to submit Word files and request ISO/CS to generate PDFs. However, this approach has led to numerous issues, with project editors frequently encountering significant discrepancies between their expected layouts and the final PDFs generated by ISO/CS. Many editors within JTC1 have shared frustrating experiences due to these problems.
> > ISO/CS does not directly convert Word documents into PDFs. Instead, they transform Word files into STS (XML) format, which discards much of the original formatting. They then generate PDFs from these STS documents. I?ve attached a diagram illustrating this process, which is based on discussions with an ISO/CS Editorial Program Manager.
> > I understand any hesitation about this transition, but I have not heard of any serious complaints regarding the OSD platform.
> > Regards,
> > Makoto
> > 
> > 
> > -- 
> >  --
> > ????????????????????
> > ????
> > _______________________________________________
> > mpeg-otspec mailing list
> > mpeg-otspec at lists.aau.at
> > https://lists.aau.at/mailman/listinfo/mpeg-otspec
> 
> 


From liam at fromoldbooks.org  Mon Sep 16 15:13:40 2024
From: liam at fromoldbooks.org (Liam R. E. Quin)
Date: Mon, 16 Sep 2024 09:13:40 -0400
Subject: [MPEG-OTSPEC] Proposed Adoption of the Online Standards
 Development Platform
In-Reply-To: <3769D020-4534-41CE-91C3-798E61FA427A@unicode.org>
References: <CALvn5ECOAG9RCT2zS21wN1a_9vdswxsRUDq9TWyhH3a22Ftk3A@mail.gmail.com>
 <CALvn5EBMd3RUPc+7VbvrirBLh3-r86XdXLrA924NJKiOM=k2Mw@mail.gmail.com>
 <3769D020-4534-41CE-91C3-798E61FA427A@unicode.org>
Message-ID: <b9a351d530060388cab1d78d7b80cdd064fdcfde.camel@fromoldbooks.org>

On Sun, 2024-09-15 at 20:23 -0700, Ken Lunde via mpeg-otspec wrote:
> Murata-san,
> 
> Another consideration is the extent to which the toolchain of ISO/CS
> can handle characters outside of basic Latin.?

I would expect it to be able to handle the needs of the Open Font
Format specification just fine.

They gave a talk on their new system at an XML confernce, i think maybe
Balisage last year.

Obviously it won't handle fonts with more than 65535 glyphs or using
avar2, but neither will Word right now :-)

Having said that, i don?t see a reason to switch when the document is
nearly ready to publish - it sounds like a lot of work for the editor
with unclear benefits and possible delays.

The new ISO system uses XML behind the scenes, and if they made XML
import available, it'd maybe be possible to use XSLT to take the Word
file and produce their XML, given a suitable blob of funding. Or they
may have a suitable Word input system working themselves. But even if
it?s entirely automated it would need a careful proofreading for sure.

For a future version of the document, starting out again as a draft, i
think it would make a lot of sense.

Kind regards,

liam

-- 
Liam Quin,?https://www.delightfulcomputing.com/
Available for XML/Document/Information Architecture/XSLT/
XSL/XQuery/Web/Text Processing/A11Y training, work & consulting.
Barefoot Web-slave, antique illustrations: ?http://www.fromoldbooks.org

From eb2mmrt at gmail.com  Mon Sep 16 15:20:05 2024
From: eb2mmrt at gmail.com (MURATA)
Date: Mon, 16 Sep 2024 22:20:05 +0900
Subject: [MPEG-OTSPEC] Proposed Adoption of the Online Standards
 Development Platform
In-Reply-To: <b9a351d530060388cab1d78d7b80cdd064fdcfde.camel@fromoldbooks.org>
References: <CALvn5ECOAG9RCT2zS21wN1a_9vdswxsRUDq9TWyhH3a22Ftk3A@mail.gmail.com>
 <CALvn5EBMd3RUPc+7VbvrirBLh3-r86XdXLrA924NJKiOM=k2Mw@mail.gmail.com>
 <3769D020-4534-41CE-91C3-798E61FA427A@unicode.org>
 <b9a351d530060388cab1d78d7b80cdd064fdcfde.camel@fromoldbooks.org>
Message-ID: <CALvn5ECYUdmVv92FD-XDUYZbSQFV4BHsdK-eD9Dzv1_588rY5g@mail.gmail.com>

> Having said that, i don?t see a reason to switch when the document is
> nearly ready to publish - it sounds like a lot of work for the editor
> with unclear benefits and possible delays.


Liam,

Yes, a lot of work will be needed.    I think that we should speak with
ISO/CS.  They make the call.

Regards,
Makoto



>
> The new ISO system uses XML behind the scenes, and if they made XML
> import available, it'd maybe be possible to use XSLT to take the Word
> file and produce their XML, given a suitable blob of funding. Or they
> may have a suitable Word input system working themselves. But even if
> it?s entirely automated it would need a careful proofreading for sure.
>
> For a future version of the document, starting out again as a draft, i
> think it would make a lot of sense.
>
> Kind regards,
>
> liam
>
> --
> Liam Quin, https://www.delightfulcomputing.com/
> Available for XML/Document/Information Architecture/XSLT/
> XSL/XQuery/Web/Text Processing/A11Y training, work & consulting.
> Barefoot Web-slave, antique illustrations:  http://www.fromoldbooks.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240916/8bb0f6bc/attachment.htm>

From htl10 at users.sourceforge.net  Mon Sep 16 22:51:03 2024
From: htl10 at users.sourceforge.net (Hin-Tak Leung)
Date: Mon, 16 Sep 2024 20:51:03 +0000 (UTC)
Subject: [MPEG-OTSPEC] Proposed Adoption of the Online Standards
 Development Platform
In-Reply-To: <b9a351d530060388cab1d78d7b80cdd064fdcfde.camel@fromoldbooks.org>
References: <CALvn5ECOAG9RCT2zS21wN1a_9vdswxsRUDq9TWyhH3a22Ftk3A@mail.gmail.com>
 <CALvn5EBMd3RUPc+7VbvrirBLh3-r86XdXLrA924NJKiOM=k2Mw@mail.gmail.com>
 <3769D020-4534-41CE-91C3-798E61FA427A@unicode.org>
 <b9a351d530060388cab1d78d7b80cdd064fdcfde.camel@fromoldbooks.org>
Message-ID: <155552877.13108248.1726519863232@mail.yahoo.com>

 Hi Liam,

Currently, 
word -> (ISO process) -> iso's kind of XML

you are saying it may be possible to go via?

word -> (XSLT) -> iso's kind of XML

I suppose if you are talking about docx (which is xml-based), that's true... ideally we might want to do the reverse:

iso's kind of XML -> (XSLT) -> docx 

and work directly with the iso XML for diffs and updates, and use word docx as a "preview" / read-only format...

Just a thought. Is the "iso's kind of XML" version of the spec available anywhere?

Regards,
Hin-Tak
     On Monday 16 September 2024 at 14:14:01 BST, Liam R. E. Quin via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:  
 
 On Sun, 2024-09-15 at 20:23 -0700, Ken Lunde via mpeg-otspec wrote:
> Murata-san,
> 
> Another consideration is the extent to which the toolchain of ISO/CS
> can handle characters outside of basic Latin.?

I would expect it to be able to handle the needs of the Open Font
Format specification just fine.

They gave a talk on their new system at an XML confernce, i think maybe
Balisage last year.

Obviously it won't handle fonts with more than 65535 glyphs or using
avar2, but neither will Word right now :-)

Having said that, i don?t see a reason to switch when the document is
nearly ready to publish - it sounds like a lot of work for the editor
with unclear benefits and possible delays.

The new ISO system uses XML behind the scenes, and if they made XML
import available, it'd maybe be possible to use XSLT to take the Word
file and produce their XML, given a suitable blob of funding. Or they
may have a suitable Word input system working themselves. But even if
it?s entirely automated it would need a careful proofreading for sure.

For a future version of the document, starting out again as a draft, i
think it would make a lot of sense.

Kind regards,

liam

-- 
Liam Quin,?https://www.delightfulcomputing.com/
Available for XML/Document/Information Architecture/XSLT/
XSL/XQuery/Web/Text Processing/A11Y training, work & consulting.
Barefoot Web-slave, antique illustrations: ?http://www.fromoldbooks.org
_______________________________________________
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/20240916/45b63577/attachment.htm>

From liam at fromoldbooks.org  Mon Sep 16 23:53:28 2024
From: liam at fromoldbooks.org (Liam R. E. Quin)
Date: Mon, 16 Sep 2024 17:53:28 -0400
Subject: [MPEG-OTSPEC] Proposed Adoption of the Online Standards
 Development Platform
In-Reply-To: <155552877.13108248.1726519863232@mail.yahoo.com>
References: <CALvn5ECOAG9RCT2zS21wN1a_9vdswxsRUDq9TWyhH3a22Ftk3A@mail.gmail.com>
 <CALvn5EBMd3RUPc+7VbvrirBLh3-r86XdXLrA924NJKiOM=k2Mw@mail.gmail.com>
 <3769D020-4534-41CE-91C3-798E61FA427A@unicode.org>
 <b9a351d530060388cab1d78d7b80cdd064fdcfde.camel@fromoldbooks.org>
 <155552877.13108248.1726519863232@mail.yahoo.com>
Message-ID: <65ef573a13d15cf5690582847aed8f67475a8833.camel@fromoldbooks.org>

On Mon, 2024-09-16 at 20:51 +0000, Hin-Tak Leung wrote:
> ????????????????Hi Liam,
> 
> Currently, 
> word -> (ISO process) -> iso's kind of XML
> 
> you are saying it may be possible to go via?
> 
> word -> (XSLT) -> iso's kind of XML

Yes - which is probably what ISO do internally.

> 
> Just a thought. Is the "iso's kind of XML" version of the spec
> available anywhere?

It?s a (rather large) ISO standard.

LibreOffice (and OpenOffice before it) uses a competing standard, which
was done at Oasis Open, and is simpler.

There?s XSLT stylesheets floating around to work with these formats.
And i write and teach and maintain XSLT for a living when not editing
font spec proposals :-)

Best,

liam

-- 
Liam Quin,?https://www.delightfulcomputing.com/
Available for XML/Document/Information Architecture/XSLT/
XSL/XQuery/Web/Text Processing/A11Y training, work & consulting.
Barefoot Web-slave, antique illustrations: ?http://www.fromoldbooks.org

From eb2mmrt at gmail.com  Tue Sep 17 02:02:09 2024
From: eb2mmrt at gmail.com (MURATA)
Date: Tue, 17 Sep 2024 09:02:09 +0900
Subject: [MPEG-OTSPEC] Proposed Adoption of the Online Standards
 Development Platform
In-Reply-To: <155552877.13108248.1726519863232@mail.yahoo.com>
References: <CALvn5ECOAG9RCT2zS21wN1a_9vdswxsRUDq9TWyhH3a22Ftk3A@mail.gmail.com>
 <CALvn5EBMd3RUPc+7VbvrirBLh3-r86XdXLrA924NJKiOM=k2Mw@mail.gmail.com>
 <3769D020-4534-41CE-91C3-798E61FA427A@unicode.org>
 <b9a351d530060388cab1d78d7b80cdd064fdcfde.camel@fromoldbooks.org>
 <155552877.13108248.1726519863232@mail.yahoo.com>
Message-ID: <CALvn5EC17PwqyFmb73=t+TQsVdvoBiqMAHySNyJMfs5BjgBxKw@mail.gmail.com>

>
>
>
>
> Just a thought. Is the "iso's kind of XML" version of the spec available
> anywhere?
>

STS. See https://www.niso.org/standards-committees/sts

Internally, they use neither OOXML nor ODF.  They convert Word to STS using
eXtyles.

Regards,
Makoto


>
> Regards,
> Hin-Tak
> On Monday 16 September 2024 at 14:14:01 BST, Liam R. E. Quin via
> mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:
>
>
> On Sun, 2024-09-15 at 20:23 -0700, Ken Lunde via mpeg-otspec wrote:
> > Murata-san,
> >
> > Another consideration is the extent to which the toolchain of ISO/CS
> > can handle characters outside of basic Latin.
>
> I would expect it to be able to handle the needs of the Open Font
> Format specification just fine.
>
> They gave a talk on their new system at an XML confernce, i think maybe
> Balisage last year.
>
> Obviously it won't handle fonts with more than 65535 glyphs or using
> avar2, but neither will Word right now :-)
>
> Having said that, i don?t see a reason to switch when the document is
> nearly ready to publish - it sounds like a lot of work for the editor
> with unclear benefits and possible delays.
>
> The new ISO system uses XML behind the scenes, and if they made XML
> import available, it'd maybe be possible to use XSLT to take the Word
> file and produce their XML, given a suitable blob of funding. Or they
> may have a suitable Word input system working themselves. But even if
> it?s entirely automated it would need a careful proofreading for sure.
>
> For a future version of the document, starting out again as a draft, i
> think it would make a lot of sense.
>
> Kind regards,
>
> liam
>
> --
> Liam Quin, https://www.delightfulcomputing.com/
> Available for XML/Document/Information Architecture/XSLT/
> XSL/XQuery/Web/Text Processing/A11Y training, work & consulting.
> Barefoot Web-slave, antique illustrations:  http://www.fromoldbooks.org
>
> _______________________________________________
> 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/20240917/886f1388/attachment-0001.htm>

From vladimir.levantovsky at gmail.com  Tue Sep 17 03:42:30 2024
From: vladimir.levantovsky at gmail.com (Vladimir Levantovsky)
Date: Mon, 16 Sep 2024 21:42:30 -0400
Subject: [MPEG-OTSPEC] Proposed Adoption of the Online Standards
 Development Platform
In-Reply-To: <CALvn5EC17PwqyFmb73=t+TQsVdvoBiqMAHySNyJMfs5BjgBxKw@mail.gmail.com>
References: <CALvn5EC17PwqyFmb73=t+TQsVdvoBiqMAHySNyJMfs5BjgBxKw@mail.gmail.com>
Message-ID: <4009183A-8190-469F-9AC3-5A0A3ED7CE70@gmail.com>

An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240916/689e77c6/attachment.htm>

From eb2mmrt at gmail.com  Tue Sep 17 06:50:46 2024
From: eb2mmrt at gmail.com (MURATA)
Date: Tue, 17 Sep 2024 13:50:46 +0900
Subject: [MPEG-OTSPEC] Proposed Adoption of the Online Standards
 Development Platform
In-Reply-To: <4009183A-8190-469F-9AC3-5A0A3ED7CE70@gmail.com>
References: <CALvn5EC17PwqyFmb73=t+TQsVdvoBiqMAHySNyJMfs5BjgBxKw@mail.gmail.com>
 <4009183A-8190-469F-9AC3-5A0A3ED7CE70@gmail.com>
Message-ID: <CALvn5EDG8e55tz=t30HSuMEYTc+xZ4XAZf755CEjZVuGGEn_vQ@mail.gmail.com>

2024?9?17?(?) 10:42 Vladimir Levantovsky <vladimir.levantovsky at gmail.com>:

> but the results it generates are absolutely dreadful and practically
> unusable for any substantive document.
>

I have heard something similar from several project editors in the JTC1
Editor's forum as well as the JP mirror of JTC1.

But what should we do if ISO/CS decides not to accept PDFs from us? Just
give up this project?  They will surely accept Word documents, but they are
likely to stick to their toolchain.

Regards,
Makoto


>
> Among many deficiencies of the ISO XML tools - two have stood out the most:
> 1)  The inability to support internal document?s hyperlinks. Yes, even the
> entries in the table of content were not hyperlinked - one had to scroll
> all the way to a desired page number. And,
> 2) All color images and illustrations ended up being converted to CMYK
> color space - good luck providing proper illustrations e.g. for various
> blending modes.
>
> There were many other bugs and issues we encountered when preparing OFF
> 4th edition for publication - so many that in the end we had to give up
> completely. The auto-generated PDF file was so horrendous that even ISO
> editor gave up trying to fix it and simply stepped over the required
> process by generating output PDF directly from Word.
>
> TBH, I still do not understand why using ISO XML tools is even necessary
> when ?Save as PDF? directly from Word does a much better job!
>
> I get it that ISO invested a lot into developing their own tool - it took
> a long time to get it running and to get it adopted internally. The irony
> of the situation is that the XML tools development began when ISO main
> product / output format was selling printed copies of standards they
> produced. I suspect the limitations of printed copies is what was informing
> their product features (no links, rigidly defined CMYK printing process)
> but in the next many years it took them to develop and implement their own
> tools the whole world moved on to electronic publishing, and they were
> still stuck in the past (and not willing to fix it).
>
> FWIW, I have zero trust in their tools - neither old nor new. Until years
> of good user experience prove me wrong - I refuse to be a guinea pig and am
> not touching ISO tools with a 10 ft. pole.
>
> Thank you,
> Vladimir
>
> P.S. As an exercise, one might want to look at the differences between
> 2nd, 3rd, and 4th editions PDF files. Second edition was published in 2009
> (before ISO XML tools were implemented); third edition was published in
> 2015 (using XML tool). When proofing the final Word file, it didn?t even
> occurred to me to check PDF for major deficiencies, and we ended up
> angering *many* users as a result. The fourth edition was published in 2019
> after I stood my ground and withdrew my approval for publication until all
> PDF issues were fixed. I only learned it years later that ?fixing the
> issues? involved a simple bypassing of XML tools by using ?Save as PDF?
> directly from Word.
>
>
> On Sep 16, 2024, at 8:02?PM, MURATA via mpeg-otspec <
> mpeg-otspec at lists.aau.at> wrote:
>
> ?
>
>>
>>
>>
>> Just a thought. Is the "iso's kind of XML" version of the spec available
>> anywhere?
>>
>
> STS. See https://www.niso.org/standards-committees/sts
>
> Internally, they use neither OOXML nor ODF.  They convert Word to STS
> using eXtyles.
>
> Regards,
> Makoto
>
>
>>
>> Regards,
>> Hin-Tak
>> On Monday 16 September 2024 at 14:14:01 BST, Liam R. E. Quin via
>> mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:
>>
>>
>> On Sun, 2024-09-15 at 20:23 -0700, Ken Lunde via mpeg-otspec wrote:
>> > Murata-san,
>> >
>> > Another consideration is the extent to which the toolchain of ISO/CS
>> > can handle characters outside of basic Latin.
>>
>> I would expect it to be able to handle the needs of the Open Font
>> Format specification just fine.
>>
>> They gave a talk on their new system at an XML confernce, i think maybe
>> Balisage last year.
>>
>> Obviously it won't handle fonts with more than 65535 glyphs or using
>> avar2, but neither will Word right now :-)
>>
>> Having said that, i don?t see a reason to switch when the document is
>> nearly ready to publish - it sounds like a lot of work for the editor
>> with unclear benefits and possible delays.
>>
>> The new ISO system uses XML behind the scenes, and if they made XML
>> import available, it'd maybe be possible to use XSLT to take the Word
>> file and produce their XML, given a suitable blob of funding. Or they
>> may have a suitable Word input system working themselves. But even if
>> it?s entirely automated it would need a careful proofreading for sure.
>>
>> For a future version of the document, starting out again as a draft, i
>> think it would make a lot of sense.
>>
>> Kind regards,
>>
>> liam
>>
>> --
>> Liam Quin, https://www.delightfulcomputing.com/
>> Available for XML/Document/Information Architecture/XSLT/
>> XSL/XQuery/Web/Text Processing/A11Y training, work & consulting.
>> Barefoot Web-slave, antique illustrations:  http://www.fromoldbooks.org
>>
>> _______________________________________________
>> mpeg-otspec mailing list
>> mpeg-otspec at lists.aau.at
>> https://lists.aau.at/mailman/listinfo/mpeg-otspec
>>
>
>
> --
>  --
> ????????????????????
> ?? ?
> _______________________________________________
> 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/20240917/fa1a34dd/attachment-0001.htm>

From wl at gnu.org  Tue Sep 17 08:30:03 2024
From: wl at gnu.org (Werner LEMBERG)
Date: Tue, 17 Sep 2024 06:30:03 +0000 (UTC)
Subject: [MPEG-OTSPEC] Proposed Adoption of the Online Standards
 Development Platform
In-Reply-To: <CALvn5EDG8e55tz=t30HSuMEYTc+xZ4XAZf755CEjZVuGGEn_vQ@mail.gmail.com>
References: <CALvn5EC17PwqyFmb73=t+TQsVdvoBiqMAHySNyJMfs5BjgBxKw@mail.gmail.com>
 <4009183A-8190-469F-9AC3-5A0A3ED7CE70@gmail.com>
 <CALvn5EDG8e55tz=t30HSuMEYTc+xZ4XAZf755CEjZVuGGEn_vQ@mail.gmail.com>
Message-ID: <20240917.083003.1049454655934949568.wl@gnu.org>


>> but the results it generates are absolutely dreadful and
>> practically unusable for any substantive document.
> 
> But what should we do if ISO/CS decides not to accept PDFs from us?
> Just give up this project?  They will surely accept Word documents,
> but they are likely to stick to their toolchain.

Complain loudly and point out the inadequacies of their toolchain,
giving a bunch of examples, and do that not only to the ISO/CS people
but to the public, too.

In general, I don't understand why so many people (especially in the
computer science field) are using XML for publishing purposes.  I have
not yet seen a single XML document processed with the standard XML
tools to create a PDF file that really looks good from a typographical
point of view.


    Werner

From eb2mmrt at gmail.com  Tue Sep 17 09:33:41 2024
From: eb2mmrt at gmail.com (MURATA)
Date: Tue, 17 Sep 2024 16:33:41 +0900
Subject: [MPEG-OTSPEC] Proposed Adoption of the Online Standards
 Development Platform
In-Reply-To: <20240917.083003.1049454655934949568.wl@gnu.org>
References: <CALvn5EC17PwqyFmb73=t+TQsVdvoBiqMAHySNyJMfs5BjgBxKw@mail.gmail.com>
 <4009183A-8190-469F-9AC3-5A0A3ED7CE70@gmail.com>
 <CALvn5EDG8e55tz=t30HSuMEYTc+xZ4XAZf755CEjZVuGGEn_vQ@mail.gmail.com>
 <20240917.083003.1049454655934949568.wl@gnu.org>
Message-ID: <CALvn5EDcFcGVuYZmokqaToLjkW1ekTVkyMPA4yiANA9FOF6T=A@mail.gmail.com>

Werner,

I am the convenor of SC34/WG4. WG4 did not have to use the ISO toolchain
due to the many pages.  But this was not the end of the story.  ISO/CS
wanted WG4 to check some of the automated checks done by their toolchain.
One of them is to find all normative modal verbs ("shall", "should", "may",
and so forth) in examples and notes and eliminate them.  WG4 did that.
See Examples
Part 1.xlsx <https://1drv.ms/x/s!AtxKXtxhCLrIiis3hG0_-Ldtnb1E?e=F2SBuM>

ISO/CS told WG4 that they would not publish the revision of 29500-1 and -4
unless WG4 does such changes.

Complain loudly and point out the inadequacies of their toolchain,
> giving a bunch of examples, and do that not only to the ISO/CS people
> but to the public, too.


I do not think that they care much.  They are already unhappy with JTC1.

Regards,
Makoto


2024?9?17?(?) 15:30 Werner LEMBERG <wl at gnu.org>:

>
> >> but the results it generates are absolutely dreadful and
> >> practically unusable for any substantive document.
> >
> > But what should we do if ISO/CS decides not to accept PDFs from us?
> > Just give up this project?  They will surely accept Word documents,
> > but they are likely to stick to their toolchain.
>
> Complain loudly and point out the inadequacies of their toolchain,
> giving a bunch of examples, and do that not only to the ISO/CS people
> but to the public, too.
>
> In general, I don't understand why so many people (especially in the
> computer science field) are using XML for publishing purposes.  I have
> not yet seen a single XML document processed with the standard XML
> tools to create a PDF file that really looks good from a typographical
> point of view.
>
>
>     Werner
>


-- 
 --
????????????????????
?? ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240917/46253f72/attachment.htm>

From liam at fromoldbooks.org  Tue Sep 17 18:38:57 2024
From: liam at fromoldbooks.org (Liam R. E. Quin)
Date: Tue, 17 Sep 2024 12:38:57 -0400
Subject: [MPEG-OTSPEC] Proposed Adoption of the Online Standards
 Development Platform
In-Reply-To: <20240917.083003.1049454655934949568.wl@gnu.org>
References: <CALvn5EC17PwqyFmb73=t+TQsVdvoBiqMAHySNyJMfs5BjgBxKw@mail.gmail.com>
 <4009183A-8190-469F-9AC3-5A0A3ED7CE70@gmail.com>
 <CALvn5EDG8e55tz=t30HSuMEYTc+xZ4XAZf755CEjZVuGGEn_vQ@mail.gmail.com>
 <20240917.083003.1049454655934949568.wl@gnu.org>
Message-ID: <da4d5d4da4953f315caafdaad10fe9dab260ec50.camel@fromoldbooks.org>

On Tue, 2024-09-17 at 06:30 +0000, Werner LEMBERG via mpeg-otspec
wrote:
> ? I have
> not yet seen a single XML document processed with the standard XML
> tools to create a PDF file that really looks good from a
> typographical point of view.

That's possibly because the good ones generally don't mention how they
were produced. E.g. a good proportion of best-selling fiction is done
from XML using CSS for print and AntennaHouse Formatter or PDFReactor
or RenderX or PrinceXML, as are a good many scientific and technical
journal articles.

Note that since Word and Open/Libre Office both use XML, the document
is ALREADY being produced from XML.

liam

-- 
Liam Quin,?https://www.delightfulcomputing.com/
Available for XML/Document/Information Architecture/XSLT/
XSL/XQuery/Web/Text Processing/A11Y training, work & consulting.
Barefoot Web-slave, antique illustrations: ?http://www.fromoldbooks.org

From wl at gnu.org  Tue Sep 17 19:27:24 2024
From: wl at gnu.org (Werner LEMBERG)
Date: Tue, 17 Sep 2024 17:27:24 +0000 (UTC)
Subject: [MPEG-OTSPEC] Proposed Adoption of the Online Standards
 Development Platform
In-Reply-To: <da4d5d4da4953f315caafdaad10fe9dab260ec50.camel@fromoldbooks.org>
References: <CALvn5EDG8e55tz=t30HSuMEYTc+xZ4XAZf755CEjZVuGGEn_vQ@mail.gmail.com>
 <20240917.083003.1049454655934949568.wl@gnu.org>
 <da4d5d4da4953f315caafdaad10fe9dab260ec50.camel@fromoldbooks.org>
Message-ID: <20240917.192724.539365954551203685.wl@gnu.org>


>> I have not yet seen a single XML document processed with the
>> standard XML tools to create a PDF file that really looks good from
>> a typographical point of view.
> 
> That's possibly because the good ones generally don't mention how
> they were produced.

This might be indeed the case.

> E.g. a good proportion of best-selling fiction is done from XML
> using CSS for print and AntennaHouse Formatter or PDFReactor or
> RenderX or PrinceXML, as are a good many scientific and technical
> journal articles.

Well, the question how much manual editing was necessary after
converting the input XML...

> Note that since Word and Open/Libre Office both use XML, the
> document is ALREADY being produced from XML.

I was imprecise, sorry.  There is a big difference between using XML
as a document storage format, with zillions of proprietary and/or
program-specific extensions, and using XML for document interchange.
I meant the latter.


    Werner

From htl10 at users.sourceforge.net  Tue Sep 17 20:34:32 2024
From: htl10 at users.sourceforge.net (Hin-Tak Leung)
Date: Tue, 17 Sep 2024 18:34:32 +0000 (UTC)
Subject: [MPEG-OTSPEC] Proposed Adoption of the Online Standards
 Development Platform
In-Reply-To: <20240917.192724.539365954551203685.wl@gnu.org>
References: <CALvn5EDG8e55tz=t30HSuMEYTc+xZ4XAZf755CEjZVuGGEn_vQ@mail.gmail.com>
 <20240917.083003.1049454655934949568.wl@gnu.org>
 <da4d5d4da4953f315caafdaad10fe9dab260ec50.camel@fromoldbooks.org>
 <20240917.192724.539365954551203685.wl@gnu.org>
Message-ID: <554443486.13796221.1726598072137@mail.yahoo.com>

 On Tuesday 17 September 2024 at 18:27:41 BST, Werner LEMBERG via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:
 
 > >> I have not yet seen a single XML document processed with the
> >> standard XML tools to create a PDF file that really looks good from
> >> a typographical point of view.
> > 
> > That's possibly because the good ones generally don't mention how
> > they were produced.

> This might be indeed the case.

> > E.g. a good proportion of best-selling fiction is done from XML
> > using CSS for print and AntennaHouse Formatter or PDFReactor or
> > RenderX or PrinceXML, as are a good many scientific and technical
> > journal articles.

> Well, the question how much manual editing was necessary after
> converting the input XML...

> > Note that since Word and Open/Libre Office both use XML, the
> > document is ALREADY being produced from XML.

> I was imprecise, sorry.? There is a big difference between using XML
> as a document storage format, with zillions of proprietary and/or
> program-specific extensions, and using XML for document interchange.
> I meant the latter.
RenderX is proprietary, I think; but I think it was considered one of the best (or only?), 2 decades ago, since I last looked. Apache FOP was just beginning 20 years ago but I remember it was quite okay - FOP stands for "formatting object processor" and from the look of it looks quite like description of pdf's data structure in XML syntax (and a special name space). FO (the namespace) is probably a w3c standard now, and FOP should be somewhat better in the last 20 years?
Granted ,
XML (some general namespace) -> (XSLT) -> FO -> (FOP / RenderX) -> PDF
Is going to depend a bit on how clever the XSLT (specific to this particular xml format)? is, and how clever FOP / RenderX does things. When I looked at FOP 20 years ago, it couldn't do automatic hyphenations (LaTeX style, sorry I am a LaTeX fan...) and spacing algorithms etc were a bit lacking, but it must have improved by now.
Although, strictly speaking, automatic hyphenation? LaTeX babel style is probably a bit against the XML philosophy of preserving the content....
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240917/2e0971b7/attachment-0001.htm>

From eb2mmrt at gmail.com  Tue Sep 24 08:57:21 2024
From: eb2mmrt at gmail.com (MURATA)
Date: Tue, 24 Sep 2024 15:57:21 +0900
Subject: [MPEG-OTSPEC] Proposed Adoption of the Online Standards
 Development Platform
In-Reply-To: <554443486.13796221.1726598072137@mail.yahoo.com>
References: <CALvn5EDG8e55tz=t30HSuMEYTc+xZ4XAZf755CEjZVuGGEn_vQ@mail.gmail.com>
 <20240917.083003.1049454655934949568.wl@gnu.org>
 <da4d5d4da4953f315caafdaad10fe9dab260ec50.camel@fromoldbooks.org>
 <20240917.192724.539365954551203685.wl@gnu.org>
 <554443486.13796221.1726598072137@mail.yahoo.com>
Message-ID: <CALvn5EC67H-0ZZuwCu3W7nnnbrH4wPAQPj774v7dcdOiaxW5wQ@mail.gmail.com>

Dear colleagues,

I previously pointed out that ISO/CS generally avoids accepting PDFs unless
there is a compelling reason. I also highlighted the risk that, just before
the publication of a standard, a PDF with a layout completely different
from our original intentions is very likely to be issued.

In my view, the most effective way to mitigate this risk is by
transitioning to the Online Standards Development Platform. It is
unfortunate that no action will likely be taken based on my concerns.

Kind regards,
Makoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240924/1e3a9988/attachment.htm>

From wjgo_10009 at btinternet.com  Thu Sep 26 19:04:27 2024
From: wjgo_10009 at btinternet.com (William_J_G Overington)
Date: Thu, 26 Sep 2024 18:04:27 +0100 (BST)
Subject: [MPEG-OTSPEC] Many to many substitution and localization
Message-ID: <2ec50151.2e2c.1922f4a8d25.Webtop.155@btinternet.com>


?
Many to many substitution and localization?
?
I write to suggest a new feature in fonts.
?
A many to many substitution that can be used for localization and 
applied in producing a display of that localization.
?
For example, please consider that a sequence !983 in a document is 
replaced by its localization into a language chosen by the person 
reading the text.
?
For example, for localization into Welsh.
?
sub !983 -> D i o l c h space a m space y m w e l d period ;
?
Yet maybe the following method of expressing such a rule could be 
allowed for convenience, to become encoded exactly the same as the above 
within the font.
?
sub !983 -> #Diolch_am_ymweld. ;
?
The facility would need to be able to be able to manage longer examples, 
such as those of a collection of encoded localizable sentences for 
seeking information through the language barrier about relatives and 
friends after a disaster.
?
I appreciate the difference of a character from a glyph. I am unsure 
whether at the present time a glyph in a font can have a one character 
name if that character is not one of the 52 letters of the uppercase and 
lowercase presentations of the basic English Alphabet. But even if that 
is not presently possible, maybe it could be in the future.
?
Yet for the future, maybe the result of the substitution could be made 
available both as characters and as glyphs.
?
I appreciate that this idea is not what fonts are &quot;for&quot; at the 
present time, yet I opine that this could be a useful feature to become 
introduced.
?
Can this idea become implemented please?
?
William Overington
?
Thursday 26 September 2024
?
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240926/5ba5e7ee/attachment.htm>

From simon at simon-cozens.org  Thu Sep 26 19:12:20 2024
From: simon at simon-cozens.org (Simon Cozens)
Date: Thu, 26 Sep 2024 18:12:20 +0100
Subject: [MPEG-OTSPEC] Many to many substitution and localization
In-Reply-To: <2ec50151.2e2c.1922f4a8d25.Webtop.155@btinternet.com>
References: <2ec50151.2e2c.1922f4a8d25.Webtop.155@btinternet.com>
Message-ID: <3592b0a7-1a5b-4d2d-9761-7e65e33374e8@simon-cozens.org>

On 26/09/2024 18:04, William_J_G Overington via mpeg-otspec wrote:
> Can this idea become implemented please?

The short answer is no.

Suppose a many-to-many substitution is implemented with the lookupflag 
of "IgnoreMarks", and suppose also that there are marks in the input 
glyph sequence. It's not possible to determine how those marks should be 
distributed amongst the new set of glyphs produced by the substitution.

It's possible to do what you're asking for by first ligating glyphs into 
a single glyph ("sub exclam nine eight three by word_983") and then 
using a multiple substitution to perform the localisation ("sub word_983 
by D i o l c h ...") (Of course, the fact that you can do it does not 
mean you should.) So in practice, many-to-many substitution is often 
unneeded.


S

From htl10 at users.sourceforge.net  Thu Sep 26 19:48:13 2024
From: htl10 at users.sourceforge.net (Hin-Tak Leung)
Date: Thu, 26 Sep 2024 17:48:13 +0000 (UTC)
Subject: [MPEG-OTSPEC] Many to many substitution and localization
In-Reply-To: <3592b0a7-1a5b-4d2d-9761-7e65e33374e8@simon-cozens.org>
References: <2ec50151.2e2c.1922f4a8d25.Webtop.155@btinternet.com>
 <3592b0a7-1a5b-4d2d-9761-7e65e33374e8@simon-cozens.org>
Message-ID: <1922014040.19822530.1727372893743@mail.yahoo.com>

 That isn't quite the response I was expecting from one of the "inplementers".

Anyway, I would give my answer, ask one question and give one example.

My short answer is, "yes, but why / do you have to?"

The one question would be: is there any genuine many to many substitution which is not expressible in a combination of chaining many-to-one (?characters to glyphs) and one-to-many (?glyph to subglyph) rules?

The one example would be arabic / Islamic honorific lignatures. They are literally entire sentences/ clauses, which are mapped from multiple characters and in turn rendered in multiple subglyphs in the typical arabic fonts, as a whole visual unit.

And the longer answer would be, it is already possible in most practically useful scenarios, without adding anything new to the current spec or the current implementations.

     On Thursday 26 September 2024 at 18:12:39 BST, Simon Cozens via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:  
 
 On 26/09/2024 18:04, William_J_G Overington via mpeg-otspec wrote:
> Can this idea become implemented please?

The short answer is no.

Suppose a many-to-many substitution is implemented with the lookupflag 
of "IgnoreMarks", and suppose also that there are marks in the input 
glyph sequence. It's not possible to determine how those marks should be 
distributed amongst the new set of glyphs produced by the substitution.

It's possible to do what you're asking for by first ligating glyphs into 
a single glyph ("sub exclam nine eight three by word_983") and then 
using a multiple substitution to perform the localisation ("sub word_983 
by D i o l c h ...") (Of course, the fact that you can do it does not 
mean you should.) So in practice, many-to-many substitution is often 
unneeded.


S
_______________________________________________
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/20240926/89def4ed/attachment.htm>

From wjgo_10009 at btinternet.com  Thu Sep 26 19:57:29 2024
From: wjgo_10009 at btinternet.com (William_J_G Overington)
Date: Thu, 26 Sep 2024 18:57:29 +0100 (BST)
Subject: [MPEG-OTSPEC] Many to many substitution and localization
Message-ID: <7f363bdc.3092.1922f7b19c8.Webtop.155@btinternet.com>


Simon Cozens wrote as follows.
?
> ?Suppose a many-to-many substitution is implemented with the 
> lookupflag of &quot;IgnoreMarks&quot;, and suppose also that there are 
> marks in the input glyph sequence. It's not possible to determine how 
> those marks should be distributed amongst the new set of glyphs 
> produced by the substitution.
?
Thank you for replying.
?
I only know a little about OpenType, and I do not know what is meant by 
the marks to which reference is made.
??
However, the input sequence is characters, not glyphs, in the same way 
that the input sequence is characters in a liga table substitution rule.
?
I am thinking of the input sequence perhaps being in an email that has 
been received, though that is just one example of the possible 
applications of the idea.
?
Here is a link to a PDF slide show that I produced some time ago.
?
http://www.users.globalnet.co.uk/~ngo/slide_show_about_localizable_sentences.pdf 
<http://www.users.globalnet.co.uk/~ngo/slide_show_about_localizable_sentences.pdf>
?
William Overington
?
Thursday 26 September 2024
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240926/52b49ceb/attachment-0001.htm>

From wjgo_10009 at btinternet.com  Thu Sep 26 20:51:35 2024
From: wjgo_10009 at btinternet.com (William_J_G Overington)
Date: Thu, 26 Sep 2024 19:51:35 +0100 (BST)
Subject: [MPEG-OTSPEC] Many to many substitution and localization
Message-ID: <2866499.3271.1922faca050.Webtop.155@btinternet.com>


Hin-Tak Leung wrote as follows.
?
> The one question would be: is there any genuine many to many 
> substitution which is not expressible in a combination of chaining 
> many-to-one (?characters to glyphs) and one-to-many (?glyph to 
> subglyph) rules?
?
Thank you for replying.
?
Alas, as I only know a little about OpenType i do not at the time of 
writing this post have sufficient knowledge of OpenType to answer your 
question.
?
I can say that I opine that being able to communicate through the 
language barrier in some particular circumstances such as for for 
seeking information through the language barrier about relatives and 
friends after a disaster, and such as for buying items from the online 
shops of museums and art galleries throughout the world are genuine many 
to many substitution scenarios.
?
On whether those applications could be done using the method stated in 
your question I am unable to express an opinion.
?
If anyone wishes to try to answer the question that you ask using an 
example, here is a sequence.
?
!313125
?
And here is its localization into English.
?
Is there any information about the following person please?
?
The idea is that there would be a collection of preset localizable 
sentences, the collection then localized into each of many different 
languages by human translators and published. Yet the code number used 
for each sentence would be unaltered in the preparation of the localized 
versions of the collection of preset localizable sentences.
?
William Overington
?
Thursday 26 September 2024
?
?
?
?
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240926/27938f52/attachment.htm>

From htl10 at users.sourceforge.net  Thu Sep 26 21:35:29 2024
From: htl10 at users.sourceforge.net (Hin-Tak Leung)
Date: Thu, 26 Sep 2024 19:35:29 +0000 (UTC)
Subject: [MPEG-OTSPEC] Many to many substitution and localization
In-Reply-To: <2866499.3271.1922faca050.Webtop.155@btinternet.com>
References: <2866499.3271.1922faca050.Webtop.155@btinternet.com>
Message-ID: <784020309.19896760.1727379329238@mail.yahoo.com>

 

On Thursday 26 September 2024 at 19:51:54 BST, William_J_G Overington via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:

> I can say that I opine that being able to communicate through the language barrier in some particular circumstances such as for for seeking information through the language barrier about relatives and friends after a disaster, and such as for buying items from the online shops of museums and art galleries throughout the world are genuine many to many substitution scenarios.

?Argh, I see. It seems that what you are looking for is, I would describe, "stock translation of commonly used phrases", such as, the many different ways of saying the equivalent of the following according to different locale and culture:

"My condolences"

"Sorry for your loss"

"Happy New Year!"

"Hello Handsome!"

"How much (cost) is this?"

You are almost asking for a a stripped down version of google translate to be built into the localisation features of opentype spec and implementations?

That's extending it a bit far...  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240926/b0064897/attachment.htm>

From wjgo_10009 at btinternet.com  Fri Sep 27 00:02:50 2024
From: wjgo_10009 at btinternet.com (William_J_G Overington)
Date: Thu, 26 Sep 2024 23:02:50 +0100 (BST)
Subject: [MPEG-OTSPEC] Many to many substitution and localization
Message-ID: <3f8e4e1d.204c3.192305bb8ed.Webtop.102@btinternet.com>


Hin-Tak Leung replied.
?
Thank you for replying.
?
Hin-Tak Leung wrote as follows.
?
> You are almost asking for a a stripped down version of google 
> translate to be built into the localisation features of opentype spec 
> and implementations?
?
No, not at all.
?
By comparison, the OpenType specification specifies the liga table, but 
does not provide a list of ligatures to use. No list of the ligatures 
used by Gutenberg or any other printer is provided in the OpenType 
specification. The OpenType specification provides the liga glyph 
substitution facility: it is a matter for the font designer to decide 
which, if any, ligatures are to be included in a liga table in any 
particular font. There might not even be a liga table in some particular 
font.
?
So it would be with this present idea. If implemented in the OpenType 
specification then no codes or sentences would be specified in the 
OpenType specification.
?
The standardization of the codes will hopefully be by ISO/TC 37 and they 
have the slide show to which I linked as a United Kingdom contribution. 
There was a good chance that the slide show would be presented by a 
Member of the United Kingdom delegation at the ISO/TC 37 plenary meeting 
that was due to be held in June 2020, but the meeting did not take place 
due to the COVID-19 situation at that time.
?
The codes, such as !983 and !313125 are just my ideas that I have 
devised for my research project. If ISO/TC 37 standardizes a collection 
of localizable sentences then they can if they wish use the codes that I 
am using in my research, or they can devise codes of their own choosing 
if they so prefer.
?
If my idea that I have written about in this thread becomes implemented 
in the OpenType specification then which, if any, codes and into which 
language or languages they are localized in any particular font will be 
a matter for the font designer, not for the OpenType specification.
?
William Overington
?
Thursday 26 September 2024
?
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240926/797c0388/attachment.htm>

From lorp at lorp.org  Fri Sep 27 00:30:15 2024
From: lorp at lorp.org (Laurence Penney)
Date: Thu, 26 Sep 2024 23:30:15 +0100
Subject: [MPEG-OTSPEC] Many to many substitution and localization
In-Reply-To: <3f8e4e1d.204c3.192305bb8ed.Webtop.102@btinternet.com>
References: <3f8e4e1d.204c3.192305bb8ed.Webtop.102@btinternet.com>
Message-ID: <52B38AD3-494B-43CB-88D3-D695179593C8@lorp.org>

William,

Your goal seems to be, essentially, to transform one short character sequence into a long character sequence, depending on local context. Nothing wrong with that, and it?s more or less how multilingual menus and error messages are handled in most software.

However your method transforms one *glyph* sequence into another *glyph* sequence, and would have the serious drawback that the text, when selected by the recipient, would still yield the original *characters* ? something meaningless like "!313125". This prevents numerous benefits of receiving the correct *character* sequence, such as:
- the ability for users or system builders to change font;
- copy & paste;
- forwarding the message to someone else without the special font;
- text-to-speech;
- and so on.

Going back to your goal, character sequences should be manipulated outside of fonts, not within fonts. If you are designing a system for exchanging messages via short codes, you should:
a) embed the decoded messages on each sending and receiving device ? in all languages that the recipient needs access to;
b) perform the encoding and decoding in regular code, not using OpenType substitution.

regards,

- Laurence

> On 26 Sep 2024, at 23:02, William_J_G Overington via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:
> 
> 
> Hin-Tak Leung replied.
>  
> Thank you for replying.
>  
> Hin-Tak Leung wrote as follows.
>  
> > You are almost asking for a a stripped down version of google translate to be built into the localisation features of opentype spec and implementations?
>  
> No, not at all.
>  
> By comparison, the OpenType specification specifies the liga table, but does not provide a list of ligatures to use. No list of the ligatures used by Gutenberg or any other printer is provided in the OpenType specification. The OpenType specification provides the liga glyph substitution facility: it is a matter for the font designer to decide which, if any, ligatures are to be included in a liga table in any particular font. There might not even be a liga table in some particular font.
>  
> So it would be with this present idea. If implemented in the OpenType specification then no codes or sentences would be specified in the OpenType specification.
>  
> The standardization of the codes will hopefully be by ISO/TC 37 and they have the slide show to which I linked as a United Kingdom contribution. There was a good chance that the slide show would be presented by a Member of the United Kingdom delegation at the ISO/TC 37 plenary meeting that was due to be held in June 2020, but the meeting did not take place due to the COVID-19 situation at that time.
>  
> The codes, such as !983 and !313125 are just my ideas that I have devised for my research project. If ISO/TC 37 standardizes a collection of localizable sentences then they can if they wish use the codes that I am using in my research, or they can devise codes of their own choosing if they so prefer.
>  
> If my idea that I have written about in this thread becomes implemented in the OpenType specification then which, if any, codes and into which language or languages they are localized in any particular font will be a matter for the font designer, not for the OpenType specification.
>  
> William Overington
>  
> Thursday 26 September 2024
>   _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec


From liam at fromoldbooks.org  Fri Sep 27 02:18:34 2024
From: liam at fromoldbooks.org (Liam R. E. Quin)
Date: Thu, 26 Sep 2024 20:18:34 -0400
Subject: [MPEG-OTSPEC] Many to many substitution and localization
In-Reply-To: <2ec50151.2e2c.1922f4a8d25.Webtop.155@btinternet.com>
References: <2ec50151.2e2c.1922f4a8d25.Webtop.155@btinternet.com>
Message-ID: <db6fa3b7d8334a00a32c048d45b933740d80efb5.camel@fromoldbooks.org>

On Thu, 2024-09-26 at 18:04 +0100, William_J_G Overington via mpeg-
otspec wrote:
> 
> For example, for localization into Welsh.
> ?
> sub !983 -> D i o l c h space a m space y m w e l d period ;

You can do this in XML with entities, and have language-appropriate
versions substituted automatically. This was by design.

Unfortunately, Web browsers do not support text entities in XML, even
XHTML, ostensibly for security reasons.

But it would be easy to write something in JavaScript that did this
sort of substitution, and that used HTTP content negotiation to get the
appropriate translation automatically, ideally with an override for
when that didn?t work, e.g. on a public kiosk.

This would be better than a font because (1) it would replace
characters, not glyphs (see Laurence?s reply about that), (2) it would
not interfere with linebreaking, and (3) it could also contain site-
specific translations, without needing expensive or specialist font
software to be used.

Best,

liam

-- 
Liam Quin,?https://www.delightfulcomputing.com/
Available for XML/Document/Information Architecture/XSLT/
XSL/XQuery/Web/Text Processing/A11Y training, work & consulting.
Barefoot Web-slave, antique illustrations: ?http://www.fromoldbooks.org

From john at tiro.ca  Fri Sep 27 19:43:43 2024
From: john at tiro.ca (John Hudson)
Date: Fri, 27 Sep 2024 10:43:43 -0700
Subject: [MPEG-OTSPEC] Many to many substitution and localization
In-Reply-To: <7f363bdc.3092.1922f7b19c8.Webtop.155@btinternet.com>
References: <7f363bdc.3092.1922f7b19c8.Webtop.155@btinternet.com>
Message-ID: <7e612650-c53f-4de0-9964-8bbb5655d20d@tiro.ca>

On 2024-09-26 10:57, William_J_G Overington via mpeg-otspec wrote:
> I only know a little about OpenType

So maybe learn more about it before suggesting things to be added to the 
OTL feature set or other aspects of the format?

Sorry if that sounds harsh, but you say elsewhere that you ?appreciate 
the difference of a character from a glyph? and then proceed to suggest 
glyph-level substitutions to affect character-level text operations such 
as string translation. There is a whole field of text localisation in 
software that has solved this for various scenarios a long time ago. You 
are trying to reinvent a well-worn wheel using an inappropriate 
technology about which, by your own admission, you only know a little.

Again, sorry if that sounds harsh, but you seem to have habit of picking 
up on bits of technology, not taking time to understand them, and then 
proposing things to do with them. A few months ago it was Unicode 
variation selectors, a couple of years ago it was using 
glyph-substitution to describe emoji as input for text-to-speech: 
further evidence that while you claim to appreciate the difference 
between characters and glyphs, you don?t actually /understand/ the 
difference.

JH


-- 

John Hudson
Tiro Typeworks Ltdwww.tiro.com

Tiro Typeworks is physically located on islands
in the?Salish Sea, on the traditional territory
of the?Snuneymuxw?and Penelakut First Nations.

__________

EMAIL HOUR
In the interests of productivity, I am only dealing
with email towards the end of the day, typically
between 4PM and 5PM. If you need to contact me more
urgently, please use other means.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240927/444c87d3/attachment.htm>

From wjgo_10009 at btinternet.com  Fri Sep 27 20:47:07 2024
From: wjgo_10009 at btinternet.com (William_J_G Overington)
Date: Fri, 27 Sep 2024 19:47:07 +0100 (BST)
Subject: [MPEG-OTSPEC] Many to many substitution and localization
Message-ID: <4bb1baa6.8f0b.19234cee44a.Webtop.188@btinternet.com>


Laurence Penney replied.
?
Thank you for replying.
?
Laurence Penney wrote as follows.
?
> However your method transforms one *glyph* sequence into another 
> *glyph* sequence, and would have the serious drawback that the text, 
> when selected by the recipient, would still yield the original 
> *characters* ? something meaningless like &quot;!313125&quot;.
?
Not exactly meaningless, the original characters would be the 
language-independent encoding of a localizable sentence, either, as in 
this example, within some of my research publications, or in an ISO 
standard document if the localizable sentences system becomes an 
international standard.
?
However, whilst recognizing that the font table for this feature would 
have a list of glyph numbers so that the rendering software could 
produce the display, the specification for the font table for this 
feature could also include a field to contain the localized text version 
of the sentence expressed as a character string, and that field could be 
accessed by the software of the rendering system if a character version 
of the displayed text is required to be exported.
?
> Going back to your goal, character sequences should be manipulated 
> outside of fonts, not within fonts.
?
A font does not contain software for a virtual machine, it contains data 
for use by software that runs outside the font.
?
My idea is a way of storing data that are localized versions of some 
particular sentences within a font. Applying that data would be carried 
out by software in the rendering system. The rendering system already 
has, in the way it can apply the liga table, software for detecting a 
specified sequence of characters in a string of text. The liga table has 
one glyph specified on the right side of the arrow in a substitution 
rule, for this idea there would be many glyphs specified on the right 
side of the arrow.
?
William Overington
Friday 27 September 2024
?
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240927/cfd4d100/attachment.htm>

From wjgo_10009 at btinternet.com  Fri Sep 27 21:40:36 2024
From: wjgo_10009 at btinternet.com (William_J_G Overington)
Date: Fri, 27 Sep 2024 20:40:36 +0100 (BST)
Subject: [MPEG-OTSPEC] Many to many substitution and localization
Message-ID: <7a9cfba4.9058.19234ffdb47.Webtop.188@btinternet.com>


John Hudson wrote as follows.
??
> So maybe learn more about it before suggesting things to be added to 
> the OTL feature set or other aspects of the format?
??
Well, that is one way of looking at it. Another way is that I have the 
opportunity to put forward my idea in a mailing list where experts in 
OpenType may possibly read about my idea and decide that it has merit 
and become enthusiastic about implementing it and apply their knowledge 
of OpenType to make the idea work and go forward with the idea and the 
idea become implemented and applied.
??
> Again, sorry if that sounds harsh, but you seem to have habit of 
> picking up on bits of technology, not taking time to understand them, 
> and then proposing things to do with them.
??
There is some truth in that, and it may work and lead to progress.
??
Back in the 1970s I knew very little about teletext technology but I put 
forward the idea of broadcasting software on teletext pages and having a 
microprocessor in a television set and that producing local 
interactivity. I coined a new word, telesoftware, for my invention. I 
wrote a Letter to the Editor of a trade newspaper, it was published. One 
thing led to another, and another and so on. As a result I was invited 
to be a joint author of a paper for the 1978 International Broadcasting 
Convention where I was able to use a working demonstration of my 
invention, that had been made by Mullard Linited, running software 
broadcast on ITV Oracle teletext. The word telesoftware is now in The 
Oxford English Dictionary, where my name appears in print in the section 
on the etymology of the word telesoftware where that 1976 Letter to the 
Editor is referenced.
??
William Overington
??
Friday 27 September 2024
??
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240927/55839c58/attachment.htm>

From wjgo_10009 at btinternet.com  Sat Sep 28 15:41:01 2024
From: wjgo_10009 at btinternet.com (William_J_G Overington)
Date: Sat, 28 Sep 2024 14:41:01 +0100 (BST)
Subject: [MPEG-OTSPEC] Many to many substitution and localization
Message-ID: <307aa3db.32539.19238dd052d.Webtop.184@btinternet.com>


John Hudson replied.
?
Thank you for replying.
?
John Hudson wrote as follows.
?
> Sorry if that sounds harsh, but you say elsewhere that you ?appreciate 
> the difference of a character from a glyph? and then proceed to 
> suggest glyph-level substitutions to affect character-level text 
> operations such as string translation.
?
Well, I am suggesting the substitution from the displaying of glyphs for
?
!983
?
to the displaying of glyphs for?
?
Diolch am ymweld.
?
if the end user has chosen Welsh, or to the displaying of glyphs for
?
Thank you for visiting.
?
if the end user has chosen English, or to the displaying of glyphs for
?
Merci de votre visite.
?
if the end user has chosen French, and so on, though not necessarily all 
in the same font. Maybe a separate font for each supported target 
language.
?
There is also a language-independent glyph to have the same meaning in 
any language. The inspiration for this is that Google street view used 
to have images of the then foyer of MoMA, The Museum of Modern Art in 
New York, and in one of them was a sign that had that meaning in six 
languages. There are many more than six languages in the world, and a 
sign cannot reasonably show a localization for all of them, so I thought 
that a language-independent symbol for that meaning would be good, so I 
designed one, later producing a different design, also a related 
language-independent symbol for
?
Welcome.
?
Please find attached two graphics that include those later designs of 
the symbols. The graphics are each a reduced size image of A3 size 
artwork.
?
William Overington
?
Saturday 28 September 2024
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240928/52d91dcb/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Welcome.png
Type: image/png
Size: 24341 bytes
Desc: not available
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240928/52d91dcb/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Thank you for visiting.png
Type: image/png
Size: 39065 bytes
Desc: not available
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240928/52d91dcb/attachment-0003.png>

From eb2mmrt at gmail.com  Sun Sep 29 09:56:02 2024
From: eb2mmrt at gmail.com (MURATA)
Date: Sun, 29 Sep 2024 16:56:02 +0900
Subject: [MPEG-OTSPEC] My personal comments on the CD
Message-ID: <CALvn5EADw+N9s20B0m6TGno8_TzcrcOrXu5DNOHf6uU8Lq-q8w@mail.gmail.com>

I plan to send them to the JP mirror, but I am forwarding this document
here for information.

Regards,
Makoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240929/a85307dc/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MM comments.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 30241 bytes
Desc: not available
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240929/a85307dc/attachment-0001.docx>

From nmccully at adobe.com  Sun Sep 29 23:33:01 2024
From: nmccully at adobe.com (Nat McCully)
Date: Sun, 29 Sep 2024 21:33:01 +0000
Subject: [MPEG-OTSPEC] My personal comments on the CD
In-Reply-To: <CALvn5EADw+N9s20B0m6TGno8_TzcrcOrXu5DNOHf6uU8Lq-q8w@mail.gmail.com>
References: <CALvn5EADw+N9s20B0m6TGno8_TzcrcOrXu5DNOHf6uU8Lq-q8w@mail.gmail.com>
Message-ID: <MW2PR02MB3659E4FE38BAAC9C8E9E0357D7752@MW2PR02MB3659.namprd02.prod.outlook.com>

Here are my comments in the template, for tonight's discussion with the Japan body


Nat McCully  |  Principal Scientist  |  Adobe  |  T 206 675 7351  |  C 206 409 0624  |  nmccully at adobe.com

________________________________
From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> on behalf of MURATA via mpeg-otspec <mpeg-otspec at lists.aau.at>
Sent: Sunday, September 29, 2024 0:56
To: mpeg-otspec <mpeg-otspec at lists.aau.at>
Subject: [MPEG-OTSPEC] My personal comments on the CD


EXTERNAL: Use caution when clicking on links or opening attachments.


I plan to send them to the JP mirror, but I am forwarding this document here for information.

Regards,
Makoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240929/d677f052/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nmccully comments for ISO14496-22.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 29609 bytes
Desc: nmccully comments for ISO14496-22.docx
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240929/d677f052/attachment-0001.docx>

From liam at fromoldbooks.org  Mon Sep 30 01:56:32 2024
From: liam at fromoldbooks.org (Liam R. E. Quin)
Date: Sun, 29 Sep 2024 19:56:32 -0400
Subject: [MPEG-OTSPEC] My personal comments on the CD
In-Reply-To: <MW2PR02MB3659E4FE38BAAC9C8E9E0357D7752@MW2PR02MB3659.namprd02.prod.outlook.com>
References: <CALvn5EADw+N9s20B0m6TGno8_TzcrcOrXu5DNOHf6uU8Lq-q8w@mail.gmail.com>
 <MW2PR02MB3659E4FE38BAAC9C8E9E0357D7752@MW2PR02MB3659.namprd02.prod.outlook.com>
Message-ID: <6a504d858f55e10cc457a3bd23571bebc6fa08bb.camel@fromoldbooks.org>

On Sun, 2024-09-29 at 21:33 +0000, Nat McCully via mpeg-otspec wrote:
> 
> Here are my comments in the template, for tonight's discussion with
> the Japan body

Just for myself, i think those are very helpful clarifications,
especially for implementers.

liam

-- 
Liam Quin,?https://www.delightfulcomputing.com/
Available for XML/Document/Information Architecture/XSLT/
XSL/XQuery/Web/Text Processing/A11Y training, work & consulting.
Barefoot Web-slave, antique illustrations: ?http://www.fromoldbooks.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240929/aaaf5fef/attachment.htm>

From wjgo_10009 at btinternet.com  Mon Sep 30 12:14:45 2024
From: wjgo_10009 at btinternet.com (William_J_G Overington)
Date: Mon, 30 Sep 2024 11:14:45 +0100 (BST)
Subject: [MPEG-OTSPEC] Many to many substitution and localization
Message-ID: <39ac2c23.1f087.192426ce26e.Webtop.250@btinternet.com>


A correction, a suggestion, and a question please.
?
Previously, I wrote as follows.
?
quote
?
For example, please consider that a sequence !983 in a document is 
replaced by its localization into a language chosen by the person 
reading the text.
?
For example, for localization into Welsh.
?
sub !983 -> D i o l c h space a m space y m w e l d period ;
?
Yet maybe the following method of expressing such a rule could be 
allowed for convenience, to become encoded exactly the same as the above 
within the font.
?
sub !983 -> #Diolch_am_ymweld. ;
?
end quote
?
I expressed the left side of the substitution rules incorrectly.
?
The corrected versions of the substitution rules are as follows.
?
sub exclam nine eight three -> D i o l c h space a m space y m w e l d 
period ;
?
sub exclam nine eight three -> #Diolch_am_ymweld. ;
?
----
?
I am thinking that this suggested new facility could possibly be 
produced by adapting a copy of the liga table, changing the name and 
having four integers for each substitution rule.
?
The four integers being as follows.
?
startOfThisGlyphIndexSequence: integer;
?
endOfThisGlyphIndexSequence: integer;
?
startOfThisCharacterString: integer;
?
endOfThisCharacterString: integer;
?
These would point to locations within two arrays, each defined just once 
for the whole font.
?
allOfTheGlyphIndexSequences: array of integer;
?
allOfTheCharacterStrings: array of char;
?
The allOfTheGlyphIndexSequences array is so that displays of the 
localized text can be produced, both on screen and in exported printed 
documents.
?
The inclusion of the allOfTheCharacterStrings array is so that if the 
localized text in electronic character form is desired then the 
rendering system could produce it from the content of the original 
document and some of the content of the allOfTheCharacterStrings array.
?
----
?
What needs to be done, by me or by others, for the suggestion in this 
thread to become formally considered for inclusion in the standard 
please?
?
William Overington
?
Monday 30 September 2024
?
??
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240930/b2366670/attachment.htm>

From simon at simon-cozens.org  Mon Sep 30 12:27:41 2024
From: simon at simon-cozens.org (Simon Cozens)
Date: Mon, 30 Sep 2024 11:27:41 +0100
Subject: [MPEG-OTSPEC] Many to many substitution and localization
In-Reply-To: <39ac2c23.1f087.192426ce26e.Webtop.250@btinternet.com>
References: <39ac2c23.1f087.192426ce26e.Webtop.250@btinternet.com>
Message-ID: <3ae64fe2-8108-4367-b29b-59ac05a43ee9@simon-cozens.org>

On 30/09/2024 11:14, William_J_G Overington via mpeg-otspec wrote:
> What needs to be done, by me or by others, for the suggestion in this 
> thread to become formally considered for inclusion in the standard please?

This is a really good question. My personal opinion:

1) Ensure that any suggestion is written in as broad terms as possible, 
allowing for general purpose rather than specific purpose use.

2) Gather evidence of broad consensus that the new feature is desirable. 
One person thinking that something is a good idea does not make it so.

3) Ensure that the font format is the most appropriate place for the 
standard. Can/should it be done by a layout engine? A rendering engine? 
A higher-level protocol? If so, it does not belong in the font format. 
If you think it should belong in the font format even though it can be 
done in other part of the text stack, demonstrate evidence.

4) Ensure that you're using the terms of the specification precisely. 
For example, there is no such thing as a "liga table" in the OFF 
specification, so it's hard for other people to follow what you mean 
when you say you want to "adapt a copy" of it. To do this, you may need 
to read, and possibly even understand, the specification.

5) Develop, or commission, a working implementation so that the feature 
can be demonstrated and evaluated.

6) Write the suggestion in a way that is suitable to be inserted into 
the existing specification.

7) Once all the above is done, gather evidence of broad consensus of 
approval.

Good examples of how to do the above seven steps are:
https://github.com/harfbuzz/boring-expansion-spec
and https://github.com/googlefonts/colr-gradients-spec

Bluntly, you are currently zero for seven.

Simon

From wjgo_10009 at btinternet.com  Mon Sep 30 15:42:41 2024
From: wjgo_10009 at btinternet.com (William_J_G Overington)
Date: Mon, 30 Sep 2024 14:42:41 +0100 (BST)
Subject: [MPEG-OTSPEC] Many to many substitution and localization
Message-ID: <19ac6af4.176ce.192432b442d.Webtop.8@btinternet.com>


Simon Cozens replied.
?
Thank you for replying.
?
Simon Cozens wrote as follows.
?
> 3) Ensure that the font format is the most appropriate place for the 
> standard. Can/should it be done by a layout engine? A rendering 
> engine?
?
As I understand it, the result is produced by a layout engine and a 
rendering engine that are in an application program such as, for 
example, a desktop publishing program, using information that is 
gathered from a font as input to use together with end user text in 
ISO/IEC 10646 characters to produce the result.
?
> A higher-level protocol? If so, it does not belong in the font 
> format.?
?
Well, codes such as !983 and !313125 are, possibly, in a higher level 
protocol, higher level than ISO/IEC 10646 yet not as high a higher level 
as, say, HTML or XML.
?
Yet I consider that it is fine, indeed appropriate, for information 
about their decoding to be stored within a font. It seems to me to be 
much the same in general principle as the established practice of using 
a font for storing information for the decoding of a sequence of 
characters to produce a display of the Welsh flag.
?
> If you think it should belong in the font format even though it can be 
> done in other part of the text stack, demonstrate evidence.
?
Here is a link to a chapter of my first novel where there is a play that 
has some applications that I hope may be of interest.
?
http://www.users.globalnet.co.uk/~ngo/localizable_sentences_the_novel_chapter_079.pdf 
<http://www.users.globalnet.co.uk/~ngo/localizable_sentences_the_novel_chapter_079.pdf>
?
The whole novel is available from the following web page. Free to read, 
no registration, just open access PDF documents.
?
http://www.users.globalnet.co.uk/~ngo/novel_plus.htm 
<http://www.users.globalnet.co.uk/~ngo/novel_plus.htm>
?
> 5) Develop, or commission, a working implementation so that the 
> feature can be demonstrated and evaluated.
?
Alas, I cannot do either of those myself.
?
I can put forward the idea, I can do some other parts, but, alas, 
neither of those two myself.
?
William Overington
?
Monday 30 September 2024
?
?
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240930/903494ef/attachment-0001.htm>

From simon at simon-cozens.org  Mon Sep 30 15:48:44 2024
From: simon at simon-cozens.org (Simon Cozens)
Date: Mon, 30 Sep 2024 14:48:44 +0100
Subject: [MPEG-OTSPEC] Many to many substitution and localization
In-Reply-To: <19ac6af4.176ce.192432b442d.Webtop.8@btinternet.com>
References: <19ac6af4.176ce.192432b442d.Webtop.8@btinternet.com>
Message-ID: <3a522a4f-fb67-40c7-b003-4749a0969e95@simon-cozens.org>

On 30/09/2024 14:42, William_J_G Overington via mpeg-otspec wrote:
> Yet I consider that it is fine, indeed appropriate, for information 
> about their decoding to be stored within a font. It seems to me to be 
> much the same in general principle as the established practice of using 
> a font for storing information for the decoding of a sequence of 
> characters to produce a display of the Welsh flag.

That's a very good analogy. Perhaps a better one than you think: the 
established practice about the decoding of that sequence into the Welsh 
flag belongs to Unicode, not to the Open Font Format.

S



From wjgo_10009 at btinternet.com  Mon Sep 30 19:35:04 2024
From: wjgo_10009 at btinternet.com (William_J_G Overington)
Date: Mon, 30 Sep 2024 18:35:04 +0100 (BST)
Subject: [MPEG-OTSPEC] Many to many substitution and localization
Message-ID: <7372dbed.4d3b5.19244000291.Webtop.7@btinternet.com>


Simon Cozens replied.
?
Thank you for replying.
?
Simon Cozens wrote as follows.
?
> 4) Ensure that you're using the terms of the specification precisely. 
> For example, there is no such thing as a &quot;liga table&quot; in the 
> OFF specification, so it's hard for other people to follow what you 
> mean when you say you want to &quot;adapt a copy&quot; of it. To do 
> this, you may need to read, and possibly even understand, the 
> specification.
?
Yes, thank you.
?
I have now rewritten that paragraph. Here is the revised text.
?
I am thinking that this suggested new layout feature could possibly be 
produced by a person who is writing software for a fontmaking program 
adapting a copy of the software that implements the liga layout feature, 
changing the name from liga to become a presently unused four lowercase 
letter sequence, and having four integers for each substitution rule.
?
The four integers being
?
startOfThisGlyphIndexSequence: integer;
?
endOfThisGlyphIndexSequence: integer;
?
startOfThisCharacterString: integer;
?
endOfThisCharacterString: integer;
?
These would point to locations within two arrays, each defined just once 
for the whole font.
?
allOfTheGlyphIndexSequences: array of integer;
?
allOfTheCharacterStrings: array of char;
?
The allOfTheGlyphIndexSequences array is so that displays of the 
localized text can be produced, both on screen and in exported printed 
documents.
?
The inclusion of the allOfTheCharacterStrings array is so that if the 
localized text in electronic character form is desired then the 
rendering system could produce it from the content of the original 
document and some of the content of the allOfTheCharacterStrings array.
?
William Overington
?
Monday 30 September 2024
??
??
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240930/344c8421/attachment.htm>