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: http://xmlgraphics.apache.org/fop/trunk/output.html#afp-configuration 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 java.net.URI. 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. Thanks, Jeremias Maerki
