You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Jeremias Maerki <de...@jeremias-maerki.ch> on 2009/03/10 10:27:01 UTC
AFP: Font access
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
Re: AFP: Font access
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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
Re: AFP: Font access
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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