You proposed a change to the desktop code that would encourage the addition of large files into the media folder, and I explained why I think that would be a problem. I’m skeptical that there would not be a measurable performance impact compared to loading individual images - both in terms of extra processing time, where you have native libraries decoding images vs JS doing the processing, and in terms of number of bytes that need to be read in order to display a card. But I’m also concerned about the large files. If you’re able to split the PDFs into multiple files, where each file isn’t much more than a few MB, then that would alleviate my concerns about syncing, assuming those files won’t be changing over time. Whether that’s actually practical or not, I do not know: teaching pdf.js how to read such split files sounds like quite a project, and you’d need to check how many of these files actually need to be read in to display a card.
Please note I am not arguing that the system you propose has no value. I’m just not sure it makes sense to try and cram it into Anki’s current architecture, which has different assumptions about how content should be stored, and how the reviewing process should work (chiefly, that any initial learning/cross-referencing is done externally, and card content contains the minimum information necessary to review).
Sounds to me like you would be better off getting some assistance from the computer science department to make an entirely new web app. Since Anki is open-source, you could copy and adapt parts of it.
You mention pre-made decks. Those could reside on the same web server that hosts the app, with copies available for anyone willing to run their own local web server.
I can’t rigorously address this until the solution is finished, and I don’t see a way to do it rapidly. Any way we can reserve judgement on this until we solve the problem of incremental loading? Theoretically if it is implemented, there will be only a minor difference, as only a fragment of the pdf file will need to be read.
Completed in my latest version. Implemented by splitting pdf files by top-level-bookmarks. This makes almost all files less than 10mb, with most less than 3mb.
I just used pdf.js internal url hash system to accomplish this, with only one subheading read in at a time (no real lazy loading). Navigation links appear in the bookmark tab for all pdf files in a particular folder.
example:
Each of these links will navigate to “__pathomanotes-Chapter 1: Growth Adaptations, Cellular Injury, and Cell Death.pdf”, etc.
Given that this problem is now solved, do you see any way we can implement true lazy loading on a level that is compatible with anki?
Again, my main intention here is to fill a gap with learning essential content that has no or extremely difficult to find supporting material, and relearning content in context. I’m not disagreeing with anyone about initial learning in general, I’m just dealing with the realities of how reviewing works for the average user.
I’ve read your detailed descriptions of your desire for something not feasible with Anki, and Damien’s explanations of why it isn’t feasible. As a retired software engineer, I believe I understood both. I did not suggest “a version of Anki” but an app that would do what you want. Rather than trying to shoehorn your ideas into where they won’t fit, you could borrow PARTS of Anki to add to your code.
This comment re-affirms to me that you did not read the discussion.
I’ve stated multiple times that I have already successfully implemented this in Anki. I’m not shoehorning anything. I’m not “hacking” anything. I’m only asking for help with a single feature that would vastly improve efficiency, but it doesn’t even matter for loading time, etc.
I don’t even know how to respond to this. It’s already done. It’s already implemented. It’s like I’m living in the twilight zone.
I will ignore any of your future comments unless they contain a good-faith attempt to solve the issue of incremental loading within anki.
Are you saying that your current implementation would fetch every split file of the document, and not just the one that was required? Why can’t you link directly to the appropriate split file in the card?
I get it: you believe you have a good idea and are frustrated that people are not as enthusiastic about it as you are. But please try not to let that frustration leak into your posts, as it’s not conducive to discussion.
It is only fetching one split file at a time, linking directly to them. I’m working right now to implement a slightly different way to accomplish this, but the issue of incremental loading remains the same. Ie, I would still like to find a way to make it only load the page needed.
It’s frustrating when you spend months on a solution for a niche community and need help on a specific piece of functionality. Then, when you ask, no one has a solution or is willing to help.
At this point, it’s clear that there are no easy solutions, and I’ll have to figure out anything I want to accomplish without any assistance. I have overestimated this community’s ability and willingness to help.
