Changes committed: http://svn.apache.org/viewvc?rev=752133&view=rev
On 10.03.2009 14:22:03 Jeremias Maerki wrote: > 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 > Jeremias Maerki
