mirror of
https://github.com/InvoiceShelf/InvoiceShelf.git
synced 2026-08-04 07:02:13 +00:00
fda75e9af7
dompdf does not use a declared line-height directly. It scales it by the font's
own height:
rendered = declared x (ascent + descent) / unitsPerEm x font_height_ratio
The bundled Noto Sans reports 1.362 for that middle term, so at dompdf's stock
font_height_ratio of 1.1 every line-height in every document came out 1.4985x
what the CSS asked for. Chromium honours the declared value exactly. That one
factor was the whole vertical disagreement between the two drivers.
Setting the ratio to 1/1.362 cancels the font term. Measured on a declared 15px
(11.25pt): 16.86pt at the stock 1.1, 15.32pt at 1.0, and 11.25pt at this value --
identical to Chromium.
Across the seven document templates the worst-edge ink difference falls from
roughly 70-150pt to under 30pt on six of them, and to 3.4pt on invoice1. The
exception is estimate1, which moves the other way: with the line-height noise
gone, a float and padding difference in its address block is now the dominant
term there. That is a separate problem this exposes rather than causes.
Worth recording that an earlier compensation shim had arrived at 1.5 empirically
and was right: 1.1 x 1.362 = 1.4985. I argued against it on the strength of a
test that used font-family: sans-serif, which resolves to a built-in core font
and so never exercised the embedded Noto Sans path where the scaling happens.
The measurement was wrong, not the constant.
PdfLineHeightTest pins the invariant -- the font's reported height equals the
font size, so a declared length renders at that length -- and needs no Gotenberg,
so CI holds it. Swapping the default face or taking a dompdf upgrade that changes
the computation now fails a test rather than quietly reintroducing the drift.
Claude-Session: https://claude.ai/code/session_01QmECndmNZwzN65Zz9P87dF
Introduction
InvoiceShelf is an open-source web app that helps you track expenses, record payments, and create professional invoices and estimates. It is self-hosted, multi-tenant, and built for individuals and small businesses that want to keep their books on their own infrastructure.
The web application is built with Laravel and Vue 3.
To get started using Docker Compose, follow the Installation guide.
Table of Contents
Documentation
System Requirements
- PHP 8.4+ is required (since v2.2.0, when InvoiceShelf moved to Laravel 13).
- Database: MySQL, MariaDB, PostgreSQL, or SQLite.
- Before updating from inside the app, verify your server meets the target version's PHP and extension requirements.
- The in-app updater verifies requirements and refuses to proceed if they are not met.
Download
Discord
Join the discussion on the InvoiceShelf Discord: Invite Link
Roadmap
Rough roadmap of things to come, not in any specific order:
- Automatic Update
- Email Configuration
- Installation Wizard
- Address Customisation & Default Notes
- Edit Email before Sending Invoice
- Available as a Docker image
- Performance Improvements
- Customer View Page
- Custom Fields on Invoices & Estimates
- Multiple Companies
- Recurring Invoices
- Customer Portal
- Decoupled system settings from company settings (v3.0)
- Proper multi-tenancy system (v3.0)
- Company member invitations with custom roles (v3.0)
- Dark mode (v3.0)
- Full TypeScript refactor of the frontend (v3.0)
- Improved backend architecture (v3.0)
- Security hardening (v3.0)
- Reworked installation wizard (v3.0)
- Module Directory (v3.0)
- Rewritten Payments module (v3.0)
- Accept Payments (Stripe integration)
- Improved template system for invoices and estimates
Translate
Help us translate InvoiceShelf into your language: https://crowdin.com/project/invoiceshelf
Star History
License
InvoiceShelf is released under the GNU Affero General Public License v3.0. See LICENSE for the full text.