Follow-up Comment #3, bug #68256 (group groff):

Hi Deri,

[comment #2 comment #2:]
> This seems to work:-

Yeah, I think I managed not to get the case at issue working when I last
tackled this.

This:


.bd S TB 2400


...takes a different code path than this...


.bd S 3 2400


...because the former is not ambiguous at any point during lexical scanning,
and the second one is.

If all you've read is


.bd S 3


...you don't know yet whether "3" is an emboldening offset or a font mounting
position.

When investigating this, I reacted with horror to the code, much of which I
wrote to try to get it working and to overcome the "scanning ahead to
disambiguate" problem.  Historically this feature has not been well
implemented by GNU _troff_.  You pretty much _had_ to study grout to figure
out anything about it.  It's not testable on terminals, and within the
formatter, the `.b` register also for many years had an unfortunate habit of
lying to you.  See bug #67038.

I'm doing a pretty big refactor to address this.  Why?

Glad you asked.  Even if you didn't.  ;-)


-// XXX: We can only conditionally (un)embolden a font specified by name,
-// not position.  Does ".bd 1 2" mean "embolden font position 1 by 2
-// units" (really one unit), or "stop conditionally emboldening font 2
-// when font 1 is selected"?
+// XXX: This is the wartiest request in the language.
+//
+// Does ".bd 1 2" mean "embolden font position 1 by 2 units" (really one
+// unit), or "stop conditionally emboldening font 2 when font 1 is
+// selected"?
+//
+// GNU troff's approach:
+//   If the first argument is a font identifier (not a nonnegative
+//   decimal integer) _and_ it has the "special" property, interpret the
+//   request as demanding conditional emboldending.
+//
+//   Otherwise, interpret the request as demanding unconditional
+//   emboldening.  For a future direction, see Savannah #61450.
+//
+// GBR thinks it's not worth being smarter than this because (a) GNU
+// troff spent 35 years getting it wrong, and few people seemed to
+// notice; and (b) he finds both emboldening features to be of dubious
+// value, the conditional one especially so.  It seems to have been a
+// hack to compensate for some text glyphs on the Graphic Systems C/A/T
+// phototypesetter getting relegated to the "S" font, and so would set
+// in running text at an inconsistent weight when the surrounding text
+// glyphs came from the bold face.  I understand why people would object
+// to that, but I also object to the solution.  Glyphs in a special font
+// are supposed to be _unstyled_.  See groff_font(5) and groff_char(7).
+//
+// And another thing!
+//
+// This request is inherently device- and type size-dependent.  The
+// emboldening amount is in basic units.  So with a request like `.bd S
+// 3 3`, interpreted on the C/A/T device with a resolution of 432
+// units/inch, you get an emboldening offset of about 5%.  Take that
+// same request and interpret it on groff's PostScript or PDF devices,
+// where the resolution is 72,000 units per inch--almost imperceptible.
+//
+// For a user to employ `bd` portably, they need to scale the
+// emboldening amount themselves using arithmetic.  Something like this?
+//
+// .nr ui 1i        \" units per inch
+// .nr ea \n(ui/20u \" divide by 20 for a 5 percent overstrike offset
+// .bd S 3 \n(ea    \" embolden special font by 5% when font 3 selected
+//
+// Even then, an overstriking offset of 1/20th of an inch is going to
+// look one way at 10 points and another at 36 points.  At some sizes,
+// an offset will be nigh-invisible; at others, revoltingly ugly.
+//
+// Ossanna could have riffed on his own technique from the (nowadays
+// equally obscure) `cs` request, which used units of thirty-sixths of
+// an em.  To keep the arithmetic integral, hundredths of an M would
+// have been practical, and device- and face-independent.
+//
+// If I should bump into Joe in the afterlife, I'll be sure to tell him.




    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?68256>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

Attachment: signature.asc
Description: PGP signature

Reply via email to