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
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
Andreas L. Delmelle wrote:
-Original Message-
From: J.Pietschmann [mailto:[EMAIL PROTECTED]
Having "getters" and "setters" for a property and an actual implementation
getting the work done are different things... unless you men
something else.
The objects to which this particular FO prope
> -Original Message-
> From: J.Pietschmann [mailto:[EMAIL PROTECTED]
>
> Having "getters" and "setters" for a property and an actual implementation
> getting the work done are different things... unless you men
> something else.
>
The objects to which this particular FO property applies wo
From: "J.Pietschmann" <[EMAIL PROTECTED]>
Chris Bowditch wrote:
Centering seems to be off by just one character.
Well, the errorneously unstripped space...
Yes I was agreeing with you here.
text justification
combination of
LineLayoutManager.getNextBreakPoss and
LineLayoutManager.makeLineBreak
C
Chris Bowditch wrote:
Centering seems to be off by just one character.
Well, the errorneously unstripped space...
text justification
combination of
LineLayoutManager.getNextBreakPoss and
LineLayoutManager.makeLineBreak
Close but no cigar. In getNextBreakPoss, the code handles lines
which are last
Andreas L. Delmelle wrote:
Now, since the other thread (between
John, Peter & yourself) mentioned getter and setter methods WRT property
management, and font-variant is a property --Would it be correct to assume
that such getters and setters would still have to be added in relevant
classes? (Apart
> -Original Message-
> From: Victor Mote [mailto:[EMAIL PROTECTED]
>
> Andreas L. Delmelle wrote:
>
> > 0.20.5; absent in HEAD --browsing through CVS indicates Victor
> could add a
> > few comments on what would need to be done to complete this particular
> > issue. In fact, I already read
Andreas L. Delmelle wrote:
> Just adding this so it might save you a (wee) bit of time:
>
> I did a quick lookup for this, comparing 0.20.5 with HEAD, following
> difference immediately caught my eye: class layout.FontState. (defined in
> 0.20.5; absent in HEAD --browsing through CVS indicates Vic
From: "J.Pietschmann" <[EMAIL PROTECTED]>
Glen Mazza wrote:
1.) The "Extensible Markup Language 1.0" title (the
one with a blue background) it not centered properly
within the block. This is probably an issue within
PDFRenderer.java renderText() function.
This may be due to unstripped spaces, se
Glen Mazza wrote:
1.) The "Extensible Markup Language 1.0" title (the
one with a blue background) it not centered properly
within the block. This is probably an issue within
PDFRenderer.java renderText() function.
This may be due to unstripped spaces, see next point.
In any case, justified text
> -Original Message-
> From: Chris Bowditch [mailto:[EMAIL PROTECTED]
> I'll definitely add (1) and (3) to my todo list and take a look probably
later in the week.
>
Just adding this so it might save you a (wee) bit of time:
I did a quick lookup for this, comparing 0.20.5 with HEAD, foll
From: Glen Mazza <[EMAIL PROTECTED]>
I wouldn't worry too much about that. I believe
methods themselves don't take up that much memory--and
to a certain degree, we're supposed to be a "reference
implementation"--so methods not relevant for all
instances of a certain base class should not be
def
30 matches
Mail list logo
