[bug #58962] Latin-1 NO-BREAK SPACE does not behave as documented

[Dave]

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/