Follow-up Comment #31, bug #66919 (group groff):

[comment #29 comment #29:]
> [comment #27 comment #27:]
>> Clearly, "can't" overstates this, because it _was_ regarded as one in past
>> groffs.
> 
> ...unless you were on an EBCDIC system, or loaded "latin2.tmac".
> 
>> Additionally, in my example input, at the time that .hcode is run, the
>> character encoding is known,
> 
> Not to the formatter.

Both these statements can't be true.  If it _was_ regarded as one in past
groffs in latin1 but not in latin2, then the formatter did somehow take the
input encoding into account.  Conversely, if the formatter knew nothing about
the encoding, then past groffs must have treated the request the same
regardless of whether latin1 or latin2 was in effect.

Determining _which_ one is true is, once again, thwarted by past releases
lacking a way to query hyphenation codes, and my attempts to deduce them
through observations of hyphenation behavior have given me seemingly
contradictory results.  I was trying to reconcile these when my attention got
diverted to other (non-groff) matters, where it may remain a while yet.  So
this question remains unresolved unless you care to tackle it before I'm able
to return to it.

But the answer would seem to determine what direction this ticket should take.
 The byte 0xF5 represents LATIN SMALL LETTER O WITH TILDE in Latin-1 and LATIN
SMALL LETTER O WITH DOUBLE ACUTE in Latin-2.  So, in older groffs with Latin-2
loaded, for the input ".hcode \[~o]" followed by the byte 0xF5:
* If the formatter treated this as reflexive, then this was a bug, which goes
a long way toward quashing objections to the behavior change.
* If the formatter didn't treat this as reflexive, then it somehow knew the
encoding, undermining much of the justification for the behavior change.


    _______________________________________________________

Reply to this item at:

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

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

Attachment: signature.asc
Description: PGP signature

Reply via email to