Re: [External] My opinions about the future of EPUB 3.2

2018年11月2日(金) 0:18 Garth Conboy <garth@google.com>:

> > I also think that some advanced features of vertical writing (e.g.,
> tatechuu yoko and handling of character orientation) are not supported by
> those RSs which are not commonly used in Japan.
>
> If this is a listed feature of EPUB 3.2 and they are 2 or more Japanese rS
> supporting this feature, the Director should not see any issue with it,
> from my understanding.
>
> Yes, I was about to say exactly the same.  So, I don't think many (any?)
> features will be in danger.  It should not be an issue of support by all,
> it's support by more than one.  Re Tate Chu Yoko, I know that we "do the
> right thing" as well as do a number of other RS's in Japan.
>
>
Garth,

Does any RS support rendition:align-x-center?
See
http://www.idpf.org/epub/301/spec/epub-publications.html#layout-property-align-x-center

About character orientation in vertical writing, I know that Kindle
does not do the right thing.  Thus, Japanese publishers are forced
to use bitmap images for some characters.  Amazon claimed
that their format is NOT EPUB and ithat they are not required
to meet requirements on EPUB RSs.

There was a thorough experiment about character orientation.
See http://densholab.jp/lab/RScheck/result.html. It
revealed that different implementations do different things.
The row for "Upright" shows that no implementations do the
right thing.  Things might have changed fter this experiment,
but I do not know.

Regards,
Makoto






> Let's get the data first, and then decide if we have an issue (I'm betting
> not).  If there are EPUB 3.2 required features that are supported by NO
> RS's having a conversation about dropping (or ramping up support) does seem
> reasonable.  Similar for any required features support by only a single RS.
>
> Best,
>    Garth
>
>
> On Thu, Nov 1, 2018 at 7:51 AM Laurent Le Meur <laurent.lemeur@edrlab.org>
> wrote:
>
>> There will be *NO* W3C REC if a feature by feature interoperability of
>> UAs is not demonstrated. Interoperability of UAs is now a flexible notion
>> at W3C, but still something the Director must be confident about. This is
>> why some of us feel required to a/ list the features of EPUB 3.2 b/ know
>> which are supported by UAs (if possible by 2 UAs).
>>
>> > I also think that some advanced features of vertical writing (e.g.,
>> tatechuu yoko and handling of character orientation) are not supported by
>> those RSs which are not commonly used in Japan.
>>
>> If this is a listed feature of EPUB 3.2 and they are 2 or more Japanese
>> rS supporting this feature, the Director should not see any issue with it,
>> from my understanding.
>>
>> We need to have a clear roadmap about what is needed to get EPUB 3.2
>> being considered an international standard, either via W3C or direct ISO
>> blessing.
>> But if we study the W3C REC path, the need to list "interesting" EPUB 3
>> features seems a first requirement. Is it something that can get consensus
>> on? it would be a first step.
>>
>> Laurent
>>
>>
>> Le 1 nov. 2018 à 14:36, MURATA Makoto <eb2m-mrt@asahi-net.or.jp> a écrit
>> :
>>
>> Liisa,
>>
>> 2018年11月1日(木) 21:52 McCloy-Kelley, Liisa <
>> lmccloy-kelley@penguinrandomhouse.com>:
>>
>>> Makoto-
>>>
>>>
>>>
>>> I think we need to do the testing to see if there are at least 2
>>> instances somewhere in the world of support for each individual EPUB 3.2
>>> feature. I suspect that there are. That is what I understand to be needed
>>> in order to move 3.2 to a rec track and then on to ISO. Let’s get through
>>> this and see where we are before we scare people that things might get cut.
>>>
>>>
>>>
>>
>> I am afraid that I have to oppose.  No matter how non-interoperable
>> EPUB 3.2 is, I would like to bless it as a REC.   Eliminating
>> non-interoperable features from 3.2 is not attractive to Japanese
>> EPUB 3 users.
>>
>> Regards,
>> Makoto
>>
>>
>> I suspect the harder bit for many of us is some of the base HTML/CSS
>>> stuff that isn’t spelled out in the 3.2 spec because it is assumed, but is
>>> still spotily supported across reading systems. Crazy little things like
>>> first letter or first line styles, which work much of the time, but not
>>> always and cause more work and compromise and trial and error for
>>> publishers to understand how they fail and where.
>>>
>>>
>>>
>>> The thing I’m looking forward to with all of this is the transparency we
>>> are trying to bring to the spec and its implementation in all the places we
>>> need it to work, not just browsers. I believe that is going to help all of
>>> us to get to a much better place of “Don’t mess up!” and even improve
>>> significantly on where we are now.
>>>
>>>
>>>
>>> Thanks so much for checking in with your colleagues.
>>>
>>>
>>>
>>> Best,
>>>
>>>
>>>
>>> Liisa
>>>
>>>
>>>
>>>
>>>
>>> *From: *MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
>>> *Date: *Wednesday, October 31, 2018 at 7:50 PM
>>> *To: *W3C Publishing Business Group <public-publishingbg@w3.org>
>>> *Subject: *Re: [External] My opinions about the future of EPUB 3.2
>>> *Resent-From: *<public-publishingbg@w3.org>
>>> *Resent-Date: *Wednesday, October 31, 2018 at 7:50 PM
>>>
>>>
>>>
>>> Folks,
>>>
>>>
>>>
>>> Rick wrote:
>>>
>>>
>>>
>>>
>>>    - The proposals (to create detailed compliance levels in the spirit
>>>    of the work done for WCAG, and to ‘fix the broken contract that bugs are
>>>    evidence of’) are excellent, and could build on top of a 3.2 rec track
>>>    specification.
>>>    -
>>>
>>> I also would like to separate EPUB 3.2  and compliance levels.
>>>
>>>
>>>
>>> Yesterday, I spoke with some Japanese involved in
>>>
>>> e-publishing business.  In Japan, thanks to the small
>>>
>>> profile of EBPAJ, EPUB 3 works.  Thus, nobody is
>>>
>>> interested in eliminating non-interoperable features
>>>
>>> from EPUB 3.2.  A common reaction is "Don't mess up!".
>>>
>>>
>>>
>>> Therefore, I would like to bless EPUB 3.2 as a REC no matter
>>>
>>> how non-interoperable it is.  But I do see advantages of
>>>
>>> an interoperable subset (or compliance levels).  Thus, I
>>>
>>> welcome a separate specification (possibly a REC) for
>>>
>>> such a subset.
>>>
>>>
>>> Long time ago, W3C create WebCGM as a REC.  It
>>> is a subset of an international standard,
>>>
>>> ISO/IEC 8632:1999(CGM).  I am wondering if we
>>>
>>> can do something similar.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Makoto
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>>
>> Praying for the victims of the Japan Tohoku earthquake
>>
>> Makoto
>>
>>
>>

-- 

Praying for the victims of the Japan Tohoku earthquake

Makoto