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 Simon Pepping <sp...@leverkruid.nl> on 2003/11/21 20:20:58 UTC
Re: Font variant SmallCaps
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
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>