Hi again Bob, I've experimented with this, and now I think I spoke too soon. But maybe I don't understand your suggestion.
The glyphs *must* have unique names. The options include simply changing the names to Adobe ones. Is this what you're suggesting? My problem with this is: I do not approve of the Adobe names. If it's a choice between our meaningful names and the ill-advised, ugly Adobe ones--well, the choice is clear. I guess when I responded before, I was thinking as if, somehow the names would be just the slot numbers or something -- removing all trace of interpretation, and maybe saving a small amount of space...I see no option for that however. Still thinking about it... On Mon, Jun 24, 2013 at 12:41 PM, Steve White <stevan.wh...@gmail.com> wrote: > BobH > > On Mon, Jun 24, 2013 at 5:34 AM, BobH <ne1oqz...@sneakemail.com> wrote: >> You may do as you wish, of course. And you need not reply to this, but lest >> I be misunderstood... >> >> >> On 2013-06-22 at 5:28 Steve White stevan.white-at-gmail.com |OpenType stuff| >> wrote: >> >> Bob, the Adobe Glyph List is deprecated. It has not been maintained, >> as it was an unfortunate idea to begin with. >> >> The link I gave refers both to the >> >> AGL (which, although not deprecated in the tradition sense, it is, by >> conscious decision, not being extended) and >> The Adobe Glyph List for New Fonts. >> >> The latter is far from deprecated -- it is the standard way of naming glyphs >> for most type designers I know. >> > I do not have access to statistics of how many fonts follow Adobe's > convention. > That might be helpful information in this discussion. > However, I do know many fonts just ignore it, because it is very ugly, > and not very helpful. > >> For their part, Microsoft and ISO both recommend names conform to the Adobe >> standard. >> > I know. > > The ostensible reason for this naming scheme does not make sense, as I said. > The only other argument I have ever heard for propagating it is to > support legacy > software. (A few printer problems too have occasionally been reported that > *might* be related to glyph names,but they are few and far between, and I can > only regard this as firmware bugs.) > > My catch on it is, it would be better for the legacy software to be > replaced, than to > force this ugly naming convention on new fonts. > > (BTW I still have never seen the bug Tae Wong mentioned with my own eyes, so I > can't be 100% sure the bug really was due to glyph naming. > A test file and thorough description of the problem might resolve that > question.) > >> We largely ignore it (except for some of the names which were good >> ideas individually). >> >> Certainly your prerogative. But if one chooses this route, I'd question >> including any names at all in the finished font -- just move to post fmt3 >> table. >> > This is certainly a thought. The usefulness of glyph names in the font > binaries > is questionable. > > Human-readable glyph names are very helpful to anybody who inspects the font, > to understand what the font designer intended. If you've ever dealt > with Indic or > Arabic scripts, you know the tables can be almost impenetrable. > > Do glyph names belong in the binary though? What purpose do they serve there? > > One view has been that the binaries and the SFD file are interchangeble, > the SFD being merely a human-readable version. I have usually taken this > view. > > However, there are other bits of information in the SFD file that is > not supported in the > binaries (table names anyway---I can't think of anything else except > info caches). > So the SFD may be regarded as "source". > > In the view that the SFD file is source, and given that with GPLed > software the user must > have access to the source, it makes sense to say, an interested user > could always > look into the SFD file to find the glyph names. > > Of course for the purposes of text display, all this human-readable > stuff is extraneous. > > Removing the glyph names wouldn't have any effect on the PDF text-copy > issue, I think. > (I only know the one way I mentioned to resolve that.) > I wonder if it would make Tae Wong's problem go away -- but is making > that problem to > go away the right thing to do? Maybe that software ought to be fixed. > So it isn't clear to me your proposal is toward the bug at hand. > > Bob, I'll think about your proposal. Let me know if you have further > thoughts on it. > It might be worth opening a bug report on it, where it can be further > discussed. > > Thanks!
