how to use org.apache.fop.layout.AreaTree

2002-07-08 Thread Baptiste Burgaud 



 
Hi all,
 
I'm not sure whether this is the right list or not 
(I already posted this mail to the fop-user list, but no one did 
answer). Please excuse me if you find this mail inappropriate.
I need to get the accurate rendered height (in pt) 
of a fo:table object (to place fo:blocs below using fo:block-container with 
absolute position). I think I can get this size adding the 
getContentHeight() result of the appropriate areas in the 
org.apache.fop.layout.AreaTree object (initially _areaTree in Driver class). 
Unfortunately, I don't have much time to look around in FOP source, does someone 
know how where and when (!...) I should get this object? Is it possible within 
the FOP API (I certainly won't risk a rebuild...)?
 
thxs in advance, 
Baptiste

Re: [ANNOUNCEMENT] FOP 0.20.4 released

2002-07-08 Thread Christian Geisert 

Satoshi Ishigami schrieb:
> Konnichiwa.

> Why is not xml-docs included to src distribution?
> I thought the elimination of xml-docs to be only bin 
> distribution.

Because the documentation generation is broken in the maintenance
branch (stylebook needs xerces1)
It is mentioned in the release notes ;-)

> Now I am translating the all of FOP documents into Japanese.

Cool

> I want to get xml-docs for every release. Can I get it anywhere 
> else?

 From CVS trunk (tag fop-0_20_4-doc)
AFAIK older source release include xml-docs.

> BTW the ReleaseNotes.html file in root directory is
> mispointed to html-docs/relnotes.html and its information
> is still 0.20.3.

Doh, seems I copied html-docs into the root directory and not into docs
(I will upload a fixed version)

Thanks,

Christian


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

Re: [ANNOUNCEMENT] FOP 0.20.4 released

2002-07-08 Thread Satoshi Ishigami 


Konnichiwa Christian-san.

On Mon, 08 Jul 2002 10:04:19 +0200 , Christian Geisert wrote:

> Because the documentation generation is broken in the maintenance
> branch (stylebook needs xerces1)
> It is mentioned in the release notes ;-)
...snip...x8...snip...x8...
> > I want to get xml-docs for every release. Can I get it anywhere 
> > else?
> 
>  From CVS trunk (tag fop-0_20_4-doc)
> AFAIK older source release include xml-docs.

OK. I will try to checkout with its tag.

Thanks,

---
Satoshi Ishigami   VIC TOKAI CORPORATION

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

Truncating text

2002-07-08 Thread RamanaJV 



HI 
All,
    I don't want the text in the 
fo:block to be wrapped if the text length did not fit the allocated region. 
Instead, I want the text to be truncated. Is it possible through FOP?  

 
Eagerly awaiting for the reply
Ramana.JV.

cvs commit: xml-fop/src/org/apache/fop/image JimiImage.java

2002-07-08 Thread keiron 

keiron  2002/07/08 01:48:26

  Modified:src/org/apache/fop/image JimiImage.java
  Log:
  fixed compile error
  
  Revision  ChangesPath
  1.12  +3 -3  xml-fop/src/org/apache/fop/image/JimiImage.java
  
  Index: JimiImage.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/image/JimiImage.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- JimiImage.java27 Jun 2002 11:45:54 -  1.11
  +++ JimiImage.java8 Jul 2002 08:48:26 -   1.12
  @@ -131,8 +131,8 @@
   for (int i = 0; i < this.m_height; i++) {
   for (int j = 0; j < this.m_width; j++) {
   int p = tmpMap[i * this.m_width + j];
  -int r = (p > > 16) & 0xFF;
  -int g = (p > > 8) & 0xFF;
  +int r = (p >> 16) & 0xFF;
  +int g = (p >> 8) & 0xFF;
   int b = (p) & 0xFF;
   this.m_bitmaps[3 * (i * this.m_width + j)] =
 (byte)(r & 0xFF);
  
  
  

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

AW: Truncating text

2002-07-08 Thread Pretterhofer, Guenter (ext.) 

Hi Ramana,
 
you could try .
 
hth
gP

-Ursprüngliche Nachricht-
Von: RamanaJV [mailto:[EMAIL PROTECTED]]
Gesendet am: Montag, 8. Juli 2002 10:40
An: [EMAIL PROTECTED]
Betreff: Truncating text

HI All,
I don't want the text in the fo:block to be wrapped if the text length
did not fit the allocated region. Instead, I want the text to be truncated.
Is it possible through FOP?  
 
Eagerly awaiting for the reply
Ramana.JV.


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

RE: Truncating text

2002-07-08 Thread RamanaJV 

Thanks for the reply Pretterhofer,
I will try to explain the problem in greater detail. The blocks I have
are in the table cells and I don't want the text in the table cell block to
occupy anything extra space than allocated.  

 I have tried using this option, but the problem with wrap-option="no-wrap"
is the text now will not wrap to the next line, but will occupy the next
cell and the text in that cell becomes clumsy with the overlapping text. I
actually don't want the text to occupy not more than what is allocated.
Reason, I have asked for truncation...

Ramana.JV.

-Original Message-
From: Pretterhofer, Guenter (ext.)
[mailto:[EMAIL PROTECTED]]
Sent: Monday, July 08, 2002 2:31 PM
To: [EMAIL PROTECTED]
Subject: AW: Truncating text


Hi Ramana,
 
you could try .
 
hth
gP

-Ursprüngliche Nachricht-
Von: RamanaJV [mailto:[EMAIL PROTECTED]]
Gesendet am: Montag, 8. Juli 2002 10:40
An: [EMAIL PROTECTED]
Betreff: Truncating text

HI All,
I don't want the text in the fo:block to be wrapped if the text length
did not fit the allocated region. Instead, I want the text to be truncated.
Is it possible through FOP?  
 
Eagerly awaiting for the reply
Ramana.JV.


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

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

AW: Truncating text

2002-07-08 Thread Pretterhofer, Guenter (ext.) 

Hi,

according to the spec you could do the truncation with overflow="hidden".
But this is currently not implemented in FOP.


Cheers,
gP

-Ursprüngliche Nachricht-
Von: RamanaJV [mailto:[EMAIL PROTECTED]]
Gesendet am: Montag, 8. Juli 2002 11:10
An: [EMAIL PROTECTED]
Betreff: RE: Truncating text

Thanks for the reply Pretterhofer,
I will try to explain the problem in greater detail. The blocks I have
are in the table cells and I don't want the text in the table cell block to
occupy anything extra space than allocated.  

 I have tried using this option, but the problem with wrap-option="no-wrap"
is the text now will not wrap to the next line, but will occupy the next
cell and the text in that cell becomes clumsy with the overlapping text. I
actually don't want the text to occupy not more than what is allocated.
Reason, I have asked for truncation...

Ramana.JV.

-Original Message-
From: Pretterhofer, Guenter (ext.)
[mailto:[EMAIL PROTECTED]]
Sent: Monday, July 08, 2002 2:31 PM
To: [EMAIL PROTECTED]
Subject: AW: Truncating text


Hi Ramana,
 
you could try .
 
hth
gP

-Ursprüngliche Nachricht-
Von: RamanaJV [mailto:[EMAIL PROTECTED]]
Gesendet am: Montag, 8. Juli 2002 10:40
An: [EMAIL PROTECTED]
Betreff: Truncating text

HI All,
I don't want the text in the fo:block to be wrapped if the text length
did not fit the allocated region. Instead, I want the text to be truncated.
Is it possible through FOP?  
 
Eagerly awaiting for the reply
Ramana.JV.


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

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

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

RE: Truncating text

2002-07-08 Thread RamanaJV 

Oh god,
Then, what to do?  Does FOP 0.20.4 has addressed this overflow
issue?

Ramana.JV.

-Original Message-
From: Pretterhofer, Guenter (ext.)
[mailto:[EMAIL PROTECTED]]
Sent: Monday, July 08, 2002 3:16 PM
To: [EMAIL PROTECTED]
Subject: AW: Truncating text


Hi,

according to the spec you could do the truncation with overflow="hidden".
But this is currently not implemented in FOP.


Cheers,
gP

-Ursprüngliche Nachricht-
Von: RamanaJV [mailto:[EMAIL PROTECTED]]
Gesendet am: Montag, 8. Juli 2002 11:10
An: [EMAIL PROTECTED]
Betreff: RE: Truncating text

Thanks for the reply Pretterhofer,
I will try to explain the problem in greater detail. The blocks I have
are in the table cells and I don't want the text in the table cell block to
occupy anything extra space than allocated.  

 I have tried using this option, but the problem with wrap-option="no-wrap"
is the text now will not wrap to the next line, but will occupy the next
cell and the text in that cell becomes clumsy with the overlapping text. I
actually don't want the text to occupy not more than what is allocated.
Reason, I have asked for truncation...

Ramana.JV.

-Original Message-
From: Pretterhofer, Guenter (ext.)
[mailto:[EMAIL PROTECTED]]
Sent: Monday, July 08, 2002 2:31 PM
To: [EMAIL PROTECTED]
Subject: AW: Truncating text


Hi Ramana,
 
you could try .
 
hth
gP

-Ursprüngliche Nachricht-
Von: RamanaJV [mailto:[EMAIL PROTECTED]]
Gesendet am: Montag, 8. Juli 2002 10:40
An: [EMAIL PROTECTED]
Betreff: Truncating text

HI All,
I don't want the text in the fo:block to be wrapped if the text length
did not fit the allocated region. Instead, I want the text to be truncated.
Is it possible through FOP?  
 
Eagerly awaiting for the reply
Ramana.JV.


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

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

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

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

[REDESIGN] image/svg viewports

2002-07-08 Thread Keiron Liddle 

Hi all,

I have implemented the inline viewport part for images and instream
foreign object. This means that the images can be scaled and aligned in
the viewport including the clipping if specified.

Still need to sort out things like the writing direction.

Keiron.



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

Page details support?

2002-07-08 Thread RamanaJV 

Dear All,
Is it possible to through FOP API to find the number of lines ( for
a defined font and page) that can be rendered?

Ramana.JV.

-Original Message-
From: RamanaJV [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 08, 2002 3:24 PM
To: [EMAIL PROTECTED]
Subject: RE: Truncating text


Oh god,
Then, what to do?  Does FOP 0.20.4 has addressed this overflow
issue?

Ramana.JV.

-Original Message-
From: Pretterhofer, Guenter (ext.)
[mailto:[EMAIL PROTECTED]]
Sent: Monday, July 08, 2002 3:16 PM
To: [EMAIL PROTECTED]
Subject: AW: Truncating text


Hi,

according to the spec you could do the truncation with overflow="hidden".
But this is currently not implemented in FOP.


Cheers,
gP

-Ursprüngliche Nachricht-
Von: RamanaJV [mailto:[EMAIL PROTECTED]]
Gesendet am: Montag, 8. Juli 2002 11:10
An: [EMAIL PROTECTED]
Betreff: RE: Truncating text

Thanks for the reply Pretterhofer,
I will try to explain the problem in greater detail. The blocks I have
are in the table cells and I don't want the text in the table cell block to
occupy anything extra space than allocated.  

 I have tried using this option, but the problem with wrap-option="no-wrap"
is the text now will not wrap to the next line, but will occupy the next
cell and the text in that cell becomes clumsy with the overlapping text. I
actually don't want the text to occupy not more than what is allocated.
Reason, I have asked for truncation...

Ramana.JV.

-Original Message-
From: Pretterhofer, Guenter (ext.)
[mailto:[EMAIL PROTECTED]]
Sent: Monday, July 08, 2002 2:31 PM
To: [EMAIL PROTECTED]
Subject: AW: Truncating text


Hi Ramana,
 
you could try .
 
hth
gP

-Ursprüngliche Nachricht-
Von: RamanaJV [mailto:[EMAIL PROTECTED]]
Gesendet am: Montag, 8. Juli 2002 10:40
An: [EMAIL PROTECTED]
Betreff: Truncating text

HI All,
I don't want the text in the fo:block to be wrapped if the text length
did not fit the allocated region. Instead, I want the text to be truncated.
Is it possible through FOP?  
 
Eagerly awaiting for the reply
Ramana.JV.


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

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

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

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

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

Re: how to use org.apache.fop.layout.AreaTree

2002-07-08 Thread Keiron Liddle 

Hi Baptiste,

What exactly are you trying to achieve.
If you want to find out the size of the table that is only known at
layout time. The layout is done at the end of the page sequence so if
you are hoping to alter some fo object (through SAX or whatever) after
the table is laid out then it will be too late.

The height of the table is available from the Area that the table
creates. There are probably a number of hacks you could do...

Are you sure you don't want to use a normal fo object such as
table-footer, footnote, region-after.

On Mon, 2002-07-08 at 09:58, Baptiste Burgaud wrote:
> 
> Hi all,
> 
> I'm not sure whether this is the right list or not (I already posted this mail to 
>the fop-user list, but no one did answer). Please excuse me if you find this mail 
>inappropriate.
> I need to get the accurate rendered height (in pt) of a fo:table object (to place 
>fo:blocs below using fo:block-container with absolute position). I think I can get 
>this size adding the getContentHeight() result of the appropriate areas in the 
>org.apache.fop.layout.AreaTree object (initially _areaTree in Driver class). 
>Unfortunately, I don't have much time to look around in FOP source, does someone know 
>how where and when (!...) I should get this object? Is it possible within the FOP API 
>(I certainly won't risk a rebuild...)?
> 
> thxs in advance, Baptiste



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

Re: how to use org.apache.fop.layout.AreaTree

2002-07-08 Thread Baptiste Burgaud 

Hi Keiron,

thanks for your reply.

> What exactly are you trying to achieve.
I'm trying to get the exact rendered size of a table. The problem is that
table cells are as high as the text blocks they contain, even if I set the
height table-cell or table-row attribute. I tried to use the padding as a
workaround but this leads to approximation errors.

> Are you sure you don't want to use a normal fo object such as
> table-footer, footnote, region-after.
I'm sure I can't : All my fo objects (tables, text blocks, images) are
independently placed in the page using fo:block-container with absolute
position and I can't handle this differently beacause of the way my fo is
generated.

> The height of the table is available from the Area that the table
> creates. There are probably a number of hacks you could do...
True! Actually I surfed again fop website and I found
http://xml.apache.org/fop/design/understanding/renderers.html where is
explained how to add a new renderer. So it's what I'm doing to get this Area
you talked about. This should work and seems "cleaner" to me than rebuiding
fop. I will simply call the render method of a "fake" driver with some
sample data (the table first column) and then use the real driver. The table
area must be the highest AreaContainer. Does all of this seems correct to
you?

regards, Baptiste.

---
import org.apache.fop.apps.Driver;
import org.apache.fop.render.Renderer;

public class FakeDriver extends Driver
{
/**
 * FakeRender, to compute table height
 */
public static final int FAKE_RENDER = 10;

public void setRenderer(int renderer) throws IllegalArgumentException
{
  if(renderer==FAKE_RENDER) setRenderer(new FakeRenderer());
else super.setRenderer(renderer);
}
}
---

import org.apache.fop.render.pdf.PDFRenderer;
import org.apache.fop.layout.AreaContainer;

public class FakeRenderer extends PDFRenderer
{
public void renderAreaContainer(AreaContainer area)
{
  //some code to handle size...
  super.renderAreaContainer(area);
}
}

- Original Message -
From: "Keiron Liddle" <[EMAIL PROTECTED]>
To: "FOP" <[EMAIL PROTECTED]>
Sent: Monday, July 08, 2002 12:27 PM
Subject: Re: how to use org.apache.fop.layout.AreaTree


> Hi Baptiste,
>
> What exactly are you trying to achieve.
> If you want to find out the size of the table that is only known at
> layout time. The layout is done at the end of the page sequence so if
> you are hoping to alter some fo object (through SAX or whatever) after
> the table is laid out then it will be too late.
>
> The height of the table is available from the Area that the table
> creates. There are probably a number of hacks you could do...
>
> Are you sure you don't want to use a normal fo object such as
> table-footer, footnote, region-after.
>
> On Mon, 2002-07-08 at 09:58, Baptiste Burgaud wrote:
> >
> > Hi all,
> >
> > I'm not sure whether this is the right list or not (I already posted
this mail to the fop-user list, but no one did answer). Please excuse me if
you find this mail inappropriate.
> > I need to get the accurate rendered height (in pt) of a fo:table object
(to place fo:blocs below using fo:block-container with absolute position). I
think I can get this size adding the getContentHeight() result of the
appropriate areas in the org.apache.fop.layout.AreaTree object (initially
_areaTree in Driver class). Unfortunately, I don't have much time to look
around in FOP source, does someone know how where and when (!...) I should
get this object? Is it possible within the FOP API (I certainly won't risk a
rebuild...)?
> >
> > thxs in advance, Baptiste
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]


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

Usage of UML Diagrams

2002-07-08 Thread RamanaJV 

To FOP Developers,
There is a lot amount of  work going on and lot of design issues.
Since, FOP codebase has become very large now, I think it is time we think
about UML diagrams to keep the things simple and easily understandable. Why
don't we draw the UML diagrams like depicting the overall design with Class
and Object diagrams and also the sequence and activity diagrams for the new
contributors to make the induction smooth.
I also feel these diagrams will help a lot to the entire FOP
developer community so that design can be easily verified and make sure that
no flaws exist in the design?
What do others feel about this?

Ramana.JV.

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

Re: Truncating text

2002-07-08 Thread Jeremias Maerki 

No. That's something that will be adressed in the redesign. I've
investigated once what it would take to add it to the PDF renderer and
it's a nice amount of work. It actually doesn't do well with the
PDF-size optimizations in the PDF renderer.

Some have reported on fop-user to work around the problem by manually
limiting the number of characters in a cell. Not very nice but it can
work. I've done this myself. The other possibility is to write code that
takes character widths into account. This is not too difficult with the
font classes from FOP. Search the archives for some ideas.

> Oh god,
>   Then, what to do?  Does FOP 0.20.4 has addressed this overflow
> issue?

Cheers,
Jeremias Märki


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

Re: Page details support?

2002-07-08 Thread Jeremias Maerki 

The font classes could help you here, too. But I wonder if that helps
you a lot. Questions like that often indicate that someone is trying to
work around a problem that is actually supposed to be worked out in a
different way. If you experience a deficiency with FOP, first try to
find out, if it's XSL:FO that doesn't provide what you need or if it's
FOP. If it's FOP, tell us what you want to accomplish. We may (!) be
able to help you find another solution that doesn't involve messing
around with FOP. And if you really decide to hack into FOP, be aware
that your solution will lose portability because you're restricting
yourself to a particular software and that may be as bad as buying
proprietary software. :-) I hope this helps.

>   Is it possible to through FOP API to find the number of lines ( for
> a defined font and page) that can be rendered?

Cheers,
Jeremias Märki


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

Re: Usage of UML Diagrams

2002-07-08 Thread Keiron Liddle 

Hi Ramana,

Thats a good idea.
Provided that the diagrams are easy to maintain and understand.

These diagrams could cover certain areas so that people can understand
them independantly and thin about how they work independantly.
Such as:
- renderers
showing the class structure, relationship with other parts, calling
processes

- fo tree
showing how it is constructed, its purpose

- layout managers
etc.

We now have a general structure in the redesigned code that is being
built upon to achieve the functionality and performance.

We haven't had success with UML in the past but that doesn't mean
anything.
If you feel this could be useful area to explore, go ahead.
The tools such as ArgoUML have improved and I just tried it out again.

Keiron.

On Mon, 2002-07-08 at 16:38, RamanaJV wrote:
> To FOP Developers,
>   There is a lot amount of  work going on and lot of design issues.
> Since, FOP codebase has become very large now, I think it is time we think
> about UML diagrams to keep the things simple and easily understandable. Why
> don't we draw the UML diagrams like depicting the overall design with Class
> and Object diagrams and also the sequence and activity diagrams for the new
> contributors to make the induction smooth.
>   I also feel these diagrams will help a lot to the entire FOP
> developer community so that design can be easily verified and make sure that
> no flaws exist in the design?
>   What do others feel about this?
> 
> Ramana.JV.



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

Re: how to use org.apache.fop.layout.AreaTree

2002-07-08 Thread Keiron Liddle 

On Mon, 2002-07-08 at 15:14, Baptiste Burgaud wrote:
> True! Actually I surfed again fop website and I found
> http://xml.apache.org/fop/design/understanding/renderers.html where is
> explained how to add a new renderer. So it's what I'm doing to get this Area
> you talked about. This should work and seems "cleaner" to me than rebuiding
> fop. I will simply call the render method of a "fake" driver with some
> sample data (the table first column) and then use the real driver. The table
> area must be the highest AreaContainer. Does all of this seems correct to
> you?

That is something that could work for your situation. You can get the
information from each area and change it on the area that needs to be
placed in a particular position.

Not a method I would normally recommend but if you have to do it.



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

cvs commit: xml-fop/docs/xml-docs/fop news.xml

2002-07-08 Thread pbwest 

pbwest  2002/07/08 09:17:02

  Modified:docs/xml-docs/fop news.xml
  Log:
  Update for 0.20.4 release
  
  Revision  ChangesPath
  1.3   +11 -5 xml-fop/docs/xml-docs/fop/news.xml
  
  Index: news.xml
  ===
  RCS file: /home/cvs/xml-fop/docs/xml-docs/fop/news.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- news.xml  22 Jun 2002 06:12:14 -  1.2
  +++ news.xml  8 Jul 2002 16:17:01 -   1.3
  @@ -11,9 +11,8 @@
   
   
 
  -  
 
  -
  +
 
Changes since 0.20.3 include:
 
  @@ -41,16 +40,23 @@
Russian and Czech messages for AWTViewer
 
 For details see CHANGES file:http://cvs.apache.org/viewcvs.cgi/xml-fop/CHANGES?rev=1.10.2.19";
  -  >http://cvs.apache.org/viewcvs.cgi/xml-fop/CHANGES?rev=1.10.2.19
  +  "http://cvs.apache.org/viewcvs.cgi/xml-fop/CHANGES?rev=1.10.2.21";
  +  >http://cvs.apache.org/viewcvs.cgi/xml-fop/CHANGES?rev=1.10.2.21
 
 
See also the full text of the http://marc.theaimsgroup.com/?l=fop-dev&m=102607087326357&w=4";
  + >announcement.
  +  
  +
  +
  +  
  + See the full text of the http://marc.theaimsgroup.com/?l=fop-dev&m=102398470424177&w=4";
>announcement.
 
   
  -
  +
 Welcome Jeremias Maerki, Joerg Pietschmann and Peter B. West!

   
  
  
  

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

RE: Usage of UML Diagrams

2002-07-08 Thread Arved Sandstrom 

> -Original Message-
> From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
> Sent: July 8, 2002 12:45 PM
> To: FOP
> Subject: Re: Usage of UML Diagrams
>
> Thats a good idea.
[ SNIP ]
> We haven't had success with UML in the past but that doesn't mean
> anything.
> If you feel this could be useful area to explore, go ahead.
> The tools such as ArgoUML have improved and I just tried it out again.

We never tried it that seriously. And the last time we did, ArgoULM aka
Poseidon CE wasn't quite there yet. I agree that now it probably is. It
wasn't (and isn't) fair to rely on high-powered stuff like Visio or
TogetherJ that most people don't have easy access to.

Nice thing about ArgoUML is that the XML file format is great as source to
put into CVS.

I second the general comments, that this is worth doing. At the moment I am
in the same boat as lots of other people, i.e., I don't comprehend the
current HEAD codebase that well, and anything that helps is welcome.

Regards,
Arved Sandstrom


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

DO NOT REPLY [Bug 10571] New: - Monospaced Fonts Calculating Incorrect Width

2002-07-08 Thread bugzilla 

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

Monospaced Fonts Calculating Incorrect Width

   Summary: Monospaced Fonts Calculating Incorrect Width
   Product: Fop
   Version: 0.20.3
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: awt renderer
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Monospaced Fonts with Spaces (x'20') in them do not align correctly in the AWT 
Renderer.  The problem lies in the class AWTFontMetrics, in the method:  width
(int i, String family, int style, int size).  

The width() method is incorrectly multiplying the width of spaces by a factor 
1.4, regardless of whether the font is proportional or monospaced.

Suggestion resolution:  1) Remove the 1.4 factor for all fonts; or 2) determine 
whether the font is proportional or monospaced and use the 1.4 factor only for 
proportional fonts.

Bill Dennis

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

DO NOT REPLY [Bug 10571] - Monospaced Fonts Calculating Incorrect Width

2002-07-08 Thread bugzilla 

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

Monospaced Fonts Calculating Incorrect Width





--- Additional Comments From [EMAIL PROTECTED]  2002-07-08 23:56 ---
Note:  Maybe be related to but 1180.

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

RE: Page details support?

2002-07-08 Thread RamanaJV 

I understand that messing around with FOP is not a good idea. But what to
do, I doesn't get any solution till. I'll put the problem in greater detail
again.

   I will be having FO templates, that specify the style of the report. 
Let's say the template is like:


  http://www.w3.org/1999/XSL/Format>

   
  
   
  
 
 
  

   
   

   



   ##" +


  



There will be templates like above where the hashpart(###) is
the hole area where the programs fill the data. The data will be got from
the database and the client program supplies the server with the data and
the sever program takes the data and for every write call the client program
says, the server creates a new "fo:block" element and places the data
supplied in the hash portion. The client proceeds in this fashion. 
   The client program may supply large amount of records, can be
around 15,000 records also. So, it is not advisable to make the user wait
till all the data is supplied and the entire FO constructed. There is an
assumption made now, say we can show 40 records per page. The client
supplies 40 records to the sever, which renders the page using FOP API. But,
the problem comes if the data supplied will not fit in the single line. If
the data spans more than 1 line, then the assumption becomes incorrect and
the remnant portion of the data ( a small chunk, could be one or two lines)
comes in the second page. This is not good. 
There actually will be number of templates and client filling out
the templates. So, I'm trying to find a solution where in which at any point
of time client should be able to know that
 "Still how many lines of display remain?". With that the
client can hold until the server gives it a ready signal again.

I hope I'm clear now... I'm not finding how to solve the above
problem... I think this type of viewing is common in business
applications...
For now, it is assumed that the page size is 8.5in * 11in and
portrait mode. Is it possible?

I'll be waiting to hear for a solution...

-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 08, 2002 8:54 PM
To: [EMAIL PROTECTED]
Subject: Re: Page details support?


The font classes could help you here, too. But I wonder if that helps
you a lot. Questions like that often indicate that someone is trying to
work around a problem that is actually supposed to be worked out in a
different way. If you experience a deficiency with FOP, first try to
find out, if it's XSL:FO that doesn't provide what you need or if it's
FOP. If it's FOP, tell us what you want to accomplish. We may (!) be
able to help you find another solution that doesn't involve messing
around with FOP. And if you really decide to hack into FOP, be aware
that your solution will lose portability because you're restricting
yourself to a particular software and that may be as bad as buying
proprietary software. :-) I hope this helps.

>   Is it possible to through FOP API to find the number of lines ( for
> a defined font and page) that can be rendered?

Cheers,
Jeremias Märki


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

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

RE: Usage of UML Diagrams

2002-07-08 Thread RamanaJV 

Hi Keiron,
We can create a folder named UML in the docs\design folder and can
place the UML diagrams there. I'll start working on them, first starting
with a diagram depicting the relationship between Driver and the different
renderers. The team can review it and can come up with suggestions. 
Discussing with diagrams, the overall efficiency increases...

Ramana.JV.

-Original Message-
From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 08, 2002 9:15 PM
To: FOP
Subject: Re: Usage of UML Diagrams


Hi Ramana,

Thats a good idea.
Provided that the diagrams are easy to maintain and understand.

These diagrams could cover certain areas so that people can understand
them independantly and thin about how they work independantly.
Such as:
- renderers
showing the class structure, relationship with other parts, calling
processes

- fo tree
showing how it is constructed, its purpose

- layout managers
etc.

We now have a general structure in the redesigned code that is being
built upon to achieve the functionality and performance.

We haven't had success with UML in the past but that doesn't mean
anything.
If you feel this could be useful area to explore, go ahead.
The tools such as ArgoUML have improved and I just tried it out again.

Keiron.

On Mon, 2002-07-08 at 16:38, RamanaJV wrote:
> To FOP Developers,
>   There is a lot amount of  work going on and lot of design issues.
> Since, FOP codebase has become very large now, I think it is time we think
> about UML diagrams to keep the things simple and easily understandable.
Why
> don't we draw the UML diagrams like depicting the overall design with
Class
> and Object diagrams and also the sequence and activity diagrams for the
new
> contributors to make the induction smooth.
>   I also feel these diagrams will help a lot to the entire FOP
> developer community so that design can be easily verified and make sure
that
> no flaws exist in the design?
>   What do others feel about this?
> 
> Ramana.JV.



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

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

cvs commit: xml-fop/src/org/apache/fop/datatypes Script.java Language.java Country.java

2002-07-08 Thread pbwest 

pbwest  2002/07/08 23:41:32

  Removed: src/org/apache/fop/datatypes Tag: FOP_0-20-0_Alt-Design
Script.java Language.java Country.java
  Log:
  Changed to Type.java to circumvent name collisions in Properties

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

cvs commit: xml-fop/src/org/apache/fop/datatypes CountryType.java LanguageType.java ScriptType.java

2002-07-08 Thread pbwest 

pbwest  2002/07/08 23:42:51

  Added:   src/org/apache/fop/datatypes Tag: FOP_0-20-0_Alt-Design
CountryType.java LanguageType.java ScriptType.java
  Log:
  Added 'Type' to name to circumvent collisions in Properties
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.1   +56 -0 xml-fop/src/org/apache/fop/datatypes/Attic/CountryType.java
  
  
  
  
  1.1.2.1   +59 -0 xml-fop/src/org/apache/fop/datatypes/Attic/LanguageType.java
  
  
  
  
  1.1.2.1   +58 -0 xml-fop/src/org/apache/fop/datatypes/Attic/ScriptType.java
  
  
  
  

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

cvs commit: xml-fop/src/org/apache/fop/fo PropertyConsts.java

2002-07-08 Thread pbwest 

pbwest  2002/07/08 23:47:25

  Modified:src/org/apache/fop/fo Tag: FOP_0-20-0_Alt-Design
PropertyConsts.java
  Log:
  Changed 'complex' method collections on COMPLEX datatypes to 'verifyParsing' method 
on all types.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.5   +31 -31xml-fop/src/org/apache/fop/fo/Attic/PropertyConsts.java
  
  Index: PropertyConsts.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/Attic/PropertyConsts.java,v
  retrieving revision 1.1.2.4
  retrieving revision 1.1.2.5
  diff -u -r1.1.2.4 -r1.1.2.5
  --- PropertyConsts.java   4 Jul 2002 02:34:37 -   1.1.2.4
  +++ PropertyConsts.java   9 Jul 2002 06:47:25 -   1.1.2.5
  @@ -425,21 +425,22 @@
   public static final ROIntArray dataTypes;
   
   /**
  - * A sparsely populated array of Method objects.  Although this
  - * array has a slot for every property, only positions corresponding to
  - * properties which have a complex() method for processing
  - * complex property value specifications, will hold a valid
  - * Method object.
  + * An array of Method objects.  This array holds, for each
  + * property, the method object corresponding to the
  + * verifyParsing method of the property's class.
  + * verifyParsing methods defined in individual properties
  + * shadow the method in the Properties class.
*/
  -private static final Method[] complexmethods;
  +private static final Method[] verifyparsingmethods;
   
   /**
  - * An unmodifiable List of the property complex methods.
  - * This random access list is derived from complexmethods, above.
  + * An unmodifiable List of the property verifyParsing methods.
  + * This random access list is derived from verifyparsingmethods,
  + * above.
* It can be indexed by the property name constants defined in
* the PropNames class.
*/
  -public static final List complexMethods;
  +public static final List verifyParsingMethods;
   
   /**
* A HashMap of Method objects.  It contains the
  @@ -462,14 +463,14 @@
   classNames   = new String[PropNames.LAST_PROPERTY_INDEX + 1];
   toIndex  = new HashMap(PropNames.LAST_PROPERTY_INDEX + 1);
   classToIndex = new HashMap(PropNames.LAST_PROPERTY_INDEX + 1);
  -inherit= new int[PropNames.LAST_PROPERTY_INDEX + 1];
  -nonInheritedProps  = new BitSet(PropNames.LAST_PROPERTY_INDEX + 1);
  -initialValueTypes  = new int[PropNames.LAST_PROPERTY_INDEX + 1];
  -traitMappings  = new int[PropNames.LAST_PROPERTY_INDEX + 1];
  -datatypes  = new int[PropNames.LAST_PROPERTY_INDEX + 1];
  -classes= new Class[PropNames.LAST_PROPERTY_INDEX + 1];
  -complexmethods = new Method[PropNames.LAST_PROPERTY_INDEX + 1];
  -mappednummethods   = new HashMap();
  +inherit  = new int[PropNames.LAST_PROPERTY_INDEX + 1];
  +nonInheritedProps= new BitSet(PropNames.LAST_PROPERTY_INDEX + 1);
  +initialValueTypes= new int[PropNames.LAST_PROPERTY_INDEX + 1];
  +traitMappings= new int[PropNames.LAST_PROPERTY_INDEX + 1];
  +datatypes= new int[PropNames.LAST_PROPERTY_INDEX + 1];
  +classes  = new Class[PropNames.LAST_PROPERTY_INDEX + 1];
  +verifyparsingmethods = new Method[PropNames.LAST_PROPERTY_INDEX + 1];
  +mappednummethods = new HashMap();
   
   for (int i = 0; i <= PropNames.LAST_PROPERTY_INDEX; i++) {
   cname = "";
  @@ -536,10 +537,9 @@
   traitMappings[i] =
   classes[i].getField("traitMapping").getInt(null);
   datatypes[i] = classes[i].getField("dataTypes").getInt(null);
  -if ((datatypes[i] & Properties.COMPLEX) != 0)
  -complexmethods[i] =
  +verifyparsingmethods[i] =
   classes[i].getMethod
  -("complex", new Class[]
  +("verifyParsing", new Class[]
   {org.apache.fop.fo.FOTree.class,
PropertyValue.class});
   if ((datatypes[i] & Properties.MAPPED_NUMERIC) != 0)
  @@ -566,14 +566,14 @@
   }
   
   // Initialise the RO arrays
  -propertyClassNames  = new ROStringArray(classNames);
  -propertyClasses = Collections.unmodifiableList
  +propertyClassNames   = new ROStringArray(classNames);
  +propertyClasses  = Collections.unmodifiableList
   (Arrays.asList(classes));
  -

cvs commit: xml-fop/src/org/apache/fop/fo Properties.java

2002-07-08 Thread pbwest 

pbwest  2002/07/08 23:49:48

  Modified:src/org/apache/fop/fo Tag: FOP_0-20-0_Alt-Design
Properties.java
  Log:
  Added verifyParsing(). Converted complex() calls to verifyParsing().
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.14  +204 -110  xml-fop/src/org/apache/fop/fo/Attic/Properties.java
  
  Index: Properties.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/Attic/Properties.java,v
  retrieving revision 1.1.2.13
  retrieving revision 1.1.2.14
  diff -u -r1.1.2.13 -r1.1.2.14
  --- Properties.java   4 Jul 2002 02:48:37 -   1.1.2.13
  +++ Properties.java   9 Jul 2002 06:49:47 -   1.1.2.14
  @@ -35,7 +35,11 @@
   import org.apache.fop.datatypes.Ints;
   import org.apache.fop.datatypes.StringType;
   import org.apache.fop.datatypes.NCName;
  +import org.apache.fop.datatypes.CountryType;
  +import org.apache.fop.datatypes.LanguageType;
  +import org.apache.fop.datatypes.ScriptType;
   import org.apache.fop.datatypes.UriType;
  +import org.apache.fop.datatypes.MimeType;
   import org.apache.fop.datatypes.Length;
   import org.apache.fop.datatypes.Ems;
   import org.apache.fop.datatypes.Percentage;
  @@ -129,7 +133,7 @@
   
   // A number of questions are unresolved about the interaction of
   // complex parsing, property expression parsing & property validation.
  -// At this time (2002/07/03) it looks as though the complex() method
  +// At this time (2002/07/03) it looks as though the verifyParsing() method
   // will take full validation responsibility, so it will not be
   // necessary to specify any individual datatypes besides COMPLEX in the
   // property dataTypes field.  This renders some such specifications
  @@ -272,6 +276,104 @@
   
   
   /**
  + * The final stage of parsing:
  + * 1) PropertyTokenizer
  + * 2) PropertyParser - returns context-free PropertyValues
  + *recognizable by the parser
  + * 3) verifyParsing - verifies results from parser, translates
  + *property types like NCName into more specific value types,
  + *resolves enumeration types, etc.
  + *
  + * This method is shadowed by individual property classes which
  + * require specific processing.
  + * @param property int property index
  + * @param value PropertyValue returned by the parser
  + * @foTree the FOTree being built
  + */
  +public static PropertyValue verifyParsing
  +(PropertyValue value, FOTree foTree)
  +throws PropertyException
  +{
  +int property = value.getProperty();
  +String propName = PropNames.getPropertyName(property);
  +int datatype = PropertyConsts.dataTypes.get(property);
  +testing_valuetypes: do {
  +if (value instanceof Numeric) {
  +// Can be any of
  +// INTEGER, FLOAT, LENGTH, PERCENTAGE, ANGLE, FREQUENCY or TIME
  +if ((datatype & (INTEGER | FLOAT | LENGTH | PERCENTAGE
  +| ANGLE | FREQUENCY | TIME)) != 0)
  +return value;
  +}
  +if (value instanceof NCName) {
  +String ncname = ((NCName)value).getNCName();
  +// Can by any of
  +// NAME, COUNTRY_T, LANGUAGE_T, SCRIPT_T, ID_T, IDREF, ENUM
  +// MAPPED_NUMERIC or CHARACTER_T
  +if ((datatype & (NAME | ID_T | IDREF | CHARACTER_T)) != 0)
  +return value;
  +if ((datatype & COUNTRY_T) != 0)
  +return new CountryType(property, ncname);
  +if ((datatype & LANGUAGE_T) != 0)
  +return new LanguageType(property, ncname);
  +if ((datatype & SCRIPT_T) != 0)
  +return new ScriptType(property, ncname);
  +if ((datatype & ENUM) != 0)
  +return new EnumType(property, ncname);
  +if ((datatype & MAPPED_NUMERIC) != 0)
  +return (new MappedNumeric(property, ncname, foTree))
  +.getMappedNumValue();
  +}
  +if (value instanceof Literal) {
  +// Can be LITERAL or CHARACTER_T
  +if ((datatype & (LITERAL | CHARACTER_T)) != 0) return value;
  +throw new PropertyException
  +("Literal value invalid  for " + propName);
  +}
  +if (value instanceof Auto) {
  +if ((datatype & AUTO) != 0) return value;
  +throw new PropertyException("'auto' invalid  for " + propName);
  +}
  +if (value instanceof Bool) {
  +if ((datatype & BOOL) != 0) retur