Follow-up Comment #35, bug #64155 (group groff):
[comment #34 comment #34:]
> > > Well, when you're prepared to discuss it, it would be good to know
if/how Dave's original report in comment #0 was invalid
> >
> > I think I can answer this - it is certainly not invalid, it just has
nothing to do with ZD not being a "proper" family (in your eyes).
>
> This isn't a matter of my subjective opinion; the "family" and "style"
features of _groff_ date back to 1990.
>
>
https://git.savannah.gnu.org/cgit/groff.git/tree/ChangeLog.115?h=1.23.0#n5535
>
> There is a long AT&T _troff_ hangover of assuming that `R`, `I`, and `B`
fonts will exist (or, in _groff_, that abstract styles that work analogously
to fonts of those names will). This assumption can extend to `S` as well.
I don't dispute R, I, B, and BI is a family, it's not the only possible
family, previously a font family of just R and B would be happily accepted and
\fBword\fP worked as expected. It was your code which insisted on a far more
inflexible rule.
[...]
> > If you do -fZD, which has no alphabetic glyphs, any start up macros which
contain conditional statements of the form:-
> >
> > .if '\*[.T]'html' \" etc..
> >
> > Will produce character not found errors, since, as we know, both sides are
formatted in separate environments and compared.
>
> Yes. I find this troublesome.
>
> It seems to be an idiom to use the output comparison operator (a term I had
to coin, for it had no name) for string comparisons even when there is no
intention of formatting either of the comparands as text.
>
> But that idiom would seem to port poorly to document environments where the
basic Latin alphabet doesn't need to be formatted at all.
>
> > The give away in Dave's initial report is that the "character undefined"
errors spell out the words "ps/pdf/html" at least can be seen.
>
> You paid better attention than I did. I managed to overlook it, staring
more closely at the 1.23.0 output, seeing only the character sequence
"psaciltnufhm", and deducing nothing much in particular from that.
>
> Good sleuthing!
>
> But also there's no way in hell we should be spewing diagnostics on, or
failing to correctly perform comparisons within, control structures that are
initializing the state of the formatter. These macro files are profoundly
uninterested in formatting any output, and they'd be buggy if they did so,
since an empty input document should produce no output no matter what (stock)
macro packages or startup macro files you load.
>
> Maybe it is time for a proper string equality operator in our conditional
expressions.
Ooh, yes please.
> > I'm sure this "feature" has come up before. Even with Branden's code which
stopped -fZD from working did not address the real problem because if you have
four fonts with R, I, B, and BI extension but don't contain alphabetic
characters, -f works for the "family" but you will see exactly the same errors
as Dave reported.
>
> Fair point.
>
> > One way for a proper fix, is to create a copy of TR as TRSKEL, add the
"special" parameter, and change the name parameter to TRSKEL, remove all
kernpairs, delete all glyph definitions above 127, and finally alter the DESC
file by incrementing the number and adding TRSKEL on the end. This will solve
the error occurring if you use -f on fonts which don't contain ascii glyphs,
such as some CJK fonts. This can all be done in the devpdf directory (I have
done it for testing), but a very similar change can be made to devps as well.
>
> Here, I must disagree. The foregoing strikes me as a workaround rather than
a proper fix.
I agree, it's a workaround, but it is also a proper fix in the sense that it
prevented Dave's errors appearing for non-latin fonts, which you agreed your
code did not (so was not a proper fix).
[...]
> A string equality test. Not a comparison of node lists, which are laden
with all sorts of other data.[1] Just a string equality test.
>
> Well, let's give the people what they are asking for. Especially since a
lot of the time, "the people" is us.
+1 here, that would be a proper fix too. What semantics are you considering
for this new conditional?
> [1] Now that I've started resurrecting and expanding the formatter's
facilities for node dumping, I'm getting a better notion of what all that
extra data is. I begin to revise upward my expectations of the performance
improvement I can expect from a straight-up simple string equality operator,
particularly since the operation can be handed off to the C++ standard library
and from there, likely to platform-specific, optimized assembly code. It
hasn't escaped me that this might also help, say, string comparisons of PDF
bookmark tags, since they too are not output to be formatted.
I liked .pline.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?64155>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
