Re: Start using *-position traits?

[Jeremias Maerki]

Thanks for sharing your thoughts, Victor. For the moment I've got my
issue solved but as I already said, it may be beneficial to reconsider
the approach here. I'll wait and see what the others have to say about
it.

You popping up again reminds me that I still have an issue on my task
list: 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 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 individual areas in the renderer (actually 
> > and effectively in each
> > (!) renderer). I wondered a few times during the last month 
> > if we should have the layout manager handle the calculation 
> > of the coordinates. This has a few advantages:
> > - All layout is really in the layout managers.
> > - Each renderer really only paints the areas in the place it 
> > is told to.
> > 
> > The obvious disadvantage is the effort needed to write the 
> > code that generates these traits in all layout managers.
> > 
> > The reason I'm bringing this up now is my attempt to 
> > implement table row backgrounds where I don't manage to place 
> > the background areas in the right places due to placement 
> > logic in the renderer(s). Of course, there are work-arounds 
> > and I only have to fix AbstractRenderer in this case but it 
> > doesn't feel right. There's already enough placement logic in 
> > the PDFRenderer which needs to be duplicated in all other 
> > renderers. I can also remember the synchronization effort 
> > when I wrote the original PSRenderer.
> > 
> > I think it would also simplify the renderers itself, making 
> > it easier to develop a new one, if we started using 
> > left-position and top-position traits. The other two may be 
> > necessary as soon as there's more effort towards implementing 
> > writing-modes.
> > 
> > Keiron responded to a similar question in 2002:
> > http://nagoya.apache.org/eyebrowse/BrowseList?listName=fop-dev
> @xml.apache.org&by=thread&from=214823
> > 
> > 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 complicated to calculate the right 
> > coordinates. But I may be wrong.
> > 
> > Opinions?
> 
> Hi Jeremias:
> 
> It is fascinating to me how many times you and I happen to be working on
> exactly the same issue, as we are right now. FWIW, the FOray approach is as
> follows: Areas do not store any location information at all. The only size
> information stored is a "progressionDimension" value and a value for the
> resolved "anteriorSpace". This is enough information, however, for each Area
> to compute and return to the Renderer where it should be rendered. Every
> Area either is or has an ancestor area that knows intrinsically what its
> location is just from its properties. Every Area knows its own IPD and BPD.
> So by considering the progressionDimension and anteriorSpace (the resolved
> value of space-before/after or space-start/end) of other Areas already
> stacked in the containing Area, any Area knows its location.
> 
> Keiron is right that the computations are tricky for changes in
> reference-orientation and writing-mode, but I think dealing with them in the
> Area tree once is much easier than any other approach I can imagine. My code
> currently has the various writing-modes handled correctly (I think), but
> doesn't yet deal with changes in writing-mode or reference-orientation. The
> main reason I haven't tackled that yet is that I am still trying to decide
> how much of that work belongs in Area Tree and how much needs to be
> considered Renderer-specific. 
> 
> With this scheme, Layout never has to worry about location, orientation, or
> writing-mode, only sizes (IPD and BPD). Renderers don't have to compute any
> of them either, they just ask each Area where it wants to be rendered.
> 
> In short, I think you are very much on the right track here. One caveat: I
> don't have all of my stuff working yet, so there may be a gotcha that I
> haven't thought of.
> 
> If these comments are not helpful, please let me know. I don't mean to
> generate noise -- I just like to support good ideas when I see them.
> 
> Victor Mote



Jeremias Maerki

Glad you're still here! (was Re: Start using *-position traits?)

[The Web Maestro]

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 complicated to calculate the right
coordinates. But I may be wrong.
Opinions?
Hi Jeremias:
It is fascinating to me how many times you and I happen to be working 
on
exactly the same issue, as we are right now. FWIW, the FOray approach 
is as
follows: Areas do not store any location information at all. The only 
size
information stored is a "progressionDimension" value and a value for 
the
resolved "anteriorSpace". This is enough information, however, for 
each Area
to compute and return to the Renderer where it should be rendered. 
Every
Area either is or has an ancestor area that knows intrinsically what 
its
location is just from its properties. Every Area knows its own IPD and 
BPD.
So by considering the progressionDimension and anteriorSpace (the 
resolved
value of space-before/after or space-start/end) of other Areas already
stacked in the containing Area, any Area knows its location.

If these comments are not helpful, please let me know. I don't mean to
generate noise -- I just like to support good ideas when I see them.
Victor Mote
COMPLETELY OT:
I just wanted to say, that I'm impressed with your ability and desire 
to continue working with us Victor. I was disappointed with your 
decision to go your own way (foray out on your own as it were ;-)), but 
I think that we are all really benefitting from the experience... I am 
grateful that you continue to contribute to the FOP community, and look 
forward to your continued contributions. Occasionally there will be 
growing pains, as we figure out what our relationship is... I sincerely 
hope that we can some day find a way to bring your work back  into the 
Apache FOP fold (either in some sort of renderer or modular sort of way 
or... who knows.

Thanks for being here!
Web Maestro Clay
--
<[EMAIL PROTECTED]> - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

RE: Start using *-position traits?

[Victor Mote]

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 these trait but recreate 
> the placement of individual areas in the renderer (actually 
> and effectively in each
> (!) renderer). I wondered a few times during the last month 
> if we should have the layout manager handle the calculation 
> of the coordinates. This has a few advantages:
> - All layout is really in the layout managers.
> - Each renderer really only paints the areas in the place it 
> is told to.
> 
> The obvious disadvantage is the effort needed to write the 
> code that generates these traits in all layout managers.
> 
> The reason I'm bringing this up now is my attempt to 
> implement table row backgrounds where I don't manage to place 
> the background areas in the right places due to placement 
> logic in the renderer(s). Of course, there are work-arounds 
> and I only have to fix AbstractRenderer in this case but it 
> doesn't feel right. There's already enough placement logic in 
> the PDFRenderer which needs to be duplicated in all other 
> renderers. I can also remember the synchronization effort 
> when I wrote the original PSRenderer.
> 
> I think it would also simplify the renderers itself, making 
> it easier to develop a new one, if we started using 
> left-position and top-position traits. The other two may be 
> necessary as soon as there's more effort towards implementing 
> writing-modes.
> 
> Keiron responded to a similar question in 2002:
> http://nagoya.apache.org/eyebrowse/BrowseList?listName=fop-dev
@xml.apache.org&by=thread&from=214823
> 
> 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 complicated to calculate the right 
> coordinates. But I may be wrong.
> 
> Opinions?

Hi Jeremias:

It is fascinating to me how many times you and I happen to be working on
exactly the same issue, as we are right now. FWIW, the FOray approach is as
follows: Areas do not store any location information at all. The only size
information stored is a "progressionDimension" value and a value for the
resolved "anteriorSpace". This is enough information, however, for each Area
to compute and return to the Renderer where it should be rendered. Every
Area either is or has an ancestor area that knows intrinsically what its
location is just from its properties. Every Area knows its own IPD and BPD.
So by considering the progressionDimension and anteriorSpace (the resolved
value of space-before/after or space-start/end) of other Areas already
stacked in the containing Area, any Area knows its location.

Keiron is right that the computations are tricky for changes in
reference-orientation and writing-mode, but I think dealing with them in the
Area tree once is much easier than any other approach I can imagine. My code
currently has the various writing-modes handled correctly (I think), but
doesn't yet deal with changes in writing-mode or reference-orientation. The
main reason I haven't tackled that yet is that I am still trying to decide
how much of that work belongs in Area Tree and how much needs to be
considered Renderer-specific. 

With this scheme, Layout never has to worry about location, orientation, or
writing-mode, only sizes (IPD and BPD). Renderers don't have to compute any
of them either, they just ask each Area where it wants to be rendered.

In short, I think you are very much on the right track here. One caveat: I
don't have all of my stuff working yet, so there may be a gotcha that I
haven't thought of.

If these comments are not helpful, please let me know. I don't mean to
generate noise -- I just like to support good ideas when I see them.

Victor Mote

Re: Start using *-position traits?

[Jeremias Maerki]

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,
> 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 individual areas in the renderer (actually and effectively in each 
> (!) renderer). I wondered a few times during the last month if we should
> have the layout manager handle the calculation of the coordinates. This
> has a few advantages:
> - All layout is really in the layout managers.
> - Each renderer really only paints the areas in the place it is told to.
> 
> The obvious disadvantage is the effort needed to write the code that
> generates these traits in all layout managers.
> 
> The reason I'm bringing this up now is my attempt to implement table row
> backgrounds where I don't manage to place the background areas in the
> right places due to placement logic in the renderer(s). Of course, there
> are work-arounds and I only have to fix AbstractRenderer in this case
> but it doesn't feel right. There's already enough placement logic in the
> PDFRenderer which needs to be duplicated in all other renderers. I can
> also remember the synchronization effort when I wrote the original
> PSRenderer.
> 
> I think it would also simplify the renderers itself, making it easier to
> develop a new one, if we started using left-position and top-position
> traits. The other two may be necessary as soon as there's more effort
> towards implementing writing-modes.
> 
> Keiron responded to a similar question in 2002:
> http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&by=thread&from=214823
> 
> 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
> complicated to calculate the right coordinates. But I may be wrong.
> 
> Opinions?


Jeremias Maerki

Start using *-position traits?

[Jeremias Maerki]

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 individual areas in the renderer (actually and effectively in each 
(!) renderer). I wondered a few times during the last month if we should
have the layout manager handle the calculation of the coordinates. This
has a few advantages:
- All layout is really in the layout managers.
- Each renderer really only paints the areas in the place it is told to.

The obvious disadvantage is the effort needed to write the code that
generates these traits in all layout managers.

The reason I'm bringing this up now is my attempt to implement table row
backgrounds where I don't manage to place the background areas in the
right places due to placement logic in the renderer(s). Of course, there
are work-arounds and I only have to fix AbstractRenderer in this case
but it doesn't feel right. There's already enough placement logic in the
PDFRenderer which needs to be duplicated in all other renderers. I can
also remember the synchronization effort when I wrote the original
PSRenderer.

I think it would also simplify the renderers itself, making it easier to
develop a new one, if we started using left-position and top-position
traits. The other two may be necessary as soon as there's more effort
towards implementing writing-modes.

Keiron responded to a similar question in 2002:
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&by=thread&from=214823

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
complicated to calculate the right coordinates. But I may be wrong.

Opinions?

Jeremias Maerki

Re: cvs commit: xml-fop/src/java/org/apache/fop/traits LayoutProps.java SpaceVal.java

[Glen Mazza]

--- 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-documenting value in particular though.

> How about having 3 interfaces: 'Properties',
> 'Elements' and 'Enums' 
> which contains the constants without any prefix. And
> then decide that 
> these interfaces are never implemented, but the
> constants are always 
> accessed using the interface name:
>  Enums.TRUE
> 
> That would keep the searchability and perhaps even
> help us when (if) we 
> move to typesafe enums.
> 

-0.  I prefer the simplicity of the current method,
and like the way the code looks as-is.  But I can
easily see how others may view this solution as more
professional.

Glen

Re: cvs commit: xml-fop/src/java/org/apache/fop/traits LayoutProps.java SpaceVal.java

[Finn Bock]

[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 some time.  
To avoid a name conflict somewhere.
After hitting the
EN_, you're at the same place you would be without the
prefix.  Furthermore, you can now hunt away for your
enumeration constants without them being intermixed
with the PR_'s and FO_'s.
It was also a commenting issue:  TRUE and FALSE, for
example, without a prefix, just weren't self
documenting enough to emphasize that we're working
with enumeration constants here.  (Remember, we
removed the old interfaces--per your desire as well as
mine--such as WritingMode.LR_TB or whatever that
previously provided that emphasis.)
How about having 3 interfaces: 'Properties', 'Elements' and 'Enums' 
which contains the constants without any prefix. And then decide that 
these interfaces are never implemented, but the constants are always 
accessed using the interface name:
Enums.TRUE

That would keep the searchability and perhaps even help us when (if) we 
move to typesafe enums.

regards,
finn

Re: cvs commit: xml-fop/src/java/org/apache/fop/traits LayoutProps.java SpaceVal.java

[Glen Mazza]

--- "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 isn't very good for
> autocompletion both in
> Emacs and Eclipse. 

We've been doing the same with PR_ (properties) and
FO_ (FO's) for quite some time.  After hitting the
EN_, you're at the same place you would be without the
prefix.  Furthermore, you can now hunt away for your
enumeration constants without them being intermixed
with the PR_'s and FO_'s.

It was also a commenting issue:  TRUE and FALSE, for
example, without a prefix, just weren't self
documenting enough to emphasize that we're working
with enumeration constants here.  (Remember, we
removed the old interfaces--per your desire as well as
mine--such as WritingMode.LR_TB or whatever that
previously provided that emphasis.)


> I also don't quite get the point
> about the
> better S&R'ability.
> 

Because it gives us a very convenient handle ("EN_")
to identify all the places where enumeration constants
are currently being used.  So if we wanted to switch
from "EN_", to "ENUM_", it would just be a quick S&R. 
Sans handle, that would be a very cumbersome
file-by-file manual process--which I just did
yesterday, in order to get the EN_'s in place to begin
with.

Glen

Re: cvs commit: xml-fop/src/java/org/apache/fop/traits LayoutProps.java SpaceVal.java

[J.Pietschmann]

[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 also don't quite get the point about the
better S&R'ability.
J.Pietschmann

cvs commit: xml-fop/src/java/org/apache/fop/traits BlockProps.java BorderProps.java InlineProps.java LayoutProps.java MinOptMax.java SpaceVal.java

[jeremias]

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 at 
http://www.apache.org/dev/apply-license.html.
  
  Revision  ChangesPath
  1.3   +16 -48xml-fop/src/java/org/apache/fop/traits/BlockProps.java
  
  Index: BlockProps.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/traits/BlockProps.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- BlockProps.java   26 Feb 2004 15:47:03 -  1.2
  +++ BlockProps.java   27 Feb 2004 17:56:25 -  1.3
  @@ -1,53 +1,21 @@
   /*
  - * $Id$
  - * 
  - *The Apache Software License, Version 1.1
  - * 
  + * Copyright 1999-2004 The Apache Software Foundation.
* 
  - * Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved.
  - * 
  - * Redistribution and use in source and binary forms, with or without modifica-
  - * tion, are permitted provided that the following conditions are met:
  - * 
  - * 1. Redistributions of source code must retain the above copyright notice,
  - *this list of conditions and the following disclaimer.
  - * 
  - * 2. Redistributions in binary form must reproduce the above copyright notice,
  - *this list of conditions and the following disclaimer in the documentation
  - *and/or other materials provided with the distribution.
  - * 
  - * 3. The end-user documentation included with the redistribution, if any, must
  - *include the following acknowledgment: "This product includes software
  - *developed by the Apache Software Foundation (http://www.apache.org/)."
  - *Alternately, this acknowledgment may appear in the software itself, if
  - *and wherever such third-party acknowledgments normally appear.
  - * 
  - * 4. The names "FOP" and "Apache Software Foundation" must not be used to
  - *endorse or promote products derived from this software without prior
  - *written permission. For written permission, please contact
  - *[EMAIL PROTECTED]
  - * 
  - * 5. Products derived from this software may not be called "Apache", nor may
  - *"Apache" appear in their name, without prior written permission of the
  - *Apache Software Foundation.
  - * 
  - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
  - * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
  - * FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
  - * APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
  - * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU-
  - * DING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
  - * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
  - * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
  - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
  - * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  - * 
  - * 
  - * This software consists of voluntary contributions made by many individuals
  - * on behalf of the Apache Software Foundation and was originally created by
  - * James Tauber <[EMAIL PROTECTED]>. For more information on the Apache
  - * Software Foundation, please see <http://www.apache.org/>.
  - */ 
  + * Licensed under the Apache License, Version 2.0 (the "License");
  + * you may not use this file except in compliance with the License.
  + * You may obtain a copy of the License at
  + * 
  + *  http://www.apache.org/licenses/LICENSE-2.0
  + * 
  + * Unless required by applicable law or agreed to in writing, software
  + * distributed under the License is distributed on an "AS IS" BASIS,
  + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  + * See the License for the specific language governing permissions and
  + * limitations under the License.
  + */
  +
  +/* $Id$ */
  + 
   package org.apache.fop.traits;
   
   import org.apache.fop.datatypes.Length;
  
  
  
  1.2   +16 -48xml-fop/src/java/org/apache/fop/traits/BorderProps.java
  
  Index: BorderProps.java
  =======
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/traits/BorderProps.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  -

cvs commit: xml-fop/src/java/org/apache/fop/traits BlockProps.java

[bckfnn]

bckfnn  2004/02/26 07:47:03

  Modified:src/java/org/apache/fop/fo FOPropertyMapping.java FObj.java
PropertyManager.java
   src/java/org/apache/fop/fo/flow ExternalGraphic.java
TableColumn.java
   src/java/org/apache/fop/layoutmgr
BlockContainerLayoutManager.java
BlockLayoutManager.java LineLayoutManager.java
PageLayoutManager.java
   src/java/org/apache/fop/layoutmgr/table Column.java Row.java
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
  baselength has been assigned by the LayoutManagers.
  
  PR: 26778 (second half)
  
  Revision  ChangesPath
  1.11  +14 -2 xml-fop/src/java/org/apache/fop/fo/FOPropertyMapping.java
  
  Index: FOPropertyMapping.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/FOPropertyMapping.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- FOPropertyMapping.java4 Feb 2004 12:38:27 -   1.10
  +++ FOPropertyMapping.java26 Feb 2004 15:47:02 -  1.11
  @@ -304,6 +304,7 @@
   genericPadding = new LengthProperty.Maker(0);
   genericPadding.setInherited(false);
   genericPadding.setDefault("0pt");
  +genericPadding.setPercentBase(LengthBase.BLOCK_WIDTH);
   genericPadding.addShorthand(s_generics[PR_PADDING]);
   
   // GenericCondBorderWidth
  @@ -1189,6 +1190,7 @@
   m.setInherited(false);
   m.setDefault("0pt");
   m.addShorthand(s_generics[PR_MARGIN]);
  +m.setPercentBase(LengthBase.BLOCK_WIDTH);
   addPropertyMaker("margin-top", m);
   
   // margin-bottom
  @@ -1196,6 +1198,7 @@
   m.setInherited(false);
   m.setDefault("0pt");
   m.addShorthand(s_generics[PR_MARGIN]);
  +m.setPercentBase(LengthBase.BLOCK_WIDTH);
   addPropertyMaker("margin-bottom", m);
   
   // margin-left
  @@ -1203,6 +1206,7 @@
   m.setInherited(false);
   m.setDefault("0pt");
   m.addShorthand(s_generics[PR_MARGIN]);
  +m.setPercentBase(LengthBase.BLOCK_WIDTH);
   addPropertyMaker("margin-left", m);
   
   // margin-right
  @@ -1210,6 +1214,7 @@
   m.setInherited(false);
   m.setDefault("0pt");
   m.addShorthand(s_generics[PR_MARGIN]);
  +m.setPercentBase(LengthBase.BLOCK_WIDTH);
   addPropertyMaker("margin-right", m);
   
   // space-before
  @@ -1343,6 +1348,7 @@
   // block-progression-dimension
   m = new LengthRangeProperty.Maker(PR_BLOCK_PROGRESSION_DIMENSION);
   m.setInherited(false);
  +m.setPercentBase(LengthBase.BLOCK_HEIGHT);
   
   l = new LengthProperty.Maker(CP_MINIMUM);
   l.setDefault("auto");
  @@ -1372,6 +1378,7 @@
{PR_MAX_HEIGHT, PR_MAX_HEIGHT, PR_MAX_WIDTH, }
   });
   pdim.setRelative(true);
  +m.setCorresponding(pdim);
   addPropertyMaker("block-progression-dimension", m);
   
   // content-height
  @@ -1398,6 +1405,7 @@
   // inline-progression-dimension
   m = new LengthRangeProperty.Maker(PR_INLINE_PROGRESSION_DIMENSION);
   m.setInherited(false);
  +m.setPercentBase(LengthBase.BLOCK_WIDTH);
   
   l = new LengthProperty.Maker(CP_MINIMUM);
   l.setDefault("auto");
  @@ -1427,6 +1435,7 @@
   {PR_MIN_WIDTH, PR_MIN_WIDTH, PR_MIN_HEIGHT, },
   {PR_MAX_WIDTH, PR_MAX_WIDTH, PR_MAX_HEIGHT, }
   });
  +m.setCorresponding(pdim);
   addPropertyMaker("inline-progression-dimension", m);
   
   // max-height
  @@ -1471,7 +1480,7 @@
   l  = new LengthProperty.Maker(PR_WIDTH);
   l.setInherited(false);
   l.setAutoOk(true);
  -l.setPercentBase(LengthBase.CONTAINING_BOX);
  +l.setPercentBase(LengthBase.BLOCK_WIDTH);
   l.setDefault("auto");
   addPropertyMaker("width", l);
   }
  @@ -1580,6 +1589,7 @@
   m  = new LengthProperty.Maker(PR_TEXT_INDENT);
   m.setInherited(false);
   m.setDefault("0pt");
  +m.setPercentBase(LengthBase.BLOCK_WIDTH);
   addPropertyMaker("text-indent", m);
   
   // white-space-collapse
  @@ -,6 +2232,7 @@
   m  = new LengthProperty.M

cvs commit: xml-fop/src/java/org/apache/fop/traits SpaceVal.java

[bckfnn]

bckfnn  2004/02/02 08:08:27

  Modified:src/java/org/apache/fop/datatypes CompoundDatatype.java
   src/java/org/apache/fop/fo BoxPropShorthandParser.java
FOPropertyMapping.java FObj.java
GenericShorthandParser.java PropertyList.java
PropertyManager.java ShorthandParser.java
   src/java/org/apache/fop/fo/expr AbsFunction.java
BodyStartFunction.java CeilingFunction.java
FloorFunction.java FopPropValFunction.java
FromParentFunction.java
FromTableColumnFunction.java Function.java
InheritedPropFunction.java LabelEndFunction.java
MaxFunction.java MinFunction.java
NCnameProperty.java NearestSpecPropFunction.java
NumericProperty.java PPColWidthFunction.java
PropertyParser.java RGBColorFunction.java
RoundFunction.java
   src/java/org/apache/fop/fo/flow ExternalGraphic.java
Leader.java Table.java TableColumn.java
TableRow.java
   src/java/org/apache/fop/fo/pagination RegionBody.java
Title.java
   src/java/org/apache/fop/fo/properties
BorderWidthPropertyMaker.java
CommonBorderAndPadding.java
CompoundPropertyMaker.java
CorrespondingPropertyMaker.java
DimensionPropertyMaker.java
IndentPropertyMaker.java
LineHeightPropertyMaker.java PropertyMaker.java
   src/java/org/apache/fop/render/rtf
ListAttributesConverter.java
PageAttributesConverter.java RTFHandler.java
TableAttributesConverter.java
TextAttributesConverter.java
   src/java/org/apache/fop/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
LengthPairProperty.java LengthProperty.java
LengthRangeProperty.java
LinearCombinationLength.java ListProperty.java
MixedLength.java NumberProperty.java
PercentLength.java Property.java SpaceProperty.java
StringProperty.java TableColLength.java
ToBeImplementedProperty.java
  Removed: src/java/org/apache/fop/datatypes AutoLength.java
FixedLength.java LinearCombinationLength.java
MixedLength.java PercentLength.java
TableColLength.java ToBeImplementedProperty.java
   src/java/org/apache/fop/fo CharacterProperty.java
ColorTypeProperty.java CondLengthProperty.java
EnumProperty.java KeepProperty.java
LengthPairProperty.java LengthProperty.java
LengthRangeProperty.java ListProperty.java
NumberProperty.java Property.java
SpaceProperty.java StringProperty.java
  Log:
  Phase 3 (last) of bug 26434.
  
  - Move the property classes to fop.fo.properties.
  
  PR: 26434
  
  Revision  ChangesPath
  1.4   +1 -1  xml-fop/src/java/org/apache/fop/datatypes/CompoundDatatype.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/datatypes/CompoundDatatype.java.diff?r1=1.3&r2=1.4
  
  
  1.9   +2 -0  xml-fop/src/java/org/apache/fop/fo/BoxPropShorthandParser.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/BoxPropShorthandParser.java.diff?r1=1.8&r2=1.9
  
  
  1.8   +15 -2 xml-fop/src/java/org/apache/fop/fo/FOPropertyMapping.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/FOPropertyMapping.java.diff?r1=1.7&r2=1.8
  
  
  1.34  +1 -0  xml-fop/src/java/org/apache/fop/fo/FObj.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/FObj.java.diff?r1=1.33&r2=1.34
  
  
  1.8   +2 -0  xml-fop/src/java/org/apache/fop/fo/GenericShorthandParser.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/GenericShorthandParser.java.diff?r1=1.7&r2=1.8
  
  
  1.30  +1 -0  xml-fop/src/java/org/apache/fop/fo/PropertyList.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/PropertyList.java.diff?r1=1.29&r2=1.30
  
  
  1.22  +1 -0  xml-fop/src/java/org/apache/fop/fo/PropertyManager.java
  
  
http://cv

cvs commit: xml-fop/src/java/org/apache/fop/traits SpaceVal.java

[bckfnn]

bckfnn  2004/02/02 07:01:41

  Modified:src/java/org/apache/fop/datatypes AutoLength.java
ColorType.java FixedLength.java Length.java
LinearCombinationLength.java MixedLength.java
PercentLength.java TableColLength.java
   src/java/org/apache/fop/fo ColorTypeProperty.java
CondLengthProperty.java EnumProperty.java
FOPropertyMapping.java KeepProperty.java
LengthPairProperty.java LengthProperty.java
LengthRangeProperty.java NumberProperty.java
Property.java SpaceProperty.java
   src/java/org/apache/fop/fo/expr AbsFunction.java
BodyStartFunction.java LabelEndFunction.java
MaxFunction.java MinFunction.java
NumericProperty.java PPColWidthFunction.java
PropertyParser.java RGBColorFunction.java
   src/java/org/apache/fop/fo/flow ExternalGraphic.java
Table.java
   src/java/org/apache/fop/fo/properties
BorderWidthPropertyMaker.java
CommonBorderAndPadding.java
IndentPropertyMaker.java
LineHeightPropertyMaker.java
   src/java/org/apache/fop/render/rtf
TableAttributesConverter.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
  Log:
  Phase 2 of bug 26434.
  
  - Roll the datatypes logic into the property classes.
  
  PR: 26434.
  
  Revision  ChangesPath
  1.2   +5 -3  xml-fop/src/java/org/apache/fop/datatypes/AutoLength.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/datatypes/AutoLength.java.diff?r1=1.1&r2=1.2
  
  
  1.5   +7 -684xml-fop/src/java/org/apache/fop/datatypes/ColorType.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/datatypes/ColorType.java.diff?r1=1.4&r2=1.5
  
  
  1.4   +5 -4  xml-fop/src/java/org/apache/fop/datatypes/FixedLength.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/datatypes/FixedLength.java.diff?r1=1.3&r2=1.4
  
  
  1.3   +3 -90 xml-fop/src/java/org/apache/fop/datatypes/Length.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/datatypes/Length.java.diff?r1=1.2&r2=1.3
  
  
  1.3   +4 -2  
xml-fop/src/java/org/apache/fop/datatypes/LinearCombinationLength.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/datatypes/LinearCombinationLength.java.diff?r1=1.2&r2=1.3
  
  
  1.3   +11 -10xml-fop/src/java/org/apache/fop/datatypes/MixedLength.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/datatypes/MixedLength.java.diff?r1=1.2&r2=1.3
  
  
  1.3   +5 -4  xml-fop/src/java/org/apache/fop/datatypes/PercentLength.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/datatypes/PercentLength.java.diff?r1=1.2&r2=1.3
  
  
  1.3   +5 -4  xml-fop/src/java/org/apache/fop/datatypes/TableColLength.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/datatypes/TableColLength.java.diff?r1=1.2&r2=1.3
  
  
  1.5   +708 -12   xml-fop/src/java/org/apache/fop/fo/ColorTypeProperty.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/ColorTypeProperty.java.diff?r1=1.4&r2=1.5
  
  
  1.6   +68 -14xml-fop/src/java/org/apache/fop/fo/CondLengthProperty.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/CondLengthProperty.java.diff?r1=1.5&r2=1.6
  
  
  1.7   +1 -1  xml-fop/src/java/org/apache/fop/fo/EnumProperty.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/EnumProperty.java.diff?r1=1.6&r2=1.7
  
  
  1.6   +3 -3  xml-fop/src/java/org/apache/fop/fo/FOPropertyMapping.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/FOPropertyMapping.java.diff?r1=1.5&r2=1.6
  
  
  1.6   +90 -10xml-fop/src/java/org/apache/fop/fo/KeepProperty.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/KeepProperty.java.diff?r1=1.5&r2=1.6
  
  
  1.6   +48 -10xml-fop/src/java/org/apache/fop/fo/LengthPairProperty.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/LengthPairProperty.java.diff?r1=1.5&r2=1.6
  
  
  1.7   +94 -23xml-fop/src/java/org/apache/fop/fo/LengthProperty.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/LengthProperty.java.diff?r1=1.6&

cvs commit: xml-fop/src/java/org/apache/fop/traits LayoutProps.java SpaceVal.java

[gmazza]

gmazza  2003/12/22 13:37:44

  Modified:.build.xml
   src/codegen fo-property-mapping.xsl properties.xsl
   src/java/org/apache/fop/datatypes CondLength.java
   src/java/org/apache/fop/fo FObj.java Property.java
PropertyList.java PropertyManager.java
   src/java/org/apache/fop/fo/flow Block.java TableRow.java
   src/java/org/apache/fop/fo/properties
CommonBorderAndPadding.java
   src/java/org/apache/fop/layoutmgr PageLayoutManager.java
   src/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-interfaces.xsl
   src/java/org/apache/fop/fo Constants.java
  Removed: src/codegen enumgen.xsl
   src/java/org/apache/fop/fo/properties Constants.java
  Log:
  1.) renamed enumgen.xsl to longer but hopefully clearer
  prop-val-enum-interfaces.xsl
  
  2.) Moved Constants.java from fo.properties to fo package, to reduce the
  need for layout and renderers to import directly from the properties package.
  
  Revision  ChangesPath
  1.95  +1 -2  xml-fop/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/xml-fop/build.xml,v
  retrieving revision 1.94
  retrieving revision 1.95
  diff -u -r1.94 -r1.95
  --- build.xml 20 Dec 2003 17:40:01 -  1.94
  +++ build.xml 22 Dec 2003 21:37:43 -  1.95
  @@ -209,7 +209,6 @@
   
   
   
  -
   
   
   
  @@ -355,7 +354,7 @@
   out="${build.gensrc}/${replacestring}/fo/properties/fo_${ignore_this}"/>
   
  -
   
  
  
  
  1.4   +2 -1  xml-fop/src/codegen/fo-property-mapping.xsl
  
  Index: fo-property-mapping.xsl
  ===
  RCS file: /home/cvs/xml-fop/src/codegen/fo-property-mapping.xsl,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- fo-property-mapping.xsl   22 Dec 2003 03:53:31 -  1.3
  +++ fo-property-mapping.xsl   22 Dec 2003 21:37:43 -  1.4
  @@ -104,6 +104,7 @@
   
   import java.util.HashMap;
   import java.util.Set;
  +import org.apache.fop.fo.Constants;
   import org.apache.fop.fo.Property;
   //import org.apache.fop.svg.*;
   
  
  
  
  1.23  +2 -1  xml-fop/src/codegen/properties.xsl
  
  Index: properties.xsl
  ===
  RCS file: /home/cvs/xml-fop/src/codegen/properties.xsl,v
  retrieving revision 1.22
  retrieving revision 1.23
  diff -u -r1.22 -r1.23
  --- properties.xsl22 Dec 2003 03:53:31 -  1.22
  +++ properties.xsl22 Dec 2003 21:37:43 -  1.23
  @@ -311,6 +311,7 @@
   
   
 package org.apache.fop.fo.properties;
  +import org.apache.fop.fo.Constants;
   
 
   
  
  
  
  1.1  xml-fop/src/codegen/prop-val-enum-interfaces.xsl
  
  Index: prop-val-enum-interfaces.xsl
  ===
   
  http://www.w3.org/1999/XSL/Transform";
  xmlns:lxslt="http://xml.apache.org/xslt";
  xmlns:redirect="org.apache.xalan.xslt.extensions.Redirect"
  extension-element-prefixes="redirect">
  
  
  
  
  
  
  
  
  

  

  


  

  

  


  


  

  

  
package org.apache.fop.fo.properties;
  
  import org.apache.fop.fo.Constants;
  
  


  public interface 


   extends 
  
  .Enums

 {

  
  int 
  
   = Constants.
  
  ;


  

 }
  
  

  
  
  


  

  
  public interface 
  
   {
  
  

  int 

 = Constants.

;
  
  
  }
  

  
  

  

  
  


  

  

  
  

  public interface 

 extends 

.Enums { }
  
  

  
  

  false
  

  
  
  


  

  


  

  

  



  

  

  
  
  public in

Traits again

[Peter B. West]

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 in the
second paragraph of the Ch. 3 of the spec[1].
However, somewhat confusingly, if you look at the
second, third, and fourth diagrams in 1.1.2,
Formatting[2], the spec also refers to traits as the
refined/finished properties of the "refined formatting
object tree".  So in some cases, they do consider
traits to be both at the finished FO tree and the area
tree.
[1]
http://www.w3.org/TR/2001/REC-xsl-20011015/slice3.html#fo-jc-intro
[2]
http://www.w3.org/TR/2001/REC-xsl-20011015/slice1.html#section-N74
2-Formatting

I don't think I had noticed this before. It looks like the standard *does*
consider the refined properties to be traits. Since a refined value in the
FO Tree should be the same as the value used in the Area Tree, that makes
some sense.
There is not a simple correspondence between properties and traits in 
all cases.  See my table 
http://xml.apache.org/fop/design/alt.design/traits.html for a summary of 
traits.  I can't recall whether it is complete, but I scoured the Rec 
for references, and put what I could find in there.

Peter
--
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>

Re: Font variant SmallCaps Was: Re: (Chris) Re: Traits

[J.Pietschmann]

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 several font sources and the
renderers merely announce which font sources they support. That leaves
to option open for later to enable multiple renderers
simultaneously.
I don't think enabling multiple simultaneous renderers is worth
the trouble. If there are fonts producing a different metric for
the same font, all you share is parsing the FO tree and some
property refining. You have to provide for the case that generated
areas can't be reused across renderers and, if there should be any
advantage, also for cases where it is possible to share areas.
This looks ... complex.
Example:
FontSource A: TrueType fonts
FontSource B: Type 1 fonts
FontSource C: AWT fonts
FontSource D: Base14 fonts
FontSource E: PCL base fonts (just a guess)
PDF renderer supports: A, B, D (maybe C)
PostScript renderer supports: A, B, D (maybe C)
Java2D/AWT renderer supports: A and C
PCL renderer: Probably A, E
.
You need
- a class managing the fonts
- inquire the supported font types from the renderer
- match the renderer font types with the managed fonts
I still think it would be easier to get a renderer specific font
manager from the renderer, or get the fonts directly from the
renderer. The font managers or the renderes can share code for
general configuration, caching, font file management etc. by
subclassing a common class or by delegation (especially in the
second case).
J.Pietschmann

RE: Font variant SmallCaps Was: Re: (Chris) Re: Traits

[Victor Mote]

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 manager, and use the abstract interface to get
> > mainly character metrics, various other font measures and perhaps
> > font attributes like "sans-serif" or so.
> 
> My idea is still different: Having several font sources and the
> renderers merely announce which font sources they support. That leaves
> to option open for later to enable multiple renderers
> simultaneously.

Yes, this latter idea is closer to my view as well.

Victor Mote

Re: Font variant SmallCaps Was: Re: (Chris) Re: Traits

[Jeremias Maerki]

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 declare used fonts explicitely
> as well as whether they should be embedded, and FOP bails out if told
> to embed an AWT font, it shouldn't be much of a problem.

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.

> > 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 manager, and use the abstract interface to get
> mainly character metrics, various other font measures and perhaps
> font attributes like "sans-serif" or so.

My idea is still different: Having several font sources and the
renderers merely announce which font sources they support. That leaves
to option open for later to enable multiple renderers
simultaneously.

Example:
FontSource A: TrueType fonts
FontSource B: Type 1 fonts
FontSource C: AWT fonts
FontSource D: Base14 fonts
FontSource E: PCL base fonts (just a guess)

PDF renderer supports: A, B, D (maybe C)
PostScript renderer supports: A, B, D (maybe C)
Java2D/AWT renderer supports: A and C
PCL renderer: Probably A, E
.

> > Seriously, I don't think working with AWT's Font will do us any good.
> > The differences between JDKs are too great.
> 
> Hmhm. I still think
> - We must be able to use AWT fonts in the AWT renderer.
> - We must be able to use the default PDF fonts for the PDF renderer
> - We should be able to use TTF for both AWT and PDF
> - We should not rely on the default PDF fonts in the AWT renderer (doh!)
> - I'd like to support using TTF with generated and possibly hand-corrected
>   metrics as well as using TTF directly.
> 
> The possiblity to use AWT fonts for non-embedded fonts in PDF is a bonus.
> The possiblity to use AWT fonts in PDF even for embedding would be just
> another bonus.

+1 to all 7 points. Should be doable with my aproach.


Jeremias Maerki

Re: Font variant SmallCaps Was: Re: (Chris) Re: Traits

[J.Pietschmann]

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, but so what.


--> Support questions
It depends. If users are still required to declare used fonts explicitely
as well as whether they should be embedded, and FOP bails out if told
to embed an AWT font, it shouldn't be much of a problem.
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 manager, and use the abstract interface to get
mainly character metrics, various other font measures and perhaps
font attributes like "sans-serif" or so.
Seriously, I don't think working with AWT's Font will do us any good.
The differences between JDKs are too great.
Hmhm. I still think
- We must be able to use AWT fonts in the AWT renderer.
- We must be able to use the default PDF fonts for the PDF renderer
- We should be able to use TTF for both AWT and PDF
- We should not rely on the default PDF fonts in the AWT renderer (doh!)
- I'd like to support using TTF with generated and possibly hand-corrected
 metrics as well as using TTF directly.
The possiblity to use AWT fonts for non-embedded fonts in PDF is a bonus.
The possiblity to use AWT fonts in PDF even for embedding would be just
another bonus.
J.Pietschmann

Re: Font variant SmallCaps Was: Re: (Chris) Re: Traits

[Jeremias Maerki]

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 physical representation the font has from
> the awt.Font object.

Javadoc tells me this works since 1.3 (Font.createFont method).

Anyway, it's the opposite of what Victor wanted.

> I thought of the following approach
> 
> interface fop.font.Font {
>   public InputStream getFontInputStream();
>   public awt.Font getAWTFont();
>   // duplicate AWT methods, with certain stuff like metrics
>   // replaced with FOP objects
> }
> 
> class fop.font.AWTFont implements fop.font.Font {
>   // delegate to AWT font
>   // encapsulate awt.FontMetric in FOP font metric
> 
>   public InputStream getFontInputStream() { return null; }
> }
> 
> class fop.font.Type1Font implements fop.font.Font {
>   public awt.Font getAWTFont() { return null;}
>   // use FOP type 1 font reader
> }
> 
> class fop.font.TrueTypeFont implements fop.font.Font {
>   public awt.Font getAWTFont() { return new Font(new FileInputStream...);}

I think you meant return Font.createFont(Font.TRUETYPE_FONT, new
FileInputStream...

>   // use FOP TTF reader or delegate to the AWT font.
> }
> 
> class fop.font.PDFBuiltinFont implements fop.font.Font {
>   public InputStream getFontInputStream() { return null; }
>   public awt.Font getAWTFont() { return null;}
>   // return generated classes for metrics etc.
> }
> 
> 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

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.

> We *could* try to use the TTF reader to search through the fonts
> in the Windows font directory (or XFonts) in order to find the
> file for an AWT font.

Yeah, but it will be so slow. You'd need some persistent cache to
overcome that.

Seriously, I don't think working with AWT's Font will do us any good.
The differences between JDKs are too great.

We need java.awt.Font objects for the Java2D-related renderers, but
producing/getting these objects is the renderer's job, just as it's the
PDFRenderer's job to produce PDF font objects for serialization. IMO
it's better to have full control over what happens.

Jeremias Maerki

Re: Font variant SmallCaps Was: Re: (Chris) Re: Traits

[J.Pietschmann]

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 object.
I thought of the following approach

interface fop.font.Font {
 public InputStream getFontInputStream();
 public awt.Font getAWTFont();
 // duplicate AWT methods, with certain stuff like metrics
 // replaced with FOP objects
}
class fop.font.AWTFont implements fop.font.Font {
 // delegate to AWT font
 // encapsulate awt.FontMetric in FOP font metric
 public InputStream getFontInputStream() { return null; }
}
class fop.font.Type1Font implements fop.font.Font {
 public awt.Font getAWTFont() { return null;}
 // use FOP type 1 font reader
}
class fop.font.TrueTypeFont implements fop.font.Font {
 public awt.Font getAWTFont() { return new Font(new FileInputStream...);}
 // use FOP TTF reader or delegate to the AWT font.
}
class fop.font.PDFBuiltinFont implements fop.font.Font {
 public InputStream getFontInputStream() { return null; }
 public awt.Font getAWTFont() { return null;}
 // return generated classes for metrics etc.
}
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.
We *could* try to use the TTF reader to search through the fonts
in the Windows font directory (or XFonts) in order to find the
file for an AWT font.
J.Pietschmann

RE: Font variant SmallCaps Was: Re: (Chris) Re: Traits

[Victor Mote]

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
> share a context if, among other things, their fonts share common
> metrics.  Is this what you mean?

Yes, pretty much. I had pushed a bit to try to make render context one of
the high-level control objects, with the idea that the Area Tree could be
reused by additional renderers.

> > Another idea on the AWT font issue is to allow the user to register the
> > location of the AWT font just like they would any other font.
> This would be
> > equivalent to saying "use the AWT metrics for this font, but get the
> > physical font from a certain file". The problem there is, of
> course, that
> > you introduce another possible layer of errors (can find the
> AWT metrics but
> > not the physical file, or vice versa), but I think that would be quite
> > managable.
> >
>
> Speaking of errors: can find the AWT metrics, but they don't match the
> metrics of the font file.

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. That is the only correct
solution to this problem.

Victor Mote

Re: Font variant SmallCaps Was: Re: (Chris) Re: Traits

[Peter B. West]

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 the Type1Font class.
I have spent more time than I should have trying to figure out why fonts are
(or were) renderer-specific. I may still be missing something important. (I
*do* understand why they are renderer-context specific, i.e the difference
between the AWT context and the others).
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 
share a context if, among other things, their fonts share common 
metrics.  Is this what you mean?

Another idea on the AWT font issue is to allow the user to register the
location of the AWT font just like they would any other font. This would be
equivalent to saying "use the AWT metrics for this font, but get the
physical font from a certain file". The problem there is, of course, that
you introduce another possible layer of errors (can find the AWT metrics but
not the physical file, or vice versa), but I think that would be quite
managable.
Speaking of errors: can find the AWT metrics, but they don't match the 
metrics of the font file.

p
--
Peter B. West 

RE: Font variant SmallCaps Was: Re: (Chris) Re: Traits

[Victor Mote]

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 use AWT fonts without a hassle, with the
> small disadvantage that they can't be embedded.
>
> Jeremias, as the resident font guru, what do you think?

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 the Type1Font class.
I have spent more time than I should have trying to figure out why fonts are
(or were) renderer-specific. I may still be missing something important. (I
*do* understand why they are renderer-context specific, i.e the difference
between the AWT context and the others).

Another idea on the AWT font issue is to allow the user to register the
location of the AWT font just like they would any other font. This would be
equivalent to saying "use the AWT metrics for this font, but get the
physical font from a certain file". The problem there is, of course, that
you introduce another possible layer of errors (can find the AWT metrics but
not the physical file, or vice versa), but I think that would be quite
managable.

I think the approach that you are recommending is roughly what Jeremias has
suggested for fonts in general, and which I can live with as long as we
essentially make everything but the interface protected. I think you still
need to have a third class that sits between awt.Font and fop.Font, because
there is no way to tell awt.Font to implement the fop.Font interface. I
favored a concrete class with a method that did the selection, which seemed
cleaner to my mind, but I see the benefits to the other approach.

Victor Mote

Re: Font variant SmallCaps Was: Re: (Chris) Re: Traits

[Jeremias Maerki]

(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
support:
http://nagoya.apache.org/wiki/apachewiki.cgi?FOPFontSubsystemDesign

Basic parts of that are:
- Font metric providing interfaces to hide the various font sources (AWT,
Type1, TrueType) (There's no PDFFont in my view)
- Renderers announce which font sources they support -> rendering run 
(Document) holds the available font sources subset.
- Font adapters provided by the renderers that know how to
register/use/put a particular font in the output.

Since I have too little time to really participate ATM I can't care too
much how it is done, i.e. with a Avalon selector or with something else.
I failed to give Avalon in FOP a good enough punch. My only concern is
the separation of font sources from the renderers, so that a uniform way
of making fonts available in FOP is possible. I'm sorry that I can't be
more of a help right now. I'd love to help, but have other priorities.

On 22.11.2003 15:18:25 J.Pietschmann wrote:
> 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 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 use AWT fonts without a hassle, with the
> small disadvantage that they can't be embedded.
> 
> Jeremias, as the resident font guru, what do you think?


Jeremias Märki

Re: Font variant SmallCaps Was: Re: (Chris) Re: Traits

[J.Pietschmann]

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 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 use AWT fonts without a hassle, with the
small disadvantage that they can't be embedded.
Jeremias, as the resident font guru, what do you think?

J.Pietscmann

RE: Font variant SmallCaps Was: Re: (Chris) Re: Traits

[Victor Mote]

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 contents. This typeface
> has a parent
> > TypefaceFamily, which represents the Courier family, and knows
> how to find
> > bold, italic, small-caps, etc. Typefaces which are related.
>
> So your font is the same as an java.awt.Font?

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.

Victor Mote

Re: Font variant SmallCaps Was: Re: (Chris) Re: Traits

[J.Pietschmann]

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 parent
TypefaceFamily, which represents the Courier family, and knows how to find
bold, italic, small-caps, etc. Typefaces which are related.
So your font is the same as an java.awt.Font?

So, during FO Tree construction, when a small-caps font is requested by the
source document, FOP tries to find the small-caps variant for the Typeface
(by looking at the parent TypefaceFamily). If it exists, it assigns that. If
not, it uses the regular variant with an emulation on the point size, and
assigns that. Everything downstream just knows to use that Font, doesn't
need to know why. It sounds like we agree on all of this.
No problem.

J.Pietschmann

RE: Font variant SmallCaps Was: Re: (Chris) Re: Traits

[Victor Mote]

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 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 parent
  
Sorry--this should say Courier-Bold-Italic.

Victor Mote

RE: Font variant SmallCaps Was: Re: (Chris) Re: Traits

[Victor Mote]

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 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 parent
TypefaceFamily, which represents the Courier family, and knows how to find
bold, italic, small-caps, etc. Typefaces which are related.

So, during FO Tree construction, when a small-caps font is requested by the
source document, FOP tries to find the small-caps variant for the Typeface
(by looking at the parent TypefaceFamily). If it exists, it assigns that. If
not, it uses the regular variant with an emulation on the point size, and
assigns that. Everything downstream just knows to use that Font, doesn't
need to know why. It sounds like we agree on all of this.

Victor Mote

Re: Font variant SmallCaps Was: Re: (Chris) Re: Traits

[Chris Bowditch]

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 or so. Did you mean this
or rather typeface==font-family?
I just added the fontVariant property to the font class (the private member 
already existed - so it felt right)


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.

I am just aiming to implement small-caps emulation at this stage. I realise 
it is not the ideal solution, but my motivation is just to get something 
rather than nothing. The emulation is by no means "easy" I have the code 
from the maintenance branch, but it cannot simply be copied.

In order to emulate small-caps, the text area in question must be broken up 
whenever case changes. This involves changing 
TextLayoutManager.getNextBreakPoss code to detect this, thus creating break 
possibilities and changing "something else" possibly the TLM.addAreas to 
ensure areas are created for each BP whilst font-variant="small-caps"

Chris

_
Find a cheaper internet access deal - choose one to suit you. 
http://www.msn.co.uk/internetaccess

Re: Font variant SmallCaps Was: Re: (Chris) Re: Traits

[J.Pietschmann]

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

RE: Font variant SmallCaps Was: Re: (Chris) Re: Traits

[Victor Mote]

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 can be implemented in several ways
> - Get a SmallCaps font and use it. The handling is the same as
>   for bold and italic (or "font-weight" and "font-style")
> - Emulate by uppercasing lowercase characters and set an 80%
>   size font for them before the text is laid out (maintenance
>   branch implementation)
> - pass the attribute into the renderer or into the output and
>   let them care for themself
>
> The layout needs font metrics, therefore from the point of view
> of the layout the first and third option are the same.
> The interesting point is whether option 2 is implemented, somewhere
> in the pipeling before individual character widths are used (and,
> if necessary, character height), or whether the layout can get its
> metrics form a FOP Font structure (FontState or whatever it is called
> now).

The new logic that I envision on Fonts (subject to Jeremias' approval
especially, and everyone else's in general) makes a distinction between
Typeface and Font. A Font is a Typeface rendered at a specific point size. A
Typeface roughly corresponds to what is contained in a ttf of pfa font file.
So when a Font object is tied to an object, it can handle both cases fine.
The FO Tree logic that determines which font object to use will have to
determine whether a true small-caps typeface exists for the TypefaceFamily,
and act accordingly. But everything downstream from there can simply use the
stored Font object.

> If the font approach is used, we need "font variant" to be a font
> attribute. I'm too lazy to check whether this is already in place.
> The maintenance code didn't have it.

I don't think it is. The idea is to have a TypeFaceFamily object that knows
the relationship between the variations of the Typeface (i.e. bold, italic,
small-caps). So each Font belongs to a Typeface, which in turn belongs to a
TypeFaceFamily. So referencing a parent TypeFaceFamily can determine whether
there is a related small-caps Typeface.

> The advantage of this approach compared to the "early emulation"
> approach is that if a user has a true small caps font, he can use
> it more easily. For FOP, there is still the problem what to do if
> there is no appropriate font. Just bailing out might be an idea,
> but not necessarily a good one. An alternative would be to let the
> emulation happen under control of the font, in the renderer. This
> would need some hooks which don't exist yet, because the emulation
> must be able to insert the font size change into the output.

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?

> Now the questions is: how should the implementation look in HEAD?
> I personally like the font+late emulation approach.
>
> J.Pietschmann

Victor Mote

Font variant SmallCaps Was: Re: (Chris) Re: Traits

[J.Pietschmann]

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 at the very least (--which I
can only guess to be the idea, from the corresponding variable declarations
being commented out, these would be replaced by a call to getFontVariant() )
(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 can be implemented in several ways
- Get a SmallCaps font and use it. The handling is the same as
 for bold and italic (or "font-weight" and "font-style")
- Emulate by uppercasing lowercase characters and set an 80%
 size font for them before the text is laid out (maintenance
 branch implementation)
- pass the attribute into the renderer or into the output and
 let them care for themself
The layout needs font metrics, therefore from the point of view
of the layout the first and third option are the same.
The interesting point is whether option 2 is implemented, somewhere
in the pipeling before individual character widths are used (and,
if necessary, character height), or whether the layout can get its
metrics form a FOP Font structure (FontState or whatever it is called
now).
If the font approach is used, we need "font variant" to be a font
attribute. I'm too lazy to check whether this is already in place.
The maintenance code didn't have it.
The advantage of this approach compared to the "early emulation"
approach is that if a user has a true small caps font, he can use
it more easily. For FOP, there is still the problem what to do if
there is no appropriate font. Just bailing out might be an idea,
but not necessarily a good one. An alternative would be to let the
emulation happen under control of the font, in the renderer. This
would need some hooks which don't exist yet, because the emulation
must be able to insert the font size change into the output.
Now the questions is: how should the implementation look in HEAD?
I personally like the font+late emulation approach.
J.Pietschmann

Re: (Chris) Re: Traits

[Peter B. West]

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 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 at the very least (--which I
can only guess to be the idea, from the corresponding variable declarations
being commented out, these would be replaced by a call to getFontVariant() )
(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 ;) )
Joerg, be gentle.

Peter
--
Peter B. West 

RE: (Chris) Re: Traits

[Andreas L. Delmelle]

> -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 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 at the very least (--which I
can only guess to be the idea, from the corresponding variable declarations
being commented out, these would be replaced by a call to getFontVariant() )

(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 ;) )


Cheerz,

Andreas

Re: (Chris) Re: Traits

[Chris Bowditch]

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
Close but no cigar. In getNextBreakPoss, the code handles lines
which are last lines or end in forced line breaks, which must not
be justified (well, handling of text-align-last seems to be
missing...)
Thats okay - I dont smoke :-)

In makeLineBreak, the space for justification is computed (dAdjust)
and then passed to the new LineBreakPosition. Somehow, somewhere
there must be leader expansion, space-start and -end adjustment
and resizing of resizable spaces. It should be called from the
renderer just before rendering, because of expansion of forward
references, but I haven't found it. I somehow guess the code just
doesn't exist, which would neatly explain why text-align+"justify"
hasn't any effect
Great - another little layout problem for me to have some fun with.

Chris

_
Find a cheaper internet access deal - choose one to suit you. 
http://www.msn.co.uk/internetaccess

Re: (Chris) Re: Traits

[J.Pietschmann]

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 lines or end in forced line breaks, which must not
be justified (well, handling of text-align-last seems to be
missing...)
In makeLineBreak, the space for justification is computed (dAdjust)
and then passed to the new LineBreakPosition. Somehow, somewhere
there must be leader expansion, space-start and -end adjustment
and resizing of resizable spaces. It should be called from the
renderer just before rendering, because of expansion of forward
references, but I haven't found it. I somehow guess the code just
doesn't exist, which would neatly explain why text-align+"justify"
hasn't any effect
J.Pietschmann

Re: (Chris) Re: Traits

[J.Pietschmann]

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 from the actual "hack" Joerg & Chris are talking about
elsewhere in this thread)
Having "getters" and "setters" for a property and an actual implementation
getting the work done are different things... unless you men something else.
J.Pietschmann

RE: (Chris) Re: Traits

[Andreas L. Delmelle]

> -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 a few in the thread he just
> > transferred here
> > from fop-user )
>

Victor,

I was referring to the comment in CVS for exactly the fonts.Font and
fonts.TypeFace classes, as these mention the transition of the
layout.FontState to the fonts package (and had your name on them, so I
presumed you might have an idea...)

> I'm not sure what you are asking for here. IIRC, layout.FontState has
> basically been moved to fonts.Font. What has happened (I think)
> is that the
> font variant code was added to the maintenance branch, but not to
> the trunk.

In fact, I'm not really asking anything, just trying to provide some
pointers --and have them provided...;) 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 from the actual "hack" Joerg & Chris are talking about
elsewhere in this thread)

> I actually don't have much insight at the moment on whether the applicable
> maintenance branch code can just be brought across to the trunk.
>

Don't worry, this is about to be explored. :)

Greetz,

Andreas

RE: (Chris) Re: Traits

[Victor Mote]

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 Victor could add a
> few comments on what would need to be done to complete this particular
> issue. In fact, I already read a few in the thread he just
> transferred here
> from fop-user )

I'm not sure what you are asking for here. IIRC, layout.FontState has
basically been moved to fonts.Font. What has happened (I think) is that the
font variant code was added to the maintenance branch, but not to the trunk.
I actually don't have much insight at the moment on whether the applicable
maintenance branch code can just be brought across to the trunk.

Victor Mote

Re: (Chris) Re: Traits

[Chris Bowditch]

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, see next point.
Centering seems to be off by just one character.

In any case, justified text seems to be broken. I can't
even figure out *where* text justification is done.
combination of
LineLayoutManager.getNextBreakPoss and
LineLayoutManager.makeLineBreak
Theres plently of TODOs and see Keirons note etc in there!




3.)  The inline font-variant="small caps" for
"Extensible Markup Language" in the Abstract section
is not working.  (However, I'm not trained in fonts at
all--this may be very difficult to fix.)
Well, in the maintenance code this was hacked in FOText.layout(),
it checked for the font-variant and fed runs of lowercase letters
to with a smaller font and uppercased to further processing in
LineArea.addText() (through addRealText()).
It's not out of the question to do the same in HEAD. Of course,
it would be even better to check whether the font understands
the small caps variant natively and try to take advantage of this
first (there is a reason small caps is a variant, rather than
everybody emulating it itself using uppercase and an 80% sized
font). This requires extending FontState or something like this.
I may be able to provide the "hack" (as you described it)

Implementing small caps *efficiently*, well, this is probably a
real challenge.
I dont think I'll have time for that.

Chris

_
Sign-up for a FREE BT Broadband connection today! 
http://www.msn.co.uk/specials/btbroadband

Re: (Chris) Re: Traits

[J.Pietschmann]

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 seems to be broken. I can't
even figure out *where* text justification is done.
2.)  The first lines of text within each fo:block
incorrectly have a leading space appended to them. 
I'm looking at this one currently, it's a problem with
layoutmgr.TextLayoutManager and fo.flow.Block, not
related to the above.
That's probably in Block.handleWhiteSpace(), I think
because bPrevWasLF starts with false. Ther's probably a
superfluous trailing space as well, for a similar reason.
Also, it seems that the current imlementation will collapse
the two spaces between A and B
 A B
but it shouldn't, there should be one space followed by an
underlined space (it's in one of the spec errata).
BTW the entire whitespace handling is incredibly wasteful
if text is intented with multiple spaces to the level of
surrounding elements.
3.)  The inline font-variant="small caps" for
"Extensible Markup Language" in the Abstract section
is not working.  (However, I'm not trained in fonts at
all--this may be very difficult to fix.)
Well, in the maintenance code this was hacked in FOText.layout(),
it checked for the font-variant and fed runs of lowercase letters
to with a smaller font and uppercased to further processing in
LineArea.addText() (through addRealText()).
It's not out of the question to do the same in HEAD. Of course,
it would be even better to check whether the font understands
the small caps variant natively and try to take advantage of this
first (there is a reason small caps is a variant, rather than
everybody emulating it itself using uppercase and an 80% sized
font). This requires extending FontState or something like this.
Implementing small caps *efficiently*, well, this is probably a
real challenge.
J.Pietschmann

RE: (Chris) Re: Traits

[Andreas L. Delmelle]

> -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, following
difference immediately caught my eye: class layout.FontState. (defined in
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 a few in the thread he just transferred here
from fop-user )

The variable name fontVariant in HEAD appears in the build process, where
classes fo.properties.FontVariant and fo.properties.FontVariantMaker are
generated --unless it has been uncomfortably renamed in other related
classes, the only other two appearances are fonts.Font and
fo.PropertyManager (which could explain why this property currently has no
effect, since the corresponding entries are commented out).

As I said, a quick lookup... I currently have too vague an idea on how to
start to get it to actually work.

Greetz,

Andreas

Re: (Chris) Re: Traits

[Chris Bowditch]

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
defined with that class.
Your right methods dont take up much memory. My only concern was increased 
cost of maintaining multiple copies of the same code. But I guess Trait 
retrieval isnt exactly rocket science stuff.

> OTOH not every
> class that derives from
> Area will have Padding and spacing attributes.
>
Yes, for that reason I would recommend keeping those
methods in the child classes--even if duplicated.
Yes this makes sense.



You said you were interested in working with
block-centering issues.  The
examples\fo\basic\normal.fo example in the 1.0
distribution--which I've been looking at--when run for
PDF in 1.0 has three errors in it (you can see how it
should look if you run it w/0.20.5):
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.
2.)  The first lines of text within each fo:block
incorrectly have a leading space appended to them.
I'm looking at this one currently, it's a problem with
layoutmgr.TextLayoutManager and fo.flow.Block, not
related to the above.
I noticed this as well.

3.)  The inline font-variant="small caps" for
"Extensible Markup Language" in the Abstract section
is not working.  (However, I'm not trained in fonts at
all--this may be very difficult to fix.)
Would you like to tackle the first one (and the third,
if you want a real challenge)?  I'm looking at the
second right now (although you're welcome to beat me
to it on that one as well!), and the third may not be
that bad, given that it's already implemented in
0.20.x (hopefully it can be copied over into 1.0).
Thanks for taking the time to find some small issues for me to tackle. As it 
happens I have already got my teeth stuck into getting padding-left working. 
I'll write a separate post for that in a minute. I'll definitely add (1) and 
(3) to my todo list and take a look probably later in the week.



Thanks,

Chris

_
Express yourself with cool emoticons - download MSN Messenger today! 
http://www.msn.co.uk/messenger

(Chris) Re: Traits

[Glen Mazza]

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 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
defined with that class.

> OTOH not every
> class that derives from 
> Area will have Padding and spacing attributes.
> 

Yes, for that reason I would recommend keeping those
methods in the child classes--even if duplicated. 

> What do you think? I can supply patches if
> necessary.
> 

You said you were interested in working with
block-centering issues.  The
examples\fo\basic\normal.fo example in the 1.0
distribution--which I've been looking at--when run for
PDF in 1.0 has three errors in it (you can see how it
should look if you run it w/0.20.5):

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.

2.)  The first lines of text within each fo:block
incorrectly have a leading space appended to them. 
I'm looking at this one currently, it's a problem with
layoutmgr.TextLayoutManager and fo.flow.Block, not
related to the above.

3.)  The inline font-variant="small caps" for
"Extensible Markup Language" in the Abstract section
is not working.  (However, I'm not trained in fonts at
all--this may be very difficult to fix.)

Would you like to tackle the first one (and the third,
if you want a real challenge)?  I'm looking at the
second right now (although you're welcome to beat me
to it on that one as well!), and the third may not be
that bad, given that it's already implemented in
0.20.x (hopefully it can be copied over into 1.0).

But in general, you don't have to wait for me--look at
*any* of the 1.0 example .fo files, check for bugs
(based on comparing 0.20.x vs. 1.0), and submit
patches for them.  Best thing may be to attach (1) the
FO file, (2) PDF before patch applied, (3) PDF after
and (4) of course! the patch itself.

Thanks,
Glen

__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

Re: Traits

[J.Pietschmann]

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 for traits. I'd guess Keiron choose the
name properly...
J.Pietschmann

RE: Traits

[Victor Mote]

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 Tree or Area
Tree at all.

Victor Mote

Re: Traits

[Chris Bowditch]

From: Glen Mazza <[EMAIL PROTECTED]>

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...
this is a good point. I didnt consider the wider effect on non-padding 
properties.



OTOH, if you notice in the Area.RegionViewport class I
recently put some helper classes in such as
getPaddingAndSpacingBefore(), for finding the values
of *specific* properties, where we can make such
"return a 0 if it's NULL"-type determinations.
looks like what I was after.

These helper functions (1) simplify the renderer code
(esp. as the business logic would otherwise be
duplicated in each renderer class), (2) allows code
sharing between the renderers and layout (which also
sometimes needs to calculate these values), and (3)
provides a central point to store property-specific
business logic (e.g., how do we handle a NULL for this
*specific* property system-wide?  Raise exception or a
warning, return 0, return 2 as the default?, etc.,
etc.)  This may be a more accurate route for us--note
for memory concerns, though, I just provided methods
in the RegionViewport to calculate the values, and did
not duplicate the values themselves in RegionViewport.
I agree. We dont want to have to replicate this business logic in all the 
renderers. On a related note, wouldnt it be better to move the helper 
functions getPaddingAndSpacingBefore() 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 think? I can supply patches if necessary.

Chris

_
Express yourself with cool emoticons - download MSN Messenger today! 
http://www.msn.co.uk/messenger

Re: Traits

[Glen Mazza]

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 Herweg?) because we precisely need NULLs to be
returned sometime.  (0 won't always be correct.)

OTOH, if you notice in the Area.RegionViewport class I
recently put some helper classes in such as
getPaddingAndSpacingBefore(), for finding the values
of *specific* properties, where we can make such
"return a 0 if it's NULL"-type determinations.

These helper functions (1) simplify the renderer code
(esp. as the business logic would otherwise be
duplicated in each renderer class), (2) allows code
sharing between the renderers and layout (which also
sometimes needs to calculate these values), and (3)
provides a central point to store property-specific
business logic (e.g., how do we handle a NULL for this
*specific* property system-wide?  Raise exception or a
warning, return 0, return 2 as the default?, etc.,
etc.)  This may be a more accurate route for us--note
for memory concerns, though, I just provided methods
in the RegionViewport to calculate the values, and did
not duplicate the values themselves in RegionViewport.

Glen

--- Chris Bowditch <[EMAIL PROTECTED]> wrote:
> 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
> saying it isnt an 
> integer, when in fact it just isnt present (for that
> block) Instead it 
> should return 0. I have submitted a patch for this.
> 
>
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24705
> 
> Chris
> 
 


__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

Traits

[Chris Bowditch]

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 saying it isnt an 
integer, when in fact it just isnt present (for that block) Instead it 
should return 0. I have submitted a patch for this.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24705

Chris

_
Use MSN Messenger to send music and pics to your friends 
http://www.msn.co.uk/messenger

cvs commit: xml-fop/src/java/org/apache/fop/traits LayoutProps.java SpaceVal.java

[gmazza]

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 implemented for these objects for help in
  testing/debugging.
  
  Revision  ChangesPath
  1.2   +10 -2 
xml-fop/src/java/org/apache/fop/fo/properties/CommonBackground.java
  
  Index: CommonBackground.java
  ===
  RCS file: 
/home/cvs/xml-fop/src/java/org/apache/fop/fo/properties/CommonBackground.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- CommonBackground.java 12 Aug 2003 18:02:45 -  1.1
  +++ CommonBackground.java 5 Nov 2003 23:48:47 -   1.2
  @@ -66,5 +66,13 @@
   public int backRepeat;
   public Length backPosHorizontal;
   public Length backPosVertical;
  -
  +
  +public String toString() {
  +return "CommonBackground:\n" +
  +"backAttachment = " + backAttachment + "; backColor = " + 
  +((backColor != null) ? backColor.toString() : "null") + "\n" +
  +"backImage = " + backImage + "; backRepeat = " + backRepeat + "\n" +
  +"backPosHorizontal = " + backPosHorizontal + 
  +"; backPosVertical = " + backPosVertical + "\n";
  +}
   }
  
  
  
  1.2   +11 -3 
xml-fop/src/java/org/apache/fop/fo/properties/CommonBorderAndPadding.java
  
  Index: CommonBorderAndPadding.java
  ===
  RCS file: 
/home/cvs/xml-fop/src/java/org/apache/fop/fo/properties/CommonBorderAndPadding.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- CommonBorderAndPadding.java   12 Aug 2003 18:02:45 -  1.1
  +++ CommonBorderAndPadding.java   5 Nov 2003 23:48:47 -   1.2
  @@ -175,7 +175,6 @@
   return getPadding(TOP, bDiscard);
   }
   
  -
   public int getBorderWidth(int side, boolean bDiscard) {
   if ((borderInfo[side] == null)
   || (borderInfo[side].mStyle == Constants.NONE)
  @@ -209,5 +208,14 @@
   return padding[side].iLength;
   }
   }
  -
  +
  +public String toString() {
  +return "CommonBordersAndPadding (Before, After, Start, End):\n" +
  +"Borders: (" + getBorderTopWidth(false) + ", " + 
getBorderBottomWidth(false) + ", " +
  +getBorderLeftWidth(false) + ", " + getBorderRightWidth(false) + ")\n" +
  +"Border Colors: (" + getBorderColor(BEFORE) + ", " + getBorderColor(AFTER) 
+ ", " +
  +getBorderColor(START) + ", " + getBorderColor(END) + ")\n" +
  +"Padding: (" + getPaddingTop(false) + ", " + getPaddingBottom(false) + ", " 
+
  +getPaddingLeft(false) + ", " + getPaddingRight(false) + ")\n";
  +}
   }
  
  
  
  1.2   +8 -0  xml-fop/src/java/org/apache/fop/traits/LayoutProps.java
  
  Index: LayoutProps.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/traits/LayoutProps.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- LayoutProps.java  11 Mar 2003 13:05:36 -  1.1
  +++ LayoutProps.java  5 Nov 2003 23:48:47 -   1.2
  @@ -99,5 +99,13 @@
   // Parent span always overrides child span
   bIsSpan = parentLP.bIsSpan;
   }
  +
  +public String toString() {
  +return "LayoutProps:\n" +
  +"breakBefore = " + breakBefore + "; breakAfter = " + breakAfter + "\n" +
  +"spaceBefore = " + ((spaceBefore != null) ? spaceBefore.toString() : 
"null") + "\n" +
  +"spaceAfter = " + ((spaceAfter != null) ? spaceAfter.toString() : "null") + 
"\n" +
  +"bIsSpan = " + bIsSpan + "\n";
  +}
   }
   
  
  
  
  1.3   +3 -0  xml-fop/src/java/org/apache/fop/traits/SpaceVal.java
  
  Index: SpaceVal.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/traits/SpaceVal.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- SpaceVal.java 28 Aug 2003 19:08:59 -  1.2
  +++ SpaceVal.java 5 Nov 2003 23:48:47 -   1.3
  @@ -133,5 +133,8 @@
   return space;
   }
   
  +public String toString() {
  +return "SpaceVal: " + getSpace().toString();
  +}
   }
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: xml-fop/src/java/org/apache/fop/traits MinOptMax.java SpaceVal.java

[vmote]

vmote   2003/08/28 12:08:59

  Modified:src/java/org/apache/fop/layoutmgr AddLMVisitor.java
BlockContainerLayoutManager.java
BlockLayoutManager.java
BlockStackingLayoutManager.java BreakPoss.java
ContentLayoutManager.java FlowLayoutManager.java
InlineStackingLayoutManager.java LayoutContext.java
LeafNodeLayoutManager.java LineLayoutManager.java
PageLayoutManager.java SpaceSpecifier.java
TextLayoutManager.java
   src/java/org/apache/fop/layoutmgr/list Item.java
ListBlockLayoutManager.java
ListItemLayoutManager.java
   src/java/org/apache/fop/layoutmgr/table Body.java
Caption.java Cell.java 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:
  move layoutmgr/MinOptMax to traits/MinOptMax
  
  Revision  ChangesPath
  1.14  +2 -1  xml-fop/src/java/org/apache/fop/layoutmgr/AddLMVisitor.java
  
  Index: AddLMVisitor.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/layoutmgr/AddLMVisitor.java,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- AddLMVisitor.java 26 Aug 2003 19:51:20 -  1.13
  +++ AddLMVisitor.java 28 Aug 2003 19:08:58 -  1.14
  @@ -125,6 +125,7 @@
   import java.awt.geom.Rectangle2D;
   
   import org.apache.fop.apps.*;
  +import org.apache.fop.traits.*;
   
   /**
* Concrete implementation of FOTreeVisitor for the purpose of adding
  
  
  
  1.6   +1 -0  
xml-fop/src/java/org/apache/fop/layoutmgr/BlockContainerLayoutManager.java
  
  Index: BlockContainerLayoutManager.java
  ===
  RCS file: 
/home/cvs/xml-fop/src/java/org/apache/fop/layoutmgr/BlockContainerLayoutManager.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- BlockContainerLayoutManager.java  24 Aug 2003 18:04:07 -  1.5
  +++ BlockContainerLayoutManager.java  28 Aug 2003 19:08:58 -  1.6
  @@ -63,6 +63,7 @@
   import org.apache.fop.fo.PropertyList;
   import org.apache.fop.area.CTM;
   import org.apache.fop.datatypes.FODimension;
  +import org.apache.fop.traits.*;
   
   /**
* LayoutManager for a block FO.
  
  
  
  1.5   +1 -0  
xml-fop/src/java/org/apache/fop/layoutmgr/BlockLayoutManager.java
  
  Index: BlockLayoutManager.java
  ===
  RCS file: 
/home/cvs/xml-fop/src/java/org/apache/fop/layoutmgr/BlockLayoutManager.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- BlockLayoutManager.java   22 Aug 2003 17:42:41 -  1.4
  +++ BlockLayoutManager.java   28 Aug 2003 19:08:58 -  1.5
  @@ -65,6 +65,7 @@
   import org.apache.fop.fo.properties.CommonBackground;
   import org.apache.fop.fonts.*;
   import org.apache.fop.apps.*;
  +import org.apache.fop.traits.*;
   
   /**
* LayoutManager for a block FO.
  
  
  
  1.2   +1 -0  
xml-fop/src/java/org/apache/fop/layoutmgr/BlockStackingLayoutManager.java
  
  Index: BlockStackingLayoutManager.java
  ===
  RCS file: 
/home/cvs/xml-fop/src/java/org/apache/fop/layoutmgr/BlockStackingLayoutManager.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- BlockStackingLayoutManager.java   11 Mar 2003 13:05:24 -  1.1
  +++ BlockStackingLayoutManager.java   28 Aug 2003 19:08:58 -  1.2
  @@ -53,6 +53,7 @@
   import org.apache.fop.area.Area;
   import org.apache.fop.area.BlockParent;
   import org.apache.fop.area.Block;
  +import org.apache.fop.traits.*;
   
   /**
* Base LayoutManager class for all areas which stack their child
  
  
  
  1.2   +1 -0  xml-fop/src/java/org/apache/fop/layoutmgr/BreakPoss.java
  
  Index: BreakPoss.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/layoutmgr/BreakPoss.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- BreakPoss.java11 Mar 2003 13:05:24 -  1.1
  +++ BreakPoss.java28 Aug 2003 19:08:58 -  1.2
  @@ -51,6 +51,7 @@
   package org.apache.fop.layoutmgr;
   
   import org.apache.fop.traits.LayoutProps;
  +import org.apache.fop.traits.*;
   
   /**
* Represents a break possibility for the layout manager.
  
  
  
  1.3   +1 -0  
xml-fop/src/java/org/apache

cvs commit: xml-fop/src/java/org/apache/fop/traits - New directory

[jeremias]

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]

cvs commit: xml-fop/src/org/apache/fop/traits InlineProps.java LayoutProps.java BlockProps.java BorderProps.java

[jeremias]

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/org/apache/fop/traits/InlineProps.java
  
  Index: InlineProps.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/traits/InlineProps.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- InlineProps.java  28 Apr 2002 21:28:02 -  1.1
  +++ InlineProps.java  7 Mar 2003 10:09:40 -   1.2
  @@ -1,25 +1,66 @@
   /*
* $Id$
  - * Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
  - * For details on use and redistribution please refer to the
  - * LICENSE file included with these sources.
  - */
  -
  + * 
  + *The Apache Software License, Version 1.1
  + * 
  + * 
  + * Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved.
  + * 
  + * Redistribution and use in source and binary forms, with or without modifica-
  + * tion, are permitted provided that the following conditions are met:
  + * 
  + * 1. Redistributions of source code must retain the above copyright notice,
  + *this list of conditions and the following disclaimer.
  + * 
  + * 2. Redistributions in binary form must reproduce the above copyright notice,
  + *this list of conditions and the following disclaimer in the documentation
  + *and/or other materials provided with the distribution.
  + * 
  + * 3. The end-user documentation included with the redistribution, if any, must
  + *include the following acknowledgment: "This product includes software
  + *developed by the Apache Software Foundation (http://www.apache.org/)."
  + *Alternately, this acknowledgment may appear in the software itself, if
  + *and wherever such third-party acknowledgments normally appear.
  + * 
  + * 4. The names "FOP" and "Apache Software Foundation" must not be used to
  + *endorse or promote products derived from this software without prior
  + *written permission. For written permission, please contact
  + *[EMAIL PROTECTED]
  + * 
  + * 5. Products derived from this software may not be called "Apache", nor may
  + *"Apache" appear in their name, without prior written permission of the
  + *Apache Software Foundation.
  + * 
  + * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
  + * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
  + * FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
  + * APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
  + * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU-
  + * DING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
  + * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
  + * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
  + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
  + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  + * 
  + * 
  + * This software consists of voluntary contributions made by many individuals
  + * on behalf of the Apache Software Foundation and was originally created by
  + * James Tauber <[EMAIL PROTECTED]>. For more information on the Apache
  + * Software Foundation, please see <http://www.apache.org/>.
  + */ 
   package org.apache.fop.traits;
   
  -
   /**
* Store all inline "margin" related properties
* Public "structure" allows direct member access.
*/
   public class InlineProps {
  +
   public int marginTop;
   public int marginBottom;
   public int marginLeft;
   public int marginRight;
   public SpaceVal spaceStart;
   public SpaceVal spaceEnd;
  -
  -public InlineProps() {}
   
   }
  
  
  
  1.4   +53 -10xml-fop/src/org/apache/fop/traits/LayoutProps.java
  
  Index: LayoutProps.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/traits/LayoutProps.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- LayoutProps.java  25 Oct 2002 09:29:48 -  1.3
  +++ LayoutProps.java  7 Mar 2003 10:09:40 -   1.4
  @@ -1,13 +1,55 @@
   /*
* $Id$
  - * Copyright (C) 2002 The Apache Software Foundation. All rights reserved.
  - * For details 

cvs commit: xml-fop/src/org/apache/fop/traits SpaceVal.java

[keiron]

keiron  2003/02/12 20:24:19

  Modified:src/org/apache/fop/fo/flow Leader.java
   src/org/apache/fop/layoutmgr
BlockContainerLayoutManager.java
BlockLayoutManager.java
BlockStackingLayoutManager.java BreakPoss.java
ContentLayoutManager.java
InlineStackingLayoutManager.java LayoutContext.java
LeafNodeLayoutManager.java LineLayoutManager.java
PageLayoutManager.java SpaceSpecifier.java
TextLayoutManager.java
   src/org/apache/fop/layoutmgr/list Item.java
ListBlockLayoutManager.java
ListItemLayoutManager.java
   src/org/apache/fop/layoutmgr/table Body.java Caption.java
Cell.java Row.java
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 to where it is used
  
  Revision  ChangesPath
  1.31  +2 -2  xml-fop/src/org/apache/fop/fo/flow/Leader.java
  
  Index: Leader.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Leader.java,v
  retrieving revision 1.30
  retrieving revision 1.31
  diff -u -r1.30 -r1.31
  --- Leader.java   18 Nov 2002 15:54:14 -  1.30
  +++ Leader.java   13 Feb 2003 04:24:17 -  1.31
  @@ -21,7 +21,7 @@
   import org.apache.fop.layoutmgr.ContentLayoutManager;
   import org.apache.fop.layoutmgr.LayoutContext;
   import org.apache.fop.layoutmgr.LMiter;
  -import org.apache.fop.area.MinOptMax;
  +import org.apache.fop.layoutmgr.MinOptMax;
   import org.apache.fop.area.inline.Space;
   import org.apache.fop.area.inline.Word;
   import org.apache.fop.area.inline.InlineParent;
  
  
  
  1.8   +1 -2  
xml-fop/src/org/apache/fop/layoutmgr/BlockContainerLayoutManager.java
  
  Index: BlockContainerLayoutManager.java
  ===
  RCS file: 
/home/cvs/xml-fop/src/org/apache/fop/layoutmgr/BlockContainerLayoutManager.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- BlockContainerLayoutManager.java  29 Nov 2002 23:18:55 -  1.7
  +++ BlockContainerLayoutManager.java  13 Feb 2003 04:24:17 -  1.8
  @@ -14,7 +14,6 @@
   import org.apache.fop.area.BlockViewport;
   import org.apache.fop.area.Block;
   import org.apache.fop.area.LineArea;
  -import org.apache.fop.area.MinOptMax;
   import org.apache.fop.fo.PropertyManager;
   import org.apache.fop.layout.AbsolutePositionProps;
   import org.apache.fop.fo.properties.AbsolutePosition;
  
  
  
  1.26  +1 -2  xml-fop/src/org/apache/fop/layoutmgr/BlockLayoutManager.java
  
  Index: BlockLayoutManager.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/layoutmgr/BlockLayoutManager.java,v
  retrieving revision 1.25
  retrieving revision 1.26
  diff -u -r1.25 -r1.26
  --- BlockLayoutManager.java   29 Nov 2002 23:18:55 -  1.25
  +++ BlockLayoutManager.java   13 Feb 2003 04:24:17 -  1.26
  @@ -14,7 +14,6 @@
   import org.apache.fop.area.BlockParent;
   import org.apache.fop.area.Block;
   import org.apache.fop.area.LineArea;
  -import org.apache.fop.area.MinOptMax;
   import org.apache.fop.area.Trait;
   import org.apache.fop.traits.LayoutProps;
   import org.apache.fop.layout.BorderAndPadding;
  
  
  
  1.14  +1 -2  
xml-fop/src/org/apache/fop/layoutmgr/BlockStackingLayoutManager.java
  
  Index: BlockStackingLayoutManager.java
  ===
  RCS file: 
/home/cvs/xml-fop/src/org/apache/fop/layoutmgr/BlockStackingLayoutManager.java,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- BlockStackingLayoutManager.java   13 Nov 2002 10:25:48 -  1.13
  +++ BlockStackingLayoutManager.java   13 Feb 2003 04:24:17 -  1.14
  @@ -11,7 +11,6 @@
   import org.apache.fop.area.Area;
   import org.apache.fop.area.BlockParent;
   import org.apache.fop.area.Block;
  -import org.apache.fop.area.MinOptMax;
   
   import java.util.Iterator;
   
  
  
  
  1.11  +1 -2  xml-fop/src/org/apache/fop/layoutmgr/BreakPoss.java
  
  Index: BreakPoss.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/layoutmgr/BreakPoss.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- BreakPoss.java18 Nov 2002 15:54:15 -  1.10
  +++ BreakPoss.java13 Feb 2003 04:24:17 -  1.11
  @@ -6,7

cvs commit: xml-fop/src/org/apache/fop/traits BorderProps.java

[keiron]

keiron  2002/11/03 08:24:22

  Modified:src/org/apache/fop/area AreaTree.java
CachedRenderPagesModel.java PageViewport.java
Trait.java
   src/org/apache/fop/datatypes ColorType.java
   src/org/apache/fop/fo/flow 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:
  fixed link/resolving problem
  made sure area tree is serializable
  
  Revision  ChangesPath
  1.11  +23 -10xml-fop/src/org/apache/fop/area/AreaTree.java
  
  Index: AreaTree.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/area/AreaTree.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- AreaTree.java 1 Nov 2002 10:49:34 -   1.10
  +++ AreaTree.java 3 Nov 2002 16:24:21 -   1.11
  @@ -397,23 +397,31 @@
   public void addPage(PageViewport page) {
   super.addPage(page);
   
  -// check prepared pages
  -boolean cont = checkPreparedPages();
  -
  -// if page finished
  -if (cont && page.isResolved()) {
  +// for links the renderer needs to prepare the page
  +// it is more appropriate to do this after queued pages but
  +// it will mean that the renderer has not prepared a page that
  +// could be referenced
  +boolean done = renderer.supportsOutOfOrder() && page.isResolved();
  +if (done) {
   try {
   renderer.renderPage(page);
   } catch (Exception e) {
   // use error handler to handle this FOP or IO Exception
  +e.printStackTrace();
   }
   page.clear();
   } else {
   preparePage(page);
   }
   
  -renderExtensions(pendingExt);
  -pendingExt.clear();
  +
  +// check prepared pages
  +boolean cont = checkPreparedPages(page);
  +
  +if (cont) {
  +renderExtensions(pendingExt);
  +pendingExt.clear();
  +}
   }
   
   /**
  @@ -422,7 +430,7 @@
* false if the renderer doesn't support out of order
* rendering and there are pending pages
*/
  -protected boolean checkPreparedPages() {
  +protected boolean checkPreparedPages(PageViewport newpage) {
   for (Iterator iter = prepared.iterator(); iter.hasNext();) {
   PageViewport p = (PageViewport)iter.next();
   if (p.isResolved()) {
  @@ -430,6 +438,7 @@
   renderer.renderPage(p);
   } catch (Exception e) {
   // use error handler to handle this FOP or IO Exception
  +e.printStackTrace();
   }
   p.clear();
   iter.remove();
  @@ -491,7 +500,11 @@
*/
   public void endDocument() {
   // render any pages that had unresolved ids
  -checkPreparedPages();
  +checkPreparedPages(null);
  +
  +renderExtensions(pendingExt);
  +pendingExt.clear();
  +
   renderExtensions(endDocExt);
   }
   }
  
  
  
  1.2   +26 -22xml-fop/src/org/apache/fop/area/CachedRenderPagesModel.java
  
  Index: CachedRenderPagesModel.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/area/CachedRenderPagesModel.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- CachedRenderPagesModel.java   9 Sep 2002 05:58:14 -   1.1
  +++ CachedRenderPagesModel.java   3 Nov 2002 16:24:21 -   1.2
  @@ -45,30 +45,33 @@
* false if the renderer doesn't support out of order
* rendering and there are pending pages
*/
  -protected boolean checkPreparedPages() {
  +protected boolean checkPreparedPages(PageViewport newpage) {
   for (Iterator iter = prepared.iterator(); iter.hasNext();) {
   PageViewport p = (PageViewport)iter.next();
   if (p.isResolved()) {
  -try {
  -// load page from cache
  -String name = (String)pageMap.get(p);
  -File temp = new File(name);
  -System.out.println("page serialized to: " + temp.length());
  -ObjectIn

Questions about the AreaTree, Traits and Renderers

[Peter Kullmann]

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 that these traits are
hard-coded into the classes - like "PageViewport" is obviously an area
with is-viewport-area = true.

2. Some traits like "top-position" are implemented as members of the
Area classes, I think (e.g. length, startIndent, getIPD and so on). Is
there a plan as to which traits will be accessible by their names in the
spec and which will be implemented through perhaps completely different
means in the Area classes. I'm rather confused with respect to this
issue, so I fear my question is rather unclear.

3. Im my imagination - or what I think I have understood from the spec -
the area tree (once it is finished) holds all information that is needed
before rendering. A renderer then takes the area tree and has a more or
less trivial task of actually painting what is described in the area
tree. In particular a renderer that is capable of adressing the output
medium in any order should be able just to translate fop coordinates to
renderer-specific coordinates and paint 'it'. So here is my question:
Why are currentIPPosition and currentBPPosition necessary in the
AbstractRenderer? Why does the renderer have to increment these
variables? In my opinion the positioning of areas to be rendered should
be done by the layout task. The renderer just reads the position of eg
word from the Word area (by accessing a trait or something else; see
Q2).

4. This isn't a question actually: Whilst trying to understand the area
tree and the rendering stuff I've written an XFig-renderer. The goal was
to create an xfig-drawing that contains boxes for the different areas of
a fo document (just on one page). The xfig renderer is working and is
producing some boxes. As you can see by the questions above I don't know
whether these boxes are 'right'. Is anyone interested in the xfig
renderer? 

Thanks a lot for answering some or all of these questions.

Peter




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: xml-fop/src/org/apache/fop/traits BorderProps.java

[klease]

klease  02/05/26 08:02:44

  Modified:src/org/apache/fop/area Area.java Block.java LineArea.java
Trait.java
   src/org/apache/fop/area/inline InlineArea.java
InlineParent.java Word.java
   src/org/apache/fop/datatypes ColorType.java
   src/org/apache/fop/layout BorderAndPadding.java
FontState.java
   src/org/apache/fop/layoutmgr AbstractBPLayoutManager.java
BPLayoutManager.java BreakPoss.java
BreakPossPosIter.java
InlineStackingBPLayoutManager.java
LayoutContext.java LineBPLayoutManager.java
PositionIterator.java SpaceSpecifier.java
TextBPLayoutManager.java TextLayoutManager.java
   src/org/apache/fop/render/pdf PDFRenderer.java
   src/org/apache/fop/render/xml XMLRenderer.java
   src/org/apache/fop/tools AreaTreeBuilder.java
  Added:   src/org/apache/fop/layoutmgr LeafPosition.java
NonLeafPosition.java Position.java TraitSetter.java
   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 of word-space and inter-area inline spaces in BP-style layout
  managers. Set border and padding traits on InlineParent areas.
  
  Revision  ChangesPath
  1.6   +32 -1 xml-fop/src/org/apache/fop/area/Area.java
  
  Index: Area.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/area/Area.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- Area.java 21 Mar 2002 09:34:19 -  1.5
  +++ Area.java 26 May 2002 15:02:42 -  1.6
  @@ -1,5 +1,5 @@
   /*
  - * $Id: Area.java,v 1.5 2002/03/21 09:34:19 keiron Exp $
  + * $Id: Area.java,v 1.6 2002/05/26 15:02:42 klease Exp $
* Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
* For details on use and redistribution please refer to the
* LICENSE file included with these sources.
  @@ -10,6 +10,8 @@
   import java.io.Serializable;
   import org.apache.fop.fo.FObj;
   
  +import java.util.HashMap;
  +
   // If the area appears more than once in the output
   // or if the area has external data it is cached
   // to keep track of it and to minimize rendered output
  @@ -125,5 +127,34 @@
   
   public FObj getGeneratingFObj() {
return this.genFObj;
  +}
  +
  +// Do nothing! Let subclasses do something if they can have child areas.
  +public void addChild(Area child) {
  +}
  +
  +
  +HashMap props = null;
  +
  +public void addTrait(Trait prop) {
  +if (props == null) {
  +props = new HashMap(20);
  +}
  +props.put(prop.propType, prop.data);
  +}
  +
  +public void addTrait(Object traitCode, Object prop) {
  +if (props == null) {
  +props = new HashMap(20);
  +}
  +props.put(traitCode, prop);
  +}
  +
  +public HashMap getTraits() {
  + return this.props;
  +}
  +
  +public Object getTrait(Object oTraitCode) {
  + return (props != null? props.get(oTraitCode) : null);
   }
   }
  
  
  
  1.7   +1 -13 xml-fop/src/org/apache/fop/area/Block.java
  
  Index: Block.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/area/Block.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- Block.java26 Apr 2002 09:40:54 -  1.6
  +++ Block.java26 May 2002 15:02:42 -  1.7
  @@ -1,5 +1,5 @@
   /*
  - * $Id: Block.java,v 1.6 2002/04/26 09:40:54 keiron Exp $
  + * $Id: Block.java,v 1.7 2002/05/26 15:02:42 klease Exp $
* Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
* For details on use and redistribution please refer to the
* LICENSE file included with these sources.
  @@ -71,18 +71,6 @@
   return positioning;
   }
   
  -// store properties in array list, need better solution
  -ArrayList traits = null;
   
  -public void addTrait(Trait prop) {
  -if (traits == null) {
  -traits = new ArrayList();
  -}
  -traits.add(prop);
  -}
  -
  -public List getTraitList() {
  -return traits;
  -}
   }
   
  
  
  
  1.6   +7 -15 xml-fop/src/org/apache/fop/area/LineArea.java
  
  Index: LineArea.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/area/LineArea.java,v
  retrieving revision

cvs commit: xml-fop/src/org/apache/fop/traits BlockProps.java InlineProps.java LayoutProps.java SpaceVal.java

[klease]

klease  02/04/28 14:28:02

  Modified:src/codegen foproperties.xml
   src/org/apache/fop/area BodyRegion.java MinOptMax.java
   src/org/apache/fop/datatypes Space.java
   src/org/apache/fop/fo FOText.java FObj.java FObjMixed.java
PropertyManager.java TextInfo.java
   src/org/apache/fop/fo/flow Block.java
   src/org/apache/fop/layout MarginInlineProps.java
   src/org/apache/fop/layoutmgr BlockLayoutManager.java
BlockStackingLayoutManager.java
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" method. Not currently enabled: to do
  so, one must make 2 changes in the source.
  
  Revision  ChangesPath
  1.31  +5 -2  xml-fop/src/codegen/foproperties.xml
  
  Index: foproperties.xml
  ===
  RCS file: /home/cvs/xml-fop/src/codegen/foproperties.xml,v
  retrieving revision 1.30
  retrieving revision 1.31
  diff -u -r1.30 -r1.31
  --- foproperties.xml  23 Feb 2002 16:47:01 -  1.30
  +++ foproperties.xml  28 Apr 2002 21:28:01 -  1.31
  @@ -1282,8 +1282,11 @@
 
   word-spacing
   true
  -ToBeImplemented
  -normal
  +GenericSpace
  +force
  +discard
  +0pt
  +
 
   
   
  
  
  
  1.5   +6 -1  xml-fop/src/org/apache/fop/area/BodyRegion.java
  
  Index: BodyRegion.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/area/BodyRegion.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- BodyRegion.java   17 Feb 2002 21:59:29 -  1.4
  +++ BodyRegion.java   28 Apr 2002 21:28:01 -  1.5
  @@ -1,5 +1,5 @@
   /*
  - * $Id: BodyRegion.java,v 1.4 2002/02/17 21:59:29 klease Exp $
  + * $Id: BodyRegion.java,v 1.5 2002/04/28 21:28:01 klease Exp $
* Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
* For details on use and redistribution please refer to the
* LICENSE file included with these sources.
  @@ -29,6 +29,11 @@
   // Number of columns when not spanning
   public void setColumnCount(int colCount) {
this.columnCount = colCount;
  +}
  +
  +// Number of columns when not spanning
  +public int getColumnCount() {
  + return this.columnCount ;
   }
   
   // A length (mpoints)
  
  
  
  1.3   +17 -2 xml-fop/src/org/apache/fop/area/MinOptMax.java
  
  Index: MinOptMax.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/area/MinOptMax.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- MinOptMax.java11 Nov 2001 14:10:29 -  1.2
  +++ MinOptMax.java28 Apr 2002 21:28:01 -  1.3
  @@ -1,5 +1,5 @@
   /*
  - * $Id: MinOptMax.java,v 1.2 2001/11/11 14:10:29 klease Exp $
  + * $Id: MinOptMax.java,v 1.3 2002/04/28 21:28:01 klease Exp $
* Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
* For details on use and redistribution please refer to the
* LICENSE file included with these sources.
  @@ -14,7 +14,7 @@
* variables are package visible.
*/
   
  -public class MinOptMax implements java.io.Serializable {
  +public class MinOptMax implements java.io.Serializable, Cloneable {
   
   /** Publicly visible min(imum), opt(imum) and max(imum) values.*/
   public int min;
  @@ -35,6 +35,15 @@
this.max = max;
   }
   
  +public Object clone() {
  + try {
  + return super.clone();
  + } catch (CloneNotSupportedException ex) {
  + // SHOULD NEVER OCCUR - all members are primitive types!
  + return null;
  + }
  +}
  +
   public static MinOptMax subtract(MinOptMax op1, MinOptMax op2) {
return new MinOptMax(op1.min - op2.max, op1.opt - op2.opt,
 op1.max - op2.min);
  @@ -43,6 +52,12 @@
   public static MinOptMax add(MinOptMax op1, MinOptMax op2) {
return new MinOptMax(op1.min + op2.min, op1.opt + op2.opt,
 op1.max + op2.max);
  +}
  +
  +public static MinOptMax multiply(MinOptMax op1, double mult) {
  + return new MinOptMax((int)(op1.min * mult),
  +  (int)(op1.opt * mult),
  +  (int)(op1.max * mult));
   }
   
   public void add(MinOptMax op) {
  
  
  
  1.6   +1 -7  xml-fop/src/org/apache/fop/datatypes/Space.java
  
  Index: Space.java
  ===
  RCS file: /home/cvs/

cvs commit: xml-fop/src/org/apache/fop/traits - New directory

[klease]

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]