At the moment, AFP fonts are exclusively accessed by local file paths 
(plus some special code for accessing JAR resources). But this is
different to what we have for other fonts where we can use URIs and the
FontManager's base URI/URL. I'm currently working on changing that. But
this will have a consequence for current users of AFP output:

On Windows, filenames are case-insensitive. Moving to URIs this
case-insensitivity falls away. The resource names in the configuration
will have to match the filename case to be found. What I can do is check
for the all uppercase and all lowercase variants if the original
resource name isn't found. That should solve most possible mismatches.
But still, "C0gsl10" will not match "C0GSL10". So that introduces a
semantic change. (It's similar to what we do in Type1FontLoader when
finding the AFM font that belongs to the PFB font.)

At the moment, you set the "path" attribute on an AFP font:
I'm proposing to introduce an attribute "base-uri" as a replacement.
This base URI can be relative itself and will be resolved against the
font base URI/URL. That alone is no problem, but the decision here is
how to provide backwards-compatibility for the "path" attribute.

In the code I've already changed locally I'm simply mapping "path" to
"base-uri" (just a few lines) and I'm switching all AFP font loading
code from String to But exactly that will be causing the
semantic change mentioned above.

The alternative would be to support both approaches at the same time but
since this goes through many classes, it would cause quite a bit of
additional code just for handling a corner case, and I'd like to avoid
that and to keep the code as clean as possible.

If anyone disagrees with that please speak up.

Jeremias Maerki

Reply via email to