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
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,
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
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
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
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:
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
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
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
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
(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
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
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-italic
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
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
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
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
17 matches
Mail list logo
