Follow-up Comment #35, bug #63354 (group groff):
This looks great!
Here's the definition from the sample file, broken down and commented, and
trivially refactored (to avoid performing the same \w twice when the value of
the first is already stored in a register):
. char \[u2012] \R#wzero \w'0'u#\# set width of a figure, setting
\n[rst]
\R#hzero \\n[rst]u/2u#\# set horizontal midpoint of a figure
\R#lfiguredash \\n[wzero]-(2*\w'\^'u)#\# set dash length
\^\
\v'-\\n[hzero]u'\# adjust horizontal position
\D'l \\n[lfiguredash]u 0m'\# draw dash
\^\
\v'\\n[hzero]u'\" restore horizontal position
The glyph is exactly the right width, and the spacing between it and the
surrounding figures seems ideal.
As the fourth line of output shows (the one that puts the created figure dash
on the same line as stock dashes and hyphens), it's a little too high in the
line. This is true across all the font families that ship with groff; dashes
and hyphens are typically set below half-height so they interact well with
lowercase letters.
This is easy to adjust by tweaking the "rst / 2" calculation. The tricky part
is finding an adjustment that works in all families. The best compromise I
could find was \\n[rst]u*10/27u (groff's integer arithmetic prevents simply
using a value between 2 and 3 in the denominator), which set the figure dash a
bit too high for a couple families, a bit too low for a couple others, and
just about right for several. But unless the dashes are right next to each
other--which shouldn't happen in real-world usage--the difference won't be
noticeable.
Alternately, .fschar could be used to tailor the dash for each groff font.
But there would still need to be a generic fallback for any user-supplied
fonts, and the metrics for this would still be speculative.
In most families (all stock groff families but C, P, and T), the generated
dash is also skinnier than the font-supplied ones, but for a fallback
definition, I propose to not worry about this level of detail. Alternately,
as above, .fschar could be used, with the same caveat.
Notably, the existing \[u2012] fallback in fallbacks.tmac already has a
hard-coded height and thickness that don't exactly match every family; this
proposed replacement improves on it by giving it the correct width, allowing
figures on adjacent lines to align properly.
A couple of potential implementation issues, ordered from most to least
important:
* This character's internal use of \w will clobber any values of its
side-effect registers (st, rst, ssc, etc.) that the user may have been relying
on. (Also true of the existing \[u2012] fallback.)
* The three named registers (wzero, hzero, lfiguredash) will clobber any
registers by those names the user is using. (These names could be tweaked to
make collisions less likely, at the minor expense of code readability.)
* Unlike .nr, the .rr request has no corresponding escape sequence, so it's
impossible to clean up the registers.
I think making available a working U+2012 is a big enough gain to offset these
drawbacks, especially given the hope that over time, more fonts (perhaps
someday, even those that ship with groff) will include U+2012, and this
fallback will see less use.
Anyone have thoughts on any of the above?
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?63354>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
