figlet doesn't interpret JIS 0201X characters

[Micah Cowan]

Binary package hint: figlet

The manpage mentions that the "banner" font supports katakana; this may be verified by using the "uskata" controlfile, which maps katakana characters into the 7-bit G0 graphical character codespace:

printf 'ABCDE' | figlet -f banner -C uskata

However, it also claims to suport mixed latin and katakana via the controlfile jis0201; looking at the control file (without knowing anything authoritative about the control file syntax), it does appear to (attempt to) map katakana characters into the 8-bit character space (same positions as with uskata, except with the high bit set, so that the 7-bit space may be reserved for ASCII latin characters: see http://en.wikipedia.org/wiki/JIS_X_0201 for the code chart). However, it doesn't actually work:

printf '\xB1\xB2\xB3\xB4\xB5' | figlet -f banner -C jis0201

prints nothing (it should print the same as in the first example).

[Micah Cowan (micahcowan)]

Update: the jis0201.flc file appears to be a Unicode mapping file from the Unicode Consortium, rather than a figlet control file. Also, the mapping specified there is to half-width katakana characters (U+FF61 - U+FF9F); whereas it appears ,from the working contents of uskata.flc, and the contents of banner.flf, that the banner font expects the normal katakana character codes (U+30A1 - U+30FE).

[Micah Cowan (micahcowan)]

I'm reporting the bug upstream at <email address hidden>; however, I won't be able to post a link to the discussion there, as the list archive requires subscription to the list.

[Micah Cowan (micahcowan)]

Actually, figlet supports Unicode mapping file formats; the remaining problem is probably just the fact that they are mapped to half-width rather than full-width katakana characters, mismatching the banner font's expectations.

[Micah Cowan (micahcowan)]

Here's the proposed control-file to replace jis0201.flc. Rather than mapping the first 256 byte values to JIS X 201, it makes use of figlet's ISO 2022 support. So you can use low- and high-value bytes, or you can use SHIFT OUT and SHIFT IN, or whatever.

Also, it maps the katakana code points to Unicode full-width katakana characters, rather than half-width katakana, which, while probably incorrect, is what the banner font expects; as far as I know, there are no other fonts for katakana, other than the katakana.flf in the international figlet fonts tarball [available upstream]; which doesn't use Unicode codepoints for the katakana characters, but just maps uppercase ASCII characters to the katakana.

[Micah Cowan (micahcowan)]

Here's the approval message from John Cowan <email address hidden>, who, while not currently the maintainer of figlet (was previously), was responsible for the ISO-2022 code in figlet, and gave his blessing for the message.

I'm afraid I can't prove this approval to anyone unless they are subscribed to the figlet mailing list, as the archives are closed to the public.

Micah Cowan scripsit:

> > I finally got around to doing this. My proposed replacement for
> > jis0201.flc is at http://launchpadlibrarian.net/8174097/myjis.flc (I
> > didn't want to waste bandwidth here, given that it's a pretty
> > special-interest thing).

I bless this. Can whoever is maintaining the Figlet archive please
insert this as a replacement for jis0201.flc?

[Micah Cowan (micahcowan)]

Here is a patch that fixes a related problem, in that the meaning of the SHIFT OUT (0x0e) and SHIFT IN (0x0f) characters are currently swapped.

I'll roll a debdiff soon, that incorporates these two changes.

[Micah Cowan (micahcowan)]

The jis0201.flc replacement I added here, myjis.flc, has a slight error in the comments at the top of the file.

# Invoke JIS Roman in G0/GL, and JIS Katakana ("halfwidth" katakana, but
# we map it to fullwidth for compatibility with existing fonts).

should be:

# Invoke JIS Roman in G0/GL, and JIS Katakana ("halfwidth" katakana, but
# we map it to fullwidth for compatibility with existing fonts) in
# G1/GR.

[Micah Cowan (micahcowan)]

Nobody besides me will care about this bug, honestly. It's been submitted upstream and approved by at least one developer, so it may come in at some point via a sync. In any case, I'm not finding time to work on much besides Wget these days, and if I'm not going to fix it, I doubt anyone else will.