Problems with SVG to PS/EPS

2005-11-11 Thread Jeremias Maerki
I tried to do the same changes as were done to the SVG/PDF support
lately. I ended up having weird differences in behaviour between PS and
PDF so this takes longer than expected. I'll leave it for now. The
SVG/PS support provides a more or less acceptable feature level right
now, so I'm going to put it aside for now and work on it after the
release. Just so everyone knows.

Jeremias Maerki



Sandbox created

2005-11-11 Thread Jeremias Maerki
Ok, the sandbox is created and the PCL, SVG and MIF support moved there.
Would someone on Unix please verify that the fop script picks up the
new fop-sandbox.jar and that the three renderers in there are recognized?
Thanks.

Jeremias Maerki



Re: Sandbox created

2005-11-11 Thread Andreas L Delmelle

On Nov 11, 2005, at 16:04, Jeremias Maerki wrote:

Ok, the sandbox is created and the PCL, SVG and MIF support moved  
there.

Would someone on Unix please verify that the fop script picks up the
new fop-sandbox.jar and that the three renderers in there are  
recognized?


FYI: ran a test for PCL and SVG output on OS X, and encountered no  
problems whatsoever, so seems to be fine.



Cheers,

Andreas



Re: Preparing for the first release

2005-11-11 Thread Manuel Mall
Just for the record -

The current version of fop (r332584) builds and passes all JUnit tests 
under RedHat ES 3 for:
jdk1.3.1_16 (1.3.1_16-b06)
j2sdk1.4.2_06 (1.4.2_06-b03)
java-1.5.0 (1.5.0_03-b07)

Manuel


DO NOT REPLY [Bug 37468] New: - Multi-Column-Page Layout Issues

2005-11-11 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=37468.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37468

   Summary: Multi-Column-Page Layout Issues
   Product: Fop
   Version: 1.0dev
  Platform: Other
OS/Version: Windows XP
Status: NEW
  Keywords: RFC
  Severity: blocker
  Priority: P3
 Component: page-master/layout
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: [EMAIL PROTECTED]


Hi, this is the first time I've used Bugzilla, so please bare with me, because 
I've got some real bug issues here.  I've looked and looked everywhere I could 
possibly try on the internet, and I have not found any documentation on the 
internet regarding this issue.  Actually, it's two issues (related, but most 
likely separate issues).  I will work with anyone who's prepared to tackle 
this problem, and I can provide screen shots, code samples (of the 
intermediate FO) or whatever it will take to fix this.  I'm working on a 
development project that will go into production soon, and I've already 
migrated my code to the newer trunk version (just recompiled the source 
yesterday, so I'm up to date.)  I'm also running WinXP with JDK1.5, if that 
helps.

Anyway, here we go..

Issue 1 (Minor) - The page regions defined on multi-column pages does not 
position correctly, and always renders offset a specific amount.  

Every fo:region-body I set up with column-count set to more than 1 seems to 
create the column layout such that the columns on the right-hand side of the 
page are smushed into the page.  (WORKAROUND: Big hint here.)  I've found a 
workaround that corrects this problem, and will most likely help you determine 
where this bug is located.  If the margin-right property for the fo:region-
body is recalculated, all columns display correctly (correct widths, position, 
and gaps).  From what I can gather, here is the way to determine what to 
change the margin-right property to:  margin-right = intended-margin-right - 
offset.  offset = (column-count - 1) * column-gap.  (or, offset = num-gaps * 
column-gap).

Example:
Create a page  body with margin-left=0.0in and margin-right=0.0in.  
Specify column-count=3 and column-gap=0.5in.  (This will leave 7.5in for 
column space, giving columns of 2.5in each from page-edge to page-edge.)  Fill 
up the page with one block filled with any text, and watch as the right side 
of the page shows a huge margin while the left side of the page is text to the 
edge like we intended.  Now determine the offset, which is 2 gaps * 0.5in/gap 
= 1.0in.  So with our intended margin-right of 0.0, set margin-right=-
1.0in.  Voila, it runs text to the edge of the page.  Try this again with 6 
columns, 0.5in gaps. That should create 5 gaps with 0.5in each, 6 columns of 
1in each.  The margin is off again, so recalculate margin-right to be -2.5in 
and again, it will display correctly.
(I can provide my code that I'm using in my product, which shows the same 
thing above, just not as nice-looking numbers to do the math in your head 
for.  Try it above with left-right margins set to 0.40625in (13/32in.) This 
workaround still works.  Okay, thats enough of that issue..  It's an issue 
that I can live with the work-around for now..  my next issue I cannot solve 
myself, and it's a real pain.)

Issue 2 (Major) - On multi-column pages, text inside fo:block with flow to the 
next column (or page, if filled last column), but fo:table and all other 
fo:table-level-elements will not flow to the next column on the same page.

Fo:table will not continue to display on the current page once a break is 
detected (or the break is determined to be page-level and not column-level, as 
it should be).  I've tried creating tables of all sizes, one-by-one tables, 
2x1 tables, 2xmany tables, 1xmany tables, nothing will force the table to 
appear in the next column, with the exception of a break-before or break-after 
found on fo:table-row within the fo:table-body.  This property also needs to 
be set to column for it to work.  My main problem is that I have a large 
table with a lot of rows, and a header I need display every time there's a 
break, so tables are necessary because the breaks cannot be determined 
manually.  Instead of the intended behavior of the tables breaking to the next 
column and displaying the header, it will simply break to the next page, 
leaving the rest of the current page blank, and simply continue in the first 
column of the following page as if it's the next column it should appear.  All 
other behavior appears correct (header displays, breaks when it should, but 
wrong break context.)  I should point out that manually calling break-after or 
break-before WILL force the table to break to 

Re: Sandbox created

2005-11-11 Thread Simon Pepping
On Fri, Nov 11, 2005 at 04:13:18PM +0100, Andreas L Delmelle wrote:
 On Nov 11, 2005, at 16:04, Jeremias Maerki wrote:
 
 Ok, the sandbox is created and the PCL, SVG and MIF support moved  
 there.
 Would someone on Unix please verify that the fop script picks up the
 new fop-sandbox.jar and that the three renderers in there are  
 recognized?
 
 FYI: ran a test for PCL and SVG output on OS X, and encountered no  
 problems whatsoever, so seems to be fine.

The script works OK on Debian GNU/Linux. 

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl