It seems to me that they are using Rollup to bundle the PDF.js source code into their own.
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.
DevDependencies are not installed when you use —production flag at npm install (saving space and time here when you include this package) they are only used for releasing the package versions in this case I assume.
Yes, I understand the general use of dev dependencies. However, in this case, 'pdfjs-dist' must be in the build output anyway. So, what is the benefit of including it indirectly?
Yeah that's the most forgivable part ;). I never understood this particular idiosyncrasy - after all you don't say "it costs dollars three", and you also put other units of measure after the value, e.g. 80 mph, 100 °F, so why on earth does the dollar sign have to go before the amount?
Wow, you're right! It's crazy how you can go your whole life never noticing or thinking about something like this that is so clearly irregular, just because it's the way you've always seen it or thought about it.
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 think it’s so you can fit the cents symbol at the end e.g. $6.75c - but this isn’t really used anymore so the dollar sign at the front is a bit of a historical anomaly at this point.
Honest question, was it ever used in that combination? I've seen ¢ used for amounts less than a dollar, e.g.: 75¢. I (still) sometimes use it like that, because, I guess, it makes me feel adjusted to my environment, as an ESL :-) But I've never seen both $ and ¢ in the same amount/expression.
Ah, so I also don't think I have seen this in practice, but I suppose it's possible that it originated from pre-decimal-system currencies, like the old British money system, where perhaps it was more important to use separate units for clarity.
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.
It makes it harder to modify amounts on checks and accounting entries. 100.00$ could more easily be turned into 1100.00$ than $100.00. It comes from a time when we did still write a lot of amounts by hand.
Except that for checks, it's not the numerical part written in the little box that matters, it's the full written amount e.g. 'Five Thousand Three Hundred Fourty-Seven and 33/100' for 5,347.33.
Similar rationale, though, because it's easier to modify a number (say, change a 7 to a 9) than to change a full word.
The only exception I could think of was R-values, eg, "Vacuum insulated panels have the highest R-value, approximately R-45 (in U.S. units) per inch; aerogel has the next highest R-value (about R-10 to R-30 per inch), followed by polyurethane (PUR) and phenolic foam insulations with R-7 per inch." , quoting https://en.wikipedia.org/wiki/R-value_(insulation)#Example_v... .
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.
that's something i keep wondering about as well. i think it depends on the reputation of the company/project. some of them probably do attach it to the option that is actually most popular, but i'd guess that most of them do not.
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.
It's a self-fulfilling prophecy at best. I don't think anyone[0] actually marks pricing plans by what's actually most popular.
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.
The license seems a bit ambiguous. $49 for a "one user license", I hope that really means "one developer"?
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.
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."
> The license seems a bit ambiguous. $49 for a "one user license", I hope that really means "one developer"?
> 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"?
It clearly says "Use in multiple websites" under both licenses, so it's talking about devs not users (like most such licenses).
It wraps a normal Javascript library into a React component, which is very useful for many web applications.
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.
React is basically a "State within a state" of front-end - it's so focused on single-purpose libraries that just about everything has its special, React-only equivalent. So much so, that there are people who just assume that React = front-end, even though that's very much not the case.
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.
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.
In my personal experience, it is not so much about the money, but about the work involved to find out the specific conditions for a license. As most open source software uses similar licenses, there are fewer surprises.
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.
> It's not that the software might not be good, or might not help them, but "it should just be free".
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.
I am quite happy with the pdf.js default viewer, which does not have react dependencies and does not need to download a meg or two to work. It does not require me to allow all kinds of scripts from the website or even third party scripts from random CDNs. It also does not need a purchase of a license. It has so far always been snappy for me.
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.
This borderline seems like a license trap: use common keywords as your package name to boost visibility, post it on NPM (with the license truncated so much as to be useless[1]), and then wait for an unsuspecting developer to pull in the package so you can file suit.
How can you call yourself a web developer when your PDF viewer doesn't even require 2 GB of RAM. This is the future, old man.
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.
It could become a kind of licensing condition or similar, that you have to allow it, in order to use it. And then uninformed tech decisions force you to use such crap at the job, all while you know, that your development machine is mining ... What a nightmare.
This is just a wrapper around pdf.js, so probably yes.
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.
Once I was stuck in this Pdf viewer trap. I learned hard way that the browsers default pdf viewer operates in its own sandbox - to which I have no access. My client wanted to edit the data displayed in the pdf viewer and save the latest in a backend storage on Print. I thought I would find the control via document.getElementById (or something similar) grab the latest data, save it, and call it a day; but - nature has some other plans for me.
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.
75 comments
[ 2.4 ms ] story [ 157 ms ] threadhttps://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.
https://react-pdf-viewer.dev/
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.
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?
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.
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.
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).
Also, it appears to be feature-rich and yet easy to use for simple use cases.
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.
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.
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.
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
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.
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.
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.
https://github.com/mozilla/pdf.js
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..."
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.
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.
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?
https://github.com/mozilla/pdf.js/issues/7967
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.
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.