PyQtGraph VS epub3-samples

PyQtGraph - Interactive and realtime 2D/3D/Image plotting and science/engineering widgets.

Image, 3D, or data visualization applications using OpenCV and the SciPy ecosystem. The Graphics View Framework can display an image and let the user interact with it, and the Python ecosystem is very rich for image processing, data analysis, and visualization. For example, LabelMe for image labeling, PyQtGraph for scientific graphics, or custom QWidget integration in Maya.

I don't think that's related to your error though - from the backtrace, it looks like the plotWidget has plotItem attribute that's somehow been assiged to itself (or maybe some other PlotWidget) , so is just endlessly recursing as it tries to proxy the same attribute lookup (presumably 'clear') to itself. Looking at the source, the plotitem is either created as a new PlotItem() object if not provided, or passed in to the constructor, so I'd check how this gets initialised - eg. does this get set as a property in your .ui file? Are you setting it to the widget itself somehow?

I did something like this recently but I used pyqtgraph: https://www.pyqtgraph.org/

Ah, I agree, Matplotlib is for publication, so slow and pretty. For fast, I use pyqtgraph, which can do that 10 million point plot interaction. And since it's QT, it integrates seamlessly into QT applications.

With MathML epubs can look decent. For example take a look at the sample MathML epub "A First Course In Linear Algebra" [0] (in a reader that supports MathML of course). It looks pretty good. The problem is Amazon STILL doesn't support MathML, so publishers just churn out a gross version where all the equations are images and so then it doesn't scale properly with the text and the book becomes 300+ MB because of it. And they can't be bothered to make two versions for readers like Kobo that do support MathML.

[0]: https://github.com/IDPF/epub3-samples/releases/download/2017...

For example, if you want to open epub files like https://github.com/IDPF/epub3-samples/releases/download/20170606/accessible_epub_3.epub inside Brave, you will have to install an epub reader extension then instead of downloading it will open inside Brave, if you want to change that behavior you have to disable the extension or limit the extension's domain list, or you right click and "save link as file", but unless the extension has the settings, there is no way to tell Brave to use extension or download manager depending on extensions, unless the extension gets disabled. And if you have an external epub reader, well, you can automatically open the extension when you tell Brave to do it as well.

I've worked on a ePub parse and renderer and the issues you're describing sound pretty familiar.

The three main components of the ePub (aside from the actual pages) are the TOC, the spine and the manifest. The manifest basically tells you where everything is, the TOC is the table of contents which can link to various pages and the spine gives you the traversal order.

Some mistakes I've seen are using the TOC to traverse the book. Using the spine to traverse the book but not handling hidden pages properly. Not handling two page spread properly.

So yeah the spec is nuanced and it would be easy to make a reader that worked with a lot of books but then had weird issues on another set of books that aren't particularly different.

I recall using this repo (https://github.com/IDPF/epub3-samples) to test specific functionality to make sure it was in line with the spec.