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 "J.Pietschmann" <j3...@yahoo.de> on 2003/11/20 20:25:01 UTC
Font variant SmallCaps Was: Re: (Chris) Re: Traits
Andreas L. Delmelle wrote:
> The objects to which this particular FO property applies would need to be
> _able_ to use the getters and setters (which does not seem to be the case in
> any of the classes at the moment) to activate the code in fonts, not? Or,
> the code in fonts should be _able_ to use them at the very least (--which I
> can only guess to be the idea, from the corresponding variable declarations
> being commented out, these would be replaced by a call to getFontVariant() )
>
> (Still not making sense? If you need any more intermediate steps in
> understanding how getters and setters actually make things work, we're just
> a message away ;) )
Dunno. Let me elaborate.
We have
FO -> FOP layout -> FOP renderer -> output
Font variant SmallCaps can be implemented in several ways
- Get a SmallCaps font and use it. The handling is the same as
for bold and italic (or "font-weight" and "font-style")
- Emulate by uppercasing lowercase characters and set an 80%
size font for them before the text is laid out (maintenance
branch implementation)
- pass the attribute into the renderer or into the output and
let them care for themself
The layout needs font metrics, therefore from the point of view
of the layout the first and third option are the same.
The interesting point is whether option 2 is implemented, somewhere
in the pipeling before individual character widths are used (and,
if necessary, character height), or whether the layout can get its
metrics form a FOP Font structure (FontState or whatever it is called
now).
If the font approach is used, we need "font variant" to be a font
attribute. I'm too lazy to check whether this is already in place.
The maintenance code didn't have it.
The advantage of this approach compared to the "early emulation"
approach is that if a user has a true small caps font, he can use
it more easily. For FOP, there is still the problem what to do if
there is no appropriate font. Just bailing out might be an idea,
but not necessarily a good one. An alternative would be to let the
emulation happen under control of the font, in the renderer. This
would need some hooks which don't exist yet, because the emulation
must be able to insert the font size change into the output.
Now the questions is: how should the implementation look in HEAD?
I personally like the font+late emulation approach.
J.Pietschmann
RE: Font variant SmallCaps
Posted by Victor Mote <vi...@outfitr.com>.
Simon Pepping wrote:
> These days everybody uses scalable fonts, but in principle it is
> possible that Courier-Bold-Italic at 10 points is a different font
> than Courier-Bold-Italic at 20 points, with a different metric file
> and different glyphs. The canonical example being of course TeX, with
> e.g. cmr5, cmr6 etc.
I assume that you are referring to bitmap fonts here. I don't think we have
anything implemented for such fonts right now, but if we were to do so, I
think the scheme remains the same as far as the rest of FOP is concerned.
IOW, the relationship between Font, Typeface, and TypefaceFamily is intact.
The Font object handles any peculiarities related to the particular point
size, regardless of their source.
Victor Mote
Re: Font variant SmallCaps
Posted by Simon Pepping <sp...@leverkruid.nl>.
On Fri, Nov 21, 2003 at 07:54:07AM -0700, Victor Mote wrote:
> No. Courier-Bold-Italic would be the Typeface, Courier would be the
> TypefaceFamily. So my Font object that gets used by FOP would be
> Courier-Bold-Italic at 12 points. It has a parent Typeface, which represents
> the Courier-Bold "font" file and its contents. This typeface has a parent
> TypefaceFamily, which represents the Courier family, and knows how to find
> bold, italic, small-caps, etc. Typefaces which are related.
These days everybody uses scalable fonts, but in principle it is
possible that Courier-Bold-Italic at 10 points is a different font
than Courier-Bold-Italic at 20 points, with a different metric file
and different glyphs. The canonical example being of course TeX, with
e.g. cmr5, cmr6 etc.
With kind regards,
Simon Pepping
--
Simon Pepping
email: spepping@leverkruid.nl
home page: http://www.leverkruid.nl
RE: Font variant SmallCaps
Posted by Victor Mote <vi...@outfitr.com>.
Peter B. West wrote:
> > BTW fonts aren't the only considerations, others are color and the
> > discretization of coordinates (e.g. bitmap vs. vector format).
>
> All of which leads me to the question of what, exactly, we are trying to
> isolate and amalgamate in the font system. We can't get away from
> renderer dependencies, so the target renderer is going to have to be
> accommodated before any atomic elements are introduced to the Area Tree.
> As I said, I haven't been closely following the fonts discussion, but
> I'm confused as to where it fits in the scheme of things, and what it is
> trying to achieve.
I think what we are trying to do is to separate Font details from the Layout
and Render processes as much as possible. Renderer dependencies need to
drive font selection, but by the time the Layout or Render actually start to
do their work, those issues should already be resolved.
Your inquiries here have actually caused me to rethink Fonts a bit. My view
of FOP's overall design (I apologize for brining this up again, but it is
necessary to explain the point) is that we have a Session (Driver) which can
have multiple Documents, each of which can have multiple RenderContexts,
each of which can have multiple Renderers. (The RenderContext class exists
only in my mind right now, as I have failed to get support for it --
however, much of the discussion in this thread revolves around that
concept). Document controls the FOTree build, RenderContext controls the
Layout/Area Tree, and the Renderers simply render the Area Tree. Now, my
plan has been to have FOTree resolve to a Font object during parsing.
However, it is clear to me that actual Font resolution has to go with the
RenderContext concept. So, probably the FOTree needs to store more raw
information (perhaps in an FOFont object) that the RenderContext can resolve
into a Font during layout. The performance impact should be minimal, but I
think the extra layer of abstraction is important.
Victor Mote
Re: Font variant SmallCaps
Posted by "Peter B. West" <pb...@powerup.com.au>.
J.Pietschmann wrote:
> Peter B. West wrote:
>
>> Although not mandated in XSL-FO, CSS2 offers a number of methods of
>> font matching, only some of which preserve metrics. The FO User Agent
>> is free to make implementation-specific decisions about this, I
>> assume. My main interest here is in whether we want to try to
>> separate out the font handling so that we try to guarantee identical
>> layout on any renderer, or whether we state up front that such
>> universality is *not* on offer.
>
>
> I don't think the TXT renderer will in general render to the same layout
> as others :-)
> Nitpicks aside, fonts may be renderer specific. If different renderers
> use an identical font (e.g. a user configured TTF) chances are that the
> layout is the same, provided bitmap images are rendered identically. If
> different renderers use different fonts, which may have different metrics
> even if they are the same family, the layout is likely to be different
> too. I can't see how to avoid this.
This was my original perception. (I hadn't even thought about the
different rendering of images.)
> BTW fonts aren't the only considerations, others are color and the
> discretization of coordinates (e.g. bitmap vs. vector format).
All of which leads me to the question of what, exactly, we are trying to
isolate and amalgamate in the font system. We can't get away from
renderer dependencies, so the target renderer is going to have to be
accommodated before any atomic elements are introduced to the Area Tree.
As I said, I haven't been closely following the fonts discussion, but
I'm confused as to where it fits in the scheme of things, and what it is
trying to achieve.
...
>
> I'd say if the user saye
> font-family="futura, sans-serif,any"
> he'll get a warning that a fallback was used in case there is no futura
> or not even a sans-serif font.
> If the user says
> font-family="futura"
> and there is no futura font, FOP should terminate. After all, the user
> hopefully thought about it.
Makes sense.
Peter
--
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
Re: Font variant SmallCaps
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Peter B. West wrote:
> Although not mandated in XSL-FO, CSS2 offers a number of methods of font
> matching, only some of which preserve metrics. The FO User Agent is
> free to make implementation-specific decisions about this, I assume. My
> main interest here is in whether we want to try to separate out the font
> handling so that we try to guarantee identical layout on any renderer,
> or whether we state up front that such universality is *not* on offer.
I don't think the TXT renderer will in general render to the same layout
as others :-)
Nitpicks aside, fonts may be renderer specific. If different renderers
use an identical font (e.g. a user configured TTF) chances are that the
layout is the same, provided bitmap images are rendered identically. If
different renderers use different fonts, which may have different metrics
even if they are the same family, the layout is likely to be different
too. I can't see how to avoid this.
BTW fonts aren't the only considerations, others are color and the
discretization of coordinates (e.g. bitmap vs. vector format).
> I would assume that the most useful response to the above situation is
> to issue a warning and do one's best to match the font. The user has
> access to a number of mechanisms for narrowing font choice, and in the
> worst case we use a fall-back font.
I'd say if the user saye
font-family="futura, sans-serif,any"
he'll get a warning that a fallback was used in case there is no futura
or not even a sans-serif font.
If the user says
font-family="futura"
and there is no futura font, FOP should terminate. After all, the user
hopefully thought about it.
J.Pietschmann
Re: Font variant SmallCaps
Posted by "Peter B. West" <pb...@powerup.com.au>.
J.Pietschmann wrote:
> Peter B. West wrote:
>
>> If a user renders a given .fo file on two different systems, using the
>> same renderer (say, PDF), and specifies a font family (say,
>> Baskerville) that does not exist on the first system, but does on the
>> second, what result should be expected?
>
>
> If the user specified a fallback, it is tried, otherwise I'd
> expect an error abort. What should be the alternative to the
> latter? Guessing the font characteristics and using a substitute
> font?
Although not mandated in XSL-FO, CSS2 offers a number of methods of font
matching, only some of which preserve metrics. The FO User Agent is
free to make implementation-specific decisions about this, I assume. My
main interest here is in whether we want to try to separate out the font
handling so that we try to guarantee identical layout on any renderer,
or whether we state up front that such universality is *not* on offer.
The latter course is certainly easier. The former seems to involve a
metrics-preserving font matching front-end to every renderer. But fonts
is an area I'm not familiar with.
I would assume that the most useful response to the above situation is
to issue a warning and do one's best to match the font. The user has
access to a number of mechanisms for narrowing font choice, and in the
worst case we use a fall-back font.
Peter
--
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
Re: Font variant SmallCaps
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Peter B. West wrote:
> If a user renders a given .fo file on two different systems, using the
> same renderer (say, PDF), and specifies a font family (say, Baskerville)
> that does not exist on the first system, but does on the second, what
> result should be expected?
If the user specified a fallback, it is tried, otherwise I'd
expect an error abort. What should be the alternative to the
latter? Guessing the font characteristics and using a substitute
font?
J.Pietschmann
Re: Font variant SmallCaps
Posted by Simon Pepping <sp...@leverkruid.nl>.
On Wed, Nov 26, 2003 at 08:21:33PM +1000, Peter B. West wrote:
> Simon Pepping wrote:
> >I have taken a look at the way this question is dealt with in LaTeX
> >(TeX does not have the notion of font families, LaTeX does). Here the
> >question what to use for small caps font is deferred to the font
> >setup. The font definition tables must define a small caps font. If
> >they do not do so, a fallback font is used; this should also be
> >defined in the fd tables. If they fail to do that as well, the system
> >uses its fallback font.
> >
> >Like FOP's layout, LaTeX only uses the font metrics. The renderer
> >should locate the actual font. If such a font does not exist, but must
> >be emulated, then this should indicated in the font system
> >configuration for the renderers. For example, the fonts map for dvips
> >has these lines, which I believe tell it how to generate a small caps
> >font:
> >pplr8rn Palatino-Roman ".82 ExtendFont TeXBase1Encoding ReEncodeFont"
> ><8r.enc
>
> Correct me if I'm wrong here, but doesn't TeX have a full font system of
> it's own? Doesn't TeX guarantee to produce .dvi (device independent, I
> think) files? I assume it does this based on its own fonts and any
> METAFONT data. The matching of this .dvi to actual output is then the
> job of a dvi->? renderer. That is, there is a translation step between
> the dvi and the native input of the renderer, e.g. PDF, PS, H-P printer
> or X11.
TeX comes indeed with a font system of its own. Later type1 fonts have
been made accessible to TeX, in addition to its own bitmapped
fonts. But one can logically separate the layout system (the TeX
program) and the font system.
The procedure you describe above is correct. The dvi file is sort of
equivalent to the area tree: It has all layout and font information in
a format that can be used by renderers to generate output.
What I tried to say is that the layout program is only satisfied if it
finds the metric data of the font that the user requests. It does not
do anything smart about missing fonts. It is the responsibility of the
font system to do the smart things: provide the font requested, or
provide a replacement font for it, or provide a general fallback for
missing fonts. And it does so based on the information in its font
configuration files. These do the translation from a
font-family/shape/weight/size combination to an actual font file
name.
This is also the place to specify if a small caps font exists or
should be mimicked by using a smaller font. That would be a major
trick, as Chris already noted. The notion of a virtual font might help
here. That is a font that consists of pointers to glyphs in other
fonts. It has its own metric file, so that the layout system does not
note any anomaly.
Typographically minded users like to buy lots of fonts and add them to
the system. The system is informed about this, and about its
shortcomings and the replacement fonts, by additional font
configuration files. In addition, one can instruct renderers to
generate glyphs by certain manipulations on the glyphs of existing
fonts, such as slanting, extending.
But perhaps I assume too easily that ideas from TeX can be copied to
FOP.
> >So my basic belief is that FOP should not know anything about
> >this. It should all be configured in the font system. That is how the
> >user imposes his choice of fonts.
>
> If a user renders a given .fo file on two different systems, using the
> same renderer (say, PDF), and specifies a font family (say, Baskerville)
> that does not exist on the first system, but does on the second, what
> result should be expected?
Traditionally that depends on the renderer. Some produce a fallback
font family, e.g. PostScript viewers may use Courier. Others just
fail.
Regards,
Simon Pepping
--
Simon Pepping
email: spepping@leverkruid.nl
home page: http://www.leverkruid.nl
RE: Font variant SmallCaps
Posted by Victor Mote <vi...@outfitr.com>.
Peter B. West wrote:
> What's the intention for the FOP font system? Is FOP going to define a
> set of fonts and font metrics in its User Agent font database (as per
> CSS2)? Will this be defined with reference to the supported renderers
> (statically), the supported renderers and the fonts available on the
> system on which FOP is running (statically + dynamically), or by some
> other means. XSL-FO does not, AFAIT, expect the User Agent to support
> the degree of font matching specified in CSS2, even though the font
> model is based on CSS2. E.g. there is no capacity to specify a download
> "src" property. Users can't specify font characteristics to the same
> degree as in CSS2.
Basically, FOP uses both user-generated font metrics (static) and AWT fonts
(dynamic). AWT fonts are not suitable for embedding, because the AWT system
doesn't tell us how to get to the physical font file. What specifically are
you seeing in CSS2 that XSL-FO doesn't have?
> I have always assumed that rendering consistency was not guaranteed by
> XSL-FO. I can't find any reference ATM to justify that.
I think you are right. If the font ain't there, you can't use it.
> > So my basic belief is that FOP should not know anything about
> > this. It should all be configured in the font system. That is how the
> > user imposes his choice of fonts.
I missed this original comment made by Simon Pepping. If, by "font system"
Simon means those fonts available through java's AWT system, this is
unacceptable at the moment because these fonts cannot be embedded. Also, not
all systems have the graphical environment that is required to use the AWT
system.
> If a user renders a given .fo file on two different systems, using the
> same renderer (say, PDF), and specifies a font family (say, Baskerville)
> that does not exist on the first system, but does on the second, what
> result should be expected?
I think either a fallback font should be used with a warning, or an abortive
error.
Victor Mote
Re: Font variant SmallCaps
Posted by "Peter B. West" <pb...@powerup.com.au>.
Simon Pepping wrote:
> I have taken a look at the way this question is dealt with in LaTeX
> (TeX does not have the notion of font families, LaTeX does). Here the
> question what to use for small caps font is deferred to the font
> setup. The font definition tables must define a small caps font. If
> they do not do so, a fallback font is used; this should also be
> defined in the fd tables. If they fail to do that as well, the system
> uses its fallback font.
>
> Like FOP's layout, LaTeX only uses the font metrics. The renderer
> should locate the actual font. If such a font does not exist, but must
> be emulated, then this should indicated in the font system
> configuration for the renderers. For example, the fonts map for dvips
> has these lines, which I believe tell it how to generate a small caps
> font:
> pplr8rn Palatino-Roman ".82 ExtendFont TeXBase1Encoding ReEncodeFont" <8r.enc
Correct me if I'm wrong here, but doesn't TeX have a full font system of
it's own? Doesn't TeX guarantee to produce .dvi (device independent, I
think) files? I assume it does this based on its own fonts and any
METAFONT data. The matching of this .dvi to actual output is then the
job of a dvi->? renderer. That is, there is a translation step between
the dvi and the native input of the renderer, e.g. PDF, PS, H-P printer
or X11.
What's the intention for the FOP font system? Is FOP going to define a
set of fonts and font metrics in its User Agent font database (as per
CSS2)? Will this be defined with reference to the supported renderers
(statically), the supported renderers and the fonts available on the
system on which FOP is running (statically + dynamically), or by some
other means. XSL-FO does not, AFAIT, expect the User Agent to support
the degree of font matching specified in CSS2, even though the font
model is based on CSS2. E.g. there is no capacity to specify a download
"src" property. Users can't specify font characteristics to the same
degree as in CSS2.
I have always assumed that rendering consistency was not guaranteed by
XSL-FO. I can't find any reference ATM to justify that.
> So my basic belief is that FOP should not know anything about
> this. It should all be configured in the font system. That is how the
> user imposes his choice of fonts.
If a user renders a given .fo file on two different systems, using the
same renderer (say, PDF), and specifies a font family (say, Baskerville)
that does not exist on the first system, but does on the second, what
result should be expected?
Peter
--
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
Re: Font variant SmallCaps
Posted by Simon Pepping <sp...@leverkruid.nl>.
I have taken a look at the way this question is dealt with in LaTeX
(TeX does not have the notion of font families, LaTeX does). Here the
question what to use for small caps font is deferred to the font
setup. The font definition tables must define a small caps font. If
they do not do so, a fallback font is used; this should also be
defined in the fd tables. If they fail to do that as well, the system
uses its fallback font.
Like FOP's layout, LaTeX only uses the font metrics. The renderer
should locate the actual font. If such a font does not exist, but must
be emulated, then this should indicated in the font system
configuration for the renderers. For example, the fonts map for dvips
has these lines, which I believe tell it how to generate a small caps
font:
pplr8rn Palatino-Roman ".82 ExtendFont TeXBase1Encoding ReEncodeFont" <8r.enc
So my basic belief is that FOP should not know anything about
this. It should all be configured in the font system. That is how the
user imposes his choice of fonts.
With kind regards,
Simon Pepping
On Thu, Nov 20, 2003 at 09:22:41PM +0100, J.Pietschmann wrote:
> Victor Mote wrote:
> >Typeface roughly corresponds to what is contained in a ttf of pfa font
> >file.
>
> Hm hm. A TTF is typically Courier-bold-italic or so. Did you mean this
> or rather typeface==font-family?
>
> >I don't understand what you are saying here. If emulation is used, it
> >should
> >probably at least be logged. Alternatively, a config option could control
> >whether this is allowed at all. But I don't follow at all what you are
> >suggesting with the renderer using the font to control the emulation. How
> >does layout get done at all then? And what is the advantage over simply
> >establishing the emulation in the FO Tree itself?
>
> The layout gets the metric from a FOP font structure, and it doesn't have
> to know whether the font is a true small caps font or emulates it.
>
> During rendering, of course, emulation has to take effect.
>
> Well, on a secont thought there is not much difference from emulating
> small caps before layout.
>
> Of course it makes sense to log if small caps is emulated.
>
> J.Pietschmann
>
>
--
Simon Pepping
email: spepping@leverkruid.nl
home page: http://www.leverkruid.nl
Re: Font variant SmallCaps Was: Re: (Chris) Re: Traits
Posted by Jeremias Maerki <de...@greenmail.ch>.
(disclaimer: Due to lack of time and a hardware failure, I haven't read
everything, yet)
I don't think we can rely on java.awt.Font. A FOP-defined Font
interfaces is necessary to really make sure FOP gets what it need. What
we came up with on the Wiki pretty much shows my ideas for the font
support:
http://nagoya.apache.org/wiki/apachewiki.cgi?FOPFontSubsystemDesign
Basic parts of that are:
- Font metric providing interfaces to hide the various font sources (AWT,
Type1, TrueType) (There's no PDFFont in my view)
- Renderers announce which font sources they support -> rendering run
(Document) holds the available font sources subset.
- Font adapters provided by the renderers that know how to
register/use/put a particular font in the output.
Since I have too little time to really participate ATM I can't care too
much how it is done, i.e. with a Avalon selector or with something else.
I failed to give Avalon in FOP a good enough punch. My only concern is
the separation of font sources from the renderers, so that a uniform way
of making fonts available in FOP is possible. I'm sorry that I can't be
more of a help right now. I'd love to help, but have other priorities.
On 22.11.2003 15:18:25 J.Pietschmann wrote:
> Victor Mote wrote:
> > Same general concept, except I think there is a separate class for font
> > metrics in that system. If I can ever find a way to get to the physical file
> > (or some representation of it) through java.awt.Font (for embedding), we
> > would use it along with our other font scheme.
>
> I believe we should just define a fop.Font interface which is
> the same as awt.Font, then provide implementations fop.AWTFont,
> fop.PDFFont (well all the variations), fop.Type1Font etc. A
> configurable selector (an Avalon selector) could selcet them.
> This way people could use AWT fonts without a hassle, with the
> small disadvantage that they can't be embedded.
>
> Jeremias, as the resident font guru, what do you think?
Jeremias Märki
Re: Font variant SmallCaps Was: Re: (Chris) Re: Traits
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Jeremias Maerki wrote:
> Font configuration should/will become easier. For TrueType and Type1
> fonts this should just be a matter of specifying a list of directories
> in which to look for fonts. A cache is needed to speed up the inventory on
> startup.
Hmhm. Not bad.
> My idea is still different: Having several font sources and the
> renderers merely announce which font sources they support. That leaves
> to option open for later to enable multiple renderers
> simultaneously.
I don't think enabling multiple simultaneous renderers is worth
the trouble. If there are fonts producing a different metric for
the same font, all you share is parsing the FO tree and some
property refining. You have to provide for the case that generated
areas can't be reused across renderers and, if there should be any
advantage, also for cases where it is possible to share areas.
This looks ... complex.
> Example:
> FontSource A: TrueType fonts
> FontSource B: Type 1 fonts
> FontSource C: AWT fonts
> FontSource D: Base14 fonts
> FontSource E: PCL base fonts (just a guess)
>
> PDF renderer supports: A, B, D (maybe C)
> PostScript renderer supports: A, B, D (maybe C)
> Java2D/AWT renderer supports: A and C
> PCL renderer: Probably A, E
> .....
You need
- a class managing the fonts
- inquire the supported font types from the renderer
- match the renderer font types with the managed fonts
I still think it would be easier to get a renderer specific font
manager from the renderer, or get the fonts directly from the
renderer. The font managers or the renderes can share code for
general configuration, caching, font file management etc. by
subclassing a common class or by delegation (especially in the
second case).
J.Pietschmann
RE: Font variant SmallCaps Was: Re: (Chris) Re: Traits
Posted by Victor Mote <vi...@outfitr.com>.
Jeremias Maerki wrote:
> > > And there's still the question if we can produce font metric
> information
> > > for the target formats (there's PCL and PostScript and..., too) that
> > > result in the desired output.
> >
> > The idea was to query the renderer for fonts, or get a renderer
> > specific font manager, and use the abstract interface to get
> > mainly character metrics, various other font measures and perhaps
> > font attributes like "sans-serif" or so.
>
> My idea is still different: Having several font sources and the
> renderers merely announce which font sources they support. That leaves
> to option open for later to enable multiple renderers
> simultaneously.
Yes, this latter idea is closer to my view as well.
Victor Mote
Re: Font variant SmallCaps Was: Re: (Chris) Re: Traits
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 27.11.2003 17:30:18 J.Pietschmann wrote:
> Jeremias Maerki wrote:
<snip/>
> >>This means users can use AWT fonts for creating PDF, but they can't
> >>embed them. This may cause the resulting PDF to fail, but so what.
> >
> >
> > --> Support questions
> It depends. If users are still required to declare used fonts explicitely
> as well as whether they should be embedded, and FOP bails out if told
> to embed an AWT font, it shouldn't be much of a problem.
Font configuration should/will become easier. For TrueType and Type1
fonts this should just be a matter of specifying a list of directories
in which to look for fonts. A cache is needed to speed up the inventory on
startup.
> > And there's still the question if we can produce font metric information
> > for the target formats (there's PCL and PostScript and..., too) that
> > result in the desired output.
>
> The idea was to query the renderer for fonts, or get a renderer
> specific font manager, and use the abstract interface to get
> mainly character metrics, various other font measures and perhaps
> font attributes like "sans-serif" or so.
My idea is still different: Having several font sources and the
renderers merely announce which font sources they support. That leaves
to option open for later to enable multiple renderers
simultaneously.
Example:
FontSource A: TrueType fonts
FontSource B: Type 1 fonts
FontSource C: AWT fonts
FontSource D: Base14 fonts
FontSource E: PCL base fonts (just a guess)
PDF renderer supports: A, B, D (maybe C)
PostScript renderer supports: A, B, D (maybe C)
Java2D/AWT renderer supports: A and C
PCL renderer: Probably A, E
.....
> > Seriously, I don't think working with AWT's Font will do us any good.
> > The differences between JDKs are too great.
>
> Hmhm. I still think
> - We must be able to use AWT fonts in the AWT renderer.
> - We must be able to use the default PDF fonts for the PDF renderer
> - We should be able to use TTF for both AWT and PDF
> - We should not rely on the default PDF fonts in the AWT renderer (doh!)
> - I'd like to support using TTF with generated and possibly hand-corrected
> metrics as well as using TTF directly.
>
> The possiblity to use AWT fonts for non-embedded fonts in PDF is a bonus.
> The possiblity to use AWT fonts in PDF even for embedding would be just
> another bonus.
+1 to all 7 points. Should be doable with my aproach.
Jeremias Maerki
Re: Font variant SmallCaps Was: Re: (Chris) Re: Traits
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Jeremias Maerki wrote:
> Anyway, it's the opposite of what Victor wanted.
Yeah.
> I think you meant return Font.createFont(Font.TRUETYPE_FONT, new
> FileInputStream...
OOps, yes.
>>This means users can use AWT fonts for creating PDF, but they can't
>>embed them. This may cause the resulting PDF to fail, but so what.
>
>
> --> Support questions
It depends. If users are still required to declare used fonts explicitely
as well as whether they should be embedded, and FOP bails out if told
to embed an AWT font, it shouldn't be much of a problem.
> And there's still the question if we can produce font metric information
> for the target formats (there's PCL and PostScript and..., too) that
> result in the desired output.
The idea was to query the renderer for fonts, or get a renderer
specific font manager, and use the abstract interface to get
mainly character metrics, various other font measures and perhaps
font attributes like "sans-serif" or so.
> Seriously, I don't think working with AWT's Font will do us any good.
> The differences between JDKs are too great.
Hmhm. I still think
- We must be able to use AWT fonts in the AWT renderer.
- We must be able to use the default PDF fonts for the PDF renderer
- We should be able to use TTF for both AWT and PDF
- We should not rely on the default PDF fonts in the AWT renderer (doh!)
- I'd like to support using TTF with generated and possibly hand-corrected
metrics as well as using TTF directly.
The possiblity to use AWT fonts for non-embedded fonts in PDF is a bonus.
The possiblity to use AWT fonts in PDF even for embedding would be just
another bonus.
J.Pietschmann
Re: Font variant SmallCaps Was: Re: (Chris) Re: Traits
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 26.11.2003 21:32:30 J.Pietschmann wrote:
> Victor Mote wrote:
> > Yes, this can get ugly. If anybody knows of a way to find the physical font
> > file from an awt Font object, please speak up.
>
> Currently (as of 1.4.1 you can create a awt.Font from an InputStream, but
> you cant get back whatever physical representation the font has from
> the awt.Font object.
Javadoc tells me this works since 1.3 (Font.createFont method).
Anyway, it's the opposite of what Victor wanted.
> I thought of the following approach
>
> interface fop.font.Font {
> public InputStream getFontInputStream();
> public awt.Font getAWTFont();
> // duplicate AWT methods, with certain stuff like metrics
> // replaced with FOP objects
> }
>
> class fop.font.AWTFont implements fop.font.Font {
> // delegate to AWT font
> // encapsulate awt.FontMetric in FOP font metric
>
> public InputStream getFontInputStream() { return null; }
> }
>
> class fop.font.Type1Font implements fop.font.Font {
> public awt.Font getAWTFont() { return null;}
> // use FOP type 1 font reader
> }
>
> class fop.font.TrueTypeFont implements fop.font.Font {
> public awt.Font getAWTFont() { return new Font(new FileInputStream...);}
I think you meant return Font.createFont(Font.TRUETYPE_FONT, new
FileInputStream...
> // use FOP TTF reader or delegate to the AWT font.
> }
>
> class fop.font.PDFBuiltinFont implements fop.font.Font {
> public InputStream getFontInputStream() { return null; }
> public awt.Font getAWTFont() { return null;}
> // return generated classes for metrics etc.
> }
>
> This means users can use AWT fonts for creating PDF, but they can't
> embed them. This may cause the resulting PDF to fail, but so what.
--> Support questions
And there's still the question if we can produce font metric information
for the target formats (there's PCL and PostScript and..., too) that
result in the desired output.
> We *could* try to use the TTF reader to search through the fonts
> in the Windows font directory (or XFonts) in order to find the
> file for an AWT font.
Yeah, but it will be sooooo slow. You'd need some persistent cache to
overcome that.
Seriously, I don't think working with AWT's Font will do us any good.
The differences between JDKs are too great.
We need java.awt.Font objects for the Java2D-related renderers, but
producing/getting these objects is the renderer's job, just as it's the
PDFRenderer's job to produce PDF font objects for serialization. IMO
it's better to have full control over what happens.
Jeremias Maerki
Re: Font variant SmallCaps Was: Re: (Chris) Re: Traits
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Victor Mote wrote:
> Yes, this can get ugly. If anybody knows of a way to find the physical font
> file from an awt Font object, please speak up.
Currently (as of 1.4.1 you can create a awt.Font from an InputStream, but
you cant get back whatever physical representation the font has from
the awt.Font object.
I thought of the following approach
interface fop.font.Font {
public InputStream getFontInputStream();
public awt.Font getAWTFont();
// duplicate AWT methods, with certain stuff like metrics
// replaced with FOP objects
}
class fop.font.AWTFont implements fop.font.Font {
// delegate to AWT font
// encapsulate awt.FontMetric in FOP font metric
public InputStream getFontInputStream() { return null; }
}
class fop.font.Type1Font implements fop.font.Font {
public awt.Font getAWTFont() { return null;}
// use FOP type 1 font reader
}
class fop.font.TrueTypeFont implements fop.font.Font {
public awt.Font getAWTFont() { return new Font(new FileInputStream...);}
// use FOP TTF reader or delegate to the AWT font.
}
class fop.font.PDFBuiltinFont implements fop.font.Font {
public InputStream getFontInputStream() { return null; }
public awt.Font getAWTFont() { return null;}
// return generated classes for metrics etc.
}
This means users can use AWT fonts for creating PDF, but they can't
embed them. This may cause the resulting PDF to fail, but so what.
We *could* try to use the TTF reader to search through the fonts
in the Windows font directory (or XFonts) in order to find the
file for an AWT font.
J.Pietschmann
RE: Font variant SmallCaps Was: Re: (Chris) Re: Traits
Posted by Victor Mote <vi...@outfitr.com>.
Peter B. West wrote:
> I'm fuzzy with this stuff, but isn't renderer-context a new notion?
> What you are calling renderer-context was previously only associated
> with the renderer as such, wasn't it? I'm assuming that the
> renderer-context is something that amalgamates font metrics. Renderers
> share a context if, among other things, their fonts share common
> metrics. Is this what you mean?
Yes, pretty much. I had pushed a bit to try to make render context one of
the high-level control objects, with the idea that the Area Tree could be
reused by additional renderers.
> > Another idea on the AWT font issue is to allow the user to register the
> > location of the AWT font just like they would any other font.
> This would be
> > equivalent to saying "use the AWT metrics for this font, but get the
> > physical font from a certain file". The problem there is, of
> course, that
> > you introduce another possible layer of errors (can find the
> AWT metrics but
> > not the physical file, or vice versa), but I think that would be quite
> > managable.
> >
>
> Speaking of errors: can find the AWT metrics, but they don't match the
> metrics of the font file.
Yes, this can get ugly. If anybody knows of a way to find the physical font
file from an awt Font object, please speak up. That is the only correct
solution to this problem.
Victor Mote
Re: Font variant SmallCaps Was: Re: (Chris) Re: Traits
Posted by "Peter B. West" <pb...@powerup.com.au>.
Victor Mote wrote:
>
> I am confused by the distinction that you make between fop.PDFFont and
> fop.Type1Font. In my mind, there is no such concept as a fop.PDFFont, unless
> it is a renderer-specific class for getting a Type1Font (for example) into
> the PDF output. But I think that should be a method in the Type1Font class.
> I have spent more time than I should have trying to figure out why fonts are
> (or were) renderer-specific. I may still be missing something important. (I
> *do* understand why they are renderer-context specific, i.e the difference
> between the AWT context and the others).
I'm fuzzy with this stuff, but isn't renderer-context a new notion?
What you are calling renderer-context was previously only associated
with the renderer as such, wasn't it? I'm assuming that the
renderer-context is something that amalgamates font metrics. Renderers
share a context if, among other things, their fonts share common
metrics. Is this what you mean?
> Another idea on the AWT font issue is to allow the user to register the
> location of the AWT font just like they would any other font. This would be
> equivalent to saying "use the AWT metrics for this font, but get the
> physical font from a certain file". The problem there is, of course, that
> you introduce another possible layer of errors (can find the AWT metrics but
> not the physical file, or vice versa), but I think that would be quite
> managable.
>
Speaking of errors: can find the AWT metrics, but they don't match the
metrics of the font file.
p
--
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
RE: Font variant SmallCaps Was: Re: (Chris) Re: Traits
Posted by Victor Mote <vi...@outfitr.com>.
J.Pietschmann wrote:
> I believe we should just define a fop.Font interface which is
> the same as awt.Font, then provide implementations fop.AWTFont,
> fop.PDFFont (well all the variations), fop.Type1Font etc. A
> configurable selector (an Avalon selector) could selcet them.
> This way people could use AWT fonts without a hassle, with the
> small disadvantage that they can't be embedded.
>
> Jeremias, as the resident font guru, what do you think?
I am confused by the distinction that you make between fop.PDFFont and
fop.Type1Font. In my mind, there is no such concept as a fop.PDFFont, unless
it is a renderer-specific class for getting a Type1Font (for example) into
the PDF output. But I think that should be a method in the Type1Font class.
I have spent more time than I should have trying to figure out why fonts are
(or were) renderer-specific. I may still be missing something important. (I
*do* understand why they are renderer-context specific, i.e the difference
between the AWT context and the others).
Another idea on the AWT font issue is to allow the user to register the
location of the AWT font just like they would any other font. This would be
equivalent to saying "use the AWT metrics for this font, but get the
physical font from a certain file". The problem there is, of course, that
you introduce another possible layer of errors (can find the AWT metrics but
not the physical file, or vice versa), but I think that would be quite
managable.
I think the approach that you are recommending is roughly what Jeremias has
suggested for fonts in general, and which I can live with as long as we
essentially make everything but the interface protected. I think you still
need to have a third class that sits between awt.Font and fop.Font, because
there is no way to tell awt.Font to implement the fop.Font interface. I
favored a concrete class with a method that did the selection, which seemed
cleaner to my mind, but I see the benefits to the other approach.
Victor Mote
Re: Font variant SmallCaps Was: Re: (Chris) Re: Traits
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Victor Mote wrote:
> Same general concept, except I think there is a separate class for font
> metrics in that system. If I can ever find a way to get to the physical file
> (or some representation of it) through java.awt.Font (for embedding), we
> would use it along with our other font scheme.
I believe we should just define a fop.Font interface which is
the same as awt.Font, then provide implementations fop.AWTFont,
fop.PDFFont (well all the variations), fop.Type1Font etc. A
configurable selector (an Avalon selector) could selcet them.
This way people could use AWT fonts without a hassle, with the
small disadvantage that they can't be embedded.
Jeremias, as the resident font guru, what do you think?
J.Pietscmann
RE: Font variant SmallCaps Was: Re: (Chris) Re: Traits
Posted by Victor Mote <vi...@outfitr.com>.
J.Pietschmann wrote:
> Victor Mote wrote:
> > No. Courier-Bold-Italic would be the Typeface, Courier would be the
> > TypefaceFamily. So my Font object that gets used by FOP would be
> > Courier-Bold-Italic at 12 points. It has a parent Typeface,
> which represents
> > the Courier-Bold "font" file and its contents. This typeface
> has a parent
> > TypefaceFamily, which represents the Courier family, and knows
> how to find
> > bold, italic, small-caps, etc. Typefaces which are related.
>
> So your font is the same as an java.awt.Font?
Same general concept, except I think there is a separate class for font
metrics in that system. If I can ever find a way to get to the physical file
(or some representation of it) through java.awt.Font (for embedding), we
would use it along with our other font scheme.
Victor Mote
Re: Font variant SmallCaps Was: Re: (Chris) Re: Traits
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Victor Mote wrote:
> No. Courier-Bold-Italic would be the Typeface, Courier would be the
> TypefaceFamily. So my Font object that gets used by FOP would be
> Courier-Bold-Italic at 12 points. It has a parent Typeface, which represents
> the Courier-Bold "font" file and its contents. This typeface has a parent
> TypefaceFamily, which represents the Courier family, and knows how to find
> bold, italic, small-caps, etc. Typefaces which are related.
So your font is the same as an java.awt.Font?
> So, during FO Tree construction, when a small-caps font is requested by the
> source document, FOP tries to find the small-caps variant for the Typeface
> (by looking at the parent TypefaceFamily). If it exists, it assigns that. If
> not, it uses the regular variant with an emulation on the point size, and
> assigns that. Everything downstream just knows to use that Font, doesn't
> need to know why. It sounds like we agree on all of this.
No problem.
J.Pietschmann
RE: Font variant SmallCaps Was: Re: (Chris) Re: Traits
Posted by Victor Mote <vi...@outfitr.com>.
Victor Mote wrote:
> > Victor Mote wrote:
> > > Typeface roughly corresponds to what is contained in a ttf of
> > pfa font file.
> >
> > Hm hm. A TTF is typically Courier-bold-italic or so. Did you mean this
> > or rather typeface==font-family?
>
> No. Courier-Bold-Italic would be the Typeface, Courier would be the
> TypefaceFamily. So my Font object that gets used by FOP would be
> Courier-Bold-Italic at 12 points. It has a parent Typeface, which
> represents
> the Courier-Bold "font" file and its contents. This typeface has a parent
^^^^^^^^^^^^
Sorry--this should say Courier-Bold-Italic.
Victor Mote
RE: Font variant SmallCaps Was: Re: (Chris) Re: Traits
Posted by Victor Mote <vi...@outfitr.com>.
J.Pietschmann wrote:
> Victor Mote wrote:
> > Typeface roughly corresponds to what is contained in a ttf of
> pfa font file.
>
> Hm hm. A TTF is typically Courier-bold-italic or so. Did you mean this
> or rather typeface==font-family?
No. Courier-Bold-Italic would be the Typeface, Courier would be the
TypefaceFamily. So my Font object that gets used by FOP would be
Courier-Bold-Italic at 12 points. It has a parent Typeface, which represents
the Courier-Bold "font" file and its contents. This typeface has a parent
TypefaceFamily, which represents the Courier family, and knows how to find
bold, italic, small-caps, etc. Typefaces which are related.
So, during FO Tree construction, when a small-caps font is requested by the
source document, FOP tries to find the small-caps variant for the Typeface
(by looking at the parent TypefaceFamily). If it exists, it assigns that. If
not, it uses the regular variant with an emulation on the point size, and
assigns that. Everything downstream just knows to use that Font, doesn't
need to know why. It sounds like we agree on all of this.
Victor Mote
Re: Font variant SmallCaps Was: Re: (Chris) Re: Traits
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Victor Mote wrote:
> Typeface roughly corresponds to what is contained in a ttf of pfa font file.
Hm hm. A TTF is typically Courier-bold-italic or so. Did you mean this
or rather typeface==font-family?
> I don't understand what you are saying here. If emulation is used, it should
> probably at least be logged. Alternatively, a config option could control
> whether this is allowed at all. But I don't follow at all what you are
> suggesting with the renderer using the font to control the emulation. How
> does layout get done at all then? And what is the advantage over simply
> establishing the emulation in the FO Tree itself?
The layout gets the metric from a FOP font structure, and it doesn't have
to know whether the font is a true small caps font or emulates it.
During rendering, of course, emulation has to take effect.
Well, on a secont thought there is not much difference from emulating
small caps before layout.
Of course it makes sense to log if small caps is emulated.
J.Pietschmann
RE: Font variant SmallCaps Was: Re: (Chris) Re: Traits
Posted by Victor Mote <vi...@outfitr.com>.
J.Pietschmann wrote:
> > (Still not making sense? If you need any more intermediate steps in
> > understanding how getters and setters actually make things
> work, we're just
> > a message away ;) )
>
> Dunno. Let me elaborate.
> We have
> FO -> FOP layout -> FOP renderer -> output
> Font variant SmallCaps can be implemented in several ways
> - Get a SmallCaps font and use it. The handling is the same as
> for bold and italic (or "font-weight" and "font-style")
> - Emulate by uppercasing lowercase characters and set an 80%
> size font for them before the text is laid out (maintenance
> branch implementation)
> - pass the attribute into the renderer or into the output and
> let them care for themself
>
> The layout needs font metrics, therefore from the point of view
> of the layout the first and third option are the same.
> The interesting point is whether option 2 is implemented, somewhere
> in the pipeling before individual character widths are used (and,
> if necessary, character height), or whether the layout can get its
> metrics form a FOP Font structure (FontState or whatever it is called
> now).
The new logic that I envision on Fonts (subject to Jeremias' approval
especially, and everyone else's in general) makes a distinction between
Typeface and Font. A Font is a Typeface rendered at a specific point size. A
Typeface roughly corresponds to what is contained in a ttf of pfa font file.
So when a Font object is tied to an object, it can handle both cases fine.
The FO Tree logic that determines which font object to use will have to
determine whether a true small-caps typeface exists for the TypefaceFamily,
and act accordingly. But everything downstream from there can simply use the
stored Font object.
> If the font approach is used, we need "font variant" to be a font
> attribute. I'm too lazy to check whether this is already in place.
> The maintenance code didn't have it.
I don't think it is. The idea is to have a TypeFaceFamily object that knows
the relationship between the variations of the Typeface (i.e. bold, italic,
small-caps). So each Font belongs to a Typeface, which in turn belongs to a
TypeFaceFamily. So referencing a parent TypeFaceFamily can determine whether
there is a related small-caps Typeface.
> The advantage of this approach compared to the "early emulation"
> approach is that if a user has a true small caps font, he can use
> it more easily. For FOP, there is still the problem what to do if
> there is no appropriate font. Just bailing out might be an idea,
> but not necessarily a good one. An alternative would be to let the
> emulation happen under control of the font, in the renderer. This
> would need some hooks which don't exist yet, because the emulation
> must be able to insert the font size change into the output.
I don't understand what you are saying here. If emulation is used, it should
probably at least be logged. Alternatively, a config option could control
whether this is allowed at all. But I don't follow at all what you are
suggesting with the renderer using the font to control the emulation. How
does layout get done at all then? And what is the advantage over simply
establishing the emulation in the FO Tree itself?
> Now the questions is: how should the implementation look in HEAD?
> I personally like the font+late emulation approach.
>
> J.Pietschmann
Victor Mote