How to create a custom print pricing calculator on the Numbers app?

Scroll up and re-read the thread.

A spreadsheet still isn’t the right tool for this.

Try using a Shortcut: Intro to Shortcuts on Mac - Apple Support

Or get somebody to write some JavaScript for you, if you’re planning on making this web-based.

Who is the audience for this calculator? You? Or are your customers inputting this data?

For a custom calculator for yourself, create and use a Shortcut app for yourself. The Apple Shortcuts app can do custom math calculations. Shortcuts is free in the Apple App Store.

Or for your own you can use PCalc and create a user formula: https://s3.amazonaws.com/tlasystems/PCalc-Manual.pdf. PCalc is a very capable third-party calculator app.

Numbers also can do formulas, of course. But while a spreadsheet is probably workable, it isn’t a great fit for a calculator.

If the customer is entering this data, then it’s not likely going to be Numbers or PCalc, it’ll be a website. That website and that calculation can then be implemented in various ways including using JavaScript / ECMAScript, or going old-style with a CGI script written in whatever language preferred.

Or one of the existing small-business online-sales website services. Those can have purchasing and billing built in.

Some of your potential customers will have Numbers, but many won’t.

If you really want to present a spreadsheet to your customers, Google Docs or another hosted tool. But that approach can have issues with defacements.

All is possible but, as with most of these things, the devil is in the details, especially when it comes to rounding and non-standard sizes :)

For example, for a single 8" x 10", that is, technically, 80 square inches, or 0.55 square feet, so is that priced at $20 x 0.55 = $11.11 ($11 rounded to the nearest .50), or are you rounding up to the next square foot and charging $20?

Similarly, I'm assuming there is a physical limitation in the printer size. Assuming you're using a wide-format printer, you're likely limited to 36", 44", or 64" widths. So when you have an order for 100 prints, you need to work out how many prints wide you can print, when then dictates the length of media used, and thus the square footage.

For example, if you're using a 36" printer and printing qty 100 of 8" x 10", you could print 4 images wide (on the 8" side) and 25 long, meaning you're using 250" of 36" wide media (750 sq ft), or you could print 3 images wide (on the 10" side) x 34 images long, for 272" x 36", or 816 sq ft. Clearly one is preferable... do you want the formula to take account of that, too? or are you just working on the raw print area (100 x 8" x 10" = 666.66 sq ft., no matter which way you're oriented).

So filling in the details will go a long way to finding a path forwards.

Pachanguero wrote:

Thank you for the quick reply!

I would like to provide a print price calculator on my website so customers can estimate their costs. Haven't had any luck finding an adequate out-of-the-box solution. Sounds like you are suggesting custom coding. I'll look into that.

You’re not going to get (most) customers to use a web-based spreadsheet.

Either custom coding, or a package intended for or with support for photography or printing.

The math part of this isn’t all that difficult, either.

Have a look at whatever content management systems or storefronts you’re considering running (various pre-built storefront services exist), or at some CGI or JavaScript or such if you’re considering embedding this into your own static website.

Got it. It's not really a Numbers-related thing, then, since it doesn't directly involve using a spreadsheet.

I concur with MrHoffman's response that it will need to be part of whatever web platform you're using for your site. There are many out there.

> I've got someone who is going to write code for this project and they have requested a spreadsheet for reference.

Then send them this spreadsheet. That has the data they need.

Regardless of how they're coding this for a web site, whether in the browser via JavaScript, or server-side, Numbers is not going to be part of the equation.

You can use it to build the rates table, but the web site won't use Numbers real-time for the pricing. The developer will take the spreadsheet you have and transpose it, somehow, into something the web site can use, without running Numbers interactively.

As the web site owner, you should make sure there is a clear step for updating the rate table in the web app so that you can update the rates as often as you need, without needing to pay the developer to incorporate the new rates.