Lowercase letters save data
Lowercasing text can slightly improve compression ratios because it removes case variation that compressors must encode, but commenters note this is essentially just discarding information rather than a property of lowercase itself. Many argue that readability, typography conventions, and proper capitalization of names outweigh any minor bandwidth gains, and that normalizing to all uppercase would have a similar effect on size. The thread branches into related topics such as information theory, QR code encoding modes, Unicode edge cases (like Turkish “i” and Han unification), and the limits of linking byte savings to carbon footprint estimates.
Readability and Use of Case
- Many disagree that lowercase “greatly” enhances readability; some find all-lowercase or all-caps equally legible once you’re used to them.
- Others report personal difficulty with title case and prefer sentence case for headings and body text.
- Road signage studies (US highway signs) are cited as evidence that mixed case is easier to read than all caps, though the mechanism (word-shape vs letter-level recognition) is debated.
- Several note that many languages using Latin script (e.g., French, Spanish, Italian) normally use sentence case for titles and do fine without special title-case rules.
Compression, Information Theory, and “Saving Data”
- Core point: lowercasing (or any normalization) doesn’t inherently save data; removing distinctions (e.g., case) lowers entropy and improves compression. All-uppercase would have the same effect.
- Multiple commenters stress this is lossy: you can’t always reconstruct original capitalization, which may be semantically significant (e.g., “jack” vs “Jack”).
- Some argue a good compressor should already exploit patterns like “period + space + capital,” making manual case-flattening less compelling in principle.
- Others suggest semantic-aware or dictionary-based schemes would dwarf any gains from case normalization.
Technical Nuances: HTML, SVG, Brotli, QR Codes
- For HTML doctype and attributes, one commenter shows gzip vs Brotli can behave differently; Brotli’s static dictionary can favor common but suboptimal patterns (e.g.,
<!DOCTYPE html>). - In SVG path data, blindly lowercasing commands is called “dodgy”; choosing absolute vs relative commands and trimming syntax matters more than case.
- QR codes are an exception: their “alphanumeric mode” encodes uppercase-only text more efficiently, producing smaller/less dense codes.
Names, Unicode, and Locale Issues
- Case-folded names (e.g., “VINCENT VAN GOGH”) lose important capitalization details, especially for particles like “van/de/von,” which vary by language and region.
- Unicode case mapping is tricky and locale-dependent (e.g., Turkish dotted/undotted “i”, German ß). Simple “normalize to upper/lower” may not round-trip correctly.
- Han unification and national character-set standardization are noted as broader examples of cultural bias and controversial unification tradeoffs.
Chess Compression Tangent
- A long subthread explores bit-level encodings of chess positions and games: specialized piece encodings, pawn-structure tricks, move-index schemes, and use of general-purpose compressors afterward.
- It illustrates that domain-specific modeling can beat naive encodings, but also becomes complex, with diminishing returns.
Environmental and Meta Points
- Some like the article’s compression trick and framing; others call the premise misleading or infuriating if interpreted as a prescription for writing style.
- The “bytes saved = CO₂ saved” framing is criticized as oversimplified; real energy/carbon impact per byte is seen as highly uncertain and stack-dependent.
- HN’s own title-casing/mangling is mentioned as an example of automated case changes people often dislike.