How to leverage the existing "issue base" in Readium-1 about architecture HOT 3 OPEN

whmccoy wrote:

Just as an FYI, the EPUB-in-Edge team whom I talked with earlier this week here in Seattle area, mentioned how many tricky issues they had to deal with. And, they are ingesting eBook content at volume from publishers that they are now selling (at least in US) from the Microsoft Store. So I +1 this idea.

But I would suggest we consider prioritizing by real-world applicability. Much as I am a fan of CFI in principle, I am not sure that it is something that lives in real content. Maybe you want "quartage" instead of "triage" where the fourth bucket is for issues that are significant, and perhaps fixable at reasonable cost, but are more theoretical than practical so low priority not because they are trivial but because they aren't (at least yet) used in the real world of content. Of course this could become a self-fulfilling prophecy as if we leave CFI buggy as heck then we can't expect it to get used... but I don't know that Readium will be the determinant of that in the first place. Another way to prioritize real-world applicability that wouldn't require exhaustive analysis of content is by feature support in other reading systems... if everyone else has good CFI support then probably that is important and we should to. If others omit it, not so much. Of course Readium has a goal to "raise the bar" of EPUB support but at some point adopter priorities should trump our pursuing noble goals, especially when resources are limited...

from architecture.

@whmccoy Well, I think it is a little more complex than that. I think there are (at least) 4 buckets:

1. issues that are entirely something intrinsic to Readium-1 and are unlikely to plague R2 for whatever reason
2. issues that are simply complex cases of layout, CSS, SVG, whatever that we may have solved in R1 and those exemplars need to be preserved as valuable tests cases
3. issues that arose because of inadequate design or implementation in R1 which we subsequently recognized and we don't want to fall into that hole again*
4. issues that arose due to bad design of the EPUB/markup - which are legal EPUB but violate best practices

* I want to point out that the implementors of Readium-1 were forging new ground in terms of languages and open source and I think they did a great job. Readium-2 has an easier (bit not easy) path because of that path-breaking.

My problem is (at least twofold)

• How do we glean all that info without review of each and every issue (>1200 in all)
• how to publish/archive that info

from architecture.

I think there is some confusion with regards to CFI support.
This is not about implementing (or even maintaining) support for CFI hyperlinking in authored documents / publications.
In fact, CFI is used internally by the Readium (shared JS) pagination and scrollview engine to designate arbitrary character-level locations in reflowable documents, to map visual areas (visible page boundaries), and to create selections/annotations.
The CFI parser/generator library is actually pretty stable / bug free (and can be reused in other projects as a standalone utility).
The existing issues are mostly related to the so-called "CFI-navigation-logic", which is coupled to Readium's mechanisms for laying page units (CSS columns) and for scrolling documents.
There is added complexity due to support for Right To Left page progression direction, as well as vertical writing modes.

from architecture.