How to leverage the existing "issue base" in Readium-1

[rkwright]

Moving this from email to an issue:
rkwright wrote

Laurent reminded me earlier today that we still have a large number of open issues in R1. This is no surprise because many of them really ARE still problems, but most are relatively minor. The problem all along has been that developers are always happy to develop features but less enthusiastic about fixing bugs. Especially in open source projects and when their REAL boss is breathing down their neck. We will run into this same problem with R2 as well, I am sure so we need to think about that.

However, I am making another pass through the open issues in R1 and reading through them got me thinking. There is a HUGE amount of time and effort invested in those issues: investigating, fixing, experimenting, etc. An not only the remaining open issues but also all the issues that have been closed. I’m trying to think of a way for us to troll through the issues and gather the info in a meaningful way. Even if R2 is better architected and designed, etc. many of the R1 issues arose not because of bad design or implementation (though that is true for some of them) but because the situation or problem was tricky.

[rkwright]

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...

[rkwright]

@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

[danielweck]

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.