Re: tables with margins and borders

[Koen . Handekyn]

Hello,
Hello Karen,

I tried it with the snapshot of the night before yesterday (due to the firewall I 
cannot get into CVS directly). It was not rendered correctly.



I have included the document (doc.xml) and the stylesheet (doc2pdf.xsl) that lead to 
docxalan.fo



If rendered to awt few borders are rendered and those rendered are not aligned with 
the table.
If rendered to pdf all borders ara rendered but all are not aligned with the table.

The version I'm using is from a file called xml-fop_20010806101537.tar.gz (it is 
stating FOP 0.19.0-CVS at startup)

Kind regards,

Koen.



Please respond to [EMAIL PROTECTED]
|--->
|  
| |
|--->
  
>---|
  |
   |
  
>---|
|--->
|   To:
| |
|--->
  
>---|
  |   [EMAIL PROTECTED]   
   |
  
>---|
|--->
|   cc:
| |
|--->
  
>---|
  |   (bcc: Koen HANDEKYN/BE/ALCATEL)  
   |
  
>---|
|--->
|  
| |
|--->
  
>---|
  |
   |
  
>---|
|--->
|   Subject:   
| |
|--->
  
>---|
  |   Re: tables with margins and borders  
   |
  
>---|




[IMAGE]
Hi Koen,

There are some table-border fixes in both PDF and AWT in the latest CVS
which probably fix this problem. Try using one of the recent source
snapshots if you can't wait for the 0.20 release. Or you can send your
.fo file and I'll see whether it still looks bad with the current
version.

Hope that helps,
Karen Lease

[EMAIL PROTECTED] wrote:

> Hello,
>
> I'm using version 0.19.0 from the di

Newbie attempting to help

[Don Wellington]

Hi-

Well, I am trying to make my first contribution to
FOP. By working on bug 2988 which I submitted.  I
willingly accept any and all help.

I tried forcing the status return from
ListItemLabel.layout to keep-with-next in an attempt
to force other code to handle keeping the
list-item-label and list-item-body together. That
didn't work, but keep-with-next is broken anyways, so
that is probably not  unexpected.  My thought right
now is to change 
the end of ListItemLabel.layout to:

if(status == Status.OK) {
   status = new Status(Status.KEEP_WITH_NEXT);
}
return status;

At least temporally, until I figure how to get FOP to
obey the keep_with_next when there is an
external-graphics as the first element in the
list-item-body. 

Anything wrong with that?  Any pointers in the right
direction?

Don Wellington

__
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

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

Re: FW: [GUMP] Build Failure - Cocoon2

[Arved Sandstrom]

At 04:26 PM 8/6/01 -0400, COFFMAN Steven wrote:
>Ok... Mark's patch breaks FOP support in Cocoon. After we get a release out,
>we need to send them a patch.
>-Steve

I don't know if we want to wait. I have enough info now to do a fairly 
creditable CHANGES file - I ought to have it in CVS within a few days, and 
then I want to allow for a few days for folks to be able to chime up and let 
me know that I left them out. So the actual release is going to happen this 
weekend coming up. I don't think we want to leave Cocoon hanging that long.

Regards,
Arved

Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia


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

Re: problems with height of cells in tables

[Arved Sandstrom]

Hi, Karen (and other interested parties)

A thought occurred to me just now. A high percentage of our bandwidth (and 
bug reports) are devoted to tables. There are so many table-related bug 
reports mainly because so many folks want to use tables, I believe, not 
because there are more bugs in tables than elsewhere.

I'm thinking that perhaps we can use table support as the centrepiece for 
all of our FOP efforts. In order to have tables be fully supported, and work 
properly, a really big percentage of the XSL specification (and FOP 
mechanics) gets exercised. Redesign of layout is something of a fuzzy goal; 
making tables work isn't.

You've currently got probably the best perspective on tables. What I am 
thinking would be useful would be a report concerning table FOs, with a 
property-by-property breakdown, that assesses what works, and what doesn't, 
and what needs to happen in order to make things work. This could drive a 
whole bunch of tasks that people could take on. It would be easier to gauge 
the progress of FOP, because table support would be a bellwether for FOP as 
a whole.

This doesn't mean that everything else would be ignored. But the shift of 
emphasis would be as follows: if I want to work on markers, I make sure that 
they work inside fo:table-and-caption, fo:table, fo:table-caption, 
fo:table-header, fo:table-footer, fo:table-body, and fo:table-cell. If 
someone wants to make sure FO X works, they make sure it works also as a 
descendant of fo:table-cell. Keiron has laid the groundwork for testing - a 
really suitable area for a first comprehensive set of test-cases could be 
(you guessed it) tables! :-)

It would be really cool if you could generate such a report concerning table 
status - we could generate tasks from the description of unimplemented or 
work-in-progress features, and take it from there. My concern at the moment 
is that a lot of what we have is somewhat superficial - things that work on 
fo:block begin to break down when blocks are nested, or occur inside lists 
and tables. I'm as guilty of this as anyone, I figure. Having one central 
major area that we can concentrate on allows us to get to the point where 
things work everywhere they are supposed to.

This is an initial thought. I'm certainly not trying to pile more work on 
your shoulders, but I genuinely believe that this is a good route to follow, 
and you can be of great assistance here.

Thanks,
Arved

Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia


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

Re: XSL-FO Engine comparisons

[Christopher Farley]

I've been using FOP in production for many months. The catch is that I
don't use it 'live'; I use it to build static PDF documents from XML
documentation. I have not personally found FOP to be very crashy with my
input docs, but I would still probably be nervous about using it live in
a servlet application...

-- 
Christopher Farley
www.northernbrewer.com

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

[Bug 2150] - New page with a table-header but without any table-body

[bugzilla]

PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT
ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW
AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE
DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL
BE LOST SOMEWHERE.

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

*** shadow/2150 Wed Jun 13 02:25:31 2001
--- shadow/2150.tmp.9188Mon Aug  6 14:41:27 2001
***
*** 2,11 
  | New page with  a table-header but without any table-body   |
  ++
  |Bug #: 2150Product: Fop |
! |   Status: NEW Version: all |
  |   Resolution:Platform: PC  |
  | Severity: MajorOS/Version: Windows NT/2K   |
! | Priority: Other Component: pdf renderer|
  ++
  |  Assigned To: [EMAIL PROTECTED]   |
  |  Reported By: [EMAIL PROTECTED]  |
--- 2,11 
  | New page with  a table-header but without any table-body   |
  ++
  |Bug #: 2150Product: Fop |
! |   Status: ASSIGNEDVersion: all |
  |   Resolution:Platform: PC  |
  | Severity: MajorOS/Version: Windows NT/2K   |
! | Priority: Other Component: page-master/layout  |
  ++
  |  Assigned To: [EMAIL PROTECTED]   |
  |  Reported By: [EMAIL PROTECTED]  |

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

[Bug 1363] - backgroud-color in fo:table-cell and fo:table-column produce no output

[bugzilla]

PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT
ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW
AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE
DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL
BE LOST SOMEWHERE.

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

*** shadow/1363 Sun May 20 17:25:22 2001
--- shadow/1363.tmp.9169Mon Aug  6 14:35:52 2001
***
*** 1,19 
! Bug#: 1363
! Product: Fop
! Version: 0.15
! Platform: PC
! OS/Version: 
! Status: NEW   
! Resolution: 
! Severity: Normal
! Priority: 
! Component: pdf renderer
! AssignedTo: [EMAIL PROTECTED],[EMAIL PROTECTED]
! ReportedBy: [EMAIL PROTECTED]   
! URL: 
! Cc: 
! Summary: backgroud-color in fo:table-cell and fo:table-column produce no output
! 
  Testing out how to create needed pdf files. Downloaded fop 
  xml-fop_20010410162819.tar.gz from your site. Working away. Found that fo:table 
  background-color and fo:block background-color properties and fo:table-row all 
--- 1,19 
! ++
! | backgroud-color in fo:table-cell and fo:table-column produce no output |
! ++
! |Bug #: 1363Product: Fop |
! |   Status: RESOLVEDVersion: 0.15|
! |   Resolution: FIXED  Platform: PC  |
! | Severity: Normal   OS/Version: All |
! | Priority: High  Component: pdf renderer|
! ++
! |  Assigned To: [EMAIL PROTECTED]   |
! |  Reported By: [EMAIL PROTECTED]  |
! |  CC list: Cc:  |
! ++
! |  URL:  |
! ++
! |  DESCRIPTION   |
  Testing out how to create needed pdf files. Downloaded fop 
  xml-fop_20010410162819.tar.gz from your site. Working away. Found that fo:table 
  background-color and fo:block background-color properties and fo:table-row all 

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

RE: logging

[Eric Galluzzo]

> And a good one.  I'm not familiar with Velocity or it's
> particular approach,
> but the basic idea of separating logging interface from logging
> implementation is sound.  Components such as fop should not require a
> particular logging implementation, they should write to an interface and
> allow different implementations of that interface to be configured.  Any
> serious application that uses fop will have its own application
> wide logging
> facilities and will not be interested in fop's logging implementation.

Actually, we had the same problem of "Which logging API do I use?"; and we
feel that others will likely have the same problem.  As a result, we wrote
an interface called Trunk (http://openinstitute.org/trunk/) that provides a
fairly full-featured generic logging interface.  There is already a Log4J
driver, and more will be written soon.  This interface could be considered
for use in FOP; and even if it is not used, please do check it out and email
with any comments that you have.

Since we just started the openinstitute.org site last week, only the
Javadocs are on there currently; but as soon as I package it up nicely and
upload it (probably within the next day or two), the code will be there too.
We're also looking for other Java developers to get involved with
openinstitute.org; so if you're interested, check out our Wiki site which is
linked off the main page at http://openinstitute.org/.

- Eric

P.S. Our ISP has been having quite a few problems lately, so if you can't
access the site, try again in a few hours.


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

[Bug 1795] - table-cell background colour doesn't work.

[bugzilla]

PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT
ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW
AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE
DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL
BE LOST SOMEWHERE.

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

*** shadow/1795 Mon May 28 01:55:44 2001
--- shadow/1795.tmp.9154Mon Aug  6 14:33:16 2001
***
*** 2,9 
  | table-cell background colour doesn't work. |
  ++
  |Bug #: 1795Product: Fop |
! |   Status: NEW Version: 0.17|
! |   Resolution:Platform: PC  |
  | Severity: Normal   OS/Version: Windows NT/2K   |
  | Priority: High  Component: general |
  ++
--- 2,9 
  | table-cell background colour doesn't work. |
  ++
  |Bug #: 1795Product: Fop |
! |   Status: RESOLVEDVersion: 0.17|
! |   Resolution: FIXED  Platform: PC  |
  | Severity: Normal   OS/Version: Windows NT/2K   |
  | Priority: High  Component: general |
  ++
***
*** 20,22 
--- 20,25 
  greetings
  
  dominik berger
+ 
+ --- Additional Comments From [EMAIL PROTECTED]  2001-08-06 14:33 ---
+ Fixed since 0.18 or maybe 0.19.
\ No newline at end of file

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

[Bug 2740] - multi-page tables sometimes render badly

[bugzilla]

PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT
ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW
AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE
DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL
BE LOST SOMEWHERE.

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

*** shadow/2740 Mon Jul 23 07:25:43 2001
--- shadow/2740.tmp.9130Mon Aug  6 14:30:47 2001
***
*** 35,37 
--- 35,44 
  --- Additional Comments From [EMAIL PROTECTED]  2001-07-23 07:25 ---
  Created an attachment (id=351)
  the badly rendered PDF - notice how row 23 is lost
+ 
+ 
+ --- Additional Comments From [EMAIL PROTECTED]  2001-08-06 14:30 ---
+ The overflow problem is fixed in CVS and will be in 0.20 release. But the test
+ file makes a different bug show up involving trailing white-space in the table
+ row. This isn't fixed yet, but the workaround is to get rid of extra white-space
+ at the end of table-cell content.
\ No newline at end of file

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

[Bug 2475] - Borders don't appear to work in

[bugzilla]

PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT
ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW
AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE
DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL
BE LOST SOMEWHERE.

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

*** shadow/2475 Fri Jul  6 05:14:24 2001
--- shadow/2475.tmp.9103Mon Aug  6 14:27:29 2001
***
*** 2,11 
  | Borders don't appear to work in  |
  ++
  |Bug #: 2475Product: Fop |
! |   Status: NEW Version: all |
  |   Resolution:Platform: PC  |
  | Severity: Normal   OS/Version: Windows NT/2K   |
! | Priority: Other Component: pdf renderer|
  ++
  |  Assigned To: [EMAIL PROTECTED]   |
  |  Reported By: [EMAIL PROTECTED]|
--- 2,11 
  | Borders don't appear to work in  |
  ++
  |Bug #: 2475Product: Fop |
! |   Status: ASSIGNEDVersion: all |
  |   Resolution:Platform: PC  |
  | Severity: Normal   OS/Version: Windows NT/2K   |
! | Priority: Other Component: general |
  ++
  |  Assigned To: [EMAIL PROTECTED]   |
  |  Reported By: [EMAIL PROTECTED]|
***
*** 33,35 
--- 33,40 
  
  'best
  -Ralph LaChance
+ 
+ --- Additional Comments From [EMAIL PROTECTED]  2001-08-06 14:27 ---
+ Known problem. borders should be taken into account on table-row if the
+ border-collapse property is set to "collapse" on table. Some clarification from
+ XSL spec is needed and is expected in the CR version.
\ No newline at end of file

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

[Bug 2964] - problems with height of cells in tables

[bugzilla]

PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT
ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW
AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE
DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL
BE LOST SOMEWHERE.

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

*** shadow/2964 Thu Aug  2 05:28:25 2001
--- shadow/2964.tmp.9076Mon Aug  6 14:23:47 2001
***
*** 23,25 
--- 23,30 
  --- Additional Comments From [EMAIL PROTECTED]  2001-08-02 05:28 
---
  Created an attachment (id=379)
  Demonstrating example
+ 
+ 
+ --- Additional Comments From [EMAIL PROTECTED]  2001-08-06 14:23 ---
+ You are right, but it's not only in tables; it's due to incorrect handling of
+ inline areas and should be fixed.
\ No newline at end of file

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

[Bug 2094] - number-rows-spanned not implemented for fo:table-body

[bugzilla]

PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT
ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW
AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE
DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL
BE LOST SOMEWHERE.

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

*** shadow/2094 Sat Jun  9 04:21:32 2001
--- shadow/2094.tmp.9063Mon Aug  6 14:22:34 2001
***
*** 2,9 
  | number-rows-spanned not implemented for fo:table-body  |
  ++
  |Bug #: 2094Product: Fop |
! |   Status: NEW Version: all |
! |   Resolution:Platform: Other   |
  | Severity: MinorOS/Version: Other   |
  | Priority: Other Component: pdf renderer|
  ++
--- 2,9 
  | number-rows-spanned not implemented for fo:table-body  |
  ++
  |Bug #: 2094Product: Fop |
! |   Status: RESOLVEDVersion: all |
! |   Resolution: FIXED  Platform: Other   |
  | Severity: MinorOS/Version: Other   |
  | Priority: Other Component: pdf renderer|
  ++
***
*** 39,41 
--- 39,45 
  total.
  
  The resulting table is discarded.
+ 
+ --- Additional Comments From [EMAIL PROTECTED]  2001-08-06 14:22 ---
+ This is fixed in CVS and will be in the 0.20 release.
+ Note: it will also work in table-header and table-footer!
\ No newline at end of file

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

[Bug 2379] - rendering a table with a grid, the table overflows the page

[bugzilla]

PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT
ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW
AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE
DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL
BE LOST SOMEWHERE.

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

*** shadow/2379 Thu Jun 28 06:49:40 2001
--- shadow/2379.tmp.9027Mon Aug  6 14:18:21 2001
***
*** 2,9 
  | rendering a table with a grid, the table overflows the page|
  ++
  |Bug #: 2379Product: Fop |
! |   Status: NEW Version: all |
! |   Resolution:Platform: PC  |
  | Severity: Blocker  OS/Version: Windows NT/2K   |
  | Priority: Other Component: pdf renderer|
  ++
--- 2,9 
  | rendering a table with a grid, the table overflows the page|
  ++
  |Bug #: 2379Product: Fop |
! |   Status: RESOLVEDVersion: all |
! |   Resolution: FIXED  Platform: PC  |
  | Severity: Blocker  OS/Version: Windows NT/2K   |
  | Priority: Other Component: pdf renderer|
  ++
***
*** 36,38 
--- 36,46 
  --- Additional Comments From [EMAIL PROTECTED]  2001-06-28 06:49 ---
  Created an attachment (id=264)
  the xml, xsl and pdf
+ 
+ 
+ --- Additional Comments From [EMAIL PROTECTED]  2001-08-06 14:18 ---
+ Problem number 2 (table with borders overflows page) is fixed in the latest CVS
+ (6 Aug. 2001, to be released as 0.20).
+ Problem number 1 (borders don't work on table-row) will only be fixed when FOP
+ correctly does the collapse-border style. This is partly waiting on expected
+ clarification when the XSL spec. goes into PR.
\ No newline at end of file

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

[Bug 2278] - left indent after table

[bugzilla]

PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT
ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW
AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE
DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL
BE LOST SOMEWHERE.

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

*** shadow/2278 Fri Jun 22 00:43:24 2001
--- shadow/2278.tmp.8734Mon Aug  6 13:50:53 2001
***
*** 2,9 
  | left indent after table|
  ++
  |Bug #: 2278Product: Fop |
! |   Status: NEW Version: all |
! |   Resolution:Platform: PC  |
  | Severity: Normal   OS/Version: Windows NT/2K   |
  | Priority: Other Component: general |
  ++
--- 2,9 
  | left indent after table|
  ++
  |Bug #: 2278Product: Fop |
! |   Status: RESOLVEDVersion: all |
! |   Resolution: WORKSFORME Platform: PC  |
  | Severity: Normal   OS/Version: Windows NT/2K   |
  | Priority: Other Component: general |
  ++
***
*** 45,47 
--- 45,53 
  --- Additional Comments From [EMAIL PROTECTED]  2001-06-22 00:43 
---
  Created an attachment (id=244)
  xsl:fo stylesheet with suspicious table for reproducing the 'bug'
+ 
+ 
+ --- Additional Comments From [EMAIL PROTECTED]  2001-08-06 13:50 ---
+ Using today's (6 Aug. 2001) CVS version of FOP, the attached fo file looks
+ normal to me. This is probably yet another table bug which has been fixed by the
+ latest changes.
\ No newline at end of file

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

Ann: Hands-on XSLT/XPath (Oct. 1-3) and XSLFO (Oct. 4-5) training (fop-dev)

[G. Ken Holman]

To Ottawa-area XML'ers (and those interested in travelling to Ottawa!):

We are again having a 5-day training blitz of two separate hands-on 
courses: 3 days of XSLT/XPath immediately followed by 2 days of XSLFO 
during the week of October 1-5, 2001.  These complementary courses provide 
comprehensive coverage over the week.

The course titles are "Practical Transformation Using XSLT and XPath" and 
"Practical Formatting Using XSLFO".

Please follow the highlighted link from our home page below for details on 
early-bird/loyalty pricing and links to the course syllabi and other 
information.  The hands-on exercises use commercial and/or non-commercial 
tools listed in the syllabi.

September 1, 2001 is the early-bird date for less-expensive course 
fees.  The courses can be taken separately, or you can save money by taking 
both courses during the one week.

After reviewing the rates on our web site, please send in your intent to 
register and we will acknowledge your intent with instructions regarding 
payment for reserving your seats (seats must be paid for to be reserved or 
they will be forfeit to other paying students).  We will also acknowledge 
if your company qualifies for the loyalty discount by having previously 
sent other students to one of our courses.  We are proud to have served 
many people in the industry with quality, highly-appreciated training.

We have had students come from the US, Asia, and Europe for these courses 
and we've learned that if you need a hotel room it is wise to book the room 
early with the hotel.  You can always cancel the hotel room if you decide 
not to register for the training, but if you leave it too late you may have 
difficulty finding one.

If you cannot make it to Ottawa, check our list of companies and 
individuals around the world who deliver the training material under 
license.  The list is growing and they are in a position to serve your 
needs with their training services!

See you in October!

 Ken

cc:
XSL List
XML-DEV
XML-L
XML-EDI
XSLFO
XSLFO-WWW
xalan-dev
fop-dev
comp.text.xml
microsoft.public.xml
microsoft.public.xsl

--
G. Ken Holman  mailto:[EMAIL PROTECTED]
Crane Softwrights Ltd.   http://www.CraneSoftwrights.com/f/
Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999   (Fax:-0995)
Web site: XSL/XML/DSSSL/SGML/OmniMark services, training, products.
Book:  Practical Transformation Using XSLT and XPath ISBN 1-894049-06-3
Article: What is XSLT? http://www.xml.com/pub/2000/08/holman/index.html
Next public instructor-led training:  2001-08-12,08-13,09-19,10-01,
- 10-04,10-22,12-09,12-10,02-02

Training Blitz: 3-days XSLT/XPath, 2-days XSLFO in Ottawa 2001-10-01/05


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

Re: tables with margins and borders

[Karen Lease]

Hi Koen,

There are some table-border fixes in both PDF and AWT in the latest CVS
which probably fix this problem. Try using one of the recent source
snapshots if you can't wait for the 0.20 release. Or you can send your
.fo file and I'll see whether it still looks bad with the current
version.

Hope that helps,
Karen Lease

[EMAIL PROTECTED] wrote:

> Hello,
> 
> I'm using version 0.19.0 from the distribution directory. It seems to have to the 
>problem both with -awt and -pdf.
> I included a snapshot from the awt renderer below.
> 
> Kind regards,
> 
> Koen.
> 
> ---
> 
> Koen,
> 
> Please indicate which version of FOP you are using
> and which renderer (-awt, -pdf, -print etc) displays
> this behavior.
> 
>  ' Best,
> -Ralph LaChance
> 
> At 11:24 AM 8/6/01 +0100, you wrote:
> 
> >I'm having some issues with the rendering of table borders. When I ask to
> >render a border around the table cell's and the table has a left margin of
> >for example 2cm, than the text is shifted correctly 2 cm to the rigth but
> >the borders appear disaligned
> >with the text, ie 2cm to much to the left (I tend to conclude that the
> >margins are not taken into account when rendering the cell borders). It
> >looks like a 'bug' to me, as the same file is rendered correctly in the
> >trial versions of the commericial tools
> >availlable?
> 
>   
>Name: pic07739.pcx
>pic07739.pcxType: unspecified type (application/octet-stream)
>Encoding: base64
> 
>   

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

Re: problems with height of cells in tables

[Karen Lease]

Arved Sandstrom wrote:
> 
> At 12:22 AM 8/6/01 +0200, Karen Lease wrote:
> >So much for the explanations. Unfortunately, I'm not sure I'll try to
> >fix this right away, since I fear that it involves some rather major
> >changes. It really comes down to the fact that the fo:inline object
> >doesn't actually generate a nested inline area, but just adds characters
> >to the LineArea. So there's no place for it to actually store the
> >line-height information. Perhaps someone else will be be braver. In any
> >case, it's certainly on the list for the layout redesign...
> 
> As soon as FOP 0.20.0 hits the streets, this is something that we may as
> well tackle and get over with. I ran into the same stumbling block a few
> weeks ago - I wanted to complete the set of FOs that can have markers, and
> fo:inline was one. Unfortunately, as you point out, fo:inline currently
> generates no area. If we are going to follow the conceptual model in the
> spec, which FOP currently does, then I figure we need to do so consistently,
> so fo:inline needs to create an area.
> 
> I actually went down the initial design and coding road a bit. My conclusion
> was that if this is carefully done then it is not that bad. I also figured
> that for an initial cut it is better to duplicate and add classes to support
> this rather than to modify any existing classes, like FOText, because they
> are too central. But one could make the argument that FOText itself maybe
> needs work, so why _not_ modify it for the general case?
> 

Yes, I pretty much agree. When I was doing the "redesign", I was working
on the concept of creating inline areas for all inline type objects
(except wrappers). I was going to just make one big "inline flow set"
with all the inline areas in a single sequence, and then do the breaking
from there. Once the line breaks were determined, then we can do the
line-height calculations according to the rules and the values of the
different properties. The biggest problem with having the actual text at
different levels in the tree is for doing things like white-space
handling, word-breaking hyphenation etc (assuming that at least some of
those should abstract from the actual inline tree).

Along those lines, and after trying to understand the white-space
handling in LineArea, I was wondering if it wouldn't be possible to do
that while building the FO tree. I was thinking of some kind of state
machine and using an iterator over the FO tree to abstract the level
problem. Sounds like I need to look into Peter's Tree work. (I'm sure
all that sounds quite obscure... oh well, just lettings people know
where I might be poking around.)

Regards,
Karen

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

[Bug 3007] New: - broken basic-link when referencing a following page

[bugzilla]

PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT
ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW
AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE
DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL
BE LOST SOMEWHERE.

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

*** shadow/3007 Mon Aug  6 13:28:29 2001
--- shadow/3007.tmp.8146Mon Aug  6 13:28:29 2001
***
*** 0 
--- 1,124 
+ ++
+ | broken basic-link when referencing a following page|
+ ++
+ |Bug #: 3007Product: Fop |
+ |   Status: NEW Version: 0.15|
+ |   Resolution:Platform: Other   |
+ | Severity: Normal   OS/Version: Other   |
+ | Priority: Other Component: general |
+ ++
+ |  Assigned To: [EMAIL PROTECTED]   |
+ |  Reported By: [EMAIL PROTECTED]   |
+ |  CC list: Cc:  |
+ ++
+ |  URL:  |
+ ++
+ |  DESCRIPTION   |
+ I am getting the following error while processing the atached file
+ 
+ ERROR: The id "Bottom" already exists in this document
+ 
+ my file locks like:
+ 
+ -- snip --
+ 
+ 
+ http://www.w3.org/1999/XSL/Format";>
+   
+   
+   
+   
+   
+ 
+   
+   
+ 
+ 
+   
+   a Link to 
+the
+ "Bottom"-ID
+   
+ 
+ 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for running into the next page 
+text for run

FW: [GUMP] Build Failure - Cocoon2

[COFFMAN Steven]

Ok... Mark's patch breaks FOP support in Cocoon. After we get a release out,
we need to send them a patch.
-Steve

-Original Message-
From: Sam Ruby [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 06, 2001 6:31 AM
To: [EMAIL PROTECTED]
Subject: [GUMP] Build Failure - Cocoon2



This email is autogenerated from the output from:



Buildfile: build.xml

init:
--- Apache Cocoon 2.1-dev [1999-2001] 

prepare:
Created dir: /home/rubys/jakarta/xml-cocoon2/build/cocoon

generate-java-code-check:

generate-java-code:
DEPRECATED - the style attribute should be relative to the project's
 basedir, not the tasks's basedir.
Transforming into
/home/rubys/jakarta/xml-cocoon2/build/cocoon/src/org/apache/cocoon/component
s/browser
Transforming into
/home/rubys/jakarta/xml-cocoon2/build/cocoon/src/org/apache/cocoon/component
s/browser
Loading stylesheet
/home/rubys/jakarta/xml-cocoon2/src/org/apache/cocoon/components/browser/Bro
wserImpl.xsl

prepare-src-main:
Created dir: /home/rubys/jakarta/xml-cocoon2/build/cocoon/classes
Copying 302 files to /home/rubys/jakarta/xml-cocoon2/build/cocoon/src

prepare-src-22-maybeupload:

prepare-src-23-maybeupload:
Copying 1 file to
/home/rubys/jakarta/xml-cocoon2/build/cocoon/src/org/apache/cocoon/environme
nt/http

prepare-src-23:

prepare-src-22:

prepare-src:

compile:
Copying 15 files to /home/rubys/jakarta/xml-cocoon2/build/cocoon/classes
Compiling 287 source files to
/home/rubys/jakarta/xml-cocoon2/build/cocoon/classes
/home/rubys/jakarta/xml-cocoon2/build/cocoon/src/org/apache/cocoon/serializa
tion/FOPSerializer.java:123: Method format() not found in class
org.apache.fop.apps.Driver.
this.driver.format();
  ^
/home/rubys/jakarta/xml-cocoon2/build/cocoon/src/org/apache/cocoon/serializa
tion/FOPSerializer.java:124: No method matching render() found in class
org.apache.fop.apps.Driver.
this.driver.render();
  ^
/home/rubys/jakarta/xml-cocoon2/build/cocoon/src/org/apache/cocoon/serializa
tion/FOPSerializer.java:125: Exception java.io.IOException is never thrown
in the body of the corresponding try statement.
} catch (IOException e) {
  ^
/home/rubys/jakarta/xml-cocoon2/build/cocoon/src/org/apache/cocoon/serializa
tion/FOPSerializer.java:128: Exception org.apache.fop.apps.FOPException is
never thrown in the body of the corresponding try statement.
} catch (FOPException e) {
  ^
Note: 14 files use or override a deprecated API.  Recompile with
"-deprecation" for details.
4 errors, 1 warning

BUILD FAILED

Compile failed, messages should have been provided.

Total time: 53 seconds

-
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: Reason for delay

[Karen Lease]

As far as I can recall, the table border placement and border-drawing
improvements (PDF only for my part) are between 0.19 and 0.20. I also
added support for the "height" property on table-row and for
display-align (except "auto") on table-cell.
Partial support for the "collapse" style of cell-borders was contributed
by Ivan Demakov (Jun 14, maybe that was already in 0.19?). The support
for "height" on table-cell was also contributed by Ivan, as I recall.

Regards,
Karen

Keiron Liddle wrote:
> 
> On Mon, 06 Aug 2001 13:17:28 Arved Sandstrom wrote:
> > Hi, all
> >
> > The main sticking point at the moment is the updating of the CHANGES
> > file. ...
> 
> 0.18 - 0.19
> - svg handled with batik, supported in pdf, awt and ps
> - svg->pdf transcoder, PDFGraphics2D for drawing into pdf
> - ps renderer
> - testing system, for use with the w3c defined testsuite.dtd including our
> tests
> 
> 0.19-0.20
> - all properties are read, a message will indicate if it is not supported
> - all elements now handled, with a message for unsupported elements
> - uses Unknown element if namespace+element not found, rather than using
> FObjMixed
> - support for only loading user fonts for pdf when needed
> - fo:wrapper should support inheriting properties better
> - table row span
> - support for drawing text into PDFGraphics2D
> - marker support (I'm sure you know)
> - streaming pdf
> - changed rendering of alpha images for svg in pdf, now uses white
> background
> - proper device information for PDFGraphics2D rendering
> - code formatted
> - element and property list mappings now added through single interface
> 
> Not sure where
> - better handling table borders
> - lines/borders render better in pdf
> - better handling of base directory, image locating
> 
> That's enough for me, my short term memory is empty.
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]

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

overflow property not working

[eric.deandrea]

I have a table with 4 columns. One of the cells has text in it that is
bigger than the size of the column and the text is over-writing the text in
the following cell. How do I stop this? I have this:










This is some text in cell 1 that
will over-write the text in cell 2.




This is some text in cell 2.




This is some text in cell 3.




This is some text in cell 4.






-Eric


Eric Deandrea
Software Engineer  (978) 698-6351  
Inforonics, Inc.   [EMAIL PROTECTED]
30 Porter Rd.
Littleton, MA 01460


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

cvs commit: xml-fop/src/org/apache/fop/layout AreaTree.java

[gears]

gears   01/08/06 10:56:35

  Modified:src/org/apache/fop/apps StreamRenderer.java
   src/org/apache/fop/layout AreaTree.java
  Log:
  This just moves the marker supporting code from before Mark's patch into
  StreamRenderer. However, I'm not satisfied that it actually works the same.
  
  Revision  ChangesPath
  1.3   +41 -0 xml-fop/src/org/apache/fop/apps/StreamRenderer.java
  
  Index: StreamRenderer.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/apps/StreamRenderer.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- StreamRenderer.java   2001/08/01 23:08:54 1.2
  +++ StreamRenderer.java   2001/08/06 17:56:35 1.3
  @@ -271,4 +271,45 @@
   return true;
   }
   }
  +
  +   public Page getNextPage(Page current, boolean isWithinPageSequence,
  +boolean isFirstCall) {
  +Page nextPage = null;
  +int pageIndex = 0;
  +if (isFirstCall)
  +pageIndex = renderQueue.size();
  +else
  +pageIndex = renderQueue.indexOf(current);
  +if ((pageIndex + 1) < renderQueue.size()) {
  +nextPage = (Page)renderQueue.elementAt(pageIndex + 1);
  +if (isWithinPageSequence
  +
&&!nextPage.getPageSequence().equals(current.getPageSequence())) {
  +nextPage = null;
  +}
  +}
  +return nextPage;
  +}
  +
  +public Page getPreviousPage(Page current, boolean isWithinPageSequence,
  +boolean isFirstCall) {
  +Page previousPage = null;
  +int pageIndex = 0;
  +if (isFirstCall)
  +pageIndex = renderQueue.size();
  +else
  +pageIndex = renderQueue.indexOf(current);
  +// System.out.println("Page index = " + pageIndex);
  +if ((pageIndex - 1) >= 0) {
  +previousPage = (Page)renderQueue.elementAt(pageIndex - 1);
  +PageSequence currentPS = current.getPageSequence();
  +// System.out.println("Current PS = '" + currentPS + "'");
  +PageSequence previousPS = previousPage.getPageSequence();
  +// System.out.println("Previous PS = '" + previousPS + "'");
  +if (isWithinPageSequence &&!previousPS.equals(currentPS)) {
  +// System.out.println("Outside page sequence");
  +previousPage = null;
  +}
  +}
  +return previousPage;
  +}
   }
  
  
  
  1.13  +3 -3  xml-fop/src/org/apache/fop/layout/AreaTree.java
  
  Index: AreaTree.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/layout/AreaTree.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- AreaTree.java 2001/08/01 23:08:54 1.12
  +++ AreaTree.java 2001/08/06 17:56:35 1.13
  @@ -1,5 +1,5 @@
   /*
  - * $Id: AreaTree.java,v 1.12 2001/08/01 23:08:54 gears Exp $
  + * $Id: AreaTree.java,v 1.13 2001/08/06 17:56:35 gears 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.
  @@ -65,12 +65,12 @@
   
   public Page getNextPage(Page current, boolean isWithinPageSequence,
   boolean isFirstCall) {
  -return current;
  +return streamRenderer.getNextPage(current, 
isWithinPageSequence,isFirstCall);
   }
   
   public Page getPreviousPage(Page current, boolean isWithinPageSequence,
   boolean isFirstCall) {
  -return current;
  +return 
streamRenderer.getPreviousPage(current,isWithinPageSequence,isFirstCall);
   }
   
   public void addPage(Page page)
  
  
  

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

Re: tables with margins and borders

[Chetan Vig]

Hi Arved,

Did you get a chance to look at the JPEG image I send you which increases the
PDF file size?

Please advise as I am not  sure what I need to do to reduce the PDF file size.

Thanks,

Chetan Vig

Arved Sandstrom wrote:

> At 11:43 AM 8/6/01 -0400, Ralph LaChance wrote:
> >fyi, the awt renderer changes are included in the latest
> >snapshot and will presumably be in 0.20.0
>
> Oh, they will be, no question about it. What's in CVS (or probably anything
> that gets added in the next couple of days) will definitely be in there.
>
> Regards,
> Arved
>
> Fairly Senior Software Type
> e-plicity (http://www.e-plicity.com)
> Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
>
> -
> 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: tables with margins and borders

[Arved Sandstrom]

At 11:43 AM 8/6/01 -0400, Ralph LaChance wrote:
>fyi, the awt renderer changes are included in the latest
>snapshot and will presumably be in 0.20.0

Oh, they will be, no question about it. What's in CVS (or probably anything 
that gets added in the next couple of days) will definitely be in there.

Regards,
Arved

Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia


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

Re: tables with margins and borders

[Ralph LaChance]

At 12:44 PM 8/6/01 +0100, you wrote:
>I'm using version 0.19.0 from the distribution directory. It seems to have 
>to the problem both with -awt and -pdf.
>I included a snapshot from the awt renderer below.

We fixed a few thing regarding border placement
in the awt renderer (-awt, -print), although I'm not
completely sure this covers what your seeing --
particularly since you report problems in PDF.
(I believe everything we did simply fixed things that
rendered differently in -awt  and -print vs -pdf.)

fyi, the awt renderer changes are included in the latest
snapshot and will presumably be in 0.20.0


 ' Best,
 -Ralph LaChance



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

Re: Reason for delay

[Ralph LaChance]

At 02:13 PM 8/6/01 +0200, you wrote:
>Just to give you a hand, I'll try to remember some of the things that have
>been changed (by various people).

here's our $.02   (effective 0.20)

AWTRenders  (-awt and -print options)
 - eliminated 3D-effect in rendering background color
 - borders now draw wider than 1 pixel if appropriate
 - fixed a roundoff error in background and border dimension/location
 - fixed a positioning error on Top and Right borders



 ' Best,
 -Ralph LaChance



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

RE: logging

[Alistair Hopkins]

+1 to that
And while we're here, is there any way to switch OFF SVG support so the
batik jar is dispensible?  I'm using fop as the printing API for a
desktop/Swing app and it is brilliant (proper print preview, high quality
saved and printed documents, easy format to build with) but the size of the
jars is quite a big issue: it's about 80% of the size of the application
right now!  More jars are not needed.

Al
ps - I log in a pretty crude way (debug, info, warn, error) to a class which
ATTEMPTS to load log4j and use that: but if it can't, or if it's called on a
thread before log4j has initialised properly, it just writes to stdout.

-Original Message-
From: Joe Batt [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 03, 2001 4:13 PM
To: [EMAIL PROTECTED]
Subject: Re: logging


When FOP is a production ready library, I wont care for any FOP logging.
Logging in FOP now is only for debugging as far as I'm concerned. There
is no need for integration into other logging systems.

Think about how you use other libraries.

Joe


-
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: logging

[Joe Batt]

When FOP is a production ready library, I wont care for any FOP logging.
Logging in FOP now is only for debugging as far as I'm concerned. There
is no need for integration into other logging systems.

Think about how you use other libraries.

Joe


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

Re: logging

[Keiron Liddle]

On Fri, 03 Aug 2001 15:34:26 Daniel Parker wrote:
> And a good one.  I'm not familiar with Velocity or it's particular
> approach,
> but the basic idea of separating logging interface from logging
> implementation is sound.  Components such as fop should not require a
> particular logging implementation, they should write to an interface and
> allow different implementations of that interface to be configured.  Any
> serious application that uses fop will have its own application wide
> logging
> facilities and will not be interested in fop's logging implementation.
> 
> Regards,
> Daniel Parker

That is exactly the role of a logging implementation (logkit etc.) it takes
care of that.
By that argument, if fop is to work with velocity we should have an
interface that can use fop's logging interface or velocity. Then each of
those two interfaces will interface to logkit, log4j etc. Then logkit and
log4j have there own mechanism for directing output etc.

So instead we can simply say that fop uses logkit.
If you want to direct the logging to somewhere else (log4j, your own system
etc.) then you need to create a target for logkit that does that for you.

After all fop needs _a_ logging implementation.


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

Re: Reason for delay

[Keiron Liddle]

On Mon, 06 Aug 2001 13:17:28 Arved Sandstrom wrote:
> Hi, all
> 
> The main sticking point at the moment is the updating of the CHANGES
> file. I 
> have not yet mustered up the courage to do this. We actually need 2 sets
> of 
> changes added - 0.18 to 0.19, and 0.19 to 0.20. I have no idea how long
> this 
> will take so I'm not going to speculate exactly on when I can build the 
> release itself. But for anyone wrapping up loose ends, you can certainly 
> assume next weekend and no earlier.

Just to give you a hand, I'll try to remember some of the things that have
been changed (by various people). Hopefully I can remember it correctly.
I'm sure I have forgotten some things...

0.18 - 0.19
- svg handled with batik, supported in pdf, awt and ps
- svg->pdf transcoder, PDFGraphics2D for drawing into pdf
- ps renderer
- testing system, for use with the w3c defined testsuite.dtd including our
tests


0.19-0.20
- all properties are read, a message will indicate if it is not supported
- all elements now handled, with a message for unsupported elements
- uses Unknown element if namespace+element not found, rather than using
FObjMixed
- support for only loading user fonts for pdf when needed
- fo:wrapper should support inheriting properties better
- table row span
- support for drawing text into PDFGraphics2D
- marker support (I'm sure you know)
- streaming pdf
- changed rendering of alpha images for svg in pdf, now uses white
background
- proper device information for PDFGraphics2D rendering
- code formatted
- element and property list mappings now added through single interface


Not sure where
- better handling table borders
- lines/borders render better in pdf
- better handling of base directory, image locating


That's enough for me, my short term memory is empty.

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

Re: problems with height of cells in tables

[Arved Sandstrom]

At 12:22 AM 8/6/01 +0200, Karen Lease wrote:
>So much for the explanations. Unfortunately, I'm not sure I'll try to
>fix this right away, since I fear that it involves some rather major
>changes. It really comes down to the fact that the fo:inline object
>doesn't actually generate a nested inline area, but just adds characters
>to the LineArea. So there's no place for it to actually store the
>line-height information. Perhaps someone else will be be braver. In any
>case, it's certainly on the list for the layout redesign...

As soon as FOP 0.20.0 hits the streets, this is something that we may as 
well tackle and get over with. I ran into the same stumbling block a few 
weeks ago - I wanted to complete the set of FOs that can have markers, and 
fo:inline was one. Unfortunately, as you point out, fo:inline currently 
generates no area. If we are going to follow the conceptual model in the 
spec, which FOP currently does, then I figure we need to do so consistently, 
so fo:inline needs to create an area.

I actually went down the initial design and coding road a bit. My conclusion 
was that if this is carefully done then it is not that bad. I also figured 
that for an initial cut it is better to duplicate and add classes to support 
this rather than to modify any existing classes, like FOText, because they 
are too central. But one could make the argument that FOText itself maybe 
needs work, so why _not_ modify it for the general case?

Regards,
Arved Sandstrom

Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia


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

Re: tables with margins and borders

[Ralph LaChance]

Koen,

Please indicate which version of FOP you are using
and which renderer (-awt, -pdf, -print etc) displays
this behavior.

 ' Best,
 -Ralph LaChance


At 11:24 AM 8/6/01 +0100, you wrote:
>I'm having some issues with the rendering of table borders. When I ask to 
>render a border around the table cell's and the table has a left margin of 
>for example 2cm, than the text is shifted correctly 2 cm to the rigth but 
>the borders appear disaligned
>with the text, ie 2cm to much to the left (I tend to conclude that the 
>margins are not taken into account when rendering the cell borders). It 
>looks like a 'bug' to me, as the same file is rendered correctly in the 
>trial versions of the commericial tools
>availlable?





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

Reason for delay

[Arved Sandstrom]

Hi, all

The main sticking point at the moment is the updating of the CHANGES file. I 
have not yet mustered up the courage to do this. We actually need 2 sets of 
changes added - 0.18 to 0.19, and 0.19 to 0.20. I have no idea how long this 
will take so I'm not going to speculate exactly on when I can build the 
release itself. But for anyone wrapping up loose ends, you can certainly 
assume next weekend and no earlier.

Regards,
Arved Sandstrom

Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia


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

Re: Linking inside a single pdf file made using fop??

[Keiron Liddle]

If you are lookng for any examples of things that are implemented in FOP a
good place to start is the docs/examples directory.

You are probably looking for something like this example
docs/examples/fo/newlinktest.fo

it has both internal and external links.

On Mon, 06 Aug 2001 12:20:26 rajeev nair wrote:
> Hi all,
> how can i make a pdf file in which there is liking
> from one location to another using FOP.
> IS it possible with fo:basic-link? If yes, what is the
> 
> syntax.
> I linked two pdf files using fo:basic-link.
> But my actual need is to have an index which links to 
> the specified topic locations in the same pdf file.
> any help is greately appreciated.
> regards
> rajiv


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

tables with margins and borders

[Koen . Handekyn]

Hello,

I'm having some issues with the rendering of table borders. When I ask to render a 
border around the table cell's and the table has a left margin of for example 2cm, 
than the text is shifted correctly 2 cm to the rigth but the borders appear disaligned
with the text, ie 2cm to much to the left (I tend to conclude that the margins are not 
taken into account when rendering the cell borders). It looks like a 'bug' to me, as 
the same file is rendered correctly in the trial versions of the commericial tools
availlable?

kind regards,

Koen.

--

                
                                
                                                
                        
                




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

Linking inside a single pdf file made using fop??

[rajeev nair]

Hi all,
how can i make a pdf file in which there is liking
from one location to another using FOP.
IS it possible with fo:basic-link? If yes, what is the

syntax.
I linked two pdf files using fo:basic-link.
But my actual need is to have an index which links to 
the specified topic locations in the same pdf file.
any help is greately appreciated.
regards
rajiv


__
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

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

Re: [PATCH] Support for lazy-loading of metrics file

[Keiron Liddle]

Looks fine to me. So I have committed it (with some minor modifications).

Good stuff.

On Sun, 05 Aug 2001 09:14:55 SASAKI Suguru wrote:
> 
> Hi.
> 
> Current Fop loads all font metrics files in startup , even if
> corresponding fonts are not used in FO document. This wastes
> memory and time, when not all registered fonts are used in FO
> (that is, I guess, almost always). So, metrics files should be
> lazy-loaded.
> 
> In Attatched patch, lazy-loading in PDFRenderer is implemented.
>  Changes:
>   1. add org/apache/fop/render/pdf/fonts/LazyFont.java
>  (wrapper for Multi/SingleByteFont)
>   2. In startup, add LazyFont to FontInfo.
>  When metrics file is needed, LazyFont loads it automatically.
>  When embeding font, get "real" font (Multi/SingleByteFont)
>  instance thorough LazyFont.getRealFont() and output as before.
> 
> Regards.
> 
> ===
> SASAKI Suguru
>   mailto : [EMAIL PROTECTED]


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

cvs commit: xml-fop/src/org/apache/fop/render/pdf/fonts LazyFont.java

[keiron]

keiron  01/08/06 02:43:08

  Modified:src/org/apache/fop/pdf PDFDocument.java
   src/org/apache/fop/render/pdf FontSetup.java
PDFRenderer.java
  Added:   src/org/apache/fop/render/pdf/fonts LazyFont.java
  Log:
  adds support for lazy loading of fonts
  saves some cpu, memory
  Submitted by: SASAKI Suguru <[EMAIL PROTECTED]>
  Reviewed by:  Keiron
  
  Revision  ChangesPath
  1.27  +8 -2  xml-fop/src/org/apache/fop/pdf/PDFDocument.java
  
  Index: PDFDocument.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/pdf/PDFDocument.java,v
  retrieving revision 1.26
  retrieving revision 1.27
  diff -u -r1.26 -r1.27
  --- PDFDocument.java  2001/08/01 23:08:54 1.26
  +++ PDFDocument.java  2001/08/06 09:43:07 1.27
  @@ -1,5 +1,5 @@
   /*
  - * $Id: PDFDocument.java,v 1.26 2001/08/01 23:08:54 gears Exp $
  + * $Id: PDFDocument.java,v 1.27 2001/08/06 09:43:07 keiron 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.
  @@ -18,6 +18,7 @@
   import org.apache.fop.datatypes.ColorSpace;
   
   import org.apache.fop.render.pdf.CIDFont;
  +import org.apache.fop.render.pdf.fonts.LazyFont;
   
   import org.apache.fop.datatypes.IDReferences;
   import org.apache.fop.layout.Page;
  @@ -813,7 +814,12 @@
   font.setDescriptor(pdfdesc);
   
   if (subtype == PDFFont.TYPE0) {
  -CIDFont cidMetrics = (CIDFont)metrics;
  +CIDFont cidMetrics;
  +if(metrics instanceof LazyFont){
  +cidMetrics = (CIDFont) ((LazyFont) metrics).getRealFont();
  +}else{
  +cidMetrics = (CIDFont)metrics;
  +}
   PDFCIDSystemInfo sysInfo =
   new PDFCIDSystemInfo(cidMetrics.getRegistry(),
cidMetrics.getOrdering(),
  
  
  
  1.13  +8 -2  xml-fop/src/org/apache/fop/render/pdf/FontSetup.java
  
  Index: FontSetup.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/render/pdf/FontSetup.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- FontSetup.java2001/07/30 20:29:33 1.12
  +++ FontSetup.java2001/08/06 09:43:07 1.13
  @@ -1,5 +1,5 @@
   /*
  - * $Id: FontSetup.java,v 1.12 2001/07/30 20:29:33 tore Exp $
  + * $Id: FontSetup.java,v 1.13 2001/08/06 09:43:07 keiron 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.
  @@ -156,11 +156,17 @@
   if (metricsFile != null) {
   internalName = "F" + num;
   num++;
  +/*
   reader = new FontReader(metricsFile);
   reader.useKerning(configFontInfo.getKerning());
   reader.setFontEmbedPath(configFontInfo.getEmbedFile());
   fontInfo.addMetrics(internalName, reader.getFont());
  -
  +*/
  +LazyFont font = new LazyFont(configFontInfo.getEmbedFile(),
  + metricsFile,
  + configFontInfo.getKerning());
  +fontInfo.addMetrics(internalName, font);
  +
   Vector triplets = configFontInfo.getFontTriplets();
   for (Enumeration t = triplets.elements();
   t.hasMoreElements(); ) {
  
  
  
  1.79  +8 -2  xml-fop/src/org/apache/fop/render/pdf/PDFRenderer.java
  
  Index: PDFRenderer.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/render/pdf/PDFRenderer.java,v
  retrieving revision 1.78
  retrieving revision 1.79
  diff -u -r1.78 -r1.79
  --- PDFRenderer.java  2001/08/06 06:21:02 1.78
  +++ PDFRenderer.java  2001/08/06 09:43:07 1.79
  @@ -1,5 +1,5 @@
   /*
  - * $Id: PDFRenderer.java,v 1.78 2001/08/06 06:21:02 keiron Exp $
  + * $Id: PDFRenderer.java,v 1.79 2001/08/06 09:43:07 keiron 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.
  @@ -22,6 +22,7 @@
   import org.apache.fop.image.*;
   import org.apache.fop.extensions.*;
   import org.apache.fop.datatypes.IDReferences;
  +import org.apache.fop.render.pdf.fonts.LazyFont;
   
   import org.apache.batik.bridge.*;
   import org.apache.batik.swing.svg.*;
  @@ -487,8 +488,13 @@
 

Re: problems with height of cells in tables

[Karen Lease]

Hi Peter,

Thanks for the test files. Yes, you are right that font metrics
influence the calculation. In fact, these examples point out a number of
problems with FOP's line sizing logic. The sizing is really determined
by the font-family and font-size specified or inherited on the fo:block
containing the text. The actual size of the text is ignored in
calculating the line height! So the last four lines of your table
correspond to this:

1. 18pt, Arial
2. 18pt,  default font-family (sans-serif)
3. default font-size (12pt), Arial
4. default font-size (12pt), default font-family (sans-serif)

The font metrics for Arial obviously have a larger ascender value than
those for the default font.

So much for the explanations. Unfortunately, I'm not sure I'll try to
fix this right away, since I fear that it involves some rather major
changes. It really comes down to the fact that the fo:inline object
doesn't actually generate a nested inline area, but just adds characters
to the LineArea. So there's no place for it to actually store the
line-height information. Perhaps someone else will be be braver. In any
case, it's certainly on the list for the layout redesign...

Regards,
Karen

Petr Andrs wrote:
> 
> Hi Karen,
> 
> I have made some further investigation. I agree that this is probably
> not specific to tables, but it is better observable on tables. When
> using embedded TTF fonts, height of line is influenced also by font-
> family attribute. If font-family is specified on table-row or cell (I
> think it can be generalized to any block level object) height of line
> is different from case when font-family is specified on inline level
> object. So I made simple testing example. I made table with lines
> having all possible combinations of place of specificatin of font-size
> and font-family (at block level v. at inline level) resulting in four
> table lines. Then I made more combinations using two different font-
> sizes and two different font-families resulting in 16 line table.
> Results of this experiment are attached. You can notice than every line
> printed by Arial 18pt (the four bottom lines) has its own unique height
> of line. So it maybe has something to do with usage of font metrics.
> 
> Petr
> 
> On 5 Aug 2001, at 0:16 Karen Lease wrote about Re: problems with height of cells i :
> 
> > Hi Petr,
> >
> > I've looked at this quickly and my first reaction is that it's probably
> > not specific to tables. I think it has to do with line-height (aka
> > leading in old typographic terms). Neither font-size nor line-height are
> > specified at a high level in your .fo. The default font-size is 12pt and
> > the default line-height 1.2 em (14.4pt). When you set font-size at the
> > block level as in the last row, that will also change the line-height,
> > since it's relative, so the total height is smaller. When you set
> > font-size at the inline or wrapper, it apparently isn't changing
> > line-height. I guess since line-height can be specified for both
> > fo:ineline and fo:character (via the fo:wrapper), that the line-height
> > should also be modified by setting font-size on those objects too.
> >
> > Good eye!
> 
> on thousand lines the difference makes several pages so it is quite
> noticable
> 
> > Regards,
> > Karen
> >
> > Petr Andrs wrote:
> > >
> > > Please see attached file. There is table with three lines, which all
> > > should have equal height. But they haven't, the last one has lower
> > > height than the other two. (Or the fist two have greater height than
> > > the las one) I would expect all three lines to look something like the
> > > last one, the first two are too high for my eye.
> > >
> > > Petr
> 
>   
>  Name: emptest.fo
>emptest.foType: unspecified type (Application/Octet-stream)
>  Encoding: BASE64
> 
>   Name: emptest.pdf
>emptest.pdfType: Portable Document Format (application/pdf)
>   Encoding: BASE64
> 
>   
> -
> 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/codegen foproperties.xml

[keiron]

keiron  01/08/06 02:17:24

  Modified:src/codegen foproperties.xml
  Log:
  setup a couple of props
  
  Revision  ChangesPath
  1.23  +8 -3  xml-fop/src/codegen/foproperties.xml
  
  Index: foproperties.xml
  ===
  RCS file: /home/cvs/xml-fop/src/codegen/foproperties.xml,v
  retrieving revision 1.22
  retrieving revision 1.23
  diff -u -r1.22 -r1.23
  --- foproperties.xml  2001/07/26 00:53:26 1.22
  +++ foproperties.xml  2001/08/06 09:17:24 1.23
  @@ -213,13 +213,13 @@
 
   source-document
   false
  -ToBeImplemented
  +String
   none
 
 
   role
   false
  -ToBeImplemented
  +String
   none
 
   
  @@ -915,7 +915,12 @@
 
   baseline-shift
   false
  -ToBeImplemented
  +Length
  +  
  +baseline
  +sub
  +super
  +  
   baseline
 
 
  
  
  

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

cvs commit: xml-fop/src/org/apache/fop/layout AbsolutePositionProps.java AccessibilityProps.java AuralProps.java MarginInlineProps.java RelativePositionProps.java BackgroundProps.java

[keiron]

keiron  01/08/06 02:14:24

  Modified:src/org/apache/fop/layout BackgroundProps.java
  Added:   src/org/apache/fop/layout AbsolutePositionProps.java
AccessibilityProps.java AuralProps.java
MarginInlineProps.java RelativePositionProps.java
  Log:
  adds the remaining property groups
  
  Revision  ChangesPath
  1.3   +11 -1 xml-fop/src/org/apache/fop/layout/BackgroundProps.java
  
  Index: BackgroundProps.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/layout/BackgroundProps.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- BackgroundProps.java  2001/07/30 20:29:27 1.2
  +++ BackgroundProps.java  2001/08/06 09:14:24 1.3
  @@ -1,5 +1,5 @@
   /*
  - * $Id: BackgroundProps.java,v 1.2 2001/07/30 20:29:27 tore Exp $
  + * $Id: BackgroundProps.java,v 1.3 2001/08/06 09:14:24 keiron 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.
  @@ -7,11 +7,21 @@
   
   package org.apache.fop.layout;
   
  +import org.apache.fop.datatypes.Length;
  +
  +import java.awt.Color;
  +
   /**
* Store all hyphenation related properties on an FO.
* Public "structure" allows direct member access.
*/
   public class BackgroundProps {
  +public int backAttachment;
  +public Color backColor;
  +public String backImage;
  +public int backRepeat;
  +public Length backPosHorizontal;
  +public Length backPosVertical;
   
   public BackgroundProps() {}
   
  
  
  
  1.1  xml-fop/src/org/apache/fop/layout/AbsolutePositionProps.java
  
  Index: AbsolutePositionProps.java
  ===
  /*
   * $Id: AbsolutePositionProps.java,v 1.1 2001/08/06 09:14:24 keiron 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.
   */
  
  package org.apache.fop.layout;
  
  import org.apache.fop.datatypes.Length;
  
  /**
   * Store all hyphenation related properties on an FO.
   * Public "structure" allows direct member access.
   */
  public class AbsolutePositionProps {
  public int absolutePosition;
  public Length top;
  public Length right;
  public Length bottom;
  public Length left;
  
  public AbsolutePositionProps() {}
  
  }
  
  
  
  1.1  xml-fop/src/org/apache/fop/layout/AccessibilityProps.java
  
  Index: AccessibilityProps.java
  ===
  /*
   * $Id: AccessibilityProps.java,v 1.1 2001/08/06 09:14:24 keiron 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.
   */
  
  package org.apache.fop.layout;
  
  /**
   * Store all hyphenation related properties on an FO.
   * Public "structure" allows direct member access.
   */
  public class AccessibilityProps {
  public String sourceDoc = null;
  public String role = null;
  
  public AccessibilityProps() {}
  
  }
  
  
  
  1.1  xml-fop/src/org/apache/fop/layout/AuralProps.java
  
  Index: AuralProps.java
  ===
  /*
   * $Id: AuralProps.java,v 1.1 2001/08/06 09:14:24 keiron 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.
   */
  
  package org.apache.fop.layout;
  
  /**
   * Store all hyphenation related properties on an FO.
   * Public "structure" allows direct member access.
   */
  public class AuralProps {
  public int azimuth;
  public String cueAfter;
  public String cueBefore;
  public int elevation;
  public int pauseAfter;
  public int pauseBefore;
  public int pitch;
  public int pitchRange;
  public int playDuring;
  public int richness;
  public int speak;
  public int speakHeader;
  public int speakNumeral;
  public int speakPunctuation;
  public int speechRate;
  public int stress;
  public int voiceFamily;
  public int volume;
  
  public AuralProps() {}
  
  }
  
  
  
  1.1  xml-fop/src/org/apache/fop/layout/MarginInlineProps.java
  
  Index: MarginInlineProps.java
  ===
  /*
   * $Id: MarginInlineProps.java,v 1.1 2001/08/06 09:14:24 keiron Exp $
   * Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
   * For details on use and redistribution pleas