Hi Branden,
On Sun Feb 9, 2025 at 3:28 PM CET, G. Branden Robinson wrote:
> At 2025-02-07T16:20:23+0100, onf wrote:
> > I've been wondering lately about the rationale behind solving the
> > problem of font sizes being integer-only by adding scaled points.
>
> It's covered in groff_diff(7), the man page I believe you said you
> always forget about.
>
> groff_diff(7):
> Fractional type sizes and new scaling units
> [...]
I actually read the text you've quoted, and I understand why they were
added, but it doesn't explain why a simpler approach wasn't used.
> > Specifically, I can't help but feel like extending troff to represent
> > font sizes everywhere (except the .s register) in basic units would
> > be a much more straightforward solution, which wouldn't require new
> > units or a new DESC entry.
> >
> > Am I missing something?
[rerranging]
> Given that, I think AT&T troff's approach to type size measurement was
> mistaken, and James Clark's rethink of it for GNU troff an improvement.
I agree.
> The crux of the problem, as I conceive it, is that a "point" is a real
> unit of measure. It's 1/72nd of an inch. On groff's "ps" and "pdf"
> output devices, that winds up being one thousand basic units "u".
> [...]
>
> If we simply treat the point as a synonym for a basic unit in certain
> contexts (as AT&T troff did), the formatter's measurement system becomes
> inconsistent. We could nevertheless proceed on this basis, I think, by
> extending the foregoing framework of rules regarding where certain
> scaling units are accepted. However, I think doing so might frustrate
> troff users who wish to apply points as a length measure to something
> other than glyph rendering. [...]
> And in the elementary training I received in typesetting as part of a
> high school journalism class, I did in fact encounter a working
> typographer (the teacher) thinking of the point, like the pica, as a
> fully general unit of length measure. [...]
I think my use of the term 'basic unit' may have been misunderstood.
Let me rephrase it a bit...
[assumptions/guesses about implementation details ahead]
AT&T troff stores font size in points. This means it converts the
argument to .ps from whatever unit it's in (default is points) to
basic units and then divides that by the size of 1 point. Because
integer arithmetic is used, this results in truncation, preventing
the use of fractional sizes.
groff stores font size in scaled points. This means it converts the
argument to .ps from whatever unit it's in (default is 'scaled' points)
to basic units and then divides that by the size of 1 'scaled' point.
Because a 'scaled' point is several orders of magnitude smaller than
a point, this allows for the use of fractional 'unscaled' point sizes.
What I am struggling to understand is, why not just store it in basic
units? That is, why not remove the "divide by 1 ('scaled') point" part
entirely? (The 's' command of groff_out(5) would then be in basic units
instead of in 'scaled' points as well.)
> Where I have a problem, as is often the case, is with our choice of
> terminology. [...]the "scaled point" is a simply terrible
> term. It's not something that undergoes scaling in the mathematical
> sense in any way distinct from any other scaling unit. Both "unscaled"
> [sic] points and scaled points get scaled to basic units!
> [...]
>
> On my mental to-do list has been a renewed attack on this aspect of our
> documentation, and I finally, within the past couple of months, thought
> of a term I'm happy with to replace "scaled point".
>
> Subdivided Point
> [...]
> Not sure yet if the "sizescale" directive needs to change. It doesn't
> seem to have _any_ obvious meaning; rather it gestures in a vaguely
> accurate direction. "pointsubdivisions" would be really good, but
> for its unwieldy length. [...]
Allow me to suggest some shorter names:
ptsubdiv
pointsubdiv
psprecision
~ onf
