On Mon, 13 Jun 2011, Pander wrote: > > mark, dotless i and j, and similar code points). The existence of a GSUB > > table pointing at those points can probably be explained by defaults from > > the auto-conversion. So in summary, yes, it's a bug in the font. > > Could the conversion software generate a warning when it recognises such > a situation?
That would be very difficult, because the conversion software has no way of knowing that the glyph its user said was "ffl" isn't really. > > The current version of my own OCR B fonts, available on ansuz.sooke.bc.ca, > > http://ansuz.sooke.bc.ca/page/fonts I haven't tried to get this package put into TeXLive because I see it as still being sort of beta (in particular, the nonstandard versions of OCRB aren't debugged and distributed yet), but if there's interest I might pursue fixing the remaining issues. Of course TeXLive is free to distribute it at any time if they do whatever packaging work is needed to make that happen. > In effect it is freeware and is owned by Barcodesoft. But according to > your README, one is allowed to redistribute this and your enhanced > version. So in the same way would TeX Live be able to so. The metadata > in the font files provides proper credits. There are four different packages here and I think you may be confusing two of them: 1. Norbert Schwarz's version (currently on CTAN, probably also in TeXLive) 2. Zdeněk Wagner's version (in TeXLive) 3. Mine (not in TeXLive) 4. Barcodesoft's version Numbers 2 and 3 are both based on number 1, and all three of those are free and could be included in TeXLive. Number 4 is a watermarked commercial demo, as far as I know unconnected to the other three. Even if its purveyors would be happy to have it distributed, I think distributing it would be a bad idea because it's of inferior quality (because of the watermarks) compared to the free ones, and distributing a commercial advertisement for something that ought to be available free of charge is ideologically objectionable. > Would it also be possible to generate Bold, Italic, Light and Condensed > versions for OCR-A and OCR-B? In that way it is also backwards > compatible with the current OCRA fonts. Someone could no doubt design bold, italic, light, and condensed fonts that visually resembled OCR-A and OCR-B, but I think it would be irresponsible to call such fonts OCR-A and OCR-B. Bear in mind that OCR-A and OCR-B exist for the specific purpose of automated character recognition. They are written up in standards documents, and hardware and software are designed specifically to handle not only those letter shapes, but also specific sizes, spacing, and so on. If we start extending the standard in non-standard ways to include extra glyphs, extra styles, and so on, then the result will no longer be within the specifications of the systems that are designed to use these fonts. Condensed would be especially likely to be a problem. Maybe for graphic design reasons it would be desirable to have fonts for human-only consumption that look "like OCR fonts, but different"; but those will no longer be OCR fonts and I'd prefer to avoid confusion as much as possible. Some of the existing fonts already include nonstandard glyphs and styles. My own approach in creating my package was to preserve what existed in my inputs (some of which are currently to-do items rather than being in the distributed package) and fix obvious bugs like the encoding, but not add anything new myself. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/
-------------------------------------------------- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
