Re: [Freefont-bugs] New glyphs are unixxxx while other glyphs are uniXXXX.

[Steve White]

Hi,

As Bob points out at the end of his post, this started with a problem report.
I still have not yet received a test case, and have not seen the
problem myself,
nor have I been enlightened as to how the problem is manifested.
For all I know, a bug exists in that software, and its authors should
be alerted.

Please send me a test case.

Bob, I answered a couple of your direct questions below.
(Only one of those contains new information, unfortunately.)

As you pointed out, we're going in circles.  I'm afraid we've become entrenched.

Instead of pursuing this lengthening exchange, I propose this:
I'm already writing up for myself a summary of the issues, and the pros/cons
of the proposed remedies.  Give me a little time; I'll send it to you
for revision.
When we're both satisfied, we could post that here.

For myself, I need to focus on what is best for our users and for the project.
It may well be that something in the direction of your proposals is in order.
I am still thinking about it.

I have to say, I'm still bucking and kicking -- the AGLFN is a poor idea, that
requires overbearing restrictions on fonts in order to function at all,
and doesn't deliver what it promises.  There is a better way.

(more below)

On Wed, Jun 26, 2013 at 4:59 PM, BobH <address@hidden> wrote:
> On 2013-06-25 at 18:15 Steve White stevan.white-at-gmail.com |OpenType
> stuff| wrote:
>>>
>>> On 2013-06-25 at 9:12 you wrote:
>>>
>> I'm talking about font generation by FontForge.
>> I find no way to *remove* the glyph names.
>> Only ways to replace them with other sets of glyph names.
>> Am I missing something?
>
>
> I think we're on a rabbit trail here (because the OpenType spec recommends
> that ttf-flavored fonts should have glyph names) but if you wanted to pursue
> this then you need to see if there are settings in FontForge that will cause
> it to generate a Format 3 post table. If not, you can use any number of font
> hacking tools to change the post table. If you want help I can show you how
> to use the Font::TTF Perl module to do this.
>
I'd be glad to look at your scripts!

>>> so I'm
>>> trying to understand what process(es) you believe do require names.
>>>
>> ??  Very few. Have you misunderstood me.
>
>
> I take this to mean that you use the names for development process but
> beyond that don't think the names have purpose.
>
> However, I suspect that neither of us know whether names are essential to
> correctly render a font on all variety of platforms/drivers/printers that
> might be required.
>
My conclusion was: one glyph name is as good as another for the
primary purpose of text display.
A general "flattening* of the names could be performed, which could
even save a tiny fraction of
file size (no I don't care about that!).
On the other hand... I see no compelling reason to do that.  And
FontForge doesn't provide an
option like that.

Regarding supporting all platforms and software:
I regard software that relies on glyph names as being buggy (outside
of font-inspection tools).
We cannot and should not support all bugs in all software and all printers.

The PDF scheme for text copying (without embedded Unicode text) *does*
use glyph names, and I regard this as a cludge and a disaster.
It was a bad idea, it doesn't work as advertized.  We do not support it.

>> It's the AGLFN names I don't like. They amount to a loss of information,
>> besides being ugly. There are a few AGL names that are just wrong (and there
>> are also a few Unicode names that are just wrong too). These things happen.
>> To be honest, more names in FreeFont are just wrong, than either the AGL or
>> Unicode. But they're *our* names, and have other advantages too (brevity,
>> etc). But again, the functioning of outside code must not depend on glyph
>> names. Keep me thinking, Bob!
>
>
> I'm curious what possible "loss of information" you might be aware of.
>
The AGLFN assumes that each un-encoded glyph corresponds to a specific
Unicode sequence.

However, a font can map multiple Unicode strings to the same glyph.
Imposing any particular AGLFN sequence to the glyph therefore results
in a loss of information.

Such many-to-one mappings commonly happen in Indic scripts, but a font
designer might choose to apply a trick involving such a mapping, in
any script.

Sure, font designers could avoid use of all such mappings.  This would
be a pity.
The AGLFN was a bad solution to the problem in the first place, a
solution that itself caused problems.
To force all fonts to compensate to its weaknesses is to put a bandage
on top of a bandage.

> I assume you understand that you can use one set of glyph names during font
> development and then, prior to packaging, change the names to be AGL
> conformant?  This is a pretty common practice in the industry.
>
Yes I know the name can be changed at font generation.

But I have objections to using the Adobe names generally.

> The focus of my argument all along has not been what names you use for
> development -- no one cares about that at all -- but it is what gets
> delivered for end-users that, imo, should conform to existing standards.
>
We do not conform to all standards: that would not make sense.  We
have to choose standards carefully.
We conform to standards that we consider useful: Unicode, OpenType, etc.
Again, we regard the AGL and AGLFN as poor idea, and we largely ignore it.

> PS: This *whole* very long thread started out from a bug report that "New
> glyphs are unixxxx while other glyphs are uniXXXX" -- I don't think you can
> argue that one is less ugly than the other, but I can argue that one has
> less information than the other (from the perspective of processes based on
> Adobe standards).
>
That's right.

An aesthetic argument would have resolved the issue of the
capitalization of hex values immediately.
And I may well go ahead and deal with that anyway.

However a bug appearing in other software was also mentioned, so I
requested to see a test case.
This has not been forthcoming.

Then you proposed that we implement the AGLFN, and most of this
discussion has followed.

>From my perspective, progress is being made.
But actually happens in the end might not be what any of us imagined at first.