search

w3c / epub-tests

Test repository for EPUB3, maintained by the EPUB3 WG
https://w3c.github.io/epub-tests/
Other
22 stars 20 forks source link

Add pkg-spine-nonlinear-usable test as per issue #283 #288

Closed gautierchomel closed 1 year ago

gautierchomel commented 1 year ago

As per #283 The pkg-spine-nonlinear-activation test shows that nonlinear resources are reachable. It does not presumes if this reachable resource is usable.

Most often what happens is that you can reach the nonlinear resource but once there you can't navigate thru this resource (because it is nonlinear).

This test with a long nonlinear resource will allow to test if the spec is implemented in a usable way.

mattgarrish commented 1 year ago

What spec requirement does this test correlate to?

I thought it was testing whether you could access the non-linear document by a link rather than the table of contents, but it says that you have to reach the end of the non-linear document once you reach it, so is it testing virtual pagination of non-linear content vs linear content? Does it matter if the reading system scrolls the document?

gautierchomel commented 1 year ago

@mattgarrish The reachable test does not presume you can read a long content.

This test will show that I can reach the non linear content but I cannot use it in some reading systems (I can't scroll nor move pages). No matter how this is achieved.

i.e. it extends the pkg-spine-nonlinear-activation test (IMHO reaching a resource you can't use is not a proper implementation).

iherman commented 1 year ago

What about the implementation results for this test? You have marked all the current reports with 'null', ie, we do not know, which, if stays that way, means that this becomes automatically an under-implemented feature and must be marked as such in the spec. Which is all right if this is indeed the case. (I was surprised to see that even in Thorium the value is null, b.t.w.). Was it possible for you to test it, e.g., on Apple (I know you used Apple's Books as a separate tester). If Apple and Thorium implements it, then we are fine as is. Nevertheless, I think, at this point, we should contact all implementers to check this test to get a more realistic picture...

cc @wareid @shiestyle @dauwhe

gautierchomel commented 1 year ago

Just added tests results for Thorium (false), Colibrio (false) and Books on OSX (true).

Because we found the Issue we may fix it in a next Thorium release.

gautierchomel commented 1 year ago

Amending my previous comment and commit, the 3 of them pass the test.

I have a file here that does not pass, I'll check why.

iherman commented 1 year ago

Amending my previous comment and commit, the 3 of them pass the test.

Ah, great. So we can add this to the test collection without any consequences. Thanks.

@wareid should I merge this and, possibly, you guys (and maybe @shiestyle and @bduga) can do the extra tests separately, or do you prefer to leave this PR open for now?

gautierchomel commented 1 year ago

Ok it does not pass if the package opf has 

<meta property="rendition:layout">pre-paginated</meta>
<meta content="true" name="fixed-layout" />

and 

<itemref idref="p_00148" linear="no" properties="rendition:layout-reflowable"/>

Use case is someone trying to add alternatives reflowables ressources to adress FXL accessibility alternative (kind of Multiple rendition). Looks like it has to be authored differently.

mattgarrish commented 1 year ago

The reachable test does not presume you can read a long content.

Right, but I'm wondering what requirement is being tested?

Don't get me wrong, I'm not saying it won't capture a problem, but nothing in the spec I find requires that you be able to fully read non-linear content. The only requirement is that reading system provide a way to read all the primary (linear) items.

That may be a failing of the spec, or it could be argued this is an implementation bug more than a spec one. In any case, it's probably too late now to add a new requirement if there isn't one I'm missing. Even the rendition:flow definition doesn't get into being able to read through a full document.

gautierchomel commented 1 year ago

@mattgarrish I understand, maybe it is not to be tested here as it is not a place to test reading systems efficiency but to test spec viability.

In that case I'll keep the file for our internal testings.

wareid commented 1 year ago

Amending my previous comment and commit, the 3 of them pass the test.

Ah, great. So we can add this to the test collection without any consequences. Thanks.

@wareid should I merge this and, possibly, you guys (and maybe @shiestyle and @bduga) can do the extra tests separately, or do you prefer to leave this PR open for now?

Waiting on which requirement this is testing, otherwise I don't think this test is valid for the test suite?

iherman commented 1 year ago

Closing by virtue of https://github.com/w3c/epub-tests/pull/288#issuecomment-1385386457