Explicitly initialize chkfont variables to prevent compiler warning,
and remove GCC-specific pragmas that don't work in all GCC versions
anyway -- warnings were still issued on the MinGW cross-compiler and
in the FreeBSD 8.0 gcc.
Signed-off-by: Claudio Matsuoka <cmatsuoka@gmail.com>
Not all non-GNU make(1) utility recognize $* in Makefile rule dependencies,
changed to a more compatible format to work e.g. with BSD make.
Signed-off-by: Claudio Matsuoka <cmatsuoka@gmail.com>
Actually verify return values of fgets() and fscanf() in chkfont instead
of disabling the warning.
Signed-off-by: Claudio Matsuoka <cmatsuoka@gmail.com>
Either initialize unitialized variables to sensible values, or supress
the warning in case the variable is always correctly initialized.
Signed-off-by: Claudio Matsuoka <cmatsuoka@gmail.com>
Changed Makefile to use BINDIR as the destination for binary files instead
of DESTDIR, and reserve DESTDIR as the extra installation prefix commonly
used in package building.
Signed-off-by: Claudio Matsuoka <cmatsuoka@gmail.com>
Zipio files were licensed under a restrictive license containing a clause
mandating that any modifications to the source code must be sent via e-mail
to the copyright owner. The author was contacted and permitted the files
to be relicensed under the MIT license. This should avoid any problems
restributing FIGlet as free software in Linux distributions.
Signed-off-by: Claudio Matsuoka <cmatsuoka@gmail.com>
Smushing characters at the line start can cause the next character to
be copied to an offset before the start of the line buffer. In this
case, add an offset to source and copy to a valid destination position.
Signed-off-by: Claudio Matsuoka <cmatsuoka@gmail.com>
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). 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).
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).
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.
Signed-off-by: Claudio Matsuoka <cmatsuoka@gmail.com>
By Micah Cowan: "the meanings of the SHIFT-OUT (0x0E) and SHIFT-IN
(0x0F) seem to be reversed: SHIFT-OUT is intended to invoke G0 into GL,
and SHIFT-IN to invoke G1 into GR; however, the command
$ printf 'Hell\x0Er' | figlet
appears to cause figlet to interpret the final "r" as... an "r", whereas
$ printf 'Hell\x0Fr' | figlet
causes figlet to interpret the final "r" to be interpreted as SMALL
LETTER o WITH GRAVE ACCENT. I would expect exactly the opposite results.
A quick look at iso2022() seems to verify that character code 14 is
invoking G0 to GL, rather than G1."
Signed-off-by: Claudio Matsuoka <cmatsuoka@gmail.com>
Exit with return code 1 if memory allocation fails instead of just
issuing a warning and resume execution with bogus pointer values.
Signed-off-by: Claudio Matsuoka <cmatsuoka@gmail.com>
Add missing headers, remove unused variables, specify implicit types.
Ensure compatibility with ancient systems is maintained.
Signed-off-by: Claudio Matsuoka <cmatsuoka@gmail.com>
