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 Victor Mote <vi...@outfitr.com> on 2002/10/05 22:51:28 UTC
fonts
Jeremias & other FOP Developers:
In addition to OpenType support, the other goal that I had for font work is
to support arbitrary fonts. My initial thoughts in this area revolved around
using the Java 2D capabilities. I understood that the GraphicsEnvironment
can only see what the O/S shows it, but it did not immediately dawn on me
that the more popular O/Ss for running FOP are probably Linux & Unix may not
have a concept of font registration like Windows & Mac do. (If there is a
way to register fonts in the character environments of these platforms in
such a manner that java can see them, please let me know -- I have looked
for this, but have not found it.)
Question: Is it therefore fair to conclude that the reason for using the
generated XML metric files is to provide a platform-neutral way of getting
such information, especially for non-graphical environments? The following
discussion assumes that the answer to this question is "yes".
-------
I am thinking through ways to eliminate as much user involvement in using
non-base-14 fonts as possible. Is there a performance benefit to parsing the
XML metric files instead of extracting the information directly from the
font file itself at runtime? If so, then perhaps I should just leave this
alone. If not, then I see some options for possible improvement, listed from
least radical to most.
1. Replace current font-by-font configuration item with a path to the font
file itself. When the font is used in a session, parse the metric
information in real time from the font file.
2. Add a configuration item that contains a PATH-like list of directories in
which font files are located. When a font is requested in a session, search
the path for the font file, parse it, and use it. (There would seem to be a
performance penalty for this, so it should be optional).
3. [This one is only half-baked]. Extend or otherwise hack the
GraphicsEnvironment and/or java.awt.font classes to "see" non-registered
fonts as if they were registered. In other words, to parse the fonts from
the font files (found in the configuration file or PATH) and create
java.awt.font objects for them that can be used. I do not know whether this
is feasible, but if it were, it seems like we might gain a bunch of benefits
from using the Java 2D classes that use these classes. If this is an
impossible or otherwise bad idea, perhaps it will trigger a good one in
someone else.
I am betting that some of you have thought about these issues for a while,
so I ask the questions hoping that you can save me many hours of tedious
unfruitful work.
Victor Mote (mailto:vic@outfitr.com)
2025 Eddington Way
Colorado Springs, Colorado 80916
Voice 719-622-0650
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: fonts
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Victor Mote wrote:
> If I followed this, then we would expect the current method to use a more
> memory, but less processor time, while parsing the font file at runtime
> would likely use less memory, but more processing.
I meant: If you are going to extract the font metrics from the
original font file directly, you have basically two alternatives:
- load the whole file into an array in order to get fast random
access
- make frequent seeks and read lots of small data packets (often
a few bytes) in order to minimize memory load
Either possibility is prospective for western fonts, which are
generally small, and not all that much different characters are
used. The first possiblity can be ruled out for large Unicode
fonts, even if you only use a few characters. Far eastern users
will probably have problems with both solutions.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: fonts
Posted by Victor Mote <vi...@outfitr.com>.
J.Pietschmann wrote:
> Well, as far as I understand TTF and PFB files have a directory
> and lots of pointers to other parts of the file. The metric
> extractor loads the whole file into memory, for convenience.
> This can be a significant memory load, and all the glyph
> geometry definitions take up space unnecessarily.
> This could probably be avoided using the RandomAccessFile class,
> but I expect performance going down the toilet in this case.
If I followed this, then we would expect the current method to use a more
memory, but less processor time, while parsing the font file at runtime
would likely use less memory, but more processing. Am I understanding you
correctly? (I understand that we are speaking in terms of expectations, not
having actually measured the effects of either approach). The other question
that I should bring in here is whether any one has real-world experience
with the tradeoffs of using java.awt.Font. And more importantly, are any of
these tradeoffs in any of these three scenarios worth considering. In other
words, should be worry about these issues at all, or assume that Moore's Law
will in good time fix all of them? This is not a rhetorical question.
> Another point, important IMO, is that the metrics file can be
> edited after extraction. Some fonts contain awful data.
I understand what you are saying, but I almost think this is a negative. If
the font metrics we use are incomplete because we aren't looking at the
other Type 1 pieces, that should be fixable. If they are bad because the
font is bad, I am not sure how much we want to encourage the use of bad
fonts. Pointers to font editing software and reliable font suppliers might
be more productive. The real question here is whether, if we had an
alternative that would allow us to abstract fonts at the java level instead
of at the FOP level, would we be willing to give up the ability to hack the
metrics files in exchange?
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: fonts
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Victor Mote wrote:
> I am thinking through ways to eliminate as much user involvement in using
> non-base-14 fonts as possible. Is there a performance benefit to parsing the
> XML metric files instead of extracting the information directly from the
> font file itself at runtime?
Well, as far as I understand TTF and PFB files have a directory
and lots of pointers to other parts of the file. The metric
extractor loads the whole file into memory, for convenience.
This can be a significant memory load, and all the glyph
geometry definitions take up space unnecessarily.
This could probably be avoided using the RandomAccessFile class,
but I expect performance going down the toilet in this case.
Another point, important IMO, is that the metrics file can be
edited after extraction. Some fonts contain awful data.
I agree that user fonts should be made more usable, for example
by integrating a one step font metrics generation and installation
into the main command line application. Another possibility would
be a metrics file repository, combined with a tool which searches
the repository and the locally installed fonts and then installs
the font in the FOP config.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: fonts
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Jeremias Maerki wrote:
> Don't ask me for details (because I wasn't directly involved) but we had
> to register new fonts with Linux so they got available in Batik for SVG.
> So there seems to be some kind of font registry in Linux.
That's probably the X Windows font registry which is used by the
AWT, whose fonts are in turn used by Batik.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: fonts
Posted by Ralph LaChance <Ra...@compuserve.com>.
At 02:31 AM 10/8/02, you wrote:
>Will we have enough information out of AWT to produce high-quality
> text? For example, you need accurate information for the placement of
> under/overlines and superscript stuff.
$.02:
Underlines are in the (newish) LineMetrics object available from a Font,
nothing I know of about overlines, sub/super script per se.
One piece of bad news is that presently the JDK has a problem producing
identical output to the screen vs a printer (I documented the problem here a
couple months ago viz-a-viz Windows, at least.) As I recall, the rasterizer
comes up with output glyphs that do not match the size predicted by
measuring text using the font-metrics.
Even worse is that it seems to fails differently between depending on major
version ~ 1.3 and 1.4 ~ (maybe even among sub versions.)
I recall wondering if fop could get better results in the awt if, at the
time it
creates its reference font metrics, it were to know the actual target
(ie printer vs screen vs pdf) graphics context. Then I wondered what this
had to do with pdf and went to sleep...
' Best,
-Ralph LaChance
In theory, there is no difference between
theory and practice, but in practice there is.
(Someone wrote that, but I don't know who.)
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: fonts
Posted by Jeremias Maerki <de...@greenmail.ch>.
Good discussion you two had. Jörg injected about the same things I would
have.
In the back of my mind I have a reminder that AWT has some strange
behaviour in font handling making it difficult to produce high-quality
text. Looking at org.apache.fop.render.awt.AWTFontMetrics there is a
pointer to an AWT bug. There's other code in there that hints at
deficiencies in AWT. And there are differences between JDK versions!
Here are some thoughts:
- I think it would be good if we could provide fonts for the PDF and
other renderers from the AWT, because it would make it easier for
users to add new fonts and it is consistent with Batik's approach...
- ...but will we be able to get at the physical font in order to embedd
it in the target file? While quickly looking into the AWT API I
haven't found anything approriate. And where will we configure that a
particular font should be embedded?
- Will we have enough information out of AWT to produce high-quality
text? For example, you need accurate information for the placement of
under/overlines and superscript stuff.
So having said that and considering what has been said before I think
relying on AWT for font handling cannot be the only answer. I'm still on
the same track as before wanting a font manager for FOP that can handle
multiple font sources. This means a good heap of work but will give us
the necessary flexibility to cope with almost every situation. That
doesn't mean we have to provide everything immediately. Incremental
improvement will do just fine.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: fonts
Posted by "Peter B. West" <pb...@powerup.com.au>.
Victor Mote wrote:
> My apologies for using up so much
> bandwidth.
Victor,
That's what it's there for. No apology required.
Peter
--
Peter B. West pbwest@powerup.com.au http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: fonts
Posted by Victor Mote <vi...@outfitr.com>.
Victor Mote wrote:
> of this decision seems significant. If 99% of ISP/ASP users are using only
> fonts that would be on their server, or if we don't mind telling them that
> they should (or use an in-house server, or get the ISP to install
> the fonts,
> or ...), then maybe we come to a different decision. How do the other
I just found something in the Java 1.3 javadocs that wasn't in my JFC book
(which must cover 1.2): a createFont method in java.awt.Font, which will
create a Font instance from an InputStream. It appears to only handle
TrueType right now. However, Type 1 fonts can be converted to TrueType.
Since OpenType isn't supported right now, I don't think anyone can complain
that it wouldn't be supported under this scheme. Unless someone thinks the
Type 1 to TrueType conversion is too big of an issue, or has some other
objection, I'll work on this approach. My apologies for using up so much
bandwidth.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: fonts
Posted by Victor Mote <vi...@outfitr.com>.
J.Pietschmann wrote:
> Victor Mote wrote:
> > Is it safe to assume that all *n*x
> > platforms have or could get an X environment?
> No. This is a FAQ.
Sorry. I have seen "headless server" postings go by, but it meant nothing to
me.
> Well, FOP is already so tightly integrated with Batik that it wont run
> without X or PJA. However, I suspect that talking an ISP/ASP into
> installing
> additional fonts will be more often a major PITA than not, and this
> could easily be seen as significant drawback of the "use the system fonts"
> approach. And if I were a server provider, I'd be uneasy with customers
> dragging in heaps of fonts I have to install and manage. Apart from the
> potential to have clashes, getting the X font subsystem to perform with
> lots of fonts apparently requires some rather arcane knowledge.
Good point, and one that I would not have thought of working in a standalone
& static environment. The question then becomes whether 1) FOP should
dictate to the end-user that it can only use registered fonts, or 2) the
end-user's environment limitations should dictate to FOP that it must build
yet another independent font registry system. I am OK with either one, but I
think it is good to ask the question before proceeding, as the ripple effect
of this decision seems significant. If 99% of ISP/ASP users are using only
fonts that would be on their server, or if we don't mind telling them that
they should (or use an in-house server, or get the ISP to install the fonts,
or ...), then maybe we come to a different decision. How do the other
implementations handle this issue? I definitely don't intend to be
argumentative here. I may be the odd man out, as the axis that we are
concerned with has less to do with servers & performance than typographical
flexibility.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: fonts
Posted by Victor Mote <vi...@outfitr.com>.
J.Pietschmann wrote:
> > in a headless environment, I get a runtime error that halts the JVM.
>
> This is interesting, but you'll probably get more and better
> answers on comp.lang.java or a more specialized Java forum.
I wasn't looking for an answer here, as I really didn't think there was a
java solution. This was simply background for a discussion about how best to
work around it in the font work I am doing.
> I'm not sure why you take this trouble, can't you control or at least
> reliably determine the run time environment in advance? You can
> install PJA in case you encounter a headless Java 1.3 environment.
Perhaps I did not give enough background. One of the reasons for the font
refactoring work I am doing is to give FOP access to system fonts. These
fonts are available through methods in
java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(). The JDK will
compile the code, but the runtime was choking in a headless environment.
Since I am writing this as an enhancement for FOP in general (as opposed to
only my own installation), the answer is no -- I cannot control or determine
the runtime environment in advance.
Rhett Aultman wrote:
> I'm curious. What's the error and stacktrace for that error?
> Have you tried catching things of type Throwable?
I had tried to catch a RunTimeException without success. It frankly did not
occur to me to try to catch a Throwable, but based on your suggestion, I
did, and it does catch it correctly. Thanks very much. Also, my apologies to
Joerg et al for asking a java question here -- I really did think it was a
FOP workaround question.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: fonts
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Victor Mote wrote:
> OK, here is a related question that does not appear to be an FAQ (per my
> review of FOP, Batik, and Cocoon lists). If I try:
> ge = GraphicsEnvironment.getLocalGraphicsEnvironment();
>
> in a headless environment, I get a runtime error that halts the JVM.
This is interesting, but you'll probably get more and better
answers on comp.lang.java or a more specialized Java forum.
> There
> does not seem to be a way to catch the error and skip the offending code
> (which is all I really need to do). It looks like 1.4 will throw a
> HeadlessException, and also gives a GraphicsEnvironment.isHeadless() method,
> both of which are helpful. However, in 1.3, I don't see a clean way to
> detect this -- I could probably do something klunky like looking at the
> $TERM variable & trying to figure it out from there.
I'd go for the DISPLAY environment variable: if it's not set, you
are most probably running headless. There is a slight possibility
you are on a system which would connect to a local X server anyway,
so just to be really, really sure open a socket to localhost:6000, and
perhaps emulate XOpenDisplay if there is something listening there.
I'm not sure why you take this trouble, can't you control or at least
reliably determine the run time environment in advance? You can
install PJA in case you encounter a headless Java 1.3 environment.
> On a related note, what are our criteria
> for determining support of various Java platforms?
There is a rule of thumb to support older environments up to two
years after the next major upgrade was available, perhaps with
slight restrictions. It depends on how much inconvenience this brings
to users of more recent versions, and on how much users of older
versions complain. There are people stuck with MS Java or IMB's
1.1.8 JRE on OS/390 USS, but they never showed up in person when it
came to discussions about dropping Java 1.1 support.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: fonts
Posted by Victor Mote <vi...@outfitr.com>.
J.Pietschmann wrote:
> Victor Mote wrote:
> > Is it safe to assume that all *n*x
> > platforms have or could get an X environment?
> No. This is a FAQ. It seems to be quite common for servers to come
> without X libraries installed, search the FOP, Cocoon and Batik lists for
> "headless server".
OK, here is a related question that does not appear to be an FAQ (per my
review of FOP, Batik, and Cocoon lists). If I try:
ge = GraphicsEnvironment.getLocalGraphicsEnvironment();
in a headless environment, I get a runtime error that halts the JVM. There
does not seem to be a way to catch the error and skip the offending code
(which is all I really need to do). It looks like 1.4 will throw a
HeadlessException, and also gives a GraphicsEnvironment.isHeadless() method,
both of which are helpful. However, in 1.3, I don't see a clean way to
detect this -- I could probably do something klunky like looking at the
$TERM variable & trying to figure it out from there. We could conceivably
use a configuration entry or environment variable to flag this (with
"headless" defaulting to "yes" -- in other words, they would have to
override it with "no" for us to know that they are in a graphical
environment). I don't mind doing that, but I don't want to create a bunch of
support headaches. Any suggestions? On a related note, what are our criteria
for determining support of various Java platforms? In other words, at what
point would we insist on 1.4 as the minimum platform supported by FOP? I'm
not suggesting that we should do that, but just thinking through the costs &
benefits of an interim solution.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: fonts
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Victor Mote wrote:
> Is it safe to assume that all *n*x
> platforms have or could get an X environment?
No. This is a FAQ. It seems to be quite common for servers to come
without X libraries installed, search the FOP, Cocoon and Batik lists for
"headless server". Also, there are providers out there who run Cocoon or
a general servlet environment but make it difficult to install it as
"headless", and some even refuse to install the X libraries for
"security reasons" or whatever.
I personally had to go to some length to have my application server at
work installed with PJA, even though a X server is running. The X
security settings prevent the application server from accessing the X
server, and the server staff just refused to change anything (I suspect
they don't have a clue how to fiddle with the X security stuff).
Well, FOP is already so tightly integrated with Batik that it wont run
without X or PJA. However, I suspect that talking an ISP/ASP into installing
additional fonts will be more often a major PITA than not, and this
could easily be seen as significant drawback of the "use the system fonts"
approach. And if I were a server provider, I'd be uneasy with customers
dragging in heaps of fonts I have to install and manage. Apart from the
potential to have clashes, getting the X font subsystem to perform with
lots of fonts apparently requires some rather arcane knowledge.
The problem with PJA OTOH is that it is sloooooow , and it only accepts one
font file format (TTF IIRC, it is OSS though, someone out there to fix it?)
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: fonts
Posted by Victor Mote <vi...@outfitr.com>.
J.Pietschmann wrote:
> Jeremias Maerki wrote:
> > Don't ask me for details (because I wasn't directly involved) but we had
> > to register new fonts with Linux so they got available in Batik for SVG.
> > So there seems to be some kind of font registry in Linux.
>
> That's probably the X Windows font registry which is used by the
> AWT, whose fonts are in turn used by Batik.
That makes sense, and I'll investigate it further on my Linux box. I
hesitated to do so before because I assumed that the use of the font metrics
files was to overcome a limitation here, perhaps when running *n*x in
character mode.
Jeremias Maerki wrote (speaking of problems with font metrics in Type 1
fonts):
> The reason for that is that currently, only the PFM file of a font is
> used to generate the XML font metrics file. The PFM lacks certain values
> that subsequently have to be guessed. These guesses tend to be wrong
> relatively often. To fix this FOP would have to learn the ability to
> also parse the AFM and maybe values from the PFB. I think the TrueType
If java can see the font files, this work has already been done for us. I
guess I am trying to push the level of font abstraction up a notch or two
higher if possible.
> > 1. Replace current font-by-font configuration item with a path
> to the font
> > file itself. When the font is used in a session, parse the metric
> > information in real time from the font file.
> >
> > 2. Add a configuration item that contains a PATH-like list of
> directories in
> > which font files are located. When a font is requested in a
> session, search
> > the path for the font file, parse it, and use it. (There would
> seem to be a
> > performance penalty for this, so it should be optional).
> >
> > 3. [This one is only half-baked]. Extend or otherwise hack the
> > GraphicsEnvironment and/or java.awt.font classes to "see" non-registered
> > fonts as if they were registered. In other words, to parse the
> fonts from
> > the font files (found in the configuration file or PATH) and create
> > java.awt.font objects for them that can be used. I do not know
> whether this
> > is feasible, but if it were, it seems like we might gain a
> bunch of benefits
> > from using the Java 2D classes that use these classes. If this is an
> > impossible or otherwise bad idea, perhaps it will trigger a good one in
> > someone else.
>
> Yes please!!! But don't forget to provide backwards compatibility
> (loading a font from a XML font metric file). Depending on what's faster
> it may be beneficial to generate an XML font metric file into some
> configurable directory acting as some kind of persistant font cache, the
> first time the font is loaded. Adobe Acrobat Reader does something
> similar, too.
My three proposals were predicated on the assumption that there was some
cross-platform need for the generated font metrics information. If in fact
we can find a way to register the fonts at the O/S level and let java see
them that way, would that not be better than any of the three options above?
The following objections come to mind:
1. Refactoring work. Answer: True, but all of the other options generate
work as well, including the status quo (which generates work for the user,
and support questions for us).
2. We exchange support of font metric generation for support of getting
fonts registered at the O/S level. Answer: True, but it would seem that
these would pretty much offset.
3. This might reduce FOP functionality on some platforms (ie. if unable to
register the fonts, can't use them anymore). Answer: True, and this is the
one that concerns me the most. However, they won't be able to run Batik
either (if I understand correctly). Is it safe to assume that all *n*x
platforms have or could get an X environment?
Unless java.awt.GraphicsEnvironment can be tricked into seeing unregistered
fonts, the current design and using java.awt.Font seem mutually exclusive.
It would be very helpful to hear comments about objection 3 above (potential
reduced functionality on some platforms).
Thanks to both Jeremias & Joerg for their help. I think I have enough to
keep me busy for a while.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: fonts
Posted by Jeremias Maerki <de...@greenmail.ch>.
Hi Victor
On 05.10.2002 22:51:28 Victor Mote wrote:
> Jeremias & other FOP Developers:
>
> In addition to OpenType support, the other goal that I had for font work is
> to support arbitrary fonts. My initial thoughts in this area revolved around
> using the Java 2D capabilities. I understood that the GraphicsEnvironment
> can only see what the O/S shows it, but it did not immediately dawn on me
> that the more popular O/Ss for running FOP are probably Linux & Unix may not
> have a concept of font registration like Windows & Mac do. (If there is a
> way to register fonts in the character environments of these platforms in
> such a manner that java can see them, please let me know -- I have looked
> for this, but have not found it.)
Don't ask me for details (because I wasn't directly involved) but we had
to register new fonts with Linux so they got available in Batik for SVG.
So there seems to be some kind of font registry in Linux. Don't know
about the other unixes but I guess they will be the same.
> Question: Is it therefore fair to conclude that the reason for using the
> generated XML metric files is to provide a platform-neutral way of getting
> such information, especially for non-graphical environments? The following
> discussion assumes that the answer to this question is "yes".
Not really. I think it's more of a historical thing. In the beginning
there was a class for each of the base 14 fonts (still in use today).
These classes are generated from XML files in the codegen directory.
Then, when I started to get involved, I finished work by others so we
could programmatically register Java classes generated from XML font
metric files (almost the same as today) in FOP. Tore Engvig then took
over, implemented TrueType support and provided a way for FOP to load
the XML font metric files directly. That's how things are today.
> I am thinking through ways to eliminate as much user involvement in using
> non-base-14 fonts as possible. Is there a performance benefit to parsing the
> XML metric files instead of extracting the information directly from the
> font file itself at runtime? If so, then perhaps I should just leave this
> alone. If not, then I see some options for possible improvement, listed from
> least radical to most.
I don't know what would be faster. We'd have to do some performance
measurings. As Joerg said, there's a benefit of being able to edit the
XML font metrics. You may have read the recent problem Paul Thibodeaux
reported with a PS Type 1 font. I've had this kind of problems before.
The reason for that is that currently, only the PFM file of a font is
used to generate the XML font metrics file. The PFM lacks certain values
that subsequently have to be guessed. These guesses tend to be wrong
relatively often. To fix this FOP would have to learn the ability to
also parse the AFM and maybe values from the PFB. I think the TrueType
support may have similar problem but far less often. I'm not sure
because I don't work with TrueType fonts.
> 1. Replace current font-by-font configuration item with a path to the font
> file itself. When the font is used in a session, parse the metric
> information in real time from the font file.
>
> 2. Add a configuration item that contains a PATH-like list of directories in
> which font files are located. When a font is requested in a session, search
> the path for the font file, parse it, and use it. (There would seem to be a
> performance penalty for this, so it should be optional).
>
> 3. [This one is only half-baked]. Extend or otherwise hack the
> GraphicsEnvironment and/or java.awt.font classes to "see" non-registered
> fonts as if they were registered. In other words, to parse the fonts from
> the font files (found in the configuration file or PATH) and create
> java.awt.font objects for them that can be used. I do not know whether this
> is feasible, but if it were, it seems like we might gain a bunch of benefits
> from using the Java 2D classes that use these classes. If this is an
> impossible or otherwise bad idea, perhaps it will trigger a good one in
> someone else.
Yes please!!! But don't forget to provide backwards compatibility
(loading a font from a XML font metric file). Depending on what's faster
it may be beneficial to generate an XML font metric file into some
configurable directory acting as some kind of persistant font cache, the
first time the font is loaded. Adobe Acrobat Reader does something
similar, too.
For Type 1 font support that would mean that we have to write a AFM
and/or PFB parser (already on my todo list, but I'm lacking time ATM) so
we get better reliability for these fonts.
> I am betting that some of you have thought about these issues for a while,
> so I ask the questions hoping that you can save me many hours of tedious
> unfruitful work.
Today, making fonts available is the responsibility of the renderer. I'm
not sure if this is good. I'd prefer a central font manager which can
provide fonts from various sources (AWT, directories containing TTFs and
PFBs, legacy font config from XML font metric files etc). The target
renderer(s) then only reports back what kinds of font sources it
supports. We would probably have to provide a way to give some font
sources a higher priority than others depending on the renderer.
Disclaimer: I haven't thought this through to the end.
Maybe we also have to think a little bit about Batik. It depends a lot on
AWT for font management even if we're using it in the context of a PDF
renderer. If I understand it correctly fonts cannot always be rendered
by FOP but have to be rendered by Batik by painting polygons or bézier
curves.
I hope this helps.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org