st: Making an integration of Foray into my JAFOP thingy. I'm quite
interested in comparing FOP 1.0dev with other implementations as I go.
Gotta find some time...
On 04.02.2005 18:04:24 Victor Mote wrote:
> Jeremias Maerki wrote:
>
> > Chapter 4.2.2 Common Traits defines fou
COMPLETELY OT...
On Feb 4, 2005, at 9:04 AM, Victor Mote wrote:
Jeremias Maerki wrote:
I don't share his opinion on point 3 because whenever we have
a change in reference-orientation we also have a new
reference-area which establishes a new coordinate system. So
I don't think it will be complicate
Jeremias Maerki wrote:
> Chapter 4.2.2 Common Traits defines four traits
> (top-position, bottom-position, left-position,
> right-position) which describes the placement of areas within
> the nearest ancestor reference-area (or the
> page-viewport-area). We don't use thes
Well, this might have been a bit premature. The change necessary
actually fixed a bug in AbstractRenderer, but still it might be worth
discussing the point.
On 04.02.2005 15:51:58 Jeremias Maerki wrote:
> Team,
>
> Chapter 4.2.2 Common Traits defines four traits (top-position,
> bot
Team,
Chapter 4.2.2 Common Traits defines four traits (top-position,
bottom-position, left-position, right-position) which describes the
placement of areas within the nearest ancestor reference-area (or the
page-viewport-area). We don't use these trait but recreate the placement
of indiv
--- Finn Bock <[EMAIL PROTECTED]> wrote:
>
> > We've been doing the same with PR_ (properties)
> and
> > FO_ (FO's) for quite some time.
>
> To avoid a name conflict somewhere.
>
Yes, I was wondering why you didn't originally do that
for the enumeration constants as well. I like their
self-d
[Glen]
2.) Appended EN_ to enumeration constants to
[J.Pietschmann]
Yuk. Having a large number of identifiers in the
same scope with
an identical prefix isn't very good for
autocompletion both in
Emacs and Eclipse.
[Glen]
We've been doing the same with PR_ (properties) and
FO_ (FO's) for quite so
--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > gmazza 2004/11/24 13:07:31
> > 2.) Appended EN_ to enumeration constants to
> make them better S&R'able throughout app.
>
> Yuk. Having a large number of identifiers in the
> same scope with
> an identical prefix
[EMAIL PROTECTED] wrote:
gmazza 2004/11/24 13:07:31
2.) Appended EN_ to enumeration constants to make them better S&R'able
throughout app.
Yuk. Having a large number of identifiers in the same scope with
an identical prefix isn't very good for autocompletion both in
Emacs and Eclipse. I als
jeremias2004/02/27 09:56:25
Modified:src/java/org/apache/fop/traits BlockProps.java
BorderProps.java InlineProps.java LayoutProps.java
MinOptMax.java SpaceVal.java
Log:
Applied Apache License Version 2.0 by following the instructions
TableLayoutManager.java
src/java/org/apache/fop/render/rtf RTFHandler.java
src/java/org/apache/fop/traits BlockProps.java
Log:
Use the new property expressions. Clients must use Length when retrieving
a length and must delay the call to Length.getValue() until the
/traits SpaceVal.java
Added: src/java/org/apache/fop/fo/properties AutoLength.java
CharacterProperty.java ColorTypeProperty.java
CondLengthProperty.java EnumProperty.java
FixedLength.java KeepProperty.java
TextAttributesConverter.java
src/java/org/apache/fop/traits SpaceVal.java
Removed: src/java/org/apache/fop/datatypes CondLength.java Keep.java
LengthPair.java LengthRange.java Space.java
src/java/org/apache/fop/fo/expr Numeric.java
/java/org/apache/fop/render/rtf RTFHandler.java
TableAttributesConverter.java
TextAttributesConverter.java
src/java/org/apache/fop/traits LayoutProps.java
SpaceVal.java
Added: src/codegen prop-val-enum
Victor Mote wrote:
Glen Mazza wrote:
...
(2.) Just as an FYI, as to the issue of whether the
FO's themselves have traits--from our previous
discussion, you were saying that elements have
attributes, FOs have properties and Area Tree elements
have traits, I believe. That fact is confirmed i
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
Sorry for the delay, Chris. BTW, I'm thrilled you're
taking an interest in layout--let's get some patches
from you so we can get you up to committer status!
--- Chris Bowditch <[EMAIL PROTECTED]> wrote:
> Wouldnt want to have to
> replicate these
> functions on every sub-class of Area.
I wou
Glen Mazza wrote:
Are we sure it should return 0? Shouldn't there be a
difference between "no value" given, and a value of
"0" given, esp. in cases when you need to calculate
inheritance?
The spec uses "trait" for a resolved property. There is
no inheritance
Glen Mazza wrote:
> I think we moved from int-->Integer for properties
> just recently (Victor did, I believe, in prodding from
> Peter Herweg?) because we precisely need NULLs to be
> returned sometime. (0 won't always be correct.)
That was only in the RTF Renderer -- it didn't affect the FO Tr
pacingBefore() to the Area class, which is the
container for Traits anyway. Wouldnt want to have to replicate these
functions on every sub-class of Area. OTOH not every class that derives from
Area will have Padding and spacing attributes.
What do you th
Are we sure it should return 0? Shouldn't there be a
difference between "no value" given, and a value of
"0" given, esp. in cases when you need to calculate
inheritance? I think so...
I think we moved from int-->Integer for properties
just recently (Victor did, I believe, in prodding from
Peter H
Fop Devs,
one thing I did notice was a small deficiency in Area.getTraitAsInteger().
If the Trait hasnt been set, i.e. the call to getTrait returns null, then an
exception gets thrown. When Padding is present it is perfectly valid as an
Integer, so the method should NOT throw an exception sayin
gmazza 2003/11/05 15:48:47
Modified:src/java/org/apache/fop/fo/properties CommonBackground.java
CommonBorderAndPadding.java
src/java/org/apache/fop/traits LayoutProps.java
SpaceVal.java
Log:
toString() methods
Row.java
TableAndCaptionLayoutManager.java
TableLayoutManager.java
src/java/org/apache/fop/traits SpaceVal.java
Added: src/java/org/apache/fop/traits MinOptMax.java
Removed: src/java/org/apache/fop/layoutmgr MinOptMax.java
Log
jeremias2003/03/11 04:52:25
xml-fop/src/java/org/apache/fop/traits - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
jeremias2003/03/07 02:09:40
Modified:src/org/apache/fop/traits InlineProps.java LayoutProps.java
BlockProps.java BorderProps.java
Log:
Switched to long licence
Some general checkstyle fixing
Revision ChangesPath
1.2 +49 -8 xml-fop/src
TableAndCaptionLayoutManager.java
TableLayoutManager.java
src/org/apache/fop/traits SpaceVal.java
Added: src/org/apache/fop/layoutmgr MinOptMax.java
Removed: src/org/apache/fop/area MinOptMax.java
Log:
moved MinOptMax
BasicLink.java
src/org/apache/fop/pdf PDFDocument.java PDFGoTo.java
PDFPage.java
src/org/apache/fop/render/pdf PDFRenderer.java
src/org/apache/fop/svg PDFGraphics2D.java
src/org/apache/fop/traits BorderProps.java
Log
I'd like to ask some questions that came up when I was trying to
understand the redesigned code.
1. Some traits have been implemented (eg font-size) and others have not.
For example the traits is-reference-area and is-viewport-area: Will they
be implemented eventually or is it the idea
src/org/apache/fop/traits BorderProps.java
Log:
Separate Position from BreakPoss and create Leaf and NonLeafPosition classes.
Move management of Trait to top level Area class and use HAshMap instead of List.
Generalize handling of Trait in XMLRenderer and AreaTreeBuilder.
Improve handling
LineLayoutManager.java SpaceSpecifier.java
Added: src/org/apache/fop/traits BlockProps.java InlineProps.java
LayoutProps.java SpaceVal.java
Log:
Add BreakPossibility style LayoutManager code as an alternative to
Keiron's "direct area creation&qu
klease 02/04/28 14:20:13
xml-fop/src/org/apache/fop/traits - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
61 matches
Mail list logo
