Add Hershey indexes to .jhf files

[frankrolf]

Some of the .jhf files provided in this repository contain dummy index numbers (12345) in place of the original Hershey index numbers. I wrote a script to re-assign the original numbers by comparing Hershey glyph “hashes” from original Hershey data with hashes provided in .jhf files. (Original Hershey data found at http://cd.textfiles.com/sourcecode/usenet/compsrcs/unix/volume04/hershey/)

I don’t know if this modification will have any impact on your visualization work, but I’d like to offer it for inclusion.

Additional fixes:

• I noticed a single glyph (3010) had a different advance width than provided in the original data, this was corrected.
• Various glyphs in gothgrt.jhf insert a number between index and hash (position 5). Since this single number is never parsed, removing it won’t have any effect.
• Additionally, I noticed that two additional glyphs are found in various .jhf files, which are not part of any other Hershey distribution: 12345 3I[Ib[b (an underscore) 12345 35JZJFJ[K[KFLFL[M[MFNFN[O[OFPFP[Q[QFRFR[S[SFTFT[U[UFVFV[W[WFXFX[Y[YFZFZ[ (a radiator-like fill glyph) – where do they come from?

[kamalmostafa]

Hi Frank-

Thanks for your contribution! I'd be pleased to get your glyph index number replacement work merged in, but there are a few problems to be addressed ...

1. The number you sometimes see at position 5 (as you noted in gothgrt.jhf) is not junk! Its the first of the 3-digit field which represents the count of coordinate pairs. Most glyphs in most files use fewer than 100 coordinate pairs so that first digit at position 5 is usually blank but removing it certainly will have a (very bad!) effect, for example this glyph which should show 208 coords, but ends up with just 8 after your change:

$ tools/hershey-font-check hershey-fonts/timesib.jhf 
hershey_jhf_load_glyph: expected 8 (not 208) coord bytes for nverts=4
hershey-fonts/timesib.jhf: Numerical result out of range
hershey-fonts/timesib.jhf: ... at line number 25
hershey-fonts/timesib.jhf: Numerical result out of range

2. Your proposed change to left/right bounds for glyph number 3010 (capital-J) would make that glyph be zero-width (bounds set to 'JJ'), which surely is not correct... But it got me to thinking about whether there are (or even could be) any other zero-width glyphs. That led me to find an interesting bug: libhersheyfont was silently just ignoring (not rendering) all glyphs with width == 0. But there are indeed a handful of (proper) zero-width glyphs in symbolic.jhf -- they are purely vertical lines. So I've now fixed the rendering of, and added a validation check for zero-width glyphs with commits 465a8c8 and d28b425. ... Which led to the finding of one more instance of a (bogus) zero-width glyph in my .jhf distribution: In my rowant.jhf, glyph number 3010 (ha!) was incorrectly zero-width ('JJ' just as in your proposed change). I've now fixed rowant.jhf with commit 3cb4789. I suspect all the instances of 'JJ' for glyph 3010 are a typo that got propagated in various .jhf files.

If you'd be so kind, please re-fetch my master branch, fix your script to leave the 3-digit field at position 5 alone (i.e. only modify the 5-character index field at position 0), then run it again. (And your manual index number corrections on top of that are also fine with me). I've merged your typo correction. I'll wait for your new pull request, or further discussion.

Thanks again, Frank!