Bug report for Fop [2003/06/15]

2003-06-15 Thread bugzilla 
+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=CriticalMAJ=Major |
| |   |   MIN=Minor   NOR=Normal  ENH=Enhancement   |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
|  635|Opn|Nor|2001-02-18|Doesn't support id= attribute in fo:page-sequence |
|  953|Opn|Nor|2001-03-12|Incorrect hyperlinks area rendering in justified t|
| 1063|New|Nor|2001-03-21|fop does not handle large fo files|
| 1180|New|Maj|2001-04-02|Problem with monospaced font  |
| 1859|Opn|Min|2001-05-22|org.apache.fop.apps.Driver.reset() doesn't fully r|
| 1998|New|Nor|2001-06-05|linefeed-treatment not understood |
| 2150|Ass|Maj|2001-06-13|New page with  a table-header but without any tabl|
| 2475|Ass|Nor|2001-07-06|Borders don't appear to work in |
| 2740|New|Maj|2001-07-23|multi-page tables sometimes render badly  |
| 2909|New|Maj|2001-07-30|Gradient render error |
| 2964|Ass|Nor|2001-08-02|problems with height of cells in tables   |
| 2988|New|Maj|2001-08-03|0.19: list-item-label does not stick to list-item-|
| 3044|Ass|Maj|2001-08-08|keep-together not functioning |
| 3280|New|Nor|2001-08-27|PCL Renderer doesn't work |
| 3305|Opn|Nor|2001-08-28|list-block overlapping footnote body  |
| 3497|New|Maj|2001-09-07|id already exists error when using span="all" attr|
| 3824|New|Blk|2001-09-25|MIF option with tables|
| 4030|New|Nor|2001-10-08|IOException creating Postscript with graphics on S|
| 4126|New|Nor|2001-10-12|FontState.width() returns pts instead of millipts |
| 4226|New|Nor|2001-10-17|The orphans property doesn't seem to work |
| 4388|New|Nor|2001-10-24|Nullpointer exception in the construction of new D|
| 4415|New|Nor|2001-10-25|scaling="uniform" does not work on images...  |
| 4510|New|Nor|2001-10-30|fo:inline common properties ignored?  |
| 4535|New|Maj|2001-10-31|PCL renderer 1.13 not rendering SVG   |
| 4614|New|Maj|2001-11-03|wrap property combined with Chinese   |
| 4767|New|Nor|2001-11-09|SVG text is distored in PDF output|
| 5001|New|Nor|2001-11-21|content-width and content-height ignored? |
| 5010|New|Enh|2001-11-21|Better error reporting needed |
| 5047|Ass|Nor|2001-11-23|Dotted border style is not supported  |
| 5124|New|Maj|2001-11-27|fo:block-container is not rendered properly using |
| 5335|Opn|Min|2001-12-10|Text with embedded CID fonts not retrievable from |
| 5655|Ass|Nor|2002-01-02|text-decoration cannot take multiple values   |
| 5674|New|Nor|2002-01-03|postscript generated by FOP is missing end command|
| 6094|Opn|Maj|2002-01-29|0.20.3rc hangs in endless loop|
| 6237|Opn|Nor|2002-02-05|fi (fi ligature) produces a "sharp"? |
| 6305|New|Nor|2002-02-07|Using fo:table-and-caption results in empty output|
| 6427|New|Enh|2002-02-13|Adding additional Type 1 fonts problem|
| 6437|New|Maj|2002-02-13|Tables without fo:table-column don't render   |
| 6483|New|Nor|2002-02-15|Table, Loop, "footer could not fit on page, moving|
| 6844|New|Nor|2002-03-04|No line breaks inserted in list-item-label|
| 6918|New|Enh|2002-03-06|reference-orientation has no effect   |
| 6929|New|Nor|2002-03-06|Cells border hidden by cells background   |
| 6997|New|Nor|2002-03-09|Row-spanned row data breaks over a page within a c|
| 7140|New|Enh|2002-03-15|page-position attribute set to "last" on condition|
| 7241|New|Nor|2002-03-19|keep-with-previous, keep-with-next only working on|
| 7283|New|Nor|2002-03-20|Table border misaligned when using margin-left in |
| 7337|New|Nor|2002-03-21|border around external image leaves empty space   |
| 7487|New|Nor|2002-03-26|break-before="page" for table inserts empty page  |
| 7496|New|Nor|2002-03-26|The table header borders are not adjusted to the b|
| 7525|New|Cri|2002-03-27|table with spans inside a list-block  |
| 7919|New|Cri|2002-04-10|problem to use attribute linefeed-treatment and li|
| 8003|Ass|Maj|2002-04-12|F

cvs commit: xml-fop/src/documentation/content/xdocs embedding.xml

2003-06-15 Thread vmote 
vmote   2003/06/15 14:18:29

  Modified:src/documentation/content/xdocs embedding.xml
  Log:
  Add comment re: multithreading with the AWT Renderer
  
  Revision  ChangesPath
  1.11  +2 -0  xml-fop/src/documentation/content/xdocs/embedding.xml
  
  Index: embedding.xml
  ===
  RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/embedding.xml,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- embedding.xml 21 May 2003 16:48:19 -  1.10
  +++ embedding.xml 15 Jun 2003 21:18:29 -  1.11
  @@ -345,6 +345,8 @@
   class to encapsulate the configuration settings and to run FOP in 
synchronized methods.
 
   
  +There is also a known issue with fonts being jumbled between threads when 
using the AWT renderer (which is used by the -awt and -print output options).
  +In general, you cannot safely run multiple threads through the AWT renderer.
 
   
 Examples
  
  
  

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

Re: FOTreeBuilder/ElementMapping change ideas

2003-06-15 Thread Glen Mazza 
Team,

No response on the below questions from any committer,
and I'm concerned about the drop-off on the FOP-DEV
mailing list over the past few weeks (at an
extrapolated 170 emails on FOP-DEV for the month, this
would be our lightest month since Dec. 1999!)  

I'd like us to continue progress on both Trunk and
Alt-Design until (1) at least one of the two methods
are finished or (2) they've been merged completely.  I
would be happy to work as best I can towards both
goals.  Do the committers need to have a vote on this?
 We need to get working again.

This thread was prompted by my suggestions earlier for
better encapsulating the layout.FOTreeBuilder object,
namely, by moving code involving its internal
ElementMapping setup from the Driver class to within
the FOTreeBuilder itself.  Moving layout-specific
functionality out of apps package was also the reason
for the patch I submitted moving the StructureHandler
and LayoutHandler classes to the layout and area
packages.

These changes may also help our other goals with the
application:

1) Avalonization:  by moving layout out of the apps
package, it makes the apps package more easily
expendable with an Avalonized version.

2) multiple LayoutStrategies:  "Pluggable" multiple
LayoutStrategy objects probably best attain their
pluggability by each object being able to work with
the same apps package. (Otherwise, keeping layout
functionality in apps package requires then including
the apps package within each LayoutStrategy!)

3) Alt-Design:  By making the code more modular, we
can more easily bring in already completed and
optimized portions of Alt-Design to start minimizing
the delta between Trunk and Alt-Design. 

*But*, if the committers need more time for
contemplation, that's fine--I'm starting to sink my
teeth into other Apache projects as well! ;)

Thanks,
Glen


>BTW, how certain are we that alt.design will be ready
>for 1.0?  Has there been agreement on switching the
>alt.design by the committers yet--to the degree that
>we should indeed forgo any improvement on the current
>layout code?  

>I didn't get the impression from Joerg's email
>http://marc.theaimsgroup.com/?l=fop-dev&m=105121991624106&w=2,
>that work on layout was frozen in preparation for
>alt.design--such freezing  strikes me as premature
>right now.

>Glen


--- "Peter B. West" <[EMAIL PROTECTED]> wrote:
> Glen,
> 
> There is no element mapping in the push parser of
> alt.design, which we 
> are looking at integrating into the code for 1.0.
> 
> Peter
> 
> Glen Mazza wrote:
> > I was looking at how the Driver class initializes
> its
> > FOTreeBuilder instance with formatting object
> > ElementMappings.  This currently occurs in three
> ways:
> 
> ...


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

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

RE: FOTreeBuilder/ElementMapping change ideas

2003-06-15 Thread Victor Mote 
Glen Mazza wrote:

> No response on the below questions from any committer,
> and I'm concerned about the drop-off on the FOP-DEV
> mailing list over the past few weeks (at an
> extrapolated 170 emails on FOP-DEV for the month, this
> would be our lightest month since Dec. 1999!)

At the moment, most of my design questions are answered, and it is merely
:-) a question of finding time to implement.

> I'd like us to continue progress on both Trunk and
> Alt-Design until (1) at least one of the two methods
> are finished or (2) they've been merged completely.  I
> would be happy to work as best I can towards both
> goals.  Do the committers need to have a vote on this?

I think most of us treat Alt-Design as Peter's "baby" and expect him at some
point to propose a reintegration of some or all of his work into the trunk.

>  We need to get working again.

There are probably multiple opinions about how best to proceed. My personal
view is that our biggest problem is not integrating Alt-Design, but rather
integrating the maintenance branch and the trunk so that we are releasing
and developing in the same branch. To that end, I am (as we speak) trying to
untangle Driver into Session, Document, and RenderContext objects, as the
first step toward refactoring to LayoutStrategy. So I guess I am working
along a different line, but working nonetheless.

Nevertheless, your point is well taken. I will address the remainder of your
email in a subsequent message.

Victor Mote


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

Nomination of Glen Mazza as committer

2003-06-15 Thread Victor Mote 
FOP Developers:

Being the greenest committer, I had hoped to defer this nomination to a more
senior developer. However, I think it is appropriate to nominate Glen Mazza
for committer status. He is knowledgeable and thoughtful, and I think it is
in the interest of the project to turn him loose so that he can keep working
without having to wait on us.

Victor Mote


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

DO NOT REPLY [Bug 20792] New: - Exception with a big image but ok with a small one

2003-06-15 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=20792

Exception with a big image but ok with a small one

   Summary: Exception with a big image but ok with a small one
   Product: Fop
   Version: 0.20.5
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: pdf renderer
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I did a test with a couple of images:
my-images/gaim_345x500.png: PNG image data, 345 x 500, 8-bit/color RGB,
non-interlaced
my-images/gaim_409x593.png: PNG image data, 409 x 593, 8-bit/color RGB,
non-interlaced

similar images but diferent size.
When I run fop.sh -d -xml big-image.xml -xsl document2fo.xsl testpng.pdf

FOP trows an exception:

java.lang.RuntimeException: org.apache.fop.apps.FOPException: No meaningful
layout in block after many attempts.  Infinite loop is assumed.  Processing halted.

But When I use a:

fop.sh -d -xml small-image.xml -xsl document2fo.xsl testpng.pdf

Everything ends fine.

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

DO NOT REPLY [Bug 20792] - Exception with a big image but ok with a small one

2003-06-15 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=20792

Exception with a big image but ok with a small one





--- Additional Comments From [EMAIL PROTECTED]  2003-06-16 03:16 ---
Created an attachment (id=6844)
test case with all the elements (dtd,xml,xsl) except jimi.jar

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

table-row wrap

2003-06-15 Thread susan atmaja 
Hi,

I have a problem with table row when the content of table cell exceeds the 
witdth specified.

E.g. a table with 3 columns, with the following values : , , 
When the value of 1st column exceeds the width specified, the last few 
characters of the first column value will be overlapped with the first few 
characters of the second column, etc. And when the columns have exceeded the 
page width, then the values are truncated.

I want the following to be the output :
Each column's value is completely displayed (no overlapping).  When the end 
of table / page is reach, I want the next values to be wrapped to the next 
row.

For example,


Please advise. Thanks.

-Susan-

_
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

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