Hmm, false alarm. Despite using URIs, case mismatches with File URI/URLs on Windows don't matter. Good to know.
On 10.03.2009 10:27:01 Jeremias Maerki wrote: > 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 > Jeremias Maerki
