React PDF Viewer
github.com
github.com
So unless the feature set of this is so unimaginably great, that it completely revolutionizes PDF viewing, I doubt, that I will ever have a use for it. Maybe a PDF reading focused website could offer it as an alternative viewer, while obviously still preserving the option to view in the standard PDF viewer. Maybe that would make sense then for people, who need it fancier.
One day, each window, page, tab -- and even individual elements of the web page -- will run in its own docker container. Imagine all the clock cycles we could harness.
Pretty rich, considering they're licensing this commercially.
[0] https://www.npmjs.com/package/@react-pdf-viewer/core
[1] On a 4K screen, the most I can see of it is "https://react-pdf-vie..."
The reason for that is that we tried pdf.js earlier this year and it is very CPU/mem hungry once you go past simple PDF's it becomes noticable.
Also rendering 5-6 single page PDF's in the same web page made Safari bog down.
This is what PDF.js is...
> PDF.js is built into version 19+ of Firefox.
But one developer can build an app used by many users. So I suppose you are oddly pressured into buying the more expensive license because you probably have more than one "user"?
Generally, I feel uncomfortable investing in source-available tools. That said, if I needed a PDF viewer in a React app in a pinch, I'd probably reach for this and pay for the full license.
More details on the license found here: https://react-pdf-viewer.dev/license/
This is the part that would freak out most lawyers: "You may combine the Item with other works and make a derivative work from it. The resulting works are subject to the terms of this license."
It clearly says "Use in multiple websites" under both licenses, so it's talking about devs not users (like most such licenses).
for example, if a thing has three pricing options (free, paid, and enterprise), it is always the second option (paid, but not enterprise) that has the "most popular" badge. which seems suspicious to me in cases where the free version is sufficient for most users and as a result there isn't really much of an incentive to switch to a paid plan.
The idea behind these callouts is to direct people away from the lowest tiers. According to theory, some buyers will always go for the priciest plan because they want "the best of the best" but most will try to get the best value for their needs. A common trick is to have a slight price increment between the bottom and middle tier and then a large increment between that one and the top tier because this suggests that you're leaving money on the table by going for the cheapest option. As an approachable example consider McDonald's McNuggets sizes where the smallest size has a noticeably higher cost per nugget than the next one up.
It's a bit silly in this case as an organization plan has a different target audience from a personal plan but to me this suggests the license works in such a way many organization end up buying only a single personal plan because the organization plan doesn't provide any added value beyond allowing multiple developers to work with it.
A common pricing strategy is to either only have two plans (free/paid or personal/organization) with easily distinguishable value propositions or to have multiple pricing tiers (e.g. basic/premium/professional plus a de-emphasized free/minimal "trial" plan and an option to get a custom offer for enterprise) with only the latter strategy normally having these callouts.
If a company does use "most popular" based on actual popularity, they'll likely only do so when the most popular option is the one they actually want you to pick anyway.
[0]: To be fair, a few years back I once came across a pricing page that had tons of plans and did distinguish between "most popular", "best value" and such. But this is a rare exception and I still don't think they actually measured that one.
Similar rationale, though, because it's easier to modify a number (say, change a 7 to a 9) than to change a full word.
#$105.90#
Is this just local to me?
I thought for a few minutes about the reason that units of currency are different and come before the number, determined there must be an obvious logical one. But, if there is, I can't think of it!
I suppose it's also possible it needs to sometimes be used (although, again, I have never seen this) in certain cases in more 'formal' situations - accounting, contracts and so on. I guess the format, with the symbols wrapping the numbers so as to make them easier to parse, does make sense.
From the same source, "an R-value expressed in I-P (inch-pound) units[13] is about 5.68 times larger than when expressed in SI units"; the latter being measured in K⋅m2/W.
I really hate it when websites tries to be smart about PDF viewing. The builtin view is much better and faster.
The demo at https://react-pdf-viewer.dev is just not as good as opening the PDF directly in the browser.
E.g. A business process involving PDF's could auto annotate some information for a human processor to whizz through.
I am the author of a similar source available package and selling to developers has been such a painful experience. They (we) have one of the most privileged situations when it comes to finances but they are so reticent in buying software. It's not that the software might not be good, or might not help them, but "it should just be free".
That has been my experience. Since my indie developer endeavour, I changed the way I see other solopreneurs and their businesses.
Let's support each other through projects like these and these types of licensing and stop taking things for granted.
Quite often, some extra administration is required, just to ensure that a license is used correctly.
More recently, with subscription based pricing models, I find it very hard to determine the actual cost upfront. With free software this insecurity is not present.
Possibly the most important factor here is trust. With open source communities, I find it fairly easy to determine the quality of a product, and its development team. Commercial companies tend to hide their internal communication, making it harder to assess priorities and how problems are resolved.
I wonder if these issues could be solved by intermediaries.
The problem is not that the software is unfree (i.e. the software costs money), the problem is that the software is unfree (i.e. the license is proprietary).
Source-available software is usually not as flexible as free and open source software, because it has additional restrictions on how the code can be used or redistributed. When there are two software options with equivalent feature sets, and one is source-available while the other is FOSS, it makes sense in many cases to prefer the FOSS one for its more flexible licensing.
The main exception is if a developer is selling proprietary software and wants to incorporate copylefted FOSS in a way that would be incompatible with the license, in which case a custom licensing agreement (multi-licensing) could satisfy both parties.
https://github.com/react-pdf-viewer/react-pdf-viewer/blob/ma...
Not sure if this was the goal.
I’d guess it makes sense for PDF.js since you likely won’t need it outside of this library in your own project and it comes with multiple builds, of which they might choose one specific.
Then install speeds are faster and node_modules are smaller.
I ended up downloading pdf.js, which has about 30k lines of code. Imagine getting familiar with all of that, making changes, and getting the final output approved by various stakeholders - execs in the loop. Yeah, my reputation was on the line.
Is that possible with just pdf.js
I’d like to have PDFs viewable in pdf.js reader that are available to download, but when downloaded, they are protected with a pdf password.
Anyone know how this can be done?
But you should know that if it is viewable by pdf.js in the browser then it will be possible to download it without a password too since you need pdf.js to somehow read the file and pdf.js runs client-side.
The license is probably cheaper than having a front end dev invest time into making this embedding work well. Well-built React components can be a great business if you can entice enough people to use them and provide enough support.
In most desktop applications, you can probably get away with an iframe to do much of the same thing if you want an alternative. Just put up a static HTML file on your web server that loads pdf.js and takes a path to a PDF file to render and you're pretty much done. If you want to work around the annoyances iframes cause, this library is probably along the lines of what you'd build.
A bit like email to fax services. Or PC cleaners. Want to edit a PDF for free? That is going to be a very unpleasant experience.
Counterexample is drawing programs 2D and 3D. Lots of excellent free open source software from Inkscape to Blender to Photopea.
Draft.js is a popular example of what I'm talking about - other libraries would just wrap around a WYSIWYG solution and call it a day. Also note how this PDF component is not advertised as a wrapper, but is one in reality.
For people who want a React wrapper around pdf.js, there are open source alternatives such as react-pdf: https://github.com/wojtekmaj/react-pdf
Also, it appears to be feature-rich and yet easy to use for simple use cases.