Slow open/render pdf files. #4
Comments
|
@mrprole Unfortunately I think this is due to the fact that the PDF renderer is written in JavaScript (it's pdf.js), so there's nothing we can do. It's the trade-off to have a more secure PDF viewer, as there are currently no other PDF libraries written in a memory-safe language. |
|
It's slow because I originally implemented it in the most straightforward way and then added proper hardening, error handling and optimizations over time. I only got around to properly optimizing it for the next release. Doing the rendering in a way that's friendly to the Chromium canvas implementation is a 10-100x increase in performance and I added caching and a basic prerendering heuristic on top of that. The problem wasn't pdf.js but how pdf.js was being used. This fork isn't representative of the security, performance and robustness of the real thing. It was a fork of a very early version before it became an official CopperheadOS project and was relicensed. Among other things, it needed more sophisticated handling of concurrency to avoid race conditions when queuing up actions. Some cleverness is required to finish the sandboxing implementation by taking away content:// access from the WebView too. It would be best if the F-Droid package and https://play.google.com/store/apps/details?id=org.ninthfloor.copperpdf didn't refer to CopperheadOS. The code should be attributed to Daniel Micay as I wrote it on my own time. |
|
I'm pretty sure you didn't upload that Google Play Store app but they stole your app id. They're pretending to be ninthfloor.org and who knows what they've done to it and plan on doing with it (ads? malware?). If you wanted you could report it as trademark infringement: https://support.google.com/legal/troubleshooter/1114905. |
|
@thestinger I understand you want to protect your brand. At this point, given the scarce interest, I'll consider killing this app altogether. I'd like to have an opinion on the two persons who contributed so far: @eighthave and @Lesik. I didn't upload the app the the Google Play Store. |
|
My concern is that I wanted a libre PDF viewer, and this app seemed like a good tradeoff between additional security through sandboxing and functionality/speed. If the original app becomes available in F-Droid, and contributions move to that repo, I'm completely fine with that. If you plan to kill off this fork with no alternative available in F-Droid, I'd rather have it stay and cherry-pick important patches which @thestinger allows us to pull despite the license. |
|
@Lesik the original app won't land in fdroid because of its non-free license. You are of course free to compile it yourself or even to download it from copperhead's fdroid repository (I didn't try this one and it is not officially supported, but it should work). |
|
I'm aware. Thus I said, if the situation stays the way it is, I'd rather not kill off this repo, being the only way to keep an official F-Droid source for this PDF viewer. |
|
This fork was deployed commercially by at least one company and at least two people have uploaded it to the Play Store. I'm not going to relicense a subset of our changes. They can't be easily applied without taking everything anyway. The whole point of using that license is preventing that kind of commercial usage without giving back to the people writing it. It demonstrates that the license is the right choice. As I pointed out, this doesn't have a comparable sandbox to the real thing. It doesn't have comparable hardening in general. It has race conditions in how it renders which is not a security issue but is definitely a major robustness issue. The pdf.js code isn't being updated which may end up creating vulnerabilities within the sandbox. Updating pdf.js requires a patch to pdf.js or it will break stuff, and until they decide they are willing to accept our patch upstream it falls under our license too: mozilla/pdf.js#8066. The current code in https://github.com/CopperheadOS/platform_packages_apps_PdfViewer proves that pdf.js can be used in a way that's blazing fast. There's literally a 10-100x performance improvement by rendering in a different way. I also added an LRU cache for rendered pages and text selection data and prerendering in addition to that. This fork doesn't support text selection at all since it predates adding support for that. Being able to copy text is a fairly essential feature for a PDF Viewer. |
|
We all agree your updated PdfViewer is superior to this fork, but as you know there is a another key difference between the two: the license. While I'm glad you are happy with your licensing choices, this fork is for people who prefer the Apache license. Take it as a fact, I don't want to start a discussion about licenses here. If this app will get an update I'll remove the reference to CopperheadOS from the F-Droid description, as you seem to prefer so. I don't care about people trying to sell it on the play store. |
They might prefer that license but they probably expect to be getting updates to dependencies like pdf.js at a minimum.
You should probably care about them using their app id. It's presented as being tied to your ninthfloor.org domain. If they bundle malware, ads with tracking, etc. it's going to reflect on you. I definitely care about them claiming it's based on the CopperheadOS PDF Viewer when it's only based on my early proof of concept. As a bonus, they steal an Adobe Reader icon and it's not like they're publishing the sources despite copy-pasting something saying it's forked to keep it 'free'. |
|
@thestinger I'm sorry for what happened. That terrible licensing choice cost you about 1 year and 4 months of work; if you fork the project right before the license change you'll probably be able to recreate everything in months (the GPL code is not lost). Keep it free and you'll have a community with you: people recognize and respect your work. Set a concrete goal and donations will come too (a "donate" button is not enough). |
|
It didn't cost me anything. I own the code. |
|
I'm not doing any more work for free and I'm not going to beg for money. Either I get properly compensated to do the work along with a proper full-time development team or I'm wrapping it up and moving on to something better. It's far too broad a project with huge amounts of in-depth research / work to do alone. It also requires custom hardware to accomplish basic goals. You are part of why I am burned out and ready to move on just like my former business partner. I don't see much difference between his greed and your own. You're still focused on getting more stuff from me for free while I suffer through being overworked, not having time for a life outside of this and all while not earning a decent income from it. No thanks. |
|
I see you're still pushing an unmaintained fork of my early proof of concept code without incorporating the security updates and with a misrepresentation of the origin: https://f-droid.org/en/packages/org.ninthfloor.copperpdf/. I think that's quite dishonest and disrespectful. It's harming people. I realize you only want to push an ideology and don't care about the well being of other people including either myself or the users harmed by being misled on security. |
|
@thestinger the origin is attributed correctly: this software was already part of COS at the time it was forked. The README explains the status and aim of this repository, especially the fact that I'm not actively maintaining it, there is nothing dishonest, and I don't benefit in any way from it. I would be very happy to hand it over to somebody else. Yes, I push an ideology. We clearly disagree on what this means, and I have no interest in discussing it here. I'm sorry if my previous message was not sensible. I understand you are burned out, get your time back. Over and out. |
No, it isn't. It's wrong and is incorrect attribution which is against the terms of the license. I've explained that already and you lied about what you were going to do about it.
CopperheadOS chose to include it as it did with apps like Etar and F-Droid. That doesn't mean that it was a Copperhead(OS) project. I expect the attribution to be fixed.
It should explain that you aren't doing security updates and should be marked that way on F-Droid too. You should stop misleading them into thinking this was based on the hardened implementation which was finished before the documentation was written and should be giving correct attribution.
Sure...
Yeah, while harming the people that actually do the work.
I don't want to talk about your religious views on software licenses. I expect you to follow the terms of the license by giving correct attribution. The commits are from danielmicay@gmail.com on my own time and the attribution should be to me as I explained months ago. |
|
Not to mention that you merged code based on the work that I did after I changed the license. |
|
I wrote "If this app will get an update I'll remove the reference to CopperheadOS from the F-Droid description", but there were no new releases since then, so no lies. If you really care, just submit a GitLab merge request to change https://gitlab.com/fdroid/fdroiddata/blob/master/metadata/org.ninthfloor.copperpdf.txt While I don't care about what you expect from me, I do care about proper attribution. I will change the I'm not aware of copyright infringments. If you want to make such a claim please be precise, and please do it in a separate issue. |
|
How exactly is this okay? |
|
@thestinger you really need to go relax somewhere and stop beating this dead horse. Free software is a thing, no matter how much you argue against it. |
|
Lying about the origin of the code now? I think you need to go relax somewhere and learn to be honest. |
|
Anyway, I'll be taking legal action against people stealing my work including here. |
|
You wouldn't have even touched it if you hadn't been paid to develop features for my app. Nice try though. |
|
@thestinger since you're throwing around accusations, I'll state clearly where the code came from, and the context. I did some work on the Copperhead PDF Viewer, paid for directly by a client of Copperhead's, with Copperhead put me in touch with. So they own the copyright, not Copperhead. I submitted that in a merge request to Copperhead. Some time afterwards, I found myself wanting to use the improvements I'd made. It wasn't feasible to use Copperhead PDF Viewer, so I wrote new patches based on this project (CopperPDF) and submitted them in a merge request. So some ideas were developed while working on that contract, but this implementation was entirely on my own time, using zero of the Copperhead client's code. |
|
Not a truthful account and yet it demonstrates why this isn't legal. You don't own the copyright and it was derived from my work which is not licensed this way. |
|
and for the record, @thestinger only involvement in the project was reviewing the merge request, which he never accepted. |
|
Continuing to present an inaccurate / misleading account of what happened doesn't change the situation. You didn't follow through on what you were supposed to do and then violated the license. I expect the infringing code to be removed here. |
|
And in response to your deleted comment: I'm not infringing on the Apache 2 license and am in the process of landing my changes (one of which is public already) upstream too. And by that I don't mean submitting a drive-by contribution, ignoring code review and then violating the license. It doesn't make much difference that it's this tiny little bit of code where the issue is occurring. I would care a lot more if it was the Auditor app / AttestationServer or other larger / more relevant projects but this whole situation is still seriously wrong. |
I am using am SM-N910H smartphone. It is rather fast system to operate with even large books in pdf format. But this app opened and rendering every new page really slow.
The text was updated successfully, but these errors were encountered: