chiark / gitweb /
Some thoughts on UnitsPerEm
authorBen Harris <bjh21@bjh21.me.uk>
Mon, 28 Oct 2024 15:05:11 +0000 (15:05 +0000)
committerBen Harris <bjh21@bjh21.me.uk>
Mon, 28 Oct 2024 15:05:11 +0000 (15:05 +0000)
NOTES

diff --git a/NOTES b/NOTES
index d5c6d59e67c2c8365bb68acd36abc5e4664dce59..0520c5eb302833c4048922a7821b850023a26445 100644 (file)
--- 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.