Follow-up Comment #8, bug #58962 (project groff):
[comment #7 comment #7:]
> I didn't because I fear encoding mangling.
Good point. I just downloaded it, and it came through as a Latin-1-encoded
file identical to the original, but that's with one browser on one OS (both
the ones I used to upload it in the first place, so I'm kinda stacking the
deck).
> Try unpatched troff with the -R flag to shut off the loading
> of troffrc.
Ah, yes, with that I see the same results you pasted at the end of your
comment.
> I _think_ what's happening here is that it's being handled
> not exactly as a space, but as an undefined glyph for which
> no information is available. I haven't chased it down, but
> I'm guessing that when that happens you get an unbreakable
> space of 'spacewidth' size in the current font.
Aha, this explains why when I went looking for the code that did that mapping
a while back, to see if I could create a simple patch that would resolve this
bug, I was never able to find it.
So the patch looks good as-is. One refinement that could maybe be made:
instead of an explicit test for input encoding, maybe define new constants in
src/roff/troff/input.h (which already has separate EBCDIC vs non-EBCDIC
blocks) to compare against. The rest of input.cpp seems to be
encoding-agnostic by using these constants. This also eliminates a run-time
conditional, putting the decision on the compiler.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?58962>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
