How shimanto008/print-bill-calculator works
1. Repository shape
- This is a single-file, client-side app: index.html contains the entire product, with the README describing usage and behavior.
- There is no backend, no build pipeline, and no separate source tree visible in the repo.
2. Primary runtime boundary
- The app runs entirely in the user’s browser on a local PC/laptop.
- The main architectural boundary is browser memory and DOM only; nothing is sent to a server.
3. User-facing purpose
- The tool calculates a printing bill by determining which pages are colour and which are black & white.
- It supports PDF and Word (.docx) documents.
4. Input layer
- The user provides:
- a currency selection
- price per colour page
- price per black & white page
- one or more uploaded documents
- The file upload control is the entry point into the processing pipeline.
5. Document processing pipeline
- Uploaded files are handled locally in the browser.
- The app must parse the document content page by page, classify each page as colour or monochrome, and count totals.
- That page classification step is the core domain logic of the app.
6. Pricing / calculation subsystem
- Once page counts are known, the app multiplies them by the user-entered rates.
- Currency is a presentation and formatting concern, while the actual bill amount is derived from:
- colour page count × colour rate
- black & white page count × B/W rate
7. Output / presentation layer
- The result is displayed directly in the browser as the calculated bill.
- The UI likely shows totals and cost breakdowns, since the README says “Read your bill.”
8. Data flow
- The flow is: user inputs settings → uploads document → browser parses pages locally → classifier counts colour vs B/W pages → calculator computes total → UI renders bill.
- There is no intermediate server-side state or external persistence in this flow.
9. Privacy and trust boundary
- The app explicitly claims that no files leave the device.
- That means the privacy boundary is the local machine; the repository is architected to avoid network dependence and remote storage.
10. Technology footprint
- The project uses plain HTML, CSS, and JavaScript only.
- There are no frameworks, no dependencies, and no internet requirement, so the architecture is intentionally lightweight and self-contained.
11. Implication for an architecture diagram
- A good diagram would show:
- User/browser as the only runtime environment
- index.html as the complete UI + logic container
- a local file input / document parser
- a page classification and billing calculator
- a rendered bill output
- There should be no server, database, or external API in the diagram.
Main entry points: index.html Local only · README.md README
Components 9
Repository
Single-file client-side calculator app and its README.
Browser runtime
Everything runs locally in the user’s browser with no server or persistence.
- Inputs · Currency selection, colour rate, B/W rate, and document upload controls.
index.html - File upload · Accepts local PDF and DOCX documents from the user.
index.html - Parser · Reads uploaded documents entirely in-browser and extracts pages.
index.html - Page classifier · Determines whether each page is colour or black and white.
index.html - Bill calc · Multiplies page counts by user-entered rates to compute totals.
index.html - Bill view · Displays the final bill and breakdown directly in the browser.
index.html - Local only · No files leave the device; processing stays on the local machine.
index.html
Connections 11
- README → App shell: describes · README explains the single-page app behavior.
- App shell → Inputs: hosts · The HTML file contains the visible controls and logic.
- Inputs → File upload: submits · User settings and file selection enter the processing flow.
- File upload → Parser: sends files · Local documents are passed to the browser parser.
- Parser → Page classifier: page data · Parsed pages are analyzed for colour versus monochrome content.
- Page classifier → Bill calc: counts · Page counts feed the pricing calculation.
- Bill calc → Bill view: bill · Computed totals and breakdown are rendered for the user.
- File upload → Local only: stays local · Uploaded files remain on the device during processing.
- Parser → Local only: browser only · Parsing happens in browser memory and DOM without server calls.
- Bill calc → Local only: no backend · Billing is computed entirely client-side.
- Bill view → Local only: no sync · Results are displayed locally and not persisted remotely.