Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sample 130 implements one of the worst edge cases possible #92

Open
JayPanoz opened this issue Dec 4, 2018 · 4 comments
Open

Sample 130 implements one of the worst edge cases possible #92

JayPanoz opened this issue Dec 4, 2018 · 4 comments

Comments

@JayPanoz
Copy link

JayPanoz commented Dec 4, 2018

In practice, sample 130 implements one of the worst edge cases possible, an edge case that is not even discussed in the EPUB3 spec: mixed writing modes and how to deal with such a publication – so most Reading Systems will actually fail to handle it properly.

It should at least be 2 different files:

  1. vertical writing;
  2. RTL direction.

It’s been popping up over and over and over again in issues I’ve been dealing with while the spec doesn’t even tell how it is supposed to be handled and is left wide-open to implementers’ interpretation.

On a related note, styling for the cover doesn’t even work in web browsers, see readium/readium-css#50 (comment)

@JayPanoz
Copy link
Author

JayPanoz commented Dec 4, 2018

And CSS explanation for the cover styling bug: readium/swift-toolkit#172

@rkwright
Copy link

rkwright commented Dec 4, 2018

Hm. Not sure that mixing the writing mode and direction is a mistake. That's a real-world use case, is it not? One of the problems I see with the epub testsuite is that it is so purely atomic. However, in practice, most bugs we see in Readium are due to a confluence of features, not one feature at a time.

Of course, the other problem with 130 is that when Kanai-san created the test, he provided sample images so the language-challenged among us could compare the rendered result to the expected. Unfortunately, the test is reflowable, so depending on how large the window, the font-settings, etc. the rendered result will rarely match the image. If you are viewing it in a desktop browser one can laboriously adjust the browser window until the rendered test and image are the same size, but it would have been nice if the test were fixed layout (though that would engender other difficulties no doubt).

@JayPanoz
Copy link
Author

JayPanoz commented Dec 4, 2018

Well, in theory you can design some logic based on W3C i18n docs, then you can map that to pagination, etc.

In practice, the EPUB spec doesn’t tell you how to handle that case. I’ve spent hours on this one and, in practice, for implementers, it’s a hugely problematic one. And it’s far from solved, as it also popped up in WPUB: w3c/wpub#126

@JayPanoz
Copy link
Author

JayPanoz commented Dec 4, 2018

And for reference, what we ended up with: https://github.com/readium/readium-css/blob/develop/docs/CSS16-internationalization.md

Which is quite an uncomfortable position to find yourself into because it is all about non-standardized handling and you pretty much end up standardising it yourself. 😰

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants