[MPEG-OTSPEC] Proposed Adoption of the Online Standards Development Platform

MURATA eb2mmrt at gmail.com
Tue Sep 17 06:50:46 CEST 2024


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>


More information about the mpeg-otspec mailing list