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 s
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
> > speci
On 27.11.2003 17:30:18 J.Pietschmann wrote:
> Jeremias Maerki wrote:
> >>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 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, bu
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 wha
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 o
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
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 th
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 cou
(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
suppor
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 w
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
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 par
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, C
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 b
From: "J.Pietschmann" <[EMAIL PROTECTED]>
I have done some investigation into emulating the Font-variant stuff in a
similar way to the maintenance branch.
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-itali
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 l
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 varian
18 matches
Mail list logo