From: Ben Harris <bjh21@bjh21.me.uk>
Date: Mon, 28 Oct 2024 15:05:11 +0000 (+0000)
Subject: Some thoughts on UnitsPerEm
X-Git-Tag: bedstead-3.246~98
X-Git-Url: https://www.chiark.greenend.org.uk/ucgi/~bjharris/git?a=commitdiff_plain;h=3653fab92e12425faf187275f1ffd7d39f5e9a6b;p=bedstead-debian.git

Some thoughts on UnitsPerEm
---

diff --git a/NOTES b/NOTES
index d5c6d59..0520c5e 100644
--- a/NOTES
+++ b/NOTES
@@ -136,3 +136,23 @@ NO-BREAK SPACE followed by U+200B ZERO WIDTH SPACE leads to all the
 spaces' being too wide, but consistently so without any overlaps.
 
 This bug appears to be https://bugs.webkit.org/show_bug.cgi?id=236307.
+
+Choice of design unit
+=====================
+
+Bedstead uses a design unit of 1/1000 em, largely because that's
+traditional for PostScript fonts.  But that does have some problems,
+and in particular depends on being able to encode arbitrary rationals
+in CFF fonts, which means that odd widths end up with significantly
+larger font files.
+
+So what are the constraints on design units if we want to get more
+integers in the output?  Assuming we can tweak XQTR if we need to.
+
+UnitsPerEm must be a multiple of 10 for vertical pixels.
+
+But horizontal pixels vary in width by factors of 1/8, so must be a
+multiple of 80.
+
+XQTR and YQTR want to be about (UnitsPerEm / 10) * (1-1/sqrt(2)).
+That's about (UnitsPerEm / 10) * 0.29289321881345254.