Posted by Claude (Opus 5), an LLM made by Anthropic, at andy5995's direction.
Some boards export message text as ISO Latin-1 in areas that carry nothing to
say so, and the reader has no way to be told. The result is that accented
characters in those areas are drawn as unrelated symbols.
What happens
A sender name spelled Björn appears as Bj÷rn. The byte in the packet is
0xF6, which is ö in Latin-1 and ÷ in CP437. The reader draws it through
the CP437 table because nothing told it otherwise.
andy5995 saw this in a QWK packet from a board running BBBS, in a FidoNet
echo. BBBS sets the export character set per conference — ISO Latin-1 or IBM
CP437 — so this is the sysop's setting, and a user downloading the packet
cannot change it or detect it from the packet contents.
Why the reader cannot currently cope
The reader decides Latin-1 per area, from the LATINCHAR flag. For QWK, that
flag is set only for areas the door marks as Internet or Usenet. A FidoNet
echo is neither, so a Latin-1 area of that kind is always read as CP437. The
code that applies this rule carries an upstream comment questioning whether it
is the right thing to do, so the limitation is known and predates this fork.
The C (Charset) key does not work around it. It flips a global setting that
combines with the per-area assumption rather than replacing it, so in this
case the conversion runs in a direction that lands on the same wrong
character. I traced this through the conversion code rather than testing every
combination on a real packet, so treat the detail as reasoned, not measured;
the observed part is that pressing C did not correct the display.
Suggested direction
A per-area character-set override the user can set and that persists, so an
area known to carry Latin-1 can be marked as such regardless of what the
packet claims. That needs somewhere to store it per area and a way to set it
from the area list.
An automatic guess is a second option — high bytes in a packet form a pattern
that leans one way or the other — but it would be wrong sometimes, and wrong
silently, which seems worse than a setting the user controls.
Low priority. It affects boards whose export charset does not match what the
area flags imply, which is a minority, and it makes text look wrong rather
than losing anything.
Some boards export message text as ISO Latin-1 in areas that carry nothing to
say so, and the reader has no way to be told. The result is that accented
characters in those areas are drawn as unrelated symbols.
What happens
A sender name spelled
Björnappears asBj÷rn. The byte in the packet is0xF6, which isöin Latin-1 and÷in CP437. The reader draws it throughthe CP437 table because nothing told it otherwise.
andy5995 saw this in a QWK packet from a board running BBBS, in a FidoNet
echo. BBBS sets the export character set per conference — ISO Latin-1 or IBM
CP437 — so this is the sysop's setting, and a user downloading the packet
cannot change it or detect it from the packet contents.
Why the reader cannot currently cope
The reader decides Latin-1 per area, from the
LATINCHARflag. For QWK, thatflag is set only for areas the door marks as Internet or Usenet. A FidoNet
echo is neither, so a Latin-1 area of that kind is always read as CP437. The
code that applies this rule carries an upstream comment questioning whether it
is the right thing to do, so the limitation is known and predates this fork.
The
C(Charset) key does not work around it. It flips a global setting thatcombines with the per-area assumption rather than replacing it, so in this
case the conversion runs in a direction that lands on the same wrong
character. I traced this through the conversion code rather than testing every
combination on a real packet, so treat the detail as reasoned, not measured;
the observed part is that pressing
Cdid not correct the display.Suggested direction
A per-area character-set override the user can set and that persists, so an
area known to carry Latin-1 can be marked as such regardless of what the
packet claims. That needs somewhere to store it per area and a way to set it
from the area list.
An automatic guess is a second option — high bytes in a packet form a pattern
that leans one way or the other — but it would be wrong sometimes, and wrong
silently, which seems worse than a setting the user controls.
Low priority. It affects boards whose export charset does not match what the
area flags imply, which is a minority, and it makes text look wrong rather
than losing anything.