From ygz@cs.purdue.edu Sat May 1 04:29:05 1993 Return-Path: Date: Sat, 1 May 1993 04:23:15 -0500 From: ygz@cs.purdue.edu (Yongguang Zhang) To: soft-authors@ifcss.org Subject: HBF Std & tools Status: O I've made two shell scripts for HBF file. One is "hbf-check.sh", to intensively check every bit of the .hbf file. (e.g. whether everything is there and in order, whether every string has the right type, if it would be better to be an hexadecimal or decimal, whether CHARSET matches CODE_SCHEME, etc.) I hope it can help you in checking the syntax and writing HBF-Std 1.0 conformed .hbf file. The other one is "hbf-show.sh", given a .hbf file and a hanzi code to display its bitmap on screen. It is useful in checking if a .hbf file interprets the bitmap file(s) correctly. As a side-product, it can be used to generated a EPS, or a X11 bitmap, or a PBM file for the given hanzi. Both files and a "hbf-chk1.awk" (used by "hbf-check.sh") are packed a .shar (shell archive) in the next mail. Note that "hbf-chk1.awk" should be put in the current directory when running "hbf-check.sh". ======== As a side note. I have been convinced by pmc (thru private e-mail) and lee that we use FAMILY_NAME for fonts. I have included 10 commonly used FAMILY_NAMEs (see my last post) in "hbf-check.sh", as well as 4 commonly used WEIGHT_NAMEs ("SingleWidth","Thin","Medium","Bold"). I also included in SLANT the following: "R", "I" (don't know if we will eventually have slanted fonts or not), "S" ("Sideway" fonts? :-), and "SI" (Sidway italic fonts?). I am willing to change that if there is strong objection. One more suggestion. Should we move the PROPERTIES section to the end of HBF, i.e., after HBF_END_CODE_RANGES and before HBF_ENF_FONT ? Reasons: 1) for applications that don't care about PROPERTIES, they may stop parsing after HBF_END_CODE_RANGES; 2) when you parse the PROPERTIES, you already have the byte2 ranges and code ranges to judge the properties (e.g. for DEFAULT_CHAR). From ygz@cs.purdue.edu Sat May 1 04:30:03 1993 Return-Path: Date: Sat, 1 May 1993 04:23:42 -0500 From: ygz@cs.purdue.edu (Yongguang Zhang) To: soft-authors@ifcss.org Subject: hbf.shar Status: O #! /bin/sh # This is a shell archive. Remove anything before this line, then unpack # it by saving it into a file and typing "sh file". To overwrite existing # files, type "sh file -c". You can also feed this as standard input via # unshar, or by typing "sh 'hbf-check.sh' <<'END_OF_FILE' X#!/bin/sh X# X# Try to check every line of the HBF file. X# X# <<< For HBF draft version 0.4 >>> X# X# Should be able to just run on most Unix system. Mostly awk,bc,sed. X# Warning: The code is from hell! Extremely ad hoc, slow, and illegible. :-) X# X# Author: Yongguang Zhang (ygz@cs.purdue.edu) X# Create date: Apr/25/93 X# Last update: Apr/30/93 X X XPASS1AWK="hbf-chk1.awk" X Xif [ "$1" = "" ]; then X echo "Usage: $0 hbf_file" 1>&2 X exit 0 Xfi XHBF_FILE=$1 Xif [ ! -r "$HBF_FILE" ]; then X echo "Cannot access \"$HBF_FILE\"." 1>&2 X exit 1 Xfi X X X########### SYNTAX ########### X Xecho " " 1>&2 Xecho "pass 1: syntax checking ... " 1>&2 X X# (tr -d '\015') is to remove the ^M, in case it is a MS-DOS file X# Xcat "$HBF_FILE" | tr -d '\015' | awk -f $PASS1AWK 1>&2 X Xif [ "$?" -ne 0 ]; then X echo " " 1>&2 X echo "Error(s) found in \"$HBF_FILE\". Stop." 1>&2 X exit $? Xfi X X X X########### INTEGER & RANGE ########### X X# function todec: turn hex/oct/dec into dec Xtodec () { X if [ $# -eq 1 ]; then X echo $1 X else X head -1 X fi | awk ' X BEGIN { c["0"] = 0; c["1"] = 1; c["2"] = 2; c["3"] = 3; c["4"] = 4; X c["5"] = 5; c["6"] = 6; c["7"] = 7; c["8"] = 8; c["9"] = 9; X c["a"] =10; c["b"] =11; c["c"] =12; X c["d"] =13; c["e"] =14; c["f"] =15; X c["A"] =10; c["B"] =11; c["C"] =12; X c["D"] =13; c["E"] =14; c["F"] =15; X s["+"] = 1; s["-"] =-1; X } X /^0[xX]/ { # hex X h = 0; X for (i = 3; i <= length($1); i++) X h = h*16 + c[substr($1,i,1)]; X print h; exit X } X /^[+-]0[xX]/ { # hex X h = 0; X for (i = 4; i <= length($1); i++) X h = h*16 + c[substr($1,i,1)]; X print s[substr($1,1,1)] * h; exit X } X /^0/ { # oct X h = 0; X for (i = 1; i <= length($1); i++) X h = h*8 + substr($1,i,1); X print h; exit X } X /^[+-]0/ { # oct X h = 0; X for (i = 1; i <= length($1); i++) X h = h*8 + substr($1,i,1); X print s[substr($1,1,1)] * h; exit X } X { print $1 } # dec X ' X} X# function to check the type Xint_type () { X if echo "$1" | egrep -s -i '^0[x][0-9a-f]+$'; then X echo "hexadecimal" X elif echo "$1" | egrep -s '^0[0-7]+$'; then X echo "octal" X elif echo "$1" | egrep -s '^[0-9]+$'; then X echo "decimal" X else X echo "error" X fi X} Xtype_check () { X case "$2" in X "unsigned" ) X t=`int_type "$1"` X if [ "$t" = "error" ]; then X echo "** Type error: Line $4: $5" X echo " \"$1\" should be an unsigned integer" X echo "--------" X exit 1 X fi X if [ "$t" != "$3" ]; then X echo "** Line $4: $5" X echo " \"$1\" is better to be in \"$3\"" X echo "--------" X return 2 X fi X return 0 X ;; X "integer" ) X ui=`echo $1 | sed 's/^+//;s/^-//'` X t=`int_type $ui` X if [ "$t" = "error" ]; then X echo "** Type error: Line $4: $5" X echo " \"$1\" should be an integer" X echo "--------" X exit 1 X fi X if [ "$t" != "$3" ]; then X echo "** Line $4: $5" X echo " \"$1\" is better to be in \"$3\"" X echo "--------" X return 2 X fi X return 0 X ;; X esac X} X# offset_byte2: count the number of codes within the range Xoffset_byte2 () { X echo $* | awk '{ X b2=$1; offset = 0; X for (i=2; i<=NF; i+=2) { X if ($i <= b2 && b2 <= $(i+1)) X offset += b2 - $i; X else if ($(i+1) < b2) X offset += $(i+1)-$i+1; X } X print offset X }' X} Xout_range () { X echo $* | awk '{ X b2=$1 X for (i=2;i<=NF;i+=2) { X if ($i <= b2 && b2 <= $(i+1)) exit 1; X } X exit 0; X }' X} X X Xecho " " 1>&2 Xecho "pass 2: integer and range checking ... (slow, please be patient)" 1>&2 X Xline=0 Xcodecnt=0 Xb2ranges="" Xcoderanges="" X Xcat "$HBF_FILE" | tr -d '\015' | \ Xwhile read keyword a1 a2 a3 a4 a5; do X X line=`expr $line + 1` X case "$keyword" in X X SIZE ) X echo "checking SIZE ..." X type_check $a1 "unsigned" "decimal" $line "$keyword $a1 $a2 $a3" X type_check $a2 "unsigned" "decimal" $line "$keyword $a1 $a2 $a3" X type_check $a3 "unsigned" "decimal" $line "$keyword $a1 $a2 $a3" X ;; X X HBF_BITMAP_BOUNDING_BOX ) X echo "checking BOUNDING BOX ......" X type_check $a1 "unsigned" "decimal" $line "$keyword $a1 $a2 $a3 $a4" X type_check $a2 "unsigned" "decimal" $line "$keyword $a1 $a2 $a3 $a4" X type_check $a3 "integer" "decimal" $line "$keyword $a1 $a2 $a3 $a4" X type_check $a4 "integer" "decimal" $line "$keyword $a1 $a2 $a3 $a4" X w=`todec $a1`; h=`todec $a2` X bpl=`echo "scale=0; ($w + 7)/8" | bc` # trunc to int X bpc=`echo "scale=0; $h * $bpl" | bc` X ;; X X FONTBOUNDINGBOX ) X type_check $a1 "unsigned" "decimal" $line "$keyword $a1 $a2 $a3 $a4" X type_check $a2 "unsigned" "decimal" $line "$keyword $a1 $a2 $a3 $a4" X type_check $a3 "integer" "decimal" $line "$keyword $a1 $a2 $a3 $a4" X type_check $a4 "integer" "decimal" $line "$keyword $a1 $a2 $a3 $a4" X wf=`todec $a1`; hf=`todec $a2` X if [ "(" $wf -lt $w ")" -o "(" $hf -lt $h ")" ]; then X echo "** Line $line: $keyword $a1 $a2 $a3 $a4" X echo " FONT bbx is smaller than HBF_BITMAP bbx. Are you sure?" X echo "--------" X fi X ;; X X CHARS ) X echo "checking CHARS ..." X type_check $a1 "unsigned" "decimal" $line "$keyword $a1" X num_code=`todec $a1` X ;; X X HBF_START_BYTE_2_RANGES ) X last_re=0 X ;; X X HBF_BYTE_2_RANGE ) X echo "checking BYTE_2 RANGE ......" X c1=`echo ${a1}${a2}${a3} | sed 's/-.*$//'` X c2=`echo ${a1}${a2}${a3} | sed 's/^.*-//'` X type_check $c1 "unsigned" "hexadecimal" $line "$keyword $a1 $a2 $a3" X type_check $c2 "unsigned" "hexadecimal" $line "$keyword $a1 $a2 $a3" X rs=`todec $c1`; re=`todec $c2` X if [ "(" $rs -gt $re ")" -o "(" $re -gt 255 ")" ]; then X echo "** Line $line: $keyword $a1 $a2 $a3" X echo " Invalid range. (0x00 <= range1 <= range2 <= 0xff)" X echo "--------" X exit 1 X fi X if [ $rs -lt $last_re ]; then X echo "** Style error: Line $line: $keyword $a1 $a2 $a3" X echo " byte2 ranges should be sorted and disjoined!" X echo "--------" X exit 1 X fi X if [ `expr $last_re + 1` -eq $rs ]; then X echo "** Line $line: $keyword $a1 $a2 $a3" X echo " Why don't you merge the adjunct byte2 ranges?" X echo "--------" X fi X b2ranges="$b2ranges $rs $re" X last_re=$re X ;; X X HBF_CODE_RANGE ) X echo "checking CODE RANGE ......" X if [ "$a4" = "" ]; then X c1=`echo ${a1} | sed 's/-.*$//'` X c2=`echo ${a1} | sed 's/^.*-//'` X bf=$a2; c3=$a3; X elif [ "$a5" = "" ]; then X c1=`echo ${a1}${a2} | sed 's/-.*$//'` X c2=`echo ${a1}${a2} | sed 's/^.*-//'` X bf=$a3; c3=$a4; X else X c1=$a1; c2=$a3; bf=$a4; c3=$a5; X fi X type_check $c1 "unsigned" "hexadecimal" $line \ X "$keyword $a1 $a2 $a3 $a4 $a5" X type_check $c2 "unsigned" "hexadecimal" $line \ X "$keyword $a1 $a2 $a3 $a4 $a5" X type_check $c3 "unsigned" "decimal" $line \ X "$keyword $a1 $a2 $a3 $a4 $a5" X cs=`todec $c1`; ce=`todec $c2`; co=`todec $c3` X coderanges="$coderanges $cs $ce" X if [ "(" $cs -gt $ce ")" -o "(" $ce -gt 65535 ")" ]; then X echo "** Range Error: Line $line: $keyword $a1 $a2 $a3 $a4 $a5" X echo " Invalid range. (0x0000 <= range1 <= range2 <= 0xffff)" X echo "--------" X exit 1 X fi X cs_b1=`echo "scale=0; $cs / 256" | bc` X cs_b2=`echo "$cs % 256" | bc` X ce_b1=`echo "scale=0; $ce / 256" | bc` X ce_b2=`echo "$ce % 256" | bc` X if out_range $cs_b2 $b2ranges ; then X echo "** Range Error: Line $line: $keyword $a1 $a2 $a3 $a4 $a5" X echo " \"$c1\" is not valid in any of the BYTE_2_RANGE." X echo "--------" X exit 1 X fi X if out_range $ce_b2 $b2ranges ; then X echo "** Range Error: Line $line: $keyword $a1 $a2 $a3 $a4 $a5" X echo " \"$c2\" is not valid in any of the BYTE_2_RANGE." X echo "--------" X exit 1 X fi X sdt=`offset_byte2 $cs_b2 $b2ranges` X edt=`offset_byte2 $ce_b2 $b2ranges` X mdt=`offset_byte2 256 $b2ranges` X num_ch=`echo "($ce_b1 - $cs_b1) * $mdt + $edt - $sdt + 1" | bc` X codecnt=`expr $codecnt + $num_ch` X if [ -r "$bf" ]; then X num_b=`echo "$num_ch * $bpc + $co" | bc` X fl=`/bin/ls -lL "$bf" | awk '{print $4;exit}'` X if [ "$fl" -lt "$num_b" ]; then X echo "** Warning: Line $line: $keyword $a1 $a2 $a3 $a4 $a5" X echo " bitmap file \"$bf\" is too short for the range." X echo "--------" X fi X else X echo "** Warning: Line $line: $keyword $a1 $a2 $a3 $a4 $a5" X echo " bitmap file \"$bf\" is not present or readable." X echo "--------" X fi X ;; X X HBF_END_CODE_RANGES ) X if [ "$codecnt" -ne "$num_code" ]; then X echo "** Warning: number of characters mismatched!" X echo " $num_code chars are declared by 'CHARS' statement." X echo " But totally $codecnt chars are found in all CODE_RANGEs." X echo "--------" X fi X ;; X X # X11 optional properties X X STARTPROPERTIES ) X echo "checking PROPERTIES ..." X prop_err=0 X ;; X X DEFAULT_CHAR ) X type_check $a1 "unsigned" "hexadecimal" $line "$keyword $a1" X def_char=$a1 X dc_line="$line: $keyword $a1" X ;; X X AVERAGE_WIDTH | CAP_HEIGHT | DESTINATION | \ X END_SPACE | MAX_SPACE | MIN_SPACE | NORM_SPACE | \ X PIXEL_SIZE | POINT_SIZE | RELATIVE_SETWIDTH | RELATIVE_WEIGHT | \ X RESOLUTION | RESOLUTION_X | RESOLUTION_Y | \ X SMALL_CAP_SIZE | SUBSCRIPT_SIZE | SUPERSCRIPT_SIZE | \ X UNDERLINE_THICKNESS | WEIGHT ) X if [ "$a1" != "" ]; then X ui=`echo $a1 | sed 's/^+//;s/^-//'` X if [ "`int_type $ui`" = "error" ]; then X echo "** Type error: Line $line: $keyword $a1 ${a2:+'...'}" X echo " \"$a1\" should be an integer" X echo "--------" X prop_err=`expr $prop_err + 1` X fi X fi X ;; X X AVG_CAPITAL_WIDTH | AVG_LOWERCASE_WIDTH | FIGURE_WIDTH | \ X FONT_ASCENT | FONT_DESCENT | ITALIC_ANGLE | QUAD_WIDTH | \ X STRIKEOUT_ASCENT | STRIKEOUT_DESCENT | SUBSCRIPT_X | SUBSCRIPT_Y | \ X SUPERSCRIPT_X | SUPERSCRIPT_Y | UNDERLINE_POSITION | X_HEIGHT ) X if [ "$a1" != "" ]; then X if [ "`int_type $a1`" = "error" ]; then X echo "** Type error: Line $line: $keyword $a1 ${a2:+'...'}" X echo " \"$a1\" should be an integer" X echo "--------" X prop_err=`expr $prop_err + 1` X fi X fi X ;; X X FONTNAME_REGISTRY | CHARSET_ENCODING | CHARSET_REGISTRY | FOUNDRY | \ X ADD_STYLE_NAME | FACE_NAME | FAMILY_NAME | SETWIDTH_NAME | WEIGHT_NAME | \ X SLANT | SPACING | FULL_NAME | COPYRIGHT | NOTICE ) X if echo "$a1$a2$a3$a4$a5" | egrep -s '^".*"$' ; then X if echo "$a1 $a2 $a3 $a4 $a5" | sed 's/^"//;s/"[ ]*$//' \ X | egrep -s '[^"]"[^"]' X then X echo "** Type error: Line $line: $keyword $a1 $a2 $a3 $a4 $a5" X echo " the quote character (\") inside the quotedString" X echo " should be represented as two in a row (\"\")." X echo "--------" X prop_err=`expr $prop_err + 1` X fi X else X echo "** Type error: Line $line: $keyword $a1 $a2 $a3 $a4 $a5" X echo " the argument should be a quotedString" X echo "--------" X prop_err=`expr $prop_err + 1` X fi X ;; X X ENDPROPERTIES ) X if [ "$prop_err" -gt 0 ]; then X echo "** Total $prop_err property error(s) have been found." X echo " Although the format of a property is not compulsory," X echo " it is better to follow the convention." X echo "--------" X fi X ;; X X HBF_END_FONT ) X dc=`todec $def_char` X dc_b2=`echo "$dc % 256" | bc` X if out_range $dc_b2 $b2ranges ; then X echo "** Range Error: Line $dc_line" X echo " \"$def_char\" is not valid in any of the BYTE_2_RANGE." X echo "--------" X exit 1 X fi X if out_range $dc $coderanges ; then X echo "** Range Error: Line $dc_line" X echo " \"$def_char\" is not in any of the CODE_RANGE." X echo "--------" X exit 1 X fi X ;; X X esac X Xdone 1>&2 X Xif [ "$?" -ne 0 ]; then X echo "Error(s) found in \"$HBF_FILE\". Stop." X exit $? Xfi X X X X########### PRAGMATIC ########### X Xecho " " 1>&2 Xecho "pass 3: pragmatic checking ... (slow, please be patient)" 1>&2 X XCODE_SCHEME='GB2312-1980 Big5 Unicode' XFAMILY_NAME='"Zhuan" "Li" "Kai" "Song" "Ming" "Xing" "Cao" '\ X'"Yuan" "Hei" "Xiaozhuan" "FangSong"' XWEIGHT_NAME='"SingleWidth" "Thin" "Medium" "Bold"' XSLANT='"R" "I" "S" "SI"' XSETWIDTH_NAME='"Normal"' X Xline=0 Xcat "$HBF_FILE" | tr -d '\015' | \ Xwhile read keyword a1 ; do X X line=`expr $line + 1` X case "$keyword" in X X HBF_START_FONT ) X echo "checking FONT header ..." X if [ "$a1" != "1.0" ]; then X echo "** Line $line: $keyword $a1" X echo " I guess the font version number should be '1.0'." X echo "--------" X fi X ;; X X HBF_CODE_SCHEME ) X code_scheme="" X a=`echo "$a1" | awk '{print $1}'` X for i in $CODE_SCHEME ; do X if echo $a | egrep -s -i '^'"$i"'$' ; then X code_scheme=$a X break; X fi X done X if [ "$code_scheme" = "" ]; then X echo "** Line $line: $keyword $a1" X echo " I don't seem to know the code scheme \"$a\"." X echo " Current acceptable code schemes are:" X echo " $CODE_SCHEME" X echo "--------" X code_scheme=$a X fi X ;; X X DEFAULT_CHAR ) X def_char=$a1 X ;; X X CHARSET_REGISTRY ) X echo "checking CHARSET ..." X char_set=`echo \"$code_scheme\" | tr '-' '.'` X if [ "$char_set" != "$a1" ]; then X echo "** Line $line: $keyword $a1" X echo " CHARSET should match code scheme \"$code_scheme\"." X echo " Suggestion: CHARSET_REGISTRY \"$code_scheme\"" X echo "--------" X fi X ;; X X CHARSET_ENCODING ) X chs_enc_line="$line: $keyword $a1" X chs_enc="$a1" X ;; X X FAMILY_NAME ) X echo "checking FONT styles ..." X found="" X for i in $FAMILY_NAME ; do X if echo $a1 | egrep -s -i '^'"$i"'$' ; then X found=$a1 X break; X fi X done X if [ "$found" = "" ]; then X echo "** Line $line: $keyword $a1" X echo " I don't seem to know the family name $a1." X echo " Commonly used family names are:" X echo " $FAMILY_NAME" X echo "--------" X fi X ;; X WEIGHT_NAME ) X found="" X for i in $WEIGHT_NAME ; do X if echo $a1 | egrep -s -i '^'"$i"'$' ; then X found=$a1 X break; X fi X done X if [ "$found" = "" ]; then X echo "** Line $line: $keyword $a1" X echo " I don't seem to know the weight name $a1." X echo " Commonly used weight names are:" X echo " $WEIGHT_NAME" X echo "--------" X fi X ;; X X SLANT ) X found="" X for i in $SLANT ; do X if echo $a1 | egrep -s -i '^'"$i"'$' ; then X found=$a1 X break; X fi X done X if [ "$found" = "" ]; then X echo "** Line $line: $keyword $a1" X echo " I don't seem to know the slant $a1." X echo " Commonly used slants are:" X echo " $SLANT" X echo "--------" X fi X ;; X X SETWIDTH_NAME ) X found="" X for i in $SETWIDTH_NAME ; do X if echo $a1 | egrep -s -i '^'"$i"'$' ; then X found=$a1 X break; X fi X done X if [ "$found" = "" ]; then X echo "** Line $line: $keyword $a1" X echo " I don't seem to know the set-width name $a1." X echo " Commonly used set-width names are:" X echo " $SETWIDTH_NAME" X echo "--------" X fi X ;; X X HBF_END_FONT ) X if echo "$code_scheme" | egrep -s -i "^GB"; then X # GB encoding are likely to have "1" as CHARSET_ENCODING X dc=`todec $def_char` X if [ "$dc" -ge 32768 ]; then X if [ "$chs_enc" != '"1"' ]; then X echo "** Line $chs_enc_line" X echo " It looks like a GR-encoding font to me." X echo " Suggestion: CHARSET_ENCODING \"1\"" X echo "--------" X fi X else X if [ "$chs_enc" != '"0"' ]; then X echo "** Line $chs_enc_line" X echo " It looks like a GL-encoding font to me." X echo " Suggestion: CHARSET_ENCODING \"0\"" X echo "--------" X fi X fi X fi X ;; X X esac X Xdone 1>&2 X Xif [ "$?" -ne 0 ]; then X echo "Error(s) found in \"$HBF_FILE\". Stop." X exit $? Xfi X X Xecho " " 1>&2 Xecho "Done with all checking. No fatal error found." 1>&2 X Xexit 0 X END_OF_FILE if test 15406 -ne `wc -c <'hbf-check.sh'`; then echo shar: \"'hbf-check.sh'\" unpacked with wrong size! fi chmod +x 'hbf-check.sh' # end of 'hbf-check.sh' fi if test -f 'hbf-chk1.awk' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'hbf-chk1.awk'\" else echo shar: Extracting \"'hbf-chk1.awk'\" \(10055 characters\) sed "s/^X//" >'hbf-chk1.awk' <<'END_OF_FILE' X# AWK script used by hbf-check.sh. X# For HBF draft version 0.4 X# [ Yongguang Zhang, Apr/25/93, Apr/30/93 ] X XBEGIN { X may_redef["HBF_BYTE_2_RANGE"] = 1; X may_redef["HBF_CODE_RANGE"] = 1; X X x11prop["FONTNAME_REGISTRY"] = "s"; X x11prop["ADD_STYLE_NAME"] = "s"; X x11prop["AVERAGE_WIDTH"] = "u"; X x11prop["AVG_CAPITAL_WIDTH"] = "i"; X x11prop["AVG_LOWERCASE_WIDTH"] = "i"; X x11prop["CAP_HEIGHT"] = "u"; X x11prop["CHARSET_ENCODING"] = "s"; X x11prop["CHARSET_REGISTRY"] = "s"; X x11prop["COPYRIGHT"] = "s"; X x11prop["DEFAULT_CHAR"] = "u"; X x11prop["DESTINATION"] = "u"; X x11prop["END_SPACE"] = "u"; X x11prop["FACE_NAME"] = "s"; X x11prop["FAMILY_NAME"] = "s"; X x11prop["FIGURE_WIDTH"] = "i"; X x11prop["FONT_ASCENT"] = "i"; X x11prop["FONT_DESCENT"] = "i"; X x11prop["FOUNDRY"] = "s"; X x11prop["FULL_NAME"] = "s"; X x11prop["ITALIC_ANGLE"] = "i"; X x11prop["MAX_SPACE"] = "u"; X x11prop["MIN_SPACE"] = "u"; X x11prop["NORM_SPACE"] = "u"; X x11prop["NOTICE"] = "s"; X x11prop["PIXEL_SIZE"] = "u"; X x11prop["POINT_SIZE"] = "u"; X x11prop["QUAD_WIDTH"] = "i"; X x11prop["RELATIVE_SETWIDTH"] = "u"; X x11prop["RELATIVE_WEIGHT"] = "u"; X x11prop["RESOLUTION"] = "u"; X x11prop["RESOLUTION_X"] = "u"; X x11prop["RESOLUTION_Y"] = "u"; X x11prop["SETWIDTH_NAME"] = "s"; X x11prop["SLANT"] = "s"; X x11prop["SMALL_CAP_SIZE"] = "u"; X x11prop["SPACING"] = "s"; X x11prop["STRIKEOUT_ASCENT"] = "i"; X x11prop["STRIKEOUT_DESCENT"] = "i"; X x11prop["SUBSCRIPT_SIZE"] = "u"; X x11prop["SUBSCRIPT_X"] = "i"; X x11prop["SUBSCRIPT_Y"] = "i"; X x11prop["SUPERSCRIPT_SIZE"] = "u"; X x11prop["SUPERSCRIPT_X"] = "i"; X x11prop["SUPERSCRIPT_Y"] = "i"; X x11prop["UNDERLINE_POSITION"] = "i"; X x11prop["UNDERLINE_THICKNESS"] = "u"; X x11prop["WEIGHT"] = "u"; X x11prop["WEIGHT_NAME"] = "s"; X x11prop["X_HEIGHT"] = "i"; X X code_scheme["GB2312-1980"] = 1; X code_scheme["Big5"] = 1; X code_scheme["Unicode"] = 1; X X in_prop = 0 X expect = "HBF_START_FONT" X expect2 = "" X} X XNF == 0 { X printf "** Warning: Line %d: %s\n", NR, $0 X printf " there should be no empty line, use 'COMMENT' if necessary\n" X printf "--------\n" X warning++ X next X} X$1 == "COMMENT" { X next X} X X{ X # check duplicated declaration etc. X if ((defined[$1] == 1) && (may_redef[$1] != 1)) { X printf "** Warning: Line %d: %s\n", NR, $0 X printf " duplicated '%s' statement.\n", $1 X printf "--------\n" X warning++ X } X defined[$1] = 1 X # check expecting statements. X if (expect != "") { X if (($1 != expect) && ($1 != expect2)) { X printf "** Error: Line %d: %s\n", NR, $0 X printf " expecting '%s' at this line.\n", expect X if (expect2 != "") X printf " or, expecting '%s' at this line.\n", expect2 X printf "--------\n" X exit 1 X } X } X} X X$1 == "HBF_START_FONT" { X if (NF != 2) { X printf "** Error: Line %d: %s\n", NR, $0 X printf " correct syntax: 'HBF_START_FONT' unquotedString\n" X printf "--------\n" X exit 1 X } X expect = "HBF_CODE_SCHEME" X next X} X X$1 == "HBF_CODE_SCHEME" { X if (NF != 2 && NF != 4) { X printf "** Error: Line %d: %s\n", NR, $0 X printf " correct syntax: 'HBF_CODE_SCHEME' unquotedString" X printf " [ unquotedString unquotedString ]\n" X printf "--------\n" X exit 1 X } X expect = "FONT" X next X} X X$1 == "FONT" { X if (NF != 2) { X printf "** Error: Line %d: %s\n", NR, $0 X printf " correct syntax: 'FONT' unquotedString\n" X printf "--------\n" X exit 1 X } X expect = "HBF_BITMAP_BOUNDING_BOX" X expect2 = "SIZE" X next X} X X$1 == "SIZE" { X if (NF != 4) { X printf "** Error: Line %d: %s\n", NR, $0 X printf " correct syntax: 'SIZE' unsignedInteger" X printf " unsignedInteger unsignedInteger \n" X printf "--------\n" X exit 1 X } X expect = "HBF_BITMAP_BOUNDING_BOX" X expect2 = "" X next X} X X$1 == "HBF_BITMAP_BOUNDING_BOX" { X if (NF != 5) { X printf "** Error: Line %d: %s\n", NR, $0 X printf " correct syntax: 'HBF_BITMAP_BOUNDING_BOX'" X printf " unsignedInteger unsignedInteger" X printf " signedInteger signedInteger\n" X printf "--------\n" X exit 1 X } X expect = "FONTBOUNDINGBOX" X expect2 = "" X next X} X X$1 == "FONTBOUNDINGBOX" { X if (NF != 5) { X printf "** Error: Line %d: %s\n", NR, $0 X printf " correct syntax: 'FONTBOUNDINGBOX' unsignedInteger" X printf " unsignedInteger signedInteger signedInteger\n" X printf "--------\n" X exit 1 X } X expect = "STARTPROPERTIES" X next X} X X$1 == "STARTPROPERTIES" { X if (NF != 2) { X printf "** Error: Line %d: %s\n", NR, $0 X printf " correct syntax: 'STARTPROPERTIES' unsignedInteger\n" X printf "--------\n" X exit 1 X } X expect = "" # cannot expect any X num_prop = $2 X num_found = 0 X line_startprop = NR X in_prop = 1 X prop_err = 0 X next X} X Xin_prop == 1 && $1 == "ENDPROPERTIES" { X if (NF != 1) { X printf "** Error: Line %d: %s\n", NR, $0 X printf " correct syntax: 'ENDPROPERTIES'\n" X printf "--------\n" X exit 1 X } X if (num_prop > num_found) { X printf "** Error: too fewer property definitions.\n" X printf " %d declared in 'STARTPROPERTIES' statement", num_prop X printf " (line %d)\n", line_startprop X printf " but only %d are found\n", num_found X printf "--------\n" X exit 1 X } X if (num_prop < num_found) { X printf "** Error: too many property definitions.\n" X printf " %d declared in 'STARTPROPERTIES' statement", num_prop X printf " (line %d)\n", line_startprop X printf " but %d are found\n", num_found X printf "--------\n" X exit 1 X } X # check compulsory definitions X if (defined["DEFAULT_CHAR"] != 1) { X printf "** Error: compulsory property 'DEFAULT_CHAR' is missing\n" X printf "--------\n" X exit 1 X } X if (prop_err > 0) { X printf "** Total %d error(s) have been found", prop_err X printf " in the PROPERTIES section.\n" X printf " Although the format of a property is not compulsory,\n" X printf " it is better to follow the convention.\n" X printf "--------\n" X } X expect = "CHARS" X in_prop = 0 X next X} X Xin_prop == 1 && $1 == "DEFAULT_CHAR" { X if (NF != 2) { X printf "** Error: Line %d: %s\n", NR, $0 X printf " correct syntax: 'DEFAULT_CHAR' unsignedInteger\n" X printf "--------\n" X exit 1 X } X num_found++; X next X} X Xin_prop == 1 { X if (x11prop[$1] == "") { X printf "** Error: Line %d: %s\n", NR, $0 X printf " unknown property, please check the syntax.\n" X printf "--------\n" X prop_err++ X } else if (x11prop[$1] == "i") { X if (NF != 2) { X printf "** Error: Line %d: %s\n", NR, $0 X printf " correct syntax: '%s' integer\n", $1 X printf "--------\n" X prop_err++ X } X } else if (x11prop[$1] == "u") { X if (NF != 2) { X printf "** Error: Line %d: %s\n", NR, $0 X printf " correct syntax: '%s' unsignedInteger\n", $1 X printf "--------\n" X prop_err++ X } X } else if (x11prop[$1] == "s") { X if (NF < 2) { X printf "** Error: Line %d: %s\n", NR, $0 X printf " correct syntax: '%s' quotedString\n", $1 X printf "--------\n" X prop_err++ X } X } X num_found++; X next X} X X$1 == "CHARS" { X if (NF != 2) { X printf "** Error: Line %d: %s\n", NR, $0 X printf " correct syntax: 'CHARS' unsignedInteger\n" X printf "--------\n" X exit 1 X } X expect = "HBF_START_BYTE_2_RANGES" X next X} X X$1 == "HBF_START_BYTE_2_RANGES" { X if (NF != 2) { X printf "** Error: Line %d: %s\n", NR, $0 X printf " correct syntax: 'HBF_START_BYTE_2_RANGES'" X printf " unsignedInteger\n" X printf "--------\n" X exit 1 X } X expect = "HBF_BYTE_2_RANGE" X num_range = $2 X num_found = 0 X next X} X X$1 == "HBF_BYTE_2_RANGE" { X if ((NF > 4) || ((NF == 4) && ($3 != "-"))) { X printf "** Error: Line %d: %s\n", NR, $0 X printf " correct syntax: 'HBF_BYTE_2_RANGE'" X printf " unsignedInteger '-' unsignedInteger\n" X printf "--------\n" X exit 1 X } X if ((NF == 3) && (substr($3,1,1) != "-") && \ X (substr($2,length($2),1) != "-")) { X printf "** Error: Line %d: %s\n", NR, $0 X printf " correct syntax: 'HBF_BYTE_2_RANGE'" X printf " unsignedInteger '-' unsignedInteger\n" X printf "--------\n" X exit 1 X } X X num_found++; X if (num_found == num_range) X expect = "HBF_END_BYTE_2_RANGES"; X else X expect = "HBF_BYTE_2_RANGE"; X next X} X X$1 == "HBF_END_BYTE_2_RANGES" { X if (NF != 1) { X printf "** Error: Line %d: %s\n", NR, $0 X printf " correct syntax: 'HBF_END_BYTE_2_RANGES'\n" X printf "--------\n" X exit 1 X } X expect = "HBF_START_CODE_RANGES" X next X} X X$1 == "HBF_START_CODE_RANGES" { X if (NF != 2) { X printf "** Error: Line %d: %s\n", NR, $0 X printf " correct syntax: 'HBF_START_CODE_RANGES'" X printf " unsignedInteger\n" X printf "--------\n" X exit 1 X } X expect = "HBF_CODE_RANGE" X num_range = $2 X num_found = 0 X next X} X X$1 == "HBF_CODE_RANGE" { X if ((NF > 6) || ((NF == 6) && ($3 != "-"))) { X printf "** Error: Line %d: %s\n", NR, $0 X printf " correct syntax: 'HBF_CODE_RANGE'" X printf " unsignedInteger '-' unsignedInteger\n" X printf "--------\n" X exit 1 X } X if ((NF == 5) && (substr($3,1,1) != "-") && \ X (substr($2,length($2),1) != "-")) { X printf "** Error: Line %d: %s\n", NR, $0 X printf " correct syntax: 'HBF_CODE_RANGE'" X printf " unsignedInteger '-' unsignedInteger\n" X printf "--------\n" X exit 1 X } X num_found++; X if (num_found == num_range) X expect = "HBF_END_CODE_RANGES"; X else X expect = "HBF_CODE_RANGE"; X next X} X X$1 == "HBF_END_CODE_RANGES" { X if (NF != 1) { X printf "** Error: Line %d: %s\n", NR, $0 X printf " correct syntax: 'HBF_END_CODE_RANGES'\n" X printf "--------\n" X exit 1 X } X expect = "HBF_END_FONT" X next X} X X$1 == "HBF_END_FONT" { X expect = "end-of-file" X next X} X X{ X printf "** Error: Line %d: %s\n", NR, $0 X printf " Unknown statement.\n" X printf "--------\n" X exit 1 X} X XEND { X if ( expect != "end-of-file" ) { X printf "** Unexpected EOF (end of file)\n" X if ( expect != "" ) { X printf " still expecting '%s'", expect X if (expect2 != "") printf " or '%s'", expect2; X printf "\n" X } X printf "--------\n" X exit 1 X } X} X END_OF_FILE if test 10055 -ne `wc -c <'hbf-chk1.awk'`; then echo shar: \"'hbf-chk1.awk'\" unpacked with wrong size! fi chmod +x 'hbf-chk1.awk' # end of 'hbf-chk1.awk' fi if test -f 'hbf-show.sh' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'hbf-show.sh'\" else echo shar: Extracting \"'hbf-show.sh'\" \(8851 characters\) sed "s/^X//" >'hbf-show.sh' <<'END_OF_FILE' X#!/bin/sh X# X# Extract the bitmap of a hanzi code from an HBF font. X# X# Given an .hbf file and a hanzi internal code as arguments, X# this program outputs the bitmap of the glyph on screen. X# Options can be used to change the pixel characters of the bitmap, or X# to produce a file in EPS, X11 bitmap, or PBM portable bitmap format. X# X# Type "hbf-show.sh -help" for usage. X# X# Should be able to run on most Unix system. X# Use mostly awk, bc, sed, od, dd. X# X# <<< For HBF version 1.0 draft v0.4 >>> X# X# Author: Yongguang Zhang (ygz@cs.purdue.edu) X# Create date: Apr/25/93 X# Last update: Apr/30/93 X X X# function todec: turn hex/oct/dec into dec Xtodec () { X if [ $# -eq 1 ]; then X echo $1 X else X head -1 X fi | awk ' X BEGIN { c["0"] = 0; c["1"] = 1; c["2"] = 2; c["3"] = 3; c["4"] = 4; X c["5"] = 5; c["6"] = 6; c["7"] = 7; c["8"] = 8; c["9"] = 9; X c["a"] =10; c["b"] =11; c["c"] =12; X c["d"] =13; c["e"] =14; c["f"] =15; X c["A"] =10; c["B"] =11; c["C"] =12; X c["D"] =13; c["E"] =14; c["F"] =15; X } X /^0[xX][0-9a-fA-F][0-9a-fA-F]*$/ { # hex X h = 0; X for (i = 3; i <= length($1); i++) X h = h*16 + c[substr($1,i,1)]; X print h; exit 0 X } X /^0[0-7][0-7]*$/ { # oct X h = 0; X for (i = 1; i <= length($1); i++) X h = h*8 + substr($1,i,1); X print h; exit 0 X } X /^[1-9][0-9]*$/ { print $1; exit 0 } # dec X /^0$/ { print 0; exit 0 } # dec X { exit 1 } X ' X} X X# number of valid codes from 0x00 to (byte2) Xoffset_byte2 () { X echo $* | awk '{ X b2=$1; offset = 0; X for (i=2;i<=NF;i+=2) { X if ($i <= b2 && b2 <= $(i+1)) X offset += b2 - $i; X else if ($(i+1) < b2) X offset += $(i+1)-$i+1; X } X print offset X }' X} X X# dump the bitmap in "black"/"white" format Xdumpbitmap() { X od -bvw$3 | head -$2 | awk ' X BEGIN { X w = '"$1"' ; black = "'"$4"'" ; white = "'"$5"'" ; X s["0"]="000"; s["1"]="001"; s["2"]="010"; s["3"]="011"; X s["4"]="100"; s["5"]="101"; s["6"]="110"; s["7"]="111"; X t["0"]="00"; t["1"]="01"; t["2"]="10"; t["3"]="11"; X } X { X zo = ""; bm = ""; X for (i = 2; i <= NF; i++) { X zo = zo t[substr($i,1,1)] s[substr($i,2,1)] s[substr($i,3,1)] X } X for (i = 1; i <= w; i++) { X if ( substr(zo,i,1) == "1" ) bm = bm black X else bm = bm white X } X printf "%s\n", bm X }' X} X X# dump the bitmap in EPSF Xbitmap_eps () { X BM=`od -bvw$3 | head -$2 | awk '{ X for (i = 2; i <= NF; i++) { X n = substr($i,1,1) * 64 + substr($i,2,1) * 8 + substr($i,3,1) X printf "%02x", n X } X printf "\n" X }'` X echo "%!PS-Adobe-2.0 EPSF-1.2" X echo "%%BoundingBox: 0 1 `expr $1 - 1` $2" X echo "%%BeginPreview: $1 $2 1 $2" X echo "$BM" | sed 's/^/% /' X echo "%%EndImage" X echo "%%EndPreview" X echo "$1 $2 scale" X echo "$1 $2 true [ $1 0 0 -$2 0 $2 ] {<" X echo "$BM" X echo ">}" imagemask X} X X# dump the bitmap in X11 bitmap format Xbitmap_xbm () { X echo "#define ${4}_width $1" X echo "#define ${4}_height $2" X echo "static char ${4}_bits[] = {" X od -bvw$3 | head -$2 | awk ' X BEGIN { X # X11 bitmap is LSB first. X rs["0"]=0; rs["1"]=4; rs["2"]=2; rs["3"]=6; X rs["4"]=1; rs["5"]=5; rs["6"]=3; rs["7"]=7; X rt["0"]=0; rt["1"]=2; rt["2"]=1; rt["3"]=3; X } X { X for (i = 2; i <= NF; i++) { X n = rt[substr($i,1,1)] + rs[substr($i,2,1)] * 4 \ X + rs[substr($i,3,1)] * 32 X printf " 0x%02x, ", n X } X printf "\n" X }' X echo "};" X} X X# dump the bitmap in PBM P4 format Xbitmap_pbm () { X echo "P4" X echo "$1 $2" X dd bs=1 count=$3 2>/dev/null X} X X# usage Xusage() { X ( X echo "Usage: $0 [ options ] hbf-filename hanzi-code" X echo " " X echo "options:" X echo " -p black white" X echo " Dump the bitmap on screen using human readable text," X echo " using the two strings to show bit 1 and 0." X echo " (Note that the two strings must have the same length.)" X echo " -eps filename.eps" X echo " Write the bitmap in EPS encapsulate postscript format" X echo " into the given file." X echo " -xbm filename.xbm" X echo " Write the bitmap in X11 bitmap format" X echo " into the given file." X echo " -pbm filename.pbm" X echo " Write the bitmap in PBM portable bitmap format" X echo " into the given file." X echo " " X echo "The above 4 options are exclusive. By default, -p \"#\" \".\"" X echo "The hanzi-code should be in hex (starts with 0x), oct, or dec." X echo " " X echo "Example: $0 cclib16st.hbf 0xb0a1" X echo " $0 -p \"**\" \". \" cclib16st.hbf 0xb0a1" X echo " $0 -eps hz_b0a1.eps cclib16st.hbf 0xb0a1" X echo " " X ) 1>&2 X} X X X# default options XFORMAT="dump" XBLACK="#" XWHITE="." X X# get command line arguments X# Xwhile [ "$1" != "" ]; do X case "$1" in X -p ) if [ $# -lt 3 ]; then usage; exit; fi X FORMAT="dump"; BLACK="$2"; WHITE="$3"; X shift 3 X ;; X -eps ) if [ $# -lt 2 ]; then usage; exit; fi X FORMAT="eps"; OUTPUT="$2" X shift 2 X ;; X -xbm ) if [ $# -lt 2 ]; then usage; exit; fi X FORMAT="xbm"; OUTPUT="$2" X shift 2 X ;; X -pbm ) if [ $# -lt 2 ]; then usage; exit; fi X FORMAT="pbm"; OUTPUT="$2" X shift 2 X ;; X -* ) usage; exit X ;; X * ) break; X ;; X esac Xdone Xif [ $# -ne 2 ]; then X usage; exit; Xfi XHBFFILE=$1 XHZCODE=$2 X X# check the arguments X# Xif [ ! -r $HBFFILE ]; then X echo "unable to open hbf-file \"$HBFFILE\"." 1>&2 X exit 1 Xfi Xif [ "`dd if=$HBFFILE bs=1 count=14 2>/dev/null`" != "HBF_START_FONT" ]; then X echo "File \"$HBFFILE\" doesn't seem to be a HBF file." X echo "Its very first line should start with \"HBF_START_FONT\"." X exit 1 Xfi X Xhz=`todec $HZCODE` Xif [ $? -ne 0 ]; then X echo "hanzi code \"$HZCODE\" is not an integer (hex, oct, or dec)." 1>&2 X exit 1 Xfi Xhz_b1=`echo "scale=0; $hz / 256" | bc` Xhz_b2=`echo "$hz % 256" | bc` Xif [ "$hz_b1" -gt 255 ]; then X echo "hanzi code \"$HZCODE\" is out of range (0x0000 -- 0xffff)." 1>&2 X exit 1 Xfi X Xif [ `echo "$BLACK" | wc -c` -ne `echo "$WHITE" | wc -c` ]; then X echo "pixels \"$BLACK\" and \"$WHITE\" must have the same length." 1>&2 X exit 1 Xfi X X# processing the file. X# Xvalid_b2=0 X X# (tr -d '\015') is to remove the ^M, in case it is a MS-DOS file X# Xcat $HBFFILE | tr -d '\015' | \ Xwhile read f1 f2 f3 f4 f5 f6 f7 f8 f9; do X X case "$f1" in X X HBF_BITMAP_BOUNDING_BOX ) X w=`todec $f2`; h=`todec $f3` X bpl=`echo "scale=0; ($w + 7)/8" | bc` # trunc to int X bpc=`echo "scale=0; $h * $bpl" | bc` X echo "$f1 $f2 $f3 $f4 $f5 => byte/row=$bpl, byte/char=$bpc" 1>&2 X ;; X X HBF_BYTE_2_RANGE ) X rs=`echo ${f2}${f3}${f4} | sed 's/-.*$//' | todec` X re=`echo ${f2}${f3}${f4} | sed 's/^.*-//' | todec` X B2RANGES="$B2RANGES $rs $re" X if [ "(" $rs -le $hz_b2 ")" -a "(" $hz_b2 -le $re ")" ]; then X valid_b2=1 X echo "$f1 $f2 => byte2 range here" 1>&2 X else X echo "$f1 $f2" 1>&2 X fi X ;; X X HBF_END_BYTE_2_RANGES ) X if [ $valid_b2 -eq 0 ]; then X echo "no such byte2 range in \"$HBFFILE\" for \"$HZCODE\"" 1>&2 X exit 1 X fi X ;; X X HBF_CODE_RANGE ) X if [ "$f5" = "" ]; then X cs=`echo ${f2} | sed 's/-.*$//' | todec` X ce=`echo ${f2} | sed 's/^.*-//' | todec` X F=$f3; co=`todec $f4` X elif [ "$f6" = "" ]; then X cs=`echo ${f2}${f3} | sed 's/-.*$//' | todec` X ce=`echo ${f2}${f3} | sed 's/^.*-//' | todec` X F=$f4; co=`todec $f5` X else X cs=`echo ${f2}${f3}${f4} | sed 's/-.*$//' | todec` X ce=`echo ${f2}${f3}${f4} | sed 's/^.*-//' | todec` X F=$f5; co=`todec $f6` X fi X if [ "(" $cs -le $hz ")" -a "(" $hz -le $ce ")" ]; then X echo "$f1 $f2 $f3 $f4 $f5 $f6 => \"$HZCODE\" is here" 1>&2 X X if [ ! -r "$F" ]; then X echo "cannot find bitmap file \"$F\"." 1>&2 X exit X fi X X cs_b1=`echo "scale=0; $cs / 256" | bc` X cs_b2=`echo "$cs % 256" | bc` X X cdt=`offset_byte2 $cs_b2 $B2RANGES` X hdt=`offset_byte2 $hz_b2 $B2RANGES` X maxdt=`offset_byte2 256 $B2RANGES` X X C=`echo "($hz_b1 - $cs_b1) * $maxdt + $hdt - $cdt" | bc` X B=`echo "$C * $bpc + $co" | bc` X X echo "bitmap is in \"$F\", offset = $B." 1>&2 X fl=`/bin/ls -lL "$F" | awk '{print $4;exit}'` X if [ "$fl" -lt "`expr $B + $bpc`" ]; then X echo "bitmap file \"$F\" is too short." 1>&2 X exit 1 X fi X X if [ "$B" -eq 0 ]; then X B=$bpc; skp=0; cnt=1 X else X skp=1; cnt=`echo "scale=0; ($bpc - 1) / $B + 1" | bc` X fi X X dd if="$F" bs=$B skip=$skp count=$cnt 2>/dev/null | \ X case $FORMAT in X eps) bitmap_eps "$w" "$h" "$bpl" > $OUTPUT X ;; X xbm) bitmap_xbm "$w" "$h" "$bpl" "HZ_$HZCODE" > $OUTPUT X ;; X pbm) bitmap_pbm "$w" "$h" "$bpc" > $OUTPUT X ;; X * ) dumpbitmap "$w" "$h" "$bpl" "$BLACK" "$WHITE" X ;; X esac X X exit X else X echo "$f1 $f2 $f3 $f4 $f5 $f6 => no \"$HZCODE\"" 1>&2 X fi X ;; X X HBF_END_CODE_RANGES ) X echo "no such code range in $HBFFILE for $HZCODE" 1>&2 X exit X ;; X X esac X Xdone END_OF_FILE if test 8851 -ne `wc -c <'hbf-show.sh'`; then echo shar: \"'hbf-show.sh'\" unpacked with wrong size! fi chmod +x 'hbf-show.sh' # end of 'hbf-show.sh' fi echo shar: End of shell archive. exit 0 From lee@fritter.Stanford.EDU Sat May 1 13:32:57 1993 Return-Path: Date: Sat, 1 May 93 11:27:00 -0700 From: lee@fritter.stanford.edu (Fung Fung Lee) To: soft-authors@ifcss.org In-Reply-To: Yongguang Zhang's message of Sat, 1 May 1993 04:23:15 -0500 <199305010923.AA01509@ector.cs.purdue.edu> Subject: HBF Std & tools Status: O >Date: Sat, 1 May 1993 04:23:15 -0500 >From: ygz@cs.purdue.edu (Yongguang Zhang) > >I've made two shell scripts for HBF file. Thanks Yongguang for his time and effort in producing the scripts. >One is "hbf-check.sh", to intensively check every bit of the .hbf file. >(e.g. whether everything is there and in order, whether every string >has the right type, if it would be better to be an hexadecimal or decimal, >whether CHARSET matches CODE_SCHEME, etc.) >I hope it can help you in checking the syntax and >writing HBF-Std 1.0 conformed .hbf file. > >The other one is "hbf-show.sh", given a .hbf file and a hanzi code >to display its bitmap on screen. It is useful in checking if a .hbf >file interprets the bitmap file(s) correctly. As a side-product, >it can be used to generated a EPS, or a X11 bitmap, or a PBM file >for the given hanzi. Given what Yongguang has done, I think he is the best person to do the sample API implementation. I have always had strong confidence in the quality of his work. >I have been convinced by pmc (thru private e-mail) and lee that >we use FAMILY_NAME for fonts. I have included 10 commonly used >FAMILY_NAMEs (see my last post) in "hbf-check.sh", as well as 4 >commonly used WEIGHT_NAMEs ("SingleWidth","Thin","Medium","Bold"). >I also included in SLANT the following: "R", "I" (don't know if >we will eventually have slanted fonts or not), "S" ("Sideway" >fonts? :-), and "SI" (Sidway italic fonts?). >I am willing to change that if there is strong objection. Yes, there is a strong objection. "S" ("Sideway") and "SI" should not be included, because they deal with how the bitmaps are stored (row/column major stuff) (the bitmaps might as well be compressed in the future!), whereas values like "I" ("Italic") have nothing to do with how bitmaps are stored. >One more suggestion. > >Should we move the PROPERTIES section to the end of HBF, i.e., >after HBF_END_CODE_RANGES and before HBF_ENF_FONT ? >Reasons: 1) for applications that don't care about PROPERTIES, >they may stop parsing after HBF_END_CODE_RANGES; 2) when you >parse the PROPERTIES, you already have the byte2 ranges and >code ranges to judge the properties (e.g. for DEFAULT_CHAR). It is easy for a program to skip the PROPERTIES (lines) it is not interested in, isn't it? Because each line is preceeded by a keyword (by conscious design). One advantage of the current line order is that translation between HBF and BDF should be easier to write because of the similarity in ordering. A footnote about jiantizi and fantizi that is relevant but not specific to HBF: With HC (Hanzi Converter, including b2g and g2b conversion) sitting on top of HBF's API, we can 1) dynamically retrieve the fanti character(s) corresponding to a GB code from a BIG5-ordered bitmap file, and vice versa, thus eliminating the need to generate and store GB-ordered fanti ziku or BIG5-ordered jianti ziku in many cases. 2) easily create applications that generate GB-ordered fanti ziku or BIG5-ordered jianti ziku -FFL From ygz@cs.purdue.edu Sun May 2 20:35:48 1993 Return-Path: To: lee@fritter.stanford.edu (Fung Fung Lee) Cc: soft-authors@ifcss.org, mcpong@cs.ust.hk Subject: Re: HBF Std & tools In-Reply-To: Your message of Sat, 01 May 1993 11:27:00 -0700. <9305011827.AA02867@fritter.Stanford.EDU> Date: Sun, 02 May 1993 20:31:06 -0500 From: ygz@cs.purdue.edu (Yongguang Zhang) Status: O Hi, In message <9305011827.AA02867@fritter.Stanford.EDU> you write > Given what Yongguang has done, I think he is the best person to do the > sample API implementation. ... Yes, you do. But come on, I cannot do everything myself. Note that all my scripts have nothing to do with API. I only use awk/sed/egrep/dd/od, etc., not even a single line of C code. That is why they are as slow as in hell. I will be quite busy this few months and I have no plan for API. For HBF, I will probably squeeze some time later to add one more script, hbftobdf.sh. I think it should be similar to the other scripts and therefore is easier for me to do it (provided that you don't care about the speed). Anyway, I really hope some one can write the sample API implementation. Then we have something solid to promote HBF. --ygz From @AWIUNI11.EDVZ.UNIVIE.AC.AT:A7621GAC@AWIUNI11.EDVZ.UNIVIE.AC.AT Mon May 3 04:51:42 1993 Return-Path: <@AWIUNI11.EDVZ.UNIVIE.AC.AT:A7621GAC@AWIUNI11.EDVZ.UNIVIE.AC.AT> Date: Mon, 03 May 93 11:15:53 MEZ From: Werner Lemberg Subject: HBF file names / baseline of a bitmap font To: soft-authors@ifcss.org Status: O Congratulations to your standard| I have not read the genesis of the HBF standard, so consider me as a person who sees the standard at the first time. A question: How can a software identify and find a HBF file? I suggest that the file name of a HBF file should consist of 8+3 characters to maintain readability on virtually all computer systems. The ending should be .HBF, and the name itself should describe the font as good as possible. In the TeX community, there is a very popular printer driver called dvips which prints TeX files on a postscript printer. Accompanied with it is a standard developped by Karl Berry how to name postscript fonts. I believe that a naming scheme similar to this would be fine. An example: ETen medium Kaiti font 24x24- HBF file could be named as emk24.hbf (I don't remember the details exactly) The first letter could represent the company, the second the weight, the third the style, and the last two characters the size. Please look at dvips for details. Secondly I believe that defining a baseline of a Chinese bitmap font is not very useful because there is no exact relation between this bitmap font and the real size in points. For my private use I arranged a 48x48 bitmap font in conjunction with 11pt postscript fonts, but anybody can also use a 12pt font -- the baseline must be changed in this case. Werner Lemberg University of Vienna "Ich brauche das nicht zu lesen um zu wissen, dass es schlecht ist" K. Kraus From CAI@neurophys.wisc.edu Mon May 3 18:15:54 1993 Return-Path: Date: Mon, 3 May 93 12:31 CST From: CAI@neurophys.wisc.edu Subject: font files and thank you To: xiaofei@ifcss.org X-Vms-To: IN%"xiaofei@ifcss.org" Status: O ------------ From: IN%"ygz@cs.purdue.EDU" 2-MAY-1993 22:36:44.66 To: CAI@neurophys.wisc.edu The corrected Full HBF files are enclosed. Take a "diff" with your old version you may see the change I made. A few highlights are listed here: ... 4) For cclibh.24, I break your code-range into two. Since the range 0xAAA1-0xAFFE is not defined, we have no reason to include it in the font (you want to waste the application program's run-time memory as well?). Also, I use "hbf-show.sh" to test the bitmap fonts in ifcss.org. I found the last few characters (0xf7fe, 0xf7fc) are all empty boxes in cclib.k24, cclibh.24, cclibk.24. (I didn't try others). Do you have any idea why? ------------- Thank you for your reply. Your script for checking HBF files is wonderful, but I could not use it since I have no access to a unix machine right now. My system manager and I tried to use it on vms but failed. So I especially appreciate your reply. For fonts like cclibh.24, I did not check individual character so I was not aware of those empty boxes. But I did accidentally find one in the middle of the fonts and I "hand-fixed" it in "cclib.h24" and alike. Now I just checked those fonts I posted (cclib.h24 or alike: 0xf0a1-0xf7fe) and found 77 empty boxes (the last two: 0xf7fc, 0xf7fe). The positions are identical. Since both set of fonts came from the same "mother fonts", it is likely those empty boxes existed in the "mother fonts". The regularity of the empty boxes suggested to me that the bitmaps were not "drawn" for some reason, maybe too complicated to be drawn in 24x24. Those fonts (cclibh.24) are posted by Xiaofei and I'll forward this message to him. Yidao Cai From CAI@neurophys.wisc.edu Mon May 3 18:19:59 1993 Return-Path: Date: Mon, 3 May 93 15:10 CST From: CAI@neurophys.wisc.edu Subject: names of HBF files, RE: WL To: soft-authors@ifcss.org X-Vms-To: IN%"soft-authors@ifcss.org" Status: O ******** From: IN%"A7621GAC@AWIUNI11.EDVZ.UniVie.AC.AT" "Werner Lemberg" 3-MAY-1993 04:49:48.91 To: soft-authors@ifcss.ORG I suggest that the file name of a HBF file should consist of 8+3 characters to maintain readability on virtually all computer systems. The ending should be .HBF, and the name itself should describe the font as good as possible. ******** I agree in part. There were a lot of discussions on the names of HBF files and it seemed to me that we "agreed" that the names should be left to individual softwares. An user who want to try different softwares can simply copy the HBF file and name it as required by the software he/she is using. However, there is still a question of naming HBF files on the ftp site (But this is a question different from that Werner raised !). MC Pong suggested "clib_h24.hbf" for bitmap file "cclib.h24" and "clibh_24.hbf" for "cclibh.24" in order to fit into the 8/3 format, and he even encouraged everybody to put your own HBF files to the ftp site so that you have a chance to name the HBF files as you like. I think there are two essential questions to consider: 1). the name must identify the file to be a HBF file; 2). it must let outsiders easily determine the bitmap font files of a HBF file and vice versa. 1) can be satisfied with ".hbf" and 2) can be satisfied with the name of bitmap font file. e.g. cclib.h24 cclib_h24.hbf cclibh.24 cclibh_24.hbf chinese.16 chinese_16.hbf An user can than ftp the HBF files and rename it to whatever name that can be recognized by the software he/she is using. This works well for those HBF files that points to only one bitmap files. For those HBF files that points to more than one bitmap files, like the one in HBF standard v1.0 (or v0.4), it does not work. From CAI@neurophys.wisc.edu Mon May 3 18:20:41 1993 Return-Path: Date: Mon, 3 May 93 13:03 CST From: CAI@neurophys.wisc.edu Subject: names of HBF files, RE: WL To: soft-authors@ifcss.org X-Vms-To: IN%"soft-authors@ifcss.org" Status: O ******** From: IN%"A7621GAC@AWIUNI11.EDVZ.UniVie.AC.AT" "Werner Lemberg" 3-MAY-1993 04:49:48.91 To: soft-authors@ifcss.ORG I suggest that the file name of a HBF file should consist of 8+3 characters to maintain readability on virtually all computer systems. The ending should be .HBF, and the name itself should describe the font as good as possible. ******** I agree. There were a lot of discussions on the names of HBF files and it seemed to me that we "agreed" that the names should be left to individual softwares. An user who want to try different softwares can simply copy the HBF file and name it as required by the software he/she is using. However, there is still a question of naming HBF files on the ftp site (This is a question different from that Werner raised !). MC Pong suggested "clib_h24.hbf" for bitmap file "cclib.h24" and "clibh_24.hbf" for "cclibh.24" in order to feed into the 8/3 format, and he even encouraged everybody to put your own HBF files to the ftp site so that you have a chance to name the HBF files as you like. I think there are two essential questions to consider: 1). the name must identify the file to be a HBF file; 2). it must let outsiders easily determine the bitmap font files of a HBF file and vice versa. 1) can be satisfied with ".hbf" and 2) can be satisfied with the name of bitmap font file. e.g. cclib.h24 cclib_h24.hbf cclibh.24 cclibh_24.hbf chinese.16 chinese_16.hbf An user can than ftp the HBF files and rename it to whatever name that can be recognized by the software he/she is using. This works well for those HBF files that points to only one bitmap files. For those HBF files that points to more than one bitmap files, like the one in HBF standard v1.0 (or v0.4), it does not work. From mcpong@cs.ust.hk Mon May 3 21:37:08 1993 Return-Path: Date: Tue, 4 May 93 10:30:08 HKT From: mcpong@cs.ust.hk (Dr. Man-Chi PONG) To: soft-authors@ifcss.org Subject: comments on HBF draft v0.4 Status: O > Date: Mon, 03 May 93 11:15:53 MEZ > From: Werner Lemberg > Subject: HBF file names / baseline of a bitmap font > > Secondly I believe that defining a baseline of a Chinese bitmap font is > not very useful because there is no exact relation between this bitmap > font and the real size in points. The baseline is used to align Chinese bitmap font & ASCII bitmap font on the display. > For my private use I arranged a 48x48 bitmap font in conjunction with > 11pt postscript fonts, but anybody can also use a 12pt font -- the baseline > must be changed in this case. Assuming we are not using outline hanzi font (no such free font available yet), most printing utility programs for hanzi uses the some hanzi bitmap font and ASCII postscript fonts to convert to raw bitmap in postscript or directly to dot matrix printers. The base line as defined now may not be useful. Further studies may be needed to get the calibration parameters for PRINTING. Nevertheless, the base line is useful for DISPLAYING where the ASCII font glyphs are also converted to bitmaps. Anything taking care of PRINTING requirement may be delayed to versions > 1.0. ===================== > Date: Mon, 3 May 93 15:10 CST > From: CAI@neurophys.wisc.edu > Subject: names of HBF files, RE: WL > > I think there are two essential questions to consider: > > 1). the name must identify the file to be a HBF file; > > 2). it must let outsiders easily determine the bitmap font files of a HBF > file and vice versa. Two good criteria. > 1) can be satisfied with ".hbf" and 2) can be satisfied with the name of > bitmap font file. e.g. > > cclib.h24 cclib_h24.hbf > cclibh.24 cclibh_24.hbf > chinese.16 chinese_16.hbf => Suffix ".hbf" is a good (enough) choice -- actually we have discussed what the 3 letters of the suffix should be. :-) I often recommend meaning names (usually longer). They are more suggestive often without looking into the details of the file or any standardization documents. Standardardization of the main name to 8 characters may be too limiting, which may have problems when some future "fancy" hanzi fonts appear. > An user can than ftp the HBF files and rename it to whatever name that > can be recognized by the software he/she is using. Agree. The application can rename any long file-name (say, in Unix) in PC environment. > This works well for those HBF files that points to only one bitmap files. > For those HBF files that points to more than one bitmap files, like the one > in HBF standard v1.0 (or v0.4), it does not work. Agree. This is a problem of the TeX style naming convention/standard of font file-names. It does not apply well to hanzi bitmap files, where one font may be splitted into several bitmap files. From @AWIUNI11.EDVZ.UNIVIE.AC.AT:A7621GAC@AWIUNI11.EDVZ.UNIVIE.AC.AT Wed May 5 08:02:38 1993 Return-Path: <@AWIUNI11.EDVZ.UNIVIE.AC.AT:A7621GAC@AWIUNI11.EDVZ.UNIVIE.AC.AT> Date: Wed, 05 May 93 14:53:46 MEZ From: Werner Lemberg Subject: Re: File names of HBF files To: soft-authors@ifcss.org Status: O If already there are any conventions how to name a HBF file, this should be mentioned in the standard. Or if there aren't any standards, this fact should be mentioned too. Werner Lemberg From mcpong@cs.ust.hk Fri May 7 22:18:02 1993 Return-Path: Date: Sat, 8 May 93 11:10:42 HKT From: mcpong@cs.ust.hk (Dr. Man-Chi PONG) To: soft-authors@ifcss.org Subject: HBF file naming convention Status: O > Date: Wed, 05 May 93 14:53:46 MEZ > From: Werner Lemberg > Subject: Re: File names of HBF files > > If already there are any conventions how to name a HBF file, this should > be mentioned in the standard. Or if there aren't any standards, this fact > should be mentioned too. It's a good idea. There isn't any standard on the naming the HBF files. Some suggestion on how to name them may be given as an Appendix. (Whether there will be such an appendix depends on whether anything would be written (by whom ... etc.) -- I'm running out of time to do it.) So far it's the only suggested update to HBF Standard draft v0.4. I'll wait for a while more to see if any more comments. Then I'll send out draft v0.5 -- hope that will be adopted as Standard v1.0 mcpong From @AWIUNI11.EDVZ.UNIVIE.AC.AT:A7621GAC@AWIUNI11.EDVZ.UNIVIE.AC.AT Tue May 18 12:05:47 1993 Return-Path: <@AWIUNI11.EDVZ.UNIVIE.AC.AT:A7621GAC@AWIUNI11.EDVZ.UNIVIE.AC.AT> Date: Tue, 18 May 93 18:55:33 MEZ From: Werner Lemberg Subject: Additional HBF-keyword To: soft-authors@ifcss.org Status: O I suggest the introduction of an additional keyword: HBF_SPECIAL blablabla... or HBF_SPECIAL_START blablabla... blablabla... . . . HBF_SPECIAL_END This would allow to incorporate software specific data. (I currently write a program which would make use of it :-) Werner Lemberg From mcpong@cs.ust.hk Tue May 18 20:24:34 1993 Return-Path: Date: Wed, 19 May 93 09:18:16 HKT From: mcpong@cs.ust.hk (Dr. Man-Chi PONG) To: A7621GAC@AWIUNI11.EDVZ.UniVie.AC.AT, soft-authors@ifcss.org Subject: Re: Additional HBF-keyword Status: O > Date: Tue, 18 May 93 18:55:33 MEZ > From: Werner Lemberg > > I suggest the introduction of an additional keyword: > > HBF_SPECIAL blablabla... > > or > > HBF_SPECIAL_START > blablabla... > blablabla... > . > . > . > HBF_SPECIAL_END > > > This would allow to incorporate software specific data. > (I currently write a program which would make use of it :-) I don't object in principle. However, "keep it simple and stupid" is a good guideline. Just curious, why these special data be necessary? I suppose it's application specific. Couldn't it be separate from the HBF file(s), and put in another file(s)? mcpong From yawei Tue May 18 20:39:57 1993 Return-Path: Date: Tue, 18 May 93 20:35:13 CDT From: yawei (Ya-Gui Wei) To: A7621GAC@AWIUNI11.EDVZ.UniVie.AC.AT, mcpong@cs.ust.hk, soft-authors@ifcss.org Subject: Re: Additional HBF-keyword Status: RO I guess naming of HBF files has been visited. How about where in the directory tree HBF files can be found? In Unix or DOS, an environment variable "HBF=..." can be specified with a list of directories from where a program may go to look for the HBF files as a convension. Perhaps this can be noted in the appendix. From CAI@neurophys.wisc.edu Wed May 19 21:17:37 1993 Return-Path: Date: Wed, 19 May 93 09:52 CST From: CAI@neurophys.wisc.edu Subject: Re: Additional HBF key word To: soft-authors@ifcss.org X-Vms-To: IN%"soft-authors@ifcss.org" Status: RO ********** From: IN%"A7621GAC@AWIUNI11.EDVZ.UniVie.AC.AT" "Werner Lemberg" 19-MAY-1993 06:38:49.54 I just downloaded to ifcss.org my preliminiary version of spr2bmf (Spring fonts to bitmap fonts) - in future versions I like to do it more user friendly. This program will take a Spring font as an input and should complete a HBF-file in addition to the bitmap font. Some informations needed before running are the bitmap size and the output file name. These facts can be described with HBF-keywords, but the name of the input file not. Hence I need a HBF_SPECIAL or something else to do the job. Werner Lemberg ******* I think it can be 1. put into a COMMENT statement, or 2. incooperated into the name of the output file, or 3. described in the NOTICE property such as NOTICE "The bitmap files are that of ETen system v2.00.03 or the equivalent." given in the HBF v1.0 (d0.4). I remember we discussed before that those rarely used and not defined (in HBF standard) properties can be put into a COMMENT statement, it is up to individual software to decide wether to read it or not. I guess the property mentioned above belongs to this catagory. Yidao From @AWIUNI11.EDVZ.UNIVIE.AC.AT:A7621GAC@AWIUNI11.EDVZ.UNIVIE.AC.AT Wed May 19 06:41:54 1993 Return-Path: <@AWIUNI11.EDVZ.UNIVIE.AC.AT:A7621GAC@AWIUNI11.EDVZ.UNIVIE.AC.AT> Date: Wed, 19 May 93 13:29:06 MEZ From: Werner Lemberg Subject: Re: Additional HBF keyword To: soft-authors@ifcss.org Status: O I just downloaded to ifcss.org my preliminiary version of spr2bmf (Spring fonts to bitmap fonts) - in future versions I like to do it more user friendly. This program will take a Spring font as an input and should complete a HBF-file in addition to the bitmap font. Some informations needed before running are the bitmap size and the output file name. These facts can be described with HBF-keywords, but the name of the input file not. Hence I need a HBF_SPECIAL or something else to do the job. Werner Lemberg From @AWIUNI11.EDVZ.UNIVIE.AC.AT:A7621GAC@AWIUNI11.EDVZ.UNIVIE.AC.AT Sat May 22 05:22:31 1993 Return-Path: <@AWIUNI11.EDVZ.UNIVIE.AC.AT:A7621GAC@AWIUNI11.EDVZ.UNIVIE.AC.AT> Date: Sat, 22 May 93 12:05:42 MEZ From: Werner Lemberg Subject: Re: Additional HBF key word To: Yidao , soft-authors@ifcss.org In-Reply-To: Your message of Wed, 19 May 93 09:52 CST Status: O On Wed, 19 May 93 09:52 CST you said: > >>This program will take a Spring font as an input and should complete >>a HBF-file in addition to the bitmap font. Some informations needed >>before running are the bitmap size and the output file name. >>These facts can be described with HBF-keywords, but the name of the input >>file not. Hence I need a HBF_SPECIAL or something else to do the job. >> >>Werner Lemberg >>******* > >I think it can be > >1. put into a COMMENT statement, or > >2. incooperated into the name of the output file, or > >3. described in the NOTICE property such as > >NOTICE "The bitmap files are that of ETen system v2.00.03 or the equivalent." > >given in the HBF v1.0 (d0.4). > >I remember we discussed before that those rarely used and not defined (in HBF >standard) properties can be put into a COMMENT statement, it is up to >individual software to decide wether to read it or not. I guess the property >mentioned above belongs to this catagory. > >Yidao I think I didn't state my suggestion precisely enough. I believe that a COMMENT or a NOTICE should be readable by human beings, but using my HBF_SPECIAL blablabla... this blablabla possibly contains just binary data (e.g. an additional character needed, or something else). Compare this idea to the "special" command in TeX or in the .gf-files. Werner Lemberg From lee@fritter.Stanford.EDU Thu May 27 13:31:40 1993 Return-Path: Date: Thu, 27 May 93 11:26:32 -0700 From: lee@fritter.stanford.edu (Fung Fung Lee) To: soft-authors@ifcss.org In-Reply-To: Werner Lemberg's message of Sat, 22 May 93 12:05:42 MEZ <9305221015.AA10323@ifcss.org> Subject: Are we ready to endorse HBF? (Was: Additional HBF key word) Status: O I don't see any advantage at this time to add the proposed new keyword "HBF_SPECIAL". The bitmap size or more precisely bitmap dimension is already taken care by the HBF_BITMAP_BOUNDING_BOX entry. Specifying the output file name is NOT part of the job of HBF. The output file name can either be obtained from command line options derived from the input file name, or by whatever scheme the translator program chooses. An .hbf file is expected to contain only ASCII text, for maximum portability, therefore NO binary data should be included. If extra character bitmaps are needed, they can always be contained in a separate raw bitmap file, and pointed to by additional HBF_CODE_RANGE entries. I think the discussion of HBF has dragged on for a sufficiently long time, and has reached beyond the point of "diminishing return". Yes, there are some minor implementation issues to be resolved, but they don't really affect the completeness and integrity of the current draft as I see it. Let's leave some room of choice for the implementation guys. Let's act quickly and finish this HBF spec business. To provide concrete support to this "emerging" standard and to whoever are working on an API implementation, I propose software authors to send a note of endorsement to Prof. M. C. Pong. Best regards, Fung F. Lee }Date: Sat, 22 May 93 12:05:42 MEZ }From: Werner Lemberg } }On Wed, 19 May 93 09:52 CST you said: }> }>>This program will take a Spring font as an input and should complete }>>a HBF-file in addition to the bitmap font. Some informations needed }>>before running are the bitmap size and the output file name. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }>>These facts can be described with HBF-keywords, but the name of the input }>>file not. Hence I need a HBF_SPECIAL or something else to do the job. }>> }>>Werner Lemberg }>>******* }> }>I think it can be }> }>1. put into a COMMENT statement, or }> }>2. incooperated into the name of the output file, or }> }>3. described in the NOTICE property such as }> }>NOTICE "The bitmap files are that of ETen system v2.00.03 or the equivalent." }> }>given in the HBF v1.0 (d0.4). }> }>I remember we discussed before that those rarely used and not defined (in HBF }>standard) properties can be put into a COMMENT statement, it is up to }>individual software to decide wether to read it or not. I guess the property }>mentioned above belongs to this catagory. }> }>Yidao } } }I think I didn't state my suggestion precisely enough. } }I believe that a COMMENT or a NOTICE should be readable by human beings, }but using my } }HBF_SPECIAL blablabla... } }this blablabla possibly contains just binary data (e.g. an additional ^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^ }character needed, or something else). Compare this idea to the "special" ^^^^^^^^^^^^^^^^ }command in TeX or in the .gf-files. } }Werner Lemberg From simpson@math.psu.edu Thu May 27 13:55:27 1993 Return-Path: From: Stephen G Simpson Date: Thu, 27 May 93 14:50:49 -0400 To: mcpong@cs.ust.hk Cc: soft-authors@ifcss.org In-Reply-To: <9305271826.AA20499@fritter.Stanford.EDU> Subject: Are we ready to endorse HBF? (Was: Additional HBF key word) Status: O Fung Fung Lee writes: > Let's act quickly and finish this HBF spec business. > To provide concrete support to this "emerging" standard and to whoever > are working on an API implementation, I propose software authors to > send a note of endorsement to Prof. M. C. Pong. I hereby endorse the HBF 1.0 standard as defined in the recent HBF_std_v0.1_d0.4 document, authored by M. C. Pong. I plan to use the HBF standard whenever possible in any software that I develop. I am already using the HBF standard in my Flash software package, available for anonymous ftp at math.psu.edu, pub/simpson/chinese/msdos/flash-13.zip. Stephen G. Simpson Department of Mathematics, Pennsylvania State University 333 McAllister Building, University Park, State College, PA 16802 Office phone: +1 814 863-0775 Internet: simpson@math.psu.edu Home phone: +1 814 238-2274 Bitnet: T20 AT PSUVM FAX: +1 814 865-3735 From lee@fritter.Stanford.EDU Thu May 27 14:20:52 1993 Return-Path: Date: Thu, 27 May 93 12:16:14 -0700 From: lee@fritter.stanford.edu (Fung Fung Lee) To: mcpong@cs.ust.hk Cc: soft-authors@ifcss.org Subject: Are we ready to endorse HBF? (Was: Additional HBF key word) Status: RO Following Stephen G Simpson's prompt response to my call for endorsement, I hereby endorse the HBF 1.0 standard as defined in the recent HBF_std_v0.1_d0.4 document, authored by M. C. Pong. I plan to use the HBF standard whenever possible in any software that I will develop and update, including future versions of "hz2ps" and "hzview". Fung F. Lee Stanford University ERL 406, Stanford, CA 94305 lee@umunhum.stanford.edu From CAI@neurophys.wisc.edu Thu May 27 15:44:12 1993 Return-Path: Date: Thu, 27 May 93 15:39 CST From: CAI@neurophys.wisc.edu Subject: Re: Are we ready to endorse HBF ? To: soft-authors@ifcss.org X-Vms-To: IN%"soft-authors@ifcss.org" Status: RO I hereby endorse the HBF 1.0 standard as defined in the recent HBF_std_v0.1_d0.4 document, authored by M. C. Pong. I have already used the HBF standard in my CNPRINT version 2.20/2.21 which are undergoing user tests and will be put on ifcss.org under directory /software/unix(vms, dos)/print next month. Yidao Cai Department of Neurophysiology The University of Wisconsin Medical School 1300 University Ave Madison, WI 53705 USA cai@neurophys.wisc.edu PS. I think the next thing is to write HBF files for those fonts on ftp site. I've put 10 HBF files on ifcss.org:/software/font/HBF. Two of those were kindly checked by ygz at purdue and I "coined" the rest because they have the same structure. If you find problems with those HBFs please let me know. Thanks. Maybe we should include the name of author into the HBF files. From mcpong@cs.ust.hk Thu May 27 23:15:20 1993 Return-Path: Date: Fri, 28 May 93 12:08:58 HKT From: mcpong@cs.ust.hk (Dr. Man-Chi PONG) To: soft-authors@ifcss.org Subject: announce HBF v1.0 = draft v0.5 Status: RO I've updated to draft v0.4 to draft v0.5 which is the Hanzi Bitmap Font (HBF) File Format Standard Version 1.0 -------------------------------------------------------- which will be sent out in next mail. Extract from the Standard: Draft v0.5 -- officially announced 1993/05/28 -- adopted as Hanzi Bitmap Font (HBF) File Format Standard Version 1.0 changes from v0.4: -- mention that HBF file name convention is not part of this standard. -- some minor presentation changes. To xiaofei@ifcss.org, Would you please make this Standard the file "HBF_std_v1.0_d0.5" in the directory "ifcss.org:/software/fonts/d/" and use a link in the directory to name it as "HBF_std_v1.0" ? Also, would you announce it in "mailing-list.ccnet-l" etc.? Many thanks. mcpong From mcpong@cs.ust.hk Fri May 28 20:29:39 1993 Return-Path: Date: Sat, 29 May 93 09:14:22 HKT From: mcpong@cs.ust.hk (Dr. Man-Chi PONG) To: rap@doc.ic.ac.uk Subject: HBF Standard v1.0 Cc: soft-authors@ifcss.org Status: O Hi, Ross, > From simpson@math.psu.edu Sat May 29 00:09:10 1993 > To: soft-authors@ifcss.org > Subject: Ross Paterson's comments on the HBF standard > > In response to M. C. Pong's announcement of HBF on CCNET, Ross > Paterson posted some useful comments. I am taking the liberty of > forwarding Ross's posting to our soft-authors list. > > Over the past year or so I have found Ross to be extremely > knowledgeable about technical issues in Chinese computing. He has a > large collection of lexicographical data and he seems to know more > than anybody else about Chinese character coding schemes. If we can > persuade him, he would be a very valuable addition to this group. > Shall we perhaps ask him to join? If the size of the group is > limited, I could resign to make way for Ross :-). > > -- Steve Simpson Would you like to join the discussion mailing list? If so, please send a mail to the coordinator xiaofei@ifcss.org to say so. (There's no limitation on group size. :-) > -------------- > > From: Ross Paterson > Sender: Chinese Computing Network > To: Multiple recipients of list CCNET-L > Subject: Re: hanzi bitmap font (HBF) Standard > Date: Fri, 28 May 1993 14:59:00 BST > > On coding schemes, > > > Accepted values for HBF_CODE_SCHEME in this Standard v1.0 are: > > [...] > > Unicode vendor v1.1 -- not simply "Unicode"; use the specific > > version "v1.1" supplied by "vendor". > > Unicode is still evolving and thus > > different versions exist. > > [ some of your comment deleted ] > > ... Thus the coding schemes should be called > > Unicode 1.0 > Unicode 1.0.1 > Unicode 1.1 > > but these are all equivalent as far as the Chinese portion is concerned, > and the first two are now obsolete. You could add an optional vendor > and vendor-version if you're using the Private Use Area, but that's > best avoided. Thanks for your comment on Unicode. The latest I know is that v1.1 is being discussed & soon be finalized. Thus I mention Unicode vendor v1.1 This format is to be consistent with Big5 vendor version Actually "vendor version" is an optional compound attribute. Probably no free Unicode hanzi font is available yet. We can straighten out this "vendor version" or "version vendor" specification issue, especially for Unicode, in later version of HBF standard. > As for the C interface, I would have expected just > > typedef struct { > /* fields corresponding to the definition */ > /* plus internal table of font files */ > } HBF_FILE; > > HBF_FILE * HBF_OpenFont(const char *hbfFileName); > int HBF_CloseFont(HBF_FILE *hbfFile); > int HBF_GetBitmap(HBF_FILE *hbfFile, > HBF_HzCode code, > char *buffer); > > (I can't see how you'd avoid re-opening font files all the time with the > existing definition.) The API implementation is free to do HBF_OpenFont and HBF_CloseFont. (Say, it may keep a reference count of how many times a font is closed.) There has been some discussion on these two API calls. If you are interested in the detailed discussion, please see the mail sent by tee@ecf.toronto.edu in the ifcss.org:/software/fonts/d/ archive and the replies. > -- > Ross Paterson > Department of Computing, Imperial College, London SW7 mcpong From mcpong@cs.ust.hk Fri Jun 4 05:56:44 1993 Return-Path: Date: Fri, 4 Jun 93 18:43:19 HKT From: mcpong@cs.ust.hk (Dr. Man-Chi PONG) To: soft-authors@ifcss.org Subject: Update of Ross's HBF API implementation Status: RO Thanks to Ross Paterson who produced a version of the HPF API implementation. That version has the essence to handle process HBF file and retrieve bitmap from the bitmap file(s). Since that version doesn't totally conform to the HBF Standard v1.0, I update it, restructure it, and enhance it to check the keywords acceptable to full HBF files as well. At the end of this mail is the shar file of the five files: Makefile hbf.h -- the interface for program using the API. -- the aim is that only this .h file needs to be #include in the user program. hbf_impl.h -- the declaration part of the implementation. hbf.c -- the coding part of the implementation. tester.c -- the test driver program. Save it to a file and run "sh savedFileName" to extract the five files. --------- Moreover, during the course, I find that there are some minor errors (or inconsistency) in the HBF Standard v1.0. (see below). In order not to broadcast the whole file, I have sent the update to xiaofei@ifcss.org who should replace the Standard in the ftp site. You may simply edit the errors instead of ftp -- it should be faster. The errors are that: the type of the parameters xDisplacement and yDisplacement in HBF_GetFontBoundingBox() and HBF_GetBitmapBoundingBox() should be int, not unsigned int, because there can be negative Displacement values: int HBF_GetFontBoundingBox( IN HBF_Handle handle, OUT unsigned int *width, OUT unsigned int *height, OUT int *xDisplacement, <-- change this line OUT int *yDisplacement ); <-- change this line int HBF_GetBitmapBoundingBox( IN HBF_Handle handle, OUT unsigned int *width, OUT unsigned int *height, OUT int *xDisplacement, <-- change this line OUT int *yDisplacement ); <-- change this line Comments and bug reports are welcome. mcpong@cs.ust.hk ---------------- cut here for the shar file --------------------------- #!/bin/sh # This is a shell archive (produced by shar 3.50) # To extract the files from this archive, save it to a file, remove # everything above the "!/bin/sh" line above, and type "sh file_name". # # made 06/04/1993 10:39 UTC by mcpong@cssu2 # Source directory /staff2/cs/mcpong/CIP/HBF/src # # existing files will NOT be overwritten unless -c is specified # # This shar contains: # length mode name # ------ ---------- ------------------------------------------ # 188 -rw-r--r-- Makefile # 4245 -rw-r--r-- hbf.h # 3390 -rw-r--r-- hbf_impl.h # 20083 -rw-r--r-- hbf.c # 3815 -rw-r--r-- tester.c # # ============= Makefile ============== if test -f 'Makefile' -a X"$1" != X"-c"; then echo 'x - skipping Makefile (File already exists)' else echo 'x - extracting Makefile (Text)' sed 's/^X//' << 'SHAR_EOF' > 'Makefile' && NAME = tester X CFLAGS = -g -DDEBUG X all: $(NAME) X $(NAME): $(NAME).o hbf.o X $(CC) $(CFLAGS) -o $@ $(NAME).o hbf.o X clobber clean: X rm -f *.o core LOG a.out $(NAME) X $(NAME).o hbf.o: hbf.h SHAR_EOF chmod 0644 Makefile || echo 'restore of Makefile failed' Wc_c="`wc -c < 'Makefile'`" test 188 -eq "$Wc_c" || echo 'Makefile: original size 188, current size' "$Wc_c" fi # ============= hbf.h ============== if test -f 'hbf.h' -a X"$1" != X"-c"; then echo 'x - skipping hbf.h (File already exists)' else echo 'x - extracting hbf.h (Text)' sed 's/^X//' << 'SHAR_EOF' > 'hbf.h' && #ifndef _hbf_h_ #define _hbf_h_ /* hbf.h */ X /* X * C interface for API for X * HBF File Format Standard v1.0. X * X * An application only need to include this file to use the X * API routines. X * X * 19930603 created Ross Paterson X * -- A sketch implemenation of API for X * HBF File Format Standard v1.0; X * but not completely conforming to the Standard. X * X * 19930604 modified Man-Chi Pong X * -- Conform to HBF File Format Standard v1.0. X * -- Can capture the properties of full HBF as well. X */ #include /* caddr_t */ X typedef unsigned int HBF_HzCode; X #ifndef __STDC__ # ifndef const # define const X /* const parameter means the parameter's value is not modified. */ # define OUT X /* OUT parameter means a value is returned via the parameter. */ # endif #endif X typedef caddr_t HBF_Handle ; /* as interface */ X /* typedef HBF_StructPtr HBF_Handle ; -- hidden in implementation */ X int HBF_OpenFont( #ifdef __STDC__ X const char * hbfFileName, X OUT HBF_Handle *addrHandleStorage #endif X ); X X /* Open and initialize an HBF file. X * X * The INOUT parameter "ptrHandleStorage" points to a storage X * large enough to store the opened font handle. X * This routine will assign the value of the opened handle X * to this storage. X * X * RETURN 0 if the font given by the hbfFileName is opened successfully; X * or non-zero if error. X */ X /************************************************************/ X X int HBF_CloseFont( #ifdef __STDC__ X const HBF_Handle hbfHandle #endif X ); X X /* Close an HBF file. X * X * RETURN 0 if OK; X * or non-zero if error. X */ X /************************************************************/ X X char * HBF_GetProperty( #ifdef __STDC__ X const HBF_Handle hbfHandle, X const char * propertyName #endif X ); X /* Get the property of the given propertyName. X * X * RETURN the character string as if appeared after the keyword of X * the property in the property line in the HBF file, X * starting with a non-blank character, with only one blank X * character separating each pair of tokens in the string, X * and with no trailing blanks; X * or NULL if invalid HBF handle or invalid propertyName. X * X * The calling routine should NOT change the returned string. X */ X /************************************************************/ X X int HBF_GetFontBoundingBox( #ifdef __STDC__ X const HBF_Handle hbfHandle, X OUT unsigned int *addrWidth, X OUT unsigned int *addrHeight, X OUT int *addrXDisplacement, X OUT int *addrYDisplacement, #endif X ); X /* Get the font bounding-box information for a given HBF. X * X * RETURN 0 if OK, and the font bounding-box information X * is returned in OUT parameters; X * or non-zero if invalid HBF handle. X */ X /************************************************************/ X X int HBF_GetBitmapBoundingBox( #ifdef __STDC__ X const HBF_Handle hbfHandle, X OUT unsigned int *addrWidth, X OUT unsigned int *addrHeight, X OUT int *addrXDisplacement, X OUT int *addrYDisplacement, #endif X ); X /* Get the glyph bitmap bounding-box information for a given HBF. X * X * RETURN 0 if OK, and the glyph bitmap bounding-box information X * is returned in OUT parameters; X * or non-zero if invalid HBF handle. X */ X /************************************************************/ X X int HBF_GetBitmap( #ifdef __STDC__ X const HBF_Handle hbfHandle, X const HBF_HzCode hanziCode, X OUT char * ptrBitmapBuffer #endif X ); X /* Get the bitmap for the given hanzi code. X * X * The INOUT parameter "ptrBitmapBuffer" points to a buffer X * large enough to store the byte sequence of the bitmap of X * the hanzi. This routine will copy the bitmap sequence X * into the buffer. X * X * RETURN 0 if the bitmap is found; X * or non-zero if invalid HBF handle or invalid hanzi code, X * and the BitmapBuffer's content is undefined. X */ X X X /* N.B.: X * It is up to the application to show the bitmap properly within X * the FONTBOUNDINGBOX, if different from HBF_BITMAP_BOUNDING_BOX. X */ X #endif/*_hbf_h_*/ SHAR_EOF chmod 0644 hbf.h || echo 'restore of hbf.h failed' Wc_c="`wc -c < 'hbf.h'`" test 4245 -eq "$Wc_c" || echo 'hbf.h: original size 4245, current size' "$Wc_c" fi # ============= hbf_impl.h ============== if test -f 'hbf_impl.h' -a X"$1" != X"-c"; then echo 'x - skipping hbf_impl.h (File already exists)' else echo 'x - extracting hbf_impl.h (Text)' sed 's/^X//' << 'SHAR_EOF' > 'hbf_impl.h' && #ifndef _hbf_impl_h_ #define _hbf_impl_h_ /* hbf_impl.h */ X /* X * Implementation part of data constants, types, and structures X * for API for X * HBF File Format Standard v1.0. X * X * This should be read with X * "hbf.h" -- the "Interface part" of the API: "hbf.h" X * "hbf.c" -- the C coding part. X * X * 19930603 created Man-Chi Pong X * -- conform to HBF File Format Standard v1.0 X */ X #define reg register X typedef int bool; #define TRUE 1 #define FALSE 0 X #define OK_RETURN 0 #define NOT_OK_RETURN -1 X extern char *malloc(); extern char *calloc(); extern char *strrchr(); extern char *strdup(); X #define HBF_MAGIC_STRING "hbfv1.0" X /* Used to check the validity of the HBF_Handle passed to API. X * The run-time HBF_Handle should has a field pointed to this X * HBF_MAGIC_STRING. X */ X /* X * Useful constants: X */ #define QUOTE '"' X #define MAXCHARPERLINE 1024 X /* X * Internal structures: X */ typedef unsigned char Uchar; X #define BM_FILE struct _HBF_BM_FILE #define B2_RANGE struct _HBF_B2_RANGE #define CODE_RANGE struct _HBF_CODE_RANGE X BM_FILE { X char *bmf_name; X FILE *bmf_file; X BM_FILE *bmf_next; }; X typedef struct _HBF_B2_RANGE { X Uchar b2r_start; X Uchar b2r_finish; X B2_RANGE * b2r_next ; /* can be removed if array implementation */ } HBF_Byte2Range, * HBF_Byte2RangePtr ; X typedef struct _HBF_CODE_RANGE { X HBF_HzCode code_start; X HBF_HzCode code_finish; X BM_FILE * code_bm_file; X unsigned long code_offset; X unsigned int code_pos; X CODE_RANGE * code_next ; /* can be removed if array implementation */ } HBF_CodeRange, * HBF_CodeRangePtr ; X typedef struct { X unsigned int HBF_width; X unsigned int HBF_height; X int HBF_xDisplacement; X int HBF_yDisplacement; } HBF_BBOX, * HBF_BBOXPtr ; X typedef struct { X const char * cpPropertyName ; X const char * cpPropertyValue ; } HBF_Property, * HBF_PropertyPtr ; X typedef struct { X /* fields related to the implemenation details or convenience: */ X X char HBF_magic_string[ sizeof( HBF_MAGIC_STRING ) ] ; X const char * filename; /* name of the HBF file */ X unsigned b2_size; /* number of legal byte-2's */ X int HBF_nOpenCount ; /* reference count -- not yet used yet */ X X /* fields corresponding to the HBF file definition: */ X X const char * HBF_version; /* HBF_START_FONT */ X const char * HBF_code_scheme; /* HBF_CODE_SCHEME */ X const char * HBF_font; /* FONT */ X const char * HBF_size; /* SIZE */ /* only in full HBF */ X HBF_BBOX HBF_bitmap_bbox; /* HBF_BITMAP_BOUNDING_BOX */ X HBF_BBOX HBF_font_bbox; /* FONTBOUNDINGBOX */ X X int HBF_nProperty ; /* >= 0 entries */ X HBF_PropertyPtr HBF_pPropertyTable ; /* >= 0 entries */ X X HBF_HzCode HBF_default_char; /* DEFAULT_CHAR */ X /* Also in HBF_pPropertyTable. */ X /* Often used, so an extra field. */ X X unsigned HBF_chars; /* CHARS */ X X int HBF_nByte2Range ; /* >= 0 entries */ X HBF_Byte2RangePtr HBF_pByte2Range ; /* >= 0 entries */ X X int HBF_nCodeRange ; /* >= 0 entries */ X HBF_CodeRangePtr HBF_pCodeRange ; /* >= 0 entries */ X X /* derived fields: */ X X int HBF_row_size; /* size of a row in bytes */ X int HBF_bm_size; /* size of a bitmap in bytes */ X X BM_FILE *bm_file; } HBF_Struct, * HBF_StructPtr ; X #endif/*_hbf_impl_h_*/ SHAR_EOF chmod 0644 hbf_impl.h || echo 'restore of hbf_impl.h failed' Wc_c="`wc -c < 'hbf_impl.h'`" test 3390 -eq "$Wc_c" || echo 'hbf_impl.h: original size 3390, current size' "$Wc_c" fi # ============= hbf.c ============== if test -f 'hbf.c' -a X"$1" != X"-c"; then echo 'x - skipping hbf.c (File already exists)' else echo 'x - extracting hbf.c (Text)' sed 's/^X//' << 'SHAR_EOF' > 'hbf.c' && /* hbf.c */ /* X * C implementation for API for X * HBF File Format Standard v1.0. X * X * This should be read with X * "hbf.h" -- the "Interface part" of the API: "hbf.h" X * "hbf_impl.h" -- the implemenation part of data constants, X * types, and structures. X * X * 19930603 created Ross Paterson X * -- A sketch implemenation of API for X * HBF File Format Standard v1.0; X * but not completely conforming to the Standard. X * X * 19930604 modified Man-Chi Pong X * -- Conform to HBF File Format Standard v1.0. X * -- Can capture the properties of full HBF as well. X */ X #include #include #include "hbf.h" #include "hbf_impl.h" X /* X * Useful macros for readability: X */ #define IsEqualString(a,b) (strcmp(a,b)==0) #define IsNotEqualString(a,b) (strcmp(a,b)) X #define FirstByte(code) ((code)>>8) #define SecondByte(code) ((code)&0xff) X #define NEW(type) ((type *)malloc((unsigned)(sizeof(type)))) X X static bool InvalidHBF( hbf ) X HBF_StructPtr hbf ; { X return (bool) IsNotEqualString( hbf->HBF_magic_string, X HBF_MAGIC_STRING ) ; } X static void clear_bbox(bbox) X HBF_BBOX *bbox; { X bbox->HBF_width = bbox->HBF_height = 0; X bbox->HBF_xDisplacement = bbox->HBF_yDisplacement = 0; } X static void clear_HBF_Struct(hbf) X HBF_StructPtr hbf; { X hbf->filename = NULL; X X hbf->HBF_version = NULL; X hbf->HBF_code_scheme = NULL; X hbf->HBF_font = NULL; X hbf->HBF_size = NULL; X clear_bbox(&(hbf->HBF_bitmap_bbox)); X clear_bbox(&(hbf->HBF_font_bbox)); X X hbf->HBF_nProperty = 0 ; X hbf->HBF_pPropertyTable = NULL; X hbf->HBF_default_char = 0; X X hbf->HBF_chars = 0; X X hbf->HBF_nByte2Range = 0 ; X hbf->HBF_pByte2Range = NULL; X X hbf->HBF_nCodeRange = 0 ; X hbf->HBF_pCodeRange = NULL; X X hbf->bm_file = NULL; } X /* X * Byte-2 ranges X */ X static void add_b2r(last_b2r, start, finish) reg B2_RANGE **last_b2r; X int start; X int finish; { X B2_RANGE *b2r; X X b2r = NEW(B2_RANGE); X while (*last_b2r != NULL && start > (*last_b2r)->b2r_start) X last_b2r = &((*last_b2r)->b2r_next); X b2r->b2r_next = *last_b2r; X b2r->b2r_start = start; X b2r->b2r_finish = finish; X *last_b2r = b2r; } X static int b2_pos(hbf, code) X HBF_Struct *hbf; X HBF_HzCode code; { reg B2_RANGE *b2r; reg unsigned c; reg int pos; X X c = SecondByte(code); X pos = 0; X for (b2r = hbf->HBF_pByte2Range; b2r != NULL; b2r = b2r->b2r_next) X if (b2r->b2r_start <= c && c <= b2r->b2r_finish) X return pos + c - b2r->b2r_start; X else X pos += b2r->b2r_finish - b2r->b2r_start + 1; X return -1; } X static int b2_size(b2r) reg B2_RANGE *b2r; { reg int size; X X size = 0; X for ( ; b2r != NULL; b2r = b2r->b2r_next) X size += b2r->b2r_finish - b2r->b2r_start + 1; X return size; } X /* X * String stuff X */ X static bool match(lp, sp) reg const char *lp; reg const char *sp; { X while (*lp == *sp && *sp != '\0') { X lp++; X sp++; X } X return isspace(*lp) && *sp == '\0'; } X #ifdef OBSOLETE static char * strdup(s) X const char *s; { X char *copy; X X copy = malloc((unsigned)(strlen(s) + 1)); X strcpy(copy, s); X return copy; } #else /*OBSOLETE*/ #endif/*OBSOLETE*/ X static void get_string(lp, ssp) reg char *lp; X char **ssp; { X char tmp[MAXCHARPERLINE]; reg char *tp; X #ifdef OBSOLETE X if (*ssp != NULL) X return; #else /*OBSOLETE*/ X /* Allows *ssp points to a string. X * It will be re-defined. X */ #endif/*OBSOLETE*/ X X while (! isspace(*lp)) X lp++; X while (isspace(*lp)) X lp++; X tp = tmp; X for (;;) { X while (*lp != '\0' && ! isspace(*lp)) X *tp++ = *lp++; X while (isspace(*lp)) X lp++; X if (*lp == '\0') X break; X *tp++ = ' '; X } X *tp = '\0'; X *ssp = strdup(tmp); } X static void get_quoted(lp, ssp) reg char * lp; X char * *ssp; { X char tmp[MAXCHARPERLINE]; reg char *tp; X bool hasFoundQUOTE ; X #ifdef OBSOLETE X if (*ssp != NULL) X return; X #else /*OBSOLETE*/ X /* Allows *ssp points to a string. X * It will be re-defined. X */ #endif/*OBSOLETE*/ X X /* skip the keyword: X */ X while (! isspace(*lp)) X lp++; X X while (isspace(*lp)) X lp++; X if (*lp++ != QUOTE) X return; X X /* The opening QUOTE has been skipped. */ X while (isspace(*lp)) X lp++; X X /* assert( has not found closing QUOTE ) */ X hasFoundQUOTE = FALSE ; X tp = tmp; X for (;;) { X if (*lp == '\0') X break; X if (*lp == QUOTE && *++lp != QUOTE) X break; X *tp++ = *lp++; X X /* only one space per separator in a quotedString: X */ X if (isspace(*lp)) { X while (isspace(*lp)) X lp++; X X if (*lp == QUOTE && *(lp+1) != QUOTE) { X /* has encountered closing QUOTE; X * any previous space are trailing space X * & can be ignored. X */ X break; X } else { X *tp++ = ' ' ; X } X } X } X *tp = '\0'; X *ssp = strdup(tmp); } X /* X * Code ranges X */ static BM_FILE * find_file(hbf, filename) X HBF_StructPtr hbf; const char * filename; { X BM_FILE **fp; reg BM_FILE *file; #ifdef unix X char *last_slash; X int size; #endif X X for (fp = &(hbf->bm_file); *fp != NULL; fp = &((*fp)->bmf_next)) X if ( IsEqualString( (*fp)->bmf_name, filename ) ) X return *fp; X *fp = file = NEW(BM_FILE); #ifdef unix X if (filename[0] != '/' && X (last_slash = strrchr(hbf->filename, '/')) != NULL) { X /* bitmap file name is relative to directory of HBF file */ X last_slash++; X size = last_slash - hbf->filename; X file->bmf_name = malloc((unsigned)size + strlen(filename) + 1); X strncpy(file->bmf_name, hbf->filename, size); X strcpy(file->bmf_name + size, filename); X } X else X file->bmf_name = strdup(filename); #else X file->bmf_name = strdup(filename); #endif X file->bmf_file = NULL; X file->bmf_next = NULL; X return file; } X static bool add_code_range(hbf, start, finish, filename, offset) X HBF_Struct *hbf; X HBF_HzCode start; X HBF_HzCode finish; X const char *filename; X long offset; { X CODE_RANGE *cp; X X if (start > finish) X return FALSE; X if ((cp = NEW(CODE_RANGE)) == NULL) X return FALSE; X cp->code_start = start; X cp->code_finish = finish; X cp->code_bm_file = find_file(hbf, filename); X cp->code_offset = offset; X cp->code_next = hbf->HBF_pCodeRange; X hbf->HBF_pCodeRange = cp; X return TRUE; } X static int AddPropertyEntry( hbf, cpPropertyName, cpPropertyValue ) reg HBF_StructPtr hbf; X char * cpPropertyName ; X char * cpPropertyValue ; { X static int nPropertyAdded = 0 ; X X if ( nPropertyAdded >= hbf->HBF_nProperty ) { X return NOT_OK_RETURN ; X } X X hbf->HBF_pPropertyTable[ nPropertyAdded ].cpPropertyName = cpPropertyName ; X hbf->HBF_pPropertyTable[ nPropertyAdded ].cpPropertyValue = cpPropertyValue ; X ++ nPropertyAdded ; X return OK_RETURN ; } X /* X * Reading and parsing of a HBF file X * RETURN TRUE if the given line is parsed correctly; X * or FALSE if parsing error (invalid keyword, incorrect value, etc.). X */ static bool parse_line(hbf, line) reg HBF_Struct *hbf; reg const char *line; { X int w, h, xd, yd; X int n ; X long nchars; X int start, finish; X long code1, code2; X long offset; X char arg[MAXCHARPERLINE]; static bool isParsePROPERTIES = FALSE ; static bool isParseBYTE_2_RANGE = FALSE ; static bool isParseCODE_RANGE = FALSE ; X char * cpReturnedString ; X X if (match(line, "COMMENT")) return TRUE ; X X if ( isParsePROPERTIES ) { X if (match(line, "FAMILY_NAME")) { X get_quoted(line, & cpReturnedString ); X if ( AddPropertyEntry( hbf, "FAMILY_NAME", X cpReturnedString ) != OK_RETURN ) { X return FALSE ; X } X } X else if (match(line, "ADD_STYLE_NAME" )) { X get_quoted(line, & cpReturnedString ); X if ( AddPropertyEntry( hbf, "ADD_STYLE_NAME", X cpReturnedString ) != OK_RETURN ) { X return FALSE ; X } X } X else if (match(line, "COPYRIGHT" )) { X get_quoted(line, & cpReturnedString ); X if ( AddPropertyEntry( hbf, "COPYRIGHT", X cpReturnedString ) != OK_RETURN ) { X return FALSE ; X } X } X else if (match(line, "NOTICE" )) { X get_quoted(line, & cpReturnedString ); X if ( AddPropertyEntry( hbf, "NOTICE", X cpReturnedString ) != OK_RETURN ) { X return FALSE ; X } X } X else if (match(line, "DEFAULT_CHAR" )) { X get_string(line, & cpReturnedString ); X if ( AddPropertyEntry( hbf, "DEFAULT_CHAR", X cpReturnedString ) != OK_RETURN ) { X return FALSE ; X } X /* Often used, so assign to an extra field: X */ X sscanf( cpReturnedString, "%i", & hbf->HBF_default_char ); X } X else if (match(line, "ENDPROPERTIES" )) { X isParsePROPERTIES = FALSE ; X } X X /* the rest are properties for full HBF: X */ X else if (match(line, "FOUNDRY" )) { X get_quoted(line, & cpReturnedString ); X if ( AddPropertyEntry( hbf, "FOUNDRY", X cpReturnedString ) != OK_RETURN ) { X return FALSE ; X } X } X else if (match(line, "WEIGHT_NAME" )) { X get_quoted(line, & cpReturnedString ); X if ( AddPropertyEntry( hbf, "WEIGHT_NAME", X cpReturnedString ) != OK_RETURN ) { X return FALSE ; X } X } X else if (match(line, "SLANT" )) { X get_quoted(line, & cpReturnedString ); X if ( AddPropertyEntry( hbf, "SLANT", X cpReturnedString ) != OK_RETURN ) { X return FALSE ; X } X } X else if (match(line, "SETWIDTH_NAME" )) { X get_quoted(line, & cpReturnedString ); X if ( AddPropertyEntry( hbf, "SETWIDTH_NAME", X cpReturnedString ) != OK_RETURN ) { X return FALSE ; X } X } X else if (match(line, "PIXEL_SIZE" )) { X get_string(line, & cpReturnedString ); X if ( AddPropertyEntry( hbf, "PIXEL_SIZE", X cpReturnedString ) != OK_RETURN ) { X return FALSE ; X } X } X else if (match(line, "POINT_SIZE" )) { X get_string(line, & cpReturnedString ); X if ( AddPropertyEntry( hbf, "POINT_SIZE", X cpReturnedString ) != OK_RETURN ) { X return FALSE ; X } X } X else if (match(line, "RESOLUTION_X" )) { X get_string(line, & cpReturnedString ); X if ( AddPropertyEntry( hbf, "RESOLUTION_X", X cpReturnedString ) != OK_RETURN ) { X return FALSE ; X } X } X else if (match(line, "RESOLUTION_Y" )) { X get_string(line, & cpReturnedString ); X if ( AddPropertyEntry( hbf, "RESOLUTION_Y", X cpReturnedString ) != OK_RETURN ) { X return FALSE ; X } X } X else if (match(line, "SPACING" )) { X get_quoted(line, & cpReturnedString ); X if ( AddPropertyEntry( hbf, "SPACING", X cpReturnedString ) != OK_RETURN ) { X return FALSE ; X } X } X else if (match(line, "AVERAGE_WIDTH" )) { X get_string(line, & cpReturnedString ); X if ( AddPropertyEntry( hbf, "AVERAGE_WIDTH", X cpReturnedString ) != OK_RETURN ) { X return FALSE ; X } X } X else if (match(line, "CHARSET_REGISTRY" )) { X get_quoted(line, & cpReturnedString ); X if ( AddPropertyEntry( hbf, "CHARSET_REGISTRY", X cpReturnedString ) != OK_RETURN ) { X return FALSE ; X } X } X else if (match(line, "CHARSET_ENCODING" )) { X get_quoted(line, & cpReturnedString ); X if ( AddPropertyEntry( hbf, "CHARSET_ENCODING", X cpReturnedString ) != OK_RETURN ) { X return FALSE ; X } X } X else if (match(line, "FONTNAME_REGISTRY" )) { X get_quoted(line, & cpReturnedString ); X if ( AddPropertyEntry( hbf, "FONTNAME_REGISTRY", X cpReturnedString ) != OK_RETURN ) { X return FALSE ; X } X } X else if (match(line, "FONT_DESCENT" )) { X get_string(line, & cpReturnedString ); X if ( AddPropertyEntry( hbf, "FONT_DESCENT", X cpReturnedString ) != OK_RETURN ) { X return FALSE ; X } X } X else if (match(line, "FONT_ASCENT" )) { X get_string(line, & cpReturnedString ); X if ( AddPropertyEntry( hbf, "FONT_ASCENT", X cpReturnedString ) != OK_RETURN ) { X return FALSE ; X } X } X else { X /* invalid keyword in PROPERTIES section */ X return FALSE ; X } X } else if ( isParseBYTE_2_RANGE ) { X if (sscanf(line, "HBF_BYTE_2_RANGE %i-%i", &start, &finish) == 2) { X add_b2r(&(hbf->HBF_pByte2Range), start, finish); X } X else if (match(line, "HBF_END_BYTE_2_RANGES" )) { X isParseBYTE_2_RANGE = FALSE ; X } X else { X /* invalid keyword in BYTE_2_RANGE section */ X return FALSE ; X } X } else if ( isParseCODE_RANGE ) { X if (sscanf(line, "HBF_CODE_RANGE %I-%I %s %I", X &code1, &code2, arg, &offset) == 4) { X if (! add_code_range(hbf, X (HBF_HzCode)code1, (HBF_HzCode)code2, X arg, offset)) { X return FALSE; X } X } X else if (match(line, "HBF_END_CODE_RANGES" )) { X isParseCODE_RANGE = FALSE ; X } X else { X /* invalid keyword in CODE_RANGE section */ X return FALSE ; X } X } else { X if (match(line, "HBF_START_FONT")) { X get_string(line, &(hbf->HBF_version)); X X } X else if (match(line, "HBF_CODE_SCHEME")) { X get_string(line, &(hbf->HBF_code_scheme)); X } X else if (match(line, "FONT")) { X get_string(line, &(hbf->HBF_font)); X } X else if (match(line, "SIZE")) { X get_string(line, &(hbf->HBF_size)); X } X else if (sscanf(line, "HBF_BITMAP_BOUNDING_BOX %i %i %i %i", X &w, &h, &xd, &yd) == 4) { X hbf->HBF_bitmap_bbox.HBF_width = w; X hbf->HBF_bitmap_bbox.HBF_height = h; X hbf->HBF_bitmap_bbox.HBF_xDisplacement = xd; X hbf->HBF_bitmap_bbox.HBF_yDisplacement = yd; X } X else if (sscanf(line, "FONTBOUNDINGBOX %i %i %i %i", X &w, &h, &xd, &yd) == 4) { X hbf->HBF_font_bbox.HBF_width = w; X hbf->HBF_font_bbox.HBF_height = h; X hbf->HBF_font_bbox.HBF_xDisplacement = xd; X hbf->HBF_font_bbox.HBF_yDisplacement = yd; X } X else if (sscanf(line, "STARTPROPERTIES %i", &n ) == 1) { X isParsePROPERTIES = TRUE ; X hbf->HBF_nProperty = n; X hbf->HBF_pPropertyTable = X (HBF_PropertyPtr) calloc( sizeof( HBF_Property ), n ); X } X else if (sscanf(line, "CHARS %I", &nchars) == 1) { X hbf->HBF_chars = nchars; X } X else if (sscanf(line, "HBF_START_BYTE_2_RANGES %i", &n ) == 1) { X isParseBYTE_2_RANGE = TRUE ; X hbf->HBF_nByte2Range = n; X } X else if (sscanf(line, "HBF_START_CODE_RANGES %i", &n ) == 1) { X isParseCODE_RANGE = TRUE ; X hbf->HBF_nCodeRange = n; X } X else if (match(line, "HBF_END_FONT")) { X /* skip */ X } X else { X return FALSE ; X } X } X return TRUE; } X static bool complete_record(hbf) reg HBF_Struct *hbf; { X if (hbf->HBF_pByte2Range == NULL) X add_b2r(&(hbf->HBF_pByte2Range), 0, 0xff); X return hbf->HBF_pCodeRange != NULL && X hbf->HBF_bitmap_bbox.HBF_height > 0 && X hbf->HBF_bitmap_bbox.HBF_width > 0; } X static bool real_open(hbfFileName, hbf) X const char *hbfFileName; reg HBF_Struct *hbf; { X FILE *f; X char line[MAXCHARPERLINE]; X CODE_RANGE *cp; X int pos; X X if ((f = fopen(hbfFileName, "r")) == NULL) X return FALSE; X while (fgets(line, MAXCHARPERLINE, f) != NULL) X if (! parse_line(hbf, line)) { X fclose(f); X return FALSE; X } X fclose(f); X X if (! complete_record(hbf)) X return FALSE; X /* set derived fields */ X hbf->b2_size = b2_size(hbf->HBF_pByte2Range); X hbf->HBF_row_size = X (hbf->HBF_bitmap_bbox.HBF_width + 7)/8; X hbf->HBF_bm_size = hbf->HBF_row_size * X hbf->HBF_bitmap_bbox.HBF_height; X for (cp = hbf->HBF_pCodeRange; cp != NULL; cp = cp->code_next) { X if ((pos = b2_pos(hbf, cp->code_start)) < 0) X return FALSE; X cp->code_pos = hbf->b2_size*FirstByte(cp->code_start) + pos; X if (b2_pos(hbf, cp->code_finish) < 0) X return FALSE; X } X X (void) strcpy( hbf->HBF_magic_string, HBF_MAGIC_STRING ); X return TRUE; } X X /* X * Exported API routines: X */ X /* X * Open a HBF file given its name: X */ int HBF_OpenFont( hbfFileName, pAddrHandleStorage ) X const char * hbfFileName ; X caddr_t *pAddrHandleStorage ; { reg HBF_Struct *hbf; X X if ((hbf = NEW(HBF_Struct)) == NULL) X return -1; X clear_HBF_Struct(hbf); X hbf->filename = strdup(hbfFileName); X if (real_open(hbfFileName, hbf)) { X *pAddrHandleStorage = (caddr_t) hbf ; X return 0 ; X } X (void)HBF_CloseFont( hbf ); X return -1; } X /* X * Fetch a bitmap -- in this version, always read it from the file. X */ int HBF_GetBitmap( hbfHandle, code, buffer ) X HBF_Handle hbfHandle ; X HBF_HzCode code; X char * buffer; { reg HBF_StructPtr hbf; X int pos; X int b2pos; reg CODE_RANGE *cp; reg BM_FILE *bmf; X X hbf = (HBF_StructPtr) hbfHandle ; X if ((b2pos = b2_pos(hbf, code)) < 0) X return -1; X pos = hbf->b2_size*FirstByte(code) + b2pos; X for (cp = hbf->HBF_pCodeRange; cp != NULL; cp = cp->code_next) X if (cp->code_start <= code && code <= cp->code_finish) { X bmf = cp->code_bm_file; X if (bmf->bmf_file == NULL) X if ((bmf->bmf_file = fopen(bmf->bmf_name, "r")) X == NULL) X return -1; X fseek(bmf->bmf_file, X cp->code_offset + X (long)(pos - cp->code_pos) * X hbf->HBF_bm_size, X 0); X return fread(buffer, X hbf->HBF_bm_size, X 1, X bmf->bmf_file X ) == 1 ? 0 : -1; X } X return -1; } X /* X * Close files, free everything associated with the HBF. X */ X int HBF_CloseFont (hbfHandle) X HBF_Handle hbfHandle; { reg HBF_StructPtr hbf; X B2_RANGE *b2r_ptr, *b2r_next; X CODE_RANGE *code_ptr, *code_next; X BM_FILE *bmf_ptr, *bmf_next; X int status; /* return status */ X int n ; /* running iteration variable */ X HBF_PropertyPtr p ; /* running pointer */ X X hbf = (HBF_StructPtr) hbfHandle; X X if ( InvalidHBF( hbf ) ) { X return -1 ; /* hbf is not a proper HBF_HANDLE or HBF_StructPtr */ X } X X status = 0; X if (hbf->filename != NULL) X free(hbf->filename); X X if (hbf->HBF_version != NULL) X free(hbf->HBF_version); X if (hbf->HBF_code_scheme != NULL) X free(hbf->HBF_code_scheme); X if (hbf->HBF_font != NULL) X free(hbf->HBF_font); X X if (hbf->HBF_size != NULL) X free(hbf->HBF_size); X X n = hbf->HBF_nProperty ; X if ( n > 0 ) { X p = hbf->HBF_pPropertyTable ; X while ( --n >= 0 ) { X free( p->cpPropertyName ); X free( p->cpPropertyValue ); X p ++ ; X } X free( hbf->HBF_pPropertyTable ); X } X X for (b2r_ptr = hbf->HBF_pByte2Range; X b2r_ptr != NULL; X b2r_ptr = b2r_next) { X b2r_next = b2r_ptr->b2r_next; X free((char *)b2r_ptr); X } X for (code_ptr = hbf->HBF_pCodeRange; X code_ptr != NULL; X code_ptr = code_next) { X code_next = code_ptr->code_next; X free((char *)code_ptr); X } X for (bmf_ptr = hbf->bm_file; X bmf_ptr != NULL; X bmf_ptr = bmf_next) { X bmf_next = bmf_ptr->bmf_next; X if (bmf_ptr->bmf_file != NULL) X if (fclose(bmf_ptr->bmf_file) != 0) X status = -1; X free(bmf_ptr->bmf_name); X free((char *)bmf_ptr); X } X free((char *)hbf); X return status; } X /* X * Get a property of a HBF file X * given the hbfHandle and the property property name: X */ char * HBF_GetProperty( hbfHandle, propertyName ) X HBF_Handle hbfHandle ; X char * propertyName ; { X HBF_StructPtr hbf; X HBF_PropertyPtr p ; X int n ; X X hbf = (HBF_StructPtr) hbfHandle; X X if ( InvalidHBF( hbf ) ) { X return NULL ; /* hbf is not a proper HBF_HANDLE or HBF_StructPtr */ X } X X X p = hbf->HBF_pPropertyTable ; X n = hbf->HBF_nProperty ; X while ( -- n >= 0 ) { X if ( IsEqualString( p->cpPropertyName, propertyName ) ) { X return p->cpPropertyValue ; X } X } X return NULL ; } X /* X * Get the FONTBOUNDINGBOX of the given hbfHandle: X */ int HBF_GetFontBoundingBox( hbfHandle, X addrWidth, X addrHeight, X addrXDisplacement, X addrYDisplacement ) const HBF_Handle hbfHandle ; X unsigned int *addrWidth ; X unsigned int *addrHeight ; X int *addrXDisplacement ; X int *addrYDisplacement ; { X HBF_StructPtr hbf; X hbf = (HBF_StructPtr) hbfHandle; X X if ( InvalidHBF( hbf ) ) { X return -1 ; /* hbf is not a proper HBF_HANDLE or HBF_StructPtr */ X } X X *addrWidth = hbf->HBF_font_bbox.HBF_width ; X *addrHeight = hbf->HBF_font_bbox.HBF_height ; X *addrXDisplacement = hbf->HBF_font_bbox.HBF_xDisplacement ; X *addrYDisplacement = hbf->HBF_font_bbox.HBF_yDisplacement ; } X /* X * Get the HBF_BITMAP_BOUNDING_BOX of the given hbfHandle: X */ int HBF_GetBitmapBoundingBox( hbfHandle, X addrWidth, X addrHeight, X addrXDisplacement, X addrYDisplacement ) const HBF_Handle hbfHandle ; X unsigned int *addrWidth ; X unsigned int *addrHeight ; X int *addrXDisplacement ; X int *addrYDisplacement ; { X HBF_StructPtr hbf; X hbf = (HBF_StructPtr) hbfHandle; X X if ( InvalidHBF( hbf ) ) { X return -1 ; /* hbf is not a proper HBF_HANDLE or HBF_StructPtr */ X } X X *addrWidth = hbf->HBF_bitmap_bbox.HBF_width ; X *addrHeight = hbf->HBF_bitmap_bbox.HBF_height ; X *addrXDisplacement = hbf->HBF_bitmap_bbox.HBF_xDisplacement ; X *addrYDisplacement = hbf->HBF_bitmap_bbox.HBF_yDisplacement ; } SHAR_EOF chmod 0644 hbf.c || echo 'restore of hbf.c failed' Wc_c="`wc -c < 'hbf.c'`" test 20083 -eq "$Wc_c" || echo 'hbf.c: original size 20083, current size' "$Wc_c" fi # ============= tester.c ============== if test -f 'tester.c' -a X"$1" != X"-c"; then echo 'x - skipping tester.c (File already exists)' else echo 'x - extracting tester.c (Text)' sed 's/^X//' << 'SHAR_EOF' > 'tester.c' && /* X * Test harness for HBF functions: X * X * usage: argv[0] font char [char ...] X * X * where 'font' is the name of a HBF file, and each 'char' is a hex X * code of a character in the font. It prints ASCII representations of the X * character bitmaps on standard output. X * X * 19930603 created Ross Paterson X * -- A sketch implemenation of API for X * HBF File Format Standard v1.0; X * but not completely conforming to the Standard. X * X * 19930604 modified Man-Chi Pong X * -- Conform to HBF File Format Standard v1.0. X * -- Can capture the properties of full HBF as well. X * -- It prints the internal represenation HBF_Handle (i.e. HBF_StructPtr) X * to show that the HBF file is opened and read properly. X * -- A usual program should only use the HBF API routines and not X * look into the internal details of data structures like HBF_Handle. X */ #include #include /* getenv() */ #include "hbf.h" #include "hbf_impl.h" X #define Test_GetBit(hbfFile,bitmap,x,y)\ X (((bitmap)[(y)*(hbfFile->HBF_row_size) + (x)/8]>>(7 - (x)%8))&01) X #define CurrentDirectory "." X extern char *malloc(); X void show_bitmap(font, bitmap) X HBF_StructPtr font; X char *bitmap; { X int x, y; X X for (y = 0; y < font->HBF_bitmap_bbox.HBF_height; y++) { X for (x = 0; x < font->HBF_bitmap_bbox.HBF_width; x++) X putchar( Test_GetBit(font, bitmap, x, y) ? '#' : ' ' ); X putchar('\n'); X } } X int main(argc, argv) X int argc; X char *argv[]; { X HBF_StructPtr font; X int code; X int i; X char * bitmap; X char filename[200]; X char * cpHBFDir ; X int n ; /* running iteration variable */ X HBF_PropertyPtr p ; /* running pointer */ X X if (argc < 3) { X fprintf(stderr, "Usage: %s font char [char ...]\n", argv[0]); X fprintf(stderr, " char is in hexadecimal without prefix '0x'\n" ); X exit(1); X } X X cpHBFDir = getenv( "HBF_FONT_DIR" ); X if ( cpHBFDir == NULL ) { X cpHBFDir = CurrentDirectory ; X } X sprintf(filename, "%s/%s.hbf", cpHBFDir, argv[1]); X if ( HBF_OpenFont( filename, & font ) != 0 ) { X fprintf(stderr, "%s: can't open font '%s'\n", X argv[0], filename ); X exit(1); X } X bitmap = malloc(font->HBF_bm_size); X X X printf("Output from directly dumping HBF_HANDLE's values:\n" ); X printf("-------------------------------------------------\n" ); X printf("HBF_START_FONT %s\n", font->HBF_version); X printf("HBF_CODE_SCHEME %s\n", font->HBF_code_scheme); X printf("FONT %s\n", font->HBF_font); X printf("SIZE %s\n", font->HBF_size); X printf("HBF_BITMAP_BOUNDING_BOX %d %d %d %d\n", X font->HBF_bitmap_bbox.HBF_width, X font->HBF_bitmap_bbox.HBF_height, X font->HBF_bitmap_bbox.HBF_xDisplacement, X font->HBF_bitmap_bbox.HBF_yDisplacement); X printf("FONTBOUNDINGBOX %d %d %d %d\n", X font->HBF_font_bbox.HBF_width, X font->HBF_font_bbox.HBF_height, X font->HBF_font_bbox.HBF_xDisplacement, X font->HBF_font_bbox.HBF_yDisplacement); X X printf("STARTPROPERTIES %u\n", font->HBF_nProperty ); X n = font->HBF_nProperty ; X if ( n > 0 ) { X p = font->HBF_pPropertyTable ; X while ( --n >= 0 ) { X printf("%s %s\n", X p->cpPropertyName, X p->cpPropertyValue ); X p ++ ; X } X } X printf("ENDPROPERTIES\n" ); /* X printf("numeric DEFAULT_CHAR 0x%.X\n", font->HBF_default_char); */ X X printf("CHARS %u\n", font->HBF_chars); X X /* dump the bitmap of the given arguments: */ X for (i = 2; i < argc; i++) { X printf("=================================================\n" ); X sscanf(argv[i], "%x", &code); X if (HBF_GetBitmap(font, code, bitmap) == 0) X show_bitmap(font, bitmap); X else X fprintf(stderr, "%s: unknown char %s (%x)\n", X argv[0], argv[i], code); X } X X (void)HBF_CloseFont(font); X return 0; } SHAR_EOF chmod 0644 tester.c || echo 'restore of tester.c failed' Wc_c="`wc -c < 'tester.c'`" test 3815 -eq "$Wc_c" || echo 'tester.c: original size 3815, current size' "$Wc_c" fi exit 0 From mcpong@cs.ust.hk Sat Jun 5 01:10:00 1993 Return-Path: Date: Sat, 5 Jun 93 14:00:17 HKT From: mcpong@cs.ust.hk (Dr. Man-Chi PONG) To: soft-authors@ifcss.org Subject: HBF: updated unix-c sample API implementation Status: O I have found one bug in my previously posted HBF C API implementation. A new updated version (which include bug fix and better error reporting) should override the previous release. To store the API implementation, xiaofei@ifcss.org has created the directory ifcss.org:software/fonts/HBF/unix-c/ In the future, we may have subdirectories msdos-c/, mswindows-c/, X-window-c/, etc. [[ msdos-pascal (? :-) ]] The new sample HBF C API implementation is software/fonts/HBF/unix-c/hbf.tar.Z N.B. The test driver program has been named testhbf.c meaning that it is to test the INTERNAL of hbf.c and thus it #include "hbf_impl.h". For an application using this API implementation, it should #include "hbf.h" only (not "hbf_impl.h") and linked with "hbf.o". mcpong From rap@doc.ic.ac.uk Mon Jun 7 11:34:12 1993 Return-Path: Date: Mon, 7 Jun 93 17:26 BST From: Ross Paterson To: soft-authors@ifcss.org Subject: C language interface to HBF Status: RO I have a few comments about the function names and their parameters in Appendix 2: - The names are a bit unusual: no Unix or STDC functions have names that begin with a capital letter, those being usually reserved for preprocessor definitions or typedef's. (Yes, I know about X and Windows, but I don't take either as worth following.) - The names "HBF_GetBitmapBoundingBox" and "HBF_GetBitmap" are the same to 13 characters, which violates the C standard for external names, I think (7 characters?). - Unix and STDC functions tend to avoid returning values (especially pointers) through pointers. I see that HBF_OpenFont() was changed to be this way, in part for more error reporting. But it's more convenient to program with the old version (like fopen()); for one thing you can put the value straight into a register variable. And I don't think specific error messages are so necessary: one can always run ygz's script (or the equivalent for other systems) to get informative diagnostics. And HBF_GetProperty returns a pointer too; I hope you won't change that. - There is no macro or function to tell the programmer how long his/her bitmap should be. Sure the formula is in the standard, but why should it be reproduced in each program? I think the aim should be to make the HBF part of each application program as small and easy as possible. - I guess I'm not a true believer in these abstract data-types, at least for C programs. It would be more C-like to return the programmer a structure containing various useful pieces of information, like the bounding boxes needed for the above bitmap size calculation, thus removing two functions from the interface. If they fiddle with it, they deserve what they get. Alternatively, the bounding boxes could be returned as pointers to structures. - I also think all these unsigned's are more trouble than they're worth. - Another useful function is something that takes a function and calls it for each valid character code in ascending order. Anyway, maybe people could try changing some of their programs to use the HBF interface (like I have) and give their views. -- Ross Paterson Department of Computing, Imperial College, London SW7 From ygz@cs.purdue.edu Tue Jun 8 02:36:09 1993 Return-Path: To: Ross Paterson Cc: soft-authors@ifcss.org Subject: Re: C language interface to HBF In-Reply-To: Your message of Mon, 07 Jun 1993 17:26:00 -0000. Date: Tue, 08 Jun 1993 02:30:10 -0500 From: ygz@cs.purdue.edu (Yongguang Zhang) Status: O My response to this C naming convention. IMHO it is a matter of taste. There is no standard on the number of characters in an identifier. I admit that some old old Unix V6/V7 boxes still only differentiate 8 chars in an identifier. But most others (including MS-C) take a much longer name (31 chars?). GCC even allows arbitary long id. And it doesn't matter if the name is HBF_xxx or hbfXXX. Also in addition to STDC we have Ansi C, Posix. (Sorry Ross, maybe UK doesn't use Ansi C, right? It is an American standard.) Instead of arguing this, how about we separate the API from HBF Standard and work for the interface convention? We can work out something like HBF-1.0 C Language Interface MCPong's Appendix 2 is sufficient and can be v0.5. We will discuss everything including those questions raised by Ross and revise it into v0.6 ... How about that? (Maybe later on we can try C++ interface, and Pascal interface, etc.) But, first, how's the endorsement of HBF v1.0? I only see 3 public anouncements. (Here is the 4th if my previous messages didn't imply this: I hereby endorse HBF as stated in the standard version 1.0.) I think this is important because even if we fail to agree on the API, we still have HBF 1.0. Separating API from HBF also ensures HBF 1.0. Comments? --ygz From rap@doc.imperial.ac.uk Tue Jun 8 05:50:44 1993 Return-Path: Via: uk.ac.imperial.doc; Tue, 8 Jun 1993 11:23:44 +0100 From: Ross Paterson Date: Tue, 8 Jun 93 11:23:26 BST To: ygz@cs.purdue.edu Subject: Re: C language interface to HBF Cc: soft-authors@ifcss.org Status: RO > My response to this C naming convention. IMHO it is a matter of taste. > There is no standard on the number of characters in an identifier. > I admit that some old old Unix V6/V7 boxes still only differentiate > 8 chars in an identifier. But most others (including MS-C) take a > much longer name (31 chars?). GCC even allows arbitary long id. > And it doesn't matter if the name is HBF_xxx or hbfXXX. > Also in addition to STDC we have Ansi C, Posix. Well, by STDC I meant ANSI C. I don't have the ANSI document, but according to the second edition of Kernighan and Ritchie (sections 2.1 and A2.3), in ANSI C programmers can rely on at least 31 characters being significant in internal identifiers, with case also significant, but only 6 characters in external identifiers, with case possibly not significant. The reason given is that this is determined by native linkers and is beyond the control of the compiler. As it happens, both the compiler and linker on the system I'm using support huge identifiers, but one has to write to the standard to assure portability. If we are going to do this, and the first 3 letters are to be hbf/HBF, one of the next 3 must be distinctive. > Instead of arguing this, how about we separate the API from HBF > Standard and work for the interface convention? We can work out > something like > HBF-1.0 C Language Interface > MCPong's Appendix 2 is sufficient and can be v0.5. > We will discuss everything including those questions raised by Ross > and revise it into v0.6 ... How about that? > (Maybe later on we can try C++ interface, and Pascal interface, etc.) Sounds extremely sensible to me. The different language interfaces can be dealt with quite separately from the file format, which has been quite thoroughly discussed now. > But, first, how's the endorsement of HBF v1.0? I only see 3 public > anouncements. (Here is the 4th if my previous messages didn't imply > this: I hereby endorse HBF as stated in the standard version 1.0.) > I think this is important because even if we fail to agree on the > API, we still have HBF 1.0. Separating API from HBF also ensures > HBF 1.0. Doesn't writing an implementation (of the file format, if not the exact C interface) count as an endorsement? Um, but I do have a suggestion for the file format. Does anyone remember HBF_ORIENTATION? Yes, I thought so. I know, I missed the discussion and you all decided to delay it. But this is a bit different, really. My understanding of the problem is that we have these font files (ZIKU) that we wish we could use with HBF-based applications, but they store the bitmaps the wrong way round. So I think it's a storage detail (like the bitmap file name and offset) that we want to hide from the applications programmer, and thus belongs in a HBF_CODE_RANGE declaration. (Not all bitmaps in a font need be stored with the same orientation, just as they need not be in the same file.) My proposal is for an optional 5th argument to HBF_CODE_RANGE -- if it's "sideways" (or some more sensible keyword), the bitmap will be flipped between being read from the file and being presented to the application. The bitmap bounding box dimensions would refer to the flipped bitmap, and the application would be entirely oblivious to how the bitmap is stored, as it is to where the bitmap is stored. As someone pointed out, this means that the stored bitmap may have a different size from that used in the application, but the HBF routines can handle that -- in fact I've already written a sample implementation to play with. Someone may object that a bitmap gets flipped while being read by the HBF routines, and may later be flipped back by the application for some purpose. True, but as Ricky Leung pointed out, the time involved is not so great, especially if you write greasy C, and the gains are the use of extra fonts and fewer details in the application program. Or perhaps the standard could just say that extra arguments to the various declarations will be ignored for now but may be used in later versions, allowing people to conduct private experiments like the above, subject to the warning that they may be invalidated by later versions. -- Ross Paterson Department of Computing, Imperial College, London SW7 From simpson@math.psu.edu Tue Jun 8 18:40:41 1993 Return-Path: From: Stephen G Simpson Date: Tue, 8 Jun 93 19:34:23 -0400 To: soft-authors@ifcss.org Subject: HBF material at ifcss.org Status: O Some comments about the HBF material at ifcss.org: 1. I'm glad ifcss.org (in the person of XiaoFei) is providing a site for HBF-related material. In order to promote HBF, we should keep this stuff as comprehensive, up-to-date, and correct as possible. 2. /software/fonts/HBF contains a number of sample HBF header files, but they are all for CCLIB fonts -- in particular they each refer to only one bitmap file -- so they do not exploit the full capability of HBF. We should provide a variety of sample header files, including both "simple" ones and "full" ones. I will upload some "simple" ones for 24x24 ET fonts -- look for et-hbf.tar.Z -- could somebody undertake to convert these to "full" ones? (I can't do this because I don't understand BDF well enough.) 3. How about a header file for one of the most-used bitmap files, CCLIB.24? (This header file is notable by its absence.) 4. The header files in software/fonts/HBF don't seem to specify, even in comments, whether the characters are traditional or simplified. Surely this information should be provided? (I don't think "Fan" is precise enough.) -- S. Simpson From mcpong@cs.ust.hk Tue Jun 8 21:34:39 1993 Return-Path: Date: Wed, 9 Jun 93 10:25:12 HKT From: mcpong@cs.ust.hk (Dr. Man-Chi PONG) To: soft-authors@ifcss.org Subject: Re: HBF material at ifcss.org Status: O > From: Stephen G Simpson > Date: Tue, 8 Jun 93 19:34:23 -0400 > Message-Id: <9306082334.AA24348@boole.math.psu.edu> > > 2. /software/fonts/HBF contains a number of sample HBF header files, > ... We should provide a variety of sample header files, including > both "simple" ones and "full" ones. I will upload some "simple" ones > for 24x24 ET fonts -- look for et-hbf.tar.Z -- could somebody > undertake to convert these to "full" ones? (I can't do this because I > don't understand BDF well enough.) The full HBF for the font files may not be necessary. Few, if any, Chinese applications are using those extra BDF properties. It would be nice to see some usable HBF for traditional Chinese, I think simple HBF should serve most purposes. > 4. The header files in software/fonts/HBF don't seem to specify, even > in comments, whether the characters are traditional or simplified. > Surely this information should be provided? (I don't think "Fan" is > precise enough.) HBF_CODE_SCHEME GB2312-80 or HBF_CODE_SCHEME Big5 should suggest the default values of whether the glyphs are simplified or traditional Chinese. ADD_STYLE_NAME "fanti" is supposed for the application to get this property and decided on what to do. Extra comment to make the files more understandable is often welcome. Probably the authors of the HBF files may like to put in more comments. mcpong From simpson@math.psu.edu Tue Jun 8 21:58:03 1993 Return-Path: From: Stephen G Simpson Date: Tue, 8 Jun 93 22:52:15 -0400 To: CAI@neurophys.wisc.edu Cc: soft-authors@ifcss.org In-Reply-To: <23060820273081@neurophys.wisc.edu> Subject: Re: HBF material at ifcss.org Status: O > ----- First, I thought /software/fonts/HBF is for storing actual HBF files, > not for samples (maybe I am wrong, hope Xiaofei can comform or deny this), Sorry, perhaps my wording was unclear. I did not mean "samples" to exclude actual files. Of course these are real, actual HBF files. But my thought was also that the /software/fonts/HBF is the place to send people who are looking for information about the HBF standard. Therefore, these HBF files are not only immediately useful, they also have an educational or illustrative function. > Besides, I would like to to say all HBF files on public domain to > be full HBF files, for reasons I've discussed in previous postings. > That's why I loaded those HBF files in full format, although simple > ones are enough for my program. I would like to see a few simple HBF header files available, illustrating the simple HBF format. > ----- See cclibj_24.hbf. I'll ask Xiaofei to link cclib_24.hbf to > cclibj_24.hbf, just as he did for cclib.24 and cclibj.24. Is there some confusion here? Referring to the bitmap files in the /software/fonts, cclib.24 is not a link to cclib.j24 (the files are different sizes) and there is no cclibj.24. From simpson@math.psu.edu Tue Jun 8 22:12:07 1993 Return-Path: From: Stephen G Simpson Date: Tue, 8 Jun 93 23:04:47 -0400 To: soft-authors@ifcss.org In-Reply-To: <9306090225.AA00346@cs.ust.hk> Subject: Re: HBF material at ifcss.org Status: O mcpong@cs.ust.hk (Dr. Man-Chi PONG) writes: > HBF_CODE_SCHEME GB2312-80 > or > HBF_CODE_SCHEME Big5 > should suggest the default values of whether the glyphs are > simplified or traditional Chinese. But this is only a default. It is not infallible, for example cclib.f24 uses GB coding but traditional characters. (Or is it cclibf.24? There are a lot of seemingly redundant fonts.) > Extra comment to make the files more understandable is often welcome. > Probably the authors of the HBF files may like to put in more comments. Amen to that. From simpson@math.psu.edu Wed Jun 9 20:32:28 1993 Return-Path: From: Stephen G Simpson Date: Wed, 9 Jun 93 21:27:04 -0400 To: soft-authors@ifcss.org Subject: ifcss.org:/software/fonts/cclib* Status: O Xiaofei writes: > there are two sets of fonts: > cclib[j,f,b,h,k].24 > and > cclib.[j,f,b,h,k]24 > on ifcss.org:/software/fonts > ... What about cclib.n24, where does that fit in? And cclib.b24 isn't there. These fonts are confusing! But anyway, this is one kind of confusion that HBF may help to clear up. From CAI@neurophys.wisc.edu Wed Jun 9 20:35:50 1993 Return-Path: Date: Wed, 9 Jun 93 20:34 CST From: CAI@neurophys.wisc.edu Subject: fonts To: xiaofei@ifcss.org, simpson@math.psu.edu X-Vms-To: IN%"xiaofei@ifcss.org", IN%"simpson@math.psu.edu" Status: O From: IN%"xiaofei@ifcss.ORG" 9-JUN-1993 17:00:38.50 To: CAI@neurophys.wisc.edu, simpson@math.psu.EDU Subj: the fonts on ifcss.org:/software/fonts The second set is posted by Yidao Cai, I believe they have the same roigin of 1st set with the empy spaces and Russian symbols, etc taken out. So they take slightly less space. *************** cclib.j24 : Song style .... ---- To the best of my knoweledge, only empty spaces were taken out, the Russian symbols are preserved. I also believe they are from the same origin. By the way, Xiaofei, did you get the HBF file for cclib.24 by mail? From CAI@neurophys.wisc.edu Wed Jun 9 20:53:11 1993 Return-Path: Date: Wed, 9 Jun 93 20:47 CST From: CAI@neurophys.wisc.edu Subject: fonts, answer to Simpson's question To: soft-authors@ifcss.org X-Vms-To: IN%"soft-authors@ifcss.org" Status: O From: IN%"simpson@math.psu.EDU" "Stephen G Simpson" 9-JUN-1993 20:33:37.75 > there are two sets of fonts: > cclib[j,f,b,h,k].24 > and > cclib.[j,f,b,h,k]24 > on ifcss.org:/software/fonts > ... What about cclib.n24, where does that fit in? And cclib.b24 isn't there. These fonts are confusing! But anyway, this is one kind of confusion that HBF may help to clear up. ----- I think Xiaofei made a mistake here. It should be cclib.[j,f,n,h,k]24. and cclib.n24 <---> cclibb.24 (in contents, except empty spaces) When I posted the fonts, I randomly picked 'n' and Xiaofei picked 'b' (maybe also randomly). For consistency, we can either change cclib.n24 to cclib.b24 or change cclibb24 to cclibn.24, and make adjustment of the HBF file name and contents accordingly. (Xiaofei, if you need assistance, please let me know). Yidao Cai From rap@doc.imperial.ac.uk Thu Jun 10 10:00:37 1993 Return-Path: Via: uk.ac.imperial.doc; Thu, 10 Jun 1993 15:46:01 +0100 From: Ross Paterson Date: Thu, 10 Jun 93 15:45:42 BST To: soft-authors@ifcss.org Subject: HBF C language interface Status: RO I thought I'd throw out a possible alternative interface for comment. It's not so very different from Appendix 2, but it seems (to me, anyway) to be more in the spirit of C, and is also a little easier to use. I know the issues involved here are pretty minor, but for HBF to take off requires HBF files (done) and applications, which need a C interface. Types defined in hbf.h: typedef unsigned int HBF_HzCode; /* or just HBF_Code? */ typedef struct { unsigned short hbf_width; unsigned short hbf_height; short hbf_xDisplacement; short hbf_yDisplacement; } HBF_BBOX; typedef ... HBF; Functions declared in hbf.h: HBF *hbfOpen(const char *hbfFileName); /* * Opens an HBF file and returns a descriptor, or NULL * on failure. */ int hbfClose(HBF *hbf); /* * Closes such a descriptor. * Returns 0 on success, negative otherwise. */ const char *hbfProperty(HBF *hbf, const char *propName); /* * Returns the value of the named property, which * persists until hbf is closed, or NULL on failure. */ const HBF_BBOX *hbfBitmapBBox(HBF *hbf); /* * Returns the bitmap bounding box, which persists until * hbf is closed. Can't fail. (possibly a macro) */ const HBF_BBOX *hbfFontBBox(HBF *hbf); /* * Returns the font bounding box, which persists until * hbf is closed. Can't fail. (possibly a macro) */ int hbfGetBitmap(HBF *hbf, HBF_HzCode code, char *buffer); /* * Reads the bitmap for a code from a font into buffer, * which the programmer must ensure points at a big * enough area. Returns 0 on success, negative otherwise. */ void hbfForEach(HBF *hbf, void (*func)(HBF *hbf, HBF_HzCode code)); /* * Calls func for each legal code in the font, in * ascending order. */ Some useful macros: /* Size in bytes of one row of a bitmap (for internal use, mainly) */ #define HBF_RowSize(hbf)\ ((hbfBitmapBBox(hbf)->hbf_width + 7)/8) /* The size in bytes of a buffer for hbfGetBitmap() */ #define HBF_BitmapSize(hbf)\ (HBF_RowSize(hbf) * hbfBitmapBBox(hbf)->hbf_height) /* Extract the bit at coordinates (x,y) in bitmap, read from hbf */ #define HBF_GetBit(hbf,bitmap,x,y)\ (((bitmap)[(y)*HBF_RowSize(hbf) + (x)/8]>>(7 - (x)%8))&01) -- Ross Paterson Department of Computing, Imperial College, London SW7 From CAI@neurophys.wisc.edu Fri Jun 11 13:49:40 1993 Return-Path: Date: Tue, 8 Jun 93 20:27 CST From: CAI@neurophys.wisc.edu Subject: Re: HBF material at ifcss.org To: simpson@math.psu.EDU, soft-authors@ifcss.org X-Vms-To: IN%"simpson@math.psu.edu", IN%"soft-authors@ifcss.org" Status: O From: IN%"simpson@math.psu.EDU" "Stephen G Simpson" 8-JUN-1993 18:41:48.06 2. /software/fonts/HBF contains a number of sample HBF header files, but they are all for CCLIB fonts -- in particular they each refer to only one bitmap file -- so they do not exploit the full capability of HBF. We should provide a variety of sample header files, including both "simple" ones and "full" ones. I will upload some "simple" ones for 24x24 ET fonts -- look for et-hbf.tar.Z -- could somebody undertake to convert these to "full" ones? (I can't do this because I don't understand BDF well enough.) ----- First, I thought /software/fonts/HBF is for storing actual HBF files, not for samples (maybe I am wrong, hope Xiaofei can comform or deny this), sample HBF files may go to /software/fonts/d. With this in mind, I loaded 10 real HBF files which has been using by some users. Since they are real, there is no need to try to demonstrate the capability of HBF standard through these HBF files. Besides, I would like to to say all HBF files on public domain to be full HBF files, for reasons I've discussed in previous postings. That's why I loaded those HBF files in full format, although simple ones are enough for my program. 3. How about a header file for one of the most-used bitmap files, CCLIB.24? (This header file is notable by its absence.) ----- See cclibj_24.hbf. I'll ask Xiaofei to link cclib_24.hbf to cclibj_24.hbf, just as he did for cclib.24 and cclibj.24. 4. The header files in software/fonts/HBF don't seem to specify, even in comments, whether the characters are traditional or simplified. Surely this information should be provided? (I don't think "Fan" is precise enough.) ----- I agree, we may put a comment there. Hope more questions and suggestions keep coming. And hope to see more HBF files there. -- S. Simpson ----- Yidao Cai