What is changed fop-0.19 from fop-0.18?

[Se-yong, Um]

 
Hi..
 
I read CHANGES file in Fop-0.19.0-CVS-src.tar.gz, but 
lastest changes log is "Done since 0.17 release".
 
 
What is changed in fop-0.19 from fop-0.18?
Or where can I find that?
 
--
 
Se-yong, Um
Republic of Korea

PDF-generation with FOP-18.1-DEV

[Ralf Scholle]

Hello,

PDF-Documents generated by FOP 18 do no longer contain any plain text. Instead, 
everything is encoded as a stream. Since we run FOP in a host-enbironment, but want to 
use the generated documents under MS-/Windows, this causes severe problems: FOP uses 
platform encodiung (EBCDIC), then encodes the stream data by ASCII-85 or ASCII-Hex 
into different EBCDIC-Characters. Once the generated document has been transferred to 
MS Windows (with correct transformation of the encoding from EBCDIC to ASCII), the 
Acrobat Reader decodes the Hex-Data. The result is the originally generated EBCDIC, 
which is of no use for Acrobat.

This begavior is different from prior versions of FOP (eg. FOP 16). Is there any 
possibility to instruct FOP to use plain text encoding like before?

Best regards and thanks in advance

Ralf Scholle


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

Re: Mailing Lists (was: Out of Memory Error)

[Martin Stricker]

Keiron Liddle wrote:
> +1
> for fop-user list.
> 
> Keiron.

+1 for [EMAIL PROTECTED]
Martin Stricker (no committer)
-- 
Homepage: http://www.martin-stricker.de/
Registered Linux user #210635: http://counter.li.org/

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

a problem wit PDF generation

[Martin Roob]

Hello,
we have a problem with the PDF generated by FOP. We are using FOP 0.18.1 (or
better, we start using it) on OS/390. Now, the text contained in the PDF
documents seem to be generated in EBCDIC, then it is enconded to AsciiHex
and put into the PDF document enclosed by stream...endstream.
Now, when we transfer the document to Windows NT (where we want to print
it), we transfer it as a text file,
so it is converted back to ASCII. When the Acrobat reader then decodes the
stream...endstream sections,
it get EBCDIC of course, which is not what it likes to see.
So, is there anyone who knows how to supress this encoding for textual
parts.
In FOP 0.15 everything was fine.
Thanks in adnvance,
Martin Roob


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

RE: Multithreading

[Kelly Campbell]

I don't know if anyone has done any extensive testing of concurrency with
FOP, so please let us know what problems you run into (the IndexOutOfBounds
for example), either via this list, or better yet, via Bugzilla so we can
track and fix the issues. I've fixed a few places where I found concurrency
issues at one time, but I'm sure there are others I didn't find.

Someone else asked a similar question a few weeks back, so you might search
the list archives for other people's replies also.

-Kelly

> -Original Message-
> From: Heiko Barthel [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 25, 2001 5:25 AM
> To: [EMAIL PROTECTED]
> Subject: Multithreading
> 
> 
> The embedding sample servlet does not implement the 
> SingleThreadModel, so I
> guess, FOP is threadsafe. But I remember with FOP 0.18.1 I got some
> mysterious IndexOutOfBoundExceptions.
> How about multithreading with FOP in general ?
> Thanks in advance for your information.
> 
> Heiko
> 
> -- 
> GMX - Die Kommunikationsplattform im Internet.
> http://www.gmx.net
> 
> --
> GMX Tipp:
> 
> Machen Sie Ihr Hobby zu Geld bei unserem Partner 1&1!
> http://profiseller.de/info/index.php3?ac=OM.PS.PS003K00596T0409a
> 
> 
> -
> 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: build fails with jdk1.2 (jdk1.3 needed !?)

[Kelly Campbell]

As a workaround, you can probably fork out a new 1.2 JVM from 1.1 in order
to run stuff like FOP+Batik that requires the 1.2 API. Integration that way
isn't exactly clean, but it is a valid workaround that's been used many
times elsewhere :-)

Upgrading from 1.1 to 1.2 is probably a much much bigger headache than say
1.2->1.3. Best of luck.

-Kelly

> -Original Message-
> From: Art Welch [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 25, 2001 11:40 AM
> To: '[EMAIL PROTECTED]'
> Subject: RE: build fails with jdk1.2 (jdk1.3 needed !?)
> 
> 
> Since it was mentioned... Here is a brief update on my JDK 
> 1.1 travails:
> 
> A few weeks ago I made an official and very vocal proposal 
> that EastPoint
> move to JDK 1.3. I called a meeting with all the relevant people, and
> basically the consensus was that we should go to JDK 1.3. So 
> far so good.
> Unfortunately this needs to be timed with a release and the next two
> releases are scheduled for 10/2001 and 4/2002. For the 
> October release we
> will be going into code freeze in August. Unfortunately the 
> management and
> business analysis types are scared about making such a change 
> in such a
> short time frame. Anyhow, an analyst has been assigned to 
> this and now the
> project has expanded to an analysis and evaluation of all of 
> our software
> and tools. In principle this is a good idea, unfortunately although
> development could (and has) described what we have and what 
> we want, this is
> looking like it will become an unending series of meetings 
> replete with
> tables, charts, reports, and perpetual discussion. So I very 
> much doubt that
> EastPoint will be going to a new JDK anytime soon...
> 
> However, I do not think that this should deter FOP from moving ahead.
> Already the recent Batik changes cause FOP to require JDK 
> 1.2+ for some
> functionality that I want (SVG). For now I am working with a 
> version of FOP
> from before the Batik changes and patching it as needed (very 
> painful!). At
> this point I think that JDK 1.2+ is available for most platforms. A
> reasonable time period has been allowed for anyone still 
> using an older JDK
> to upgrade. Anyone that has not upgraded to a more current 
> environment at
> this point is most likely not interested or committed to new 
> technology, and
> FOP - indeed all of Apache XML - is close to the bleeding 
> edge. Should a
> very few people/companies that are only marginally interested 
> in Java/XML
> hold FOP back - I think NOT! A year ago I argued for 
> maintaining support for
> JDK 1.1, to allow users (like EastPoint) time to migrate to a 
> more current
> environment. At the time I was sure that EastPoint would have 
> upgraded long
> before now. The people in charge of this had indicated that 
> was the plan.
> Even with the layoff, sale, etc this could have been done. I 
> have yet to see
> any signs of change from the new owners.
> 
> Apologies to the list for venting a bit. Also for the length 
> - I seem to be
> incapable of writing a brief e-mail.
> 
> So, if it comes to a vote...
> 
> For changing the minimum JDK version required by FOP to 1.2 
> from 1.1 I vote:
> +1!
> 
> Art
> 
> -Original Message-
> From: Christian Geisert [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 25, 2001 4:47 AM
> To: [EMAIL PROTECTED]
> Subject: build fails with jdk1.2 (jdk1.3 needed !?)
> 
> ...
> 
> The problem is that URL.getPath() is jdk1.3+ only.
> No problem for me but I think we still have jdk.1.1 as target.
> (Maybe we can think about jdk1.2 as target, even Art talks 
> about switching
> ;-)
> 
> Christian
> 
> -
> 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: build fails with jdk1.2 (jdk1.3 needed !?)

[Art Welch]

Since it was mentioned... Here is a brief update on my JDK 1.1 travails:

A few weeks ago I made an official and very vocal proposal that EastPoint
move to JDK 1.3. I called a meeting with all the relevant people, and
basically the consensus was that we should go to JDK 1.3. So far so good.
Unfortunately this needs to be timed with a release and the next two
releases are scheduled for 10/2001 and 4/2002. For the October release we
will be going into code freeze in August. Unfortunately the management and
business analysis types are scared about making such a change in such a
short time frame. Anyhow, an analyst has been assigned to this and now the
project has expanded to an analysis and evaluation of all of our software
and tools. In principle this is a good idea, unfortunately although
development could (and has) described what we have and what we want, this is
looking like it will become an unending series of meetings replete with
tables, charts, reports, and perpetual discussion. So I very much doubt that
EastPoint will be going to a new JDK anytime soon...

However, I do not think that this should deter FOP from moving ahead.
Already the recent Batik changes cause FOP to require JDK 1.2+ for some
functionality that I want (SVG). For now I am working with a version of FOP
from before the Batik changes and patching it as needed (very painful!). At
this point I think that JDK 1.2+ is available for most platforms. A
reasonable time period has been allowed for anyone still using an older JDK
to upgrade. Anyone that has not upgraded to a more current environment at
this point is most likely not interested or committed to new technology, and
FOP - indeed all of Apache XML - is close to the bleeding edge. Should a
very few people/companies that are only marginally interested in Java/XML
hold FOP back - I think NOT! A year ago I argued for maintaining support for
JDK 1.1, to allow users (like EastPoint) time to migrate to a more current
environment. At the time I was sure that EastPoint would have upgraded long
before now. The people in charge of this had indicated that was the plan.
Even with the layoff, sale, etc this could have been done. I have yet to see
any signs of change from the new owners.

Apologies to the list for venting a bit. Also for the length - I seem to be
incapable of writing a brief e-mail.

So, if it comes to a vote...

For changing the minimum JDK version required by FOP to 1.2 from 1.1 I vote:
+1!

Art

-Original Message-
From: Christian Geisert [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 25, 2001 4:47 AM
To: [EMAIL PROTECTED]
Subject: build fails with jdk1.2 (jdk1.3 needed !?)

...

The problem is that URL.getPath() is jdk1.3+ only.
No problem for me but I think we still have jdk.1.1 as target.
(Maybe we can think about jdk1.2 as target, even Art talks about switching
;-)

Christian

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

RE: page-position="last"

[Kahn, Gary]

I'll second that one.
We use a different page layout for the last page on many of our reports.
It is also important that I include various legal info on the last page.

page-position="last" will go a long way in proving that FOP is viable for
production quality work here.

Thanks,
Gary


-Original Message-
From: Alessandro Marcellini [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 25, 2001 11:56 AM
To: [EMAIL PROTECTED]
Subject: Re: page-position="last"


Hi All,
OK, if this can move up the priority of this argument ... I say that I
need it very mutch!!
I'm building a invoice on the basis of data stored in a Database.
So, the grand total have to be written on the region-after of the last
page ONLY!!
Thank's
Alessandro


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



--
This message is intended only for the personal and confidential use of the designated 
recipient(s) named above.  If you are not the intended recipient of this message you 
are hereby notified that any review, dissemination, distribution or copying of this 
message is strictly prohibited.  This communication is for information purposes only 
and should not be regarded as an offer to sell or as a solicitation of an offer to buy 
any financial product, an official confirmation of any transaction, or as an official 
statement of Lehman Brothers.  Email transmission cannot be guaranteed to be secure or 
error-free.  Therefore, we do not represent that this information is complete or 
accurate and it should not be relied upon as such.  All information is subject to 
change without notice.



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

Embeded Fop

[Emmanuel Dupouy]

Hi,

I'm using fop to generate pdf files and it works well.

But in my xsl:fo document produced I use fonts that are not contained by
default. So I produced an xml which contains the font metrics as fop manual
says. After I made an xml configuration file to complete the font
declaration of Fop.

If I use Fop from command line I can had this new configuration file with
this option :
-c resources/FOPConfig.xml

How can I do this when I Instantiate an org.apache.fop.apps.Driver.

Do I have to de-jar Fop and add the font declaration directly in config.xml
of Fop?
Or can I pass to the additional information to Fop via my java program. I
rather prefer this last solution which much more elegant.

Thanks for any help.

Emmanuel

Emmanuel DUPOUY
[EMAIL PROTECTED]
Valtech http://www.valtech.com/
Phone (33)1 41.88.23.00 Fax (33)1 41.88.23.01



= 
Ce message et toutes les pièces jointes sont propriété de VALTECH et 
susceptibles de contenir des informations confidentielles à l'intention 
exclusive de ses destinataires. Si vous avez reçu ce message par erreur 
ou si celui ci vous est parvenu incomplet ou altéré, merci d'en avertir 
l'expéditeur par retour.Toute utilisation, diffusion ou publication non 
expressément autorisée par nous par écrit est strictement interdite. 
 -- 
This message and any attachments are Valtech property and may contain 
iconfidential information intended solely for the addressees. If your are 
not the intended recipient of this message or if you have received it 
uncomplete or altered, please notify the author by replying to his e-mail 
immediately. Any unauthorised use, diffusion or dissemination not 
expressly authorised by us in writing is strictly prohibited. 
= 
Copyright Valtech 2000 



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

Adding fonts to... the AWTRenderer

[Martin Batty]

Hi,

Is there any way I can add Arial to the AWTRenderer with 0.18.1? I've added
it to the org.apache.fop.layout.FontInfo and no error occurs when I specify
font-family="Arial" in the fo document. However, the text still appears in
SansSerif.

I this possible?

Any help is appreciated,

Martin

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

Table height

[Alessandro Marcellini]

Hi All,
I hope someone can help!
I'm using fop 0.17 on Linux.
My question is: can I have a table of fixed height?
My problem is: I've a table splitted on few pages, in the firsts pages the
table is full of rows
so it doesn't respect the height Property and fill the region-body.
Only in the last page, where the table isn't full, the height Property is
respected!

Have someone any suggestion?
Thank's & bye
Alessandro


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

problems with rowspans

[Petr Andrs]

Hi all,

in my project I am using tables with rowspans, something like this :


  
  
  
  
  

  good
  bad
  ugly
  ugly


  nice
  
dice
  
  vice


  literature
  art


  java
  music
  perl
  python

  


As you can see third row contains only two cells because place for 
other two is covered by spanning cell from previous row. My problem is 
that FOP on this line says "WARNING: Number of cell columns under table-
row not equal to number of table-columns" and completely DISCARDS this 
row, so some content is not rendered and is conpletely lost. I 
understand that implementation of rowspans is more difficult than 
colspans. But loss of data is absolutely unacceptable. Would it be 
possible not to discard rows which have less cells than count of table-
columns and render them for example as if they had empty cells at the 
end of row to match required number of table-cells. Rendered this way 
the will not look as it shoul but at least no data will be lost.

Petr Andrs

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

Re: page-position="last"

[Alessandro Marcellini]

Hi All,
OK, if this can move up the priority of this argument ... I say that I
need it very mutch!!
I'm building a invoice on the basis of data stored in a Database.
So, the grand total have to be written on the region-after of the last
page ONLY!!
Thank's
Alessandro


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

Problem with breaks

[GALLO Jean-Claude]

I wrote a page with a block element and surprisingly, the block is broken
over 2 pages. But the block contains a title displayed on the first page,
and  the body displayed on the second one.  If I run Fop version .18, the
title and the contain remains togeter on the second page, with .19, they are
separated. The keep-with-next don't work. Does it apply ?

What means "keep-with-next(broken) " in the features page of the
documentation ?

jean claude

Thanks

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

keep-together-property

[Andreas Kroop]

Hi there,

Is there a chance, that the "keep-together"-property will be realised in
a (nearly)future release ???
When I use this property, it causes no error, but it also will not work
properly...
Is there another way to the same functionality about other properties ?

thx ANDREAS...


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

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

[keiron]

keiron  01/06/25 07:15:54

  Modified:src/org/apache/fop/render/pdf PDFRenderer.java
  Log:
  workaround for a bug in Acrobat Reader where text may disappear or
  be placed in the wrong position
  
  Revision  ChangesPath
  1.70  +16 -6 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.69
  retrieving revision 1.70
  diff -u -r1.69 -r1.70
  --- PDFRenderer.java  2001/06/10 17:04:36 1.69
  +++ PDFRenderer.java  2001/06/25 14:15:45 1.70
  @@ -1,4 +1,4 @@
  -/* $Id: PDFRenderer.java,v 1.69 2001/06/10 17:04:36 arved Exp $
  +/* $Id: PDFRenderer.java,v 1.70 2001/06/25 14:15:45 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."
  @@ -374,7 +374,6 @@
   GraphicsNodeRenderContext rc = getRenderContext();
   BridgeContext ctx = new BridgeContext(userAgent, rc);
   GraphicsNode root;
  -//System.out.println("creating PDFGraphics2D");
   PDFGraphics2D graphics =
 new PDFGraphics2D(true, fs, pdfDoc,
   currentFontName, currentFontSize, currentXPosition,
  @@ -387,7 +386,7 @@
   root.paint(graphics, rc);
   currentStream.add(graphics.getString());
   } catch (Exception e) {
  -e.printStackTrace();
  +MessageHandler.errorln("Error: svg graphic could not be rendered: " + 
e.getMessage());
   }
   
   currentStream.add("Q\n");
  @@ -408,6 +407,7 @@
   true);
   
   TextPainter textPainter = new StrokingTextPainter();
  +//TextPainter textPainter = new PDFTextPainter();
   
   GraphicsNodeRableFactory gnrFactory =
 new ConcreteGraphicsNodeRableFactory();
  @@ -499,9 +499,19 @@
   int space = prevWordX - rx + prevWordWidth;
   float emDiff =
 (float) space / (float) currentFontSize * 1000f;
  -pdf.append(Float.toString(emDiff));
  -pdf.append(" ");
  -pdf.append(startText);
  +// this prevents a problem in Acrobat Reader where large
  +// numbers cause text to disappear or default to a limit
  +if(emDiff < -33000) {
  +closeText();
  +
  +pdf.append("1 0 0 1 " +(rx / 1000f) + " " +
  +   (bl / 1000f) + " Tm [" + startText);
  +textOpen = true;
  +} else {
  +pdf.append(Float.toString(emDiff));
  +pdf.append(" ");
  +pdf.append(startText);
  +}
   }
   prevWordWidth = area.getContentWidth();
   prevWordX = rx;
  
  
  

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

RE: Mailing Lists

[Fotis Jannidis]

> Keiron wrote:
> > I think we should make the move of getting a fop-user mailing list
> > and keeping the fop-dev list of development (and someone else
> > suggested it to me too).
> 
+1
for fop-user list.

Fotis

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

RE: Mailing Lists

[Alain Fagot]

Keiron wrote:
> I think we should make the move of getting a fop-user mailing list
> and keeping the fop-dev list of development (and someone else
> suggested it to me too).

+1
for fop-user list.

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

Multithreading

[Heiko Barthel]

The embedding sample servlet does not implement the SingleThreadModel, so I
guess, FOP is threadsafe. But I remember with FOP 0.18.1 I got some
mysterious IndexOutOfBoundExceptions.
How about multithreading with FOP in general ?
Thanks in advance for your information.

Heiko

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

--
GMX Tipp:

Machen Sie Ihr Hobby zu Geld bei unserem Partner 1&1!
http://profiseller.de/info/index.php3?ac=OM.PS.PS003K00596T0409a


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

RE: inline padding

[Williamson, James]

Title: RE: inline padding





Thanks Arved, 


Solved my problem, didn't think of looking at the leader element's space property.


Regards, 


James


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 24 June 2001 06:43
To: [EMAIL PROTECTED]
Subject: Re: inline padding



Quoting "Williamson, James" <[EMAIL PROTECTED]>:


> Hi All, 
> 
> Tell me to RTFM but is it possible to 'pad' inline elements, I'm trying to
> achieve something like this:
> 
> Name:     Mr Fred Bloggs
> 
> using something like this:
> 
> 
> Name
> 
> Mr Fred Bloggs
> 
> 
> 
> I've tried all the tricks I know, padding-left, padding-right, margin-left,
> and even tried a criminal ugly hack by using white spice but even that gets
> gobbled up. From what I've read the inline element is purely used to change
> the formatting of the text, it cannot influence position? I could use
> tables
> but curiosity's taken over now.
> 
> Anyone got any ideas?


I would suggest investigating the use of fo:leader. There are several different 
options by which you can use that to get a run of spaces - "leader-pattern" set 
to "use-content" with no children of fo:leader will do that, as will (naturally 
enough) "leader-pattern" with a value of "space".


Regards,
Arved Sandstrom



---
 This mail was sent through the Nova Scotia Provincial Server, 
 with technical resources provided by Chebucto Community Net.
 http://nsaccess.ns.ca/mail/ http://www.chebucto.ns.ca/



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




**
This e-mail (including any documents which may accompany it) contains
information which is confidential and may also be privileged.
It is for the exclusive use of the intended recipient(s).
If you are not the intended recipient(s) please note that any form of
distribution, copying or use of this e-mail or the information in it
or attached to it is strictly prohibited and may be unlawful.
If you have received this e-mail in error please notify us immediately
by e-mail to [EMAIL PROTECTED] or telephone +44 (0)207 940 1200 and
delete the e-mail.
Please advise immediately if you or your employer do not consent to
Internet E-Mail for messages of this type.
Information or opinions in this message that do not relate to the
business of Windsor plc and/or subsidiary and/or associated companies
shall be treated as neither given or endorsed by it.
**

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

[keiron]

keiron  01/06/25 02:01:07

  Modified:src/org/apache/fop/image FopImage.java
  Log:
  changed license
  
  Revision  ChangesPath
  1.7   +5 -49 xml-fop/src/org/apache/fop/image/FopImage.java
  
  Index: FopImage.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/image/FopImage.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- FopImage.java 2000/05/23 09:05:07 1.6
  +++ FopImage.java 2001/06/25 09:01:07 1.7
  @@ -1,53 +1,9 @@
  -/*-- $Id: FopImage.java,v 1.6 2000/05/23 09:05:07 eschaeffer Exp $ -- 
  -
  - 
  -   The Apache Software License, Version 1.1
  - 
  - 
  -Copyright (C) 1999 The Apache Software Foundation. All rights reserved.
  - 
  - Redistribution and use in source and binary forms, with or without modifica-
  - tion, are permitted provided that the following conditions are met:
  - 
  - 1. Redistributions of  source code must  retain the above copyright  notice,
  -this list of conditions and the following disclaimer.
  - 
  - 2. Redistributions in binary form must reproduce the above copyright notice,
  -this list of conditions and the following disclaimer in the documentation
  -and/or other materials provided with the distribution.
  - 
  - 3. The end-user documentation included with the redistribution, if any, must
  -include  the following  acknowledgment:  "This product includes  software
  -developed  by the  Apache Software Foundation  (http://www.apache.org/)."
  -Alternately, this  acknowledgment may  appear in the software itself,  if
  -and wherever such third-party acknowledgments normally appear.
  - 
  - 4. The names "Fop" and  "Apache Software Foundation"  must not be used to
  -endorse  or promote  products derived  from this  software without  prior
  -written permission. For written permission, please contact
  -[EMAIL PROTECTED]
  - 
  - 5. Products  derived from this software may not  be called "Apache", nor may
  -"Apache" appear  in their name,  without prior written permission  of the
  -Apache Software Foundation.
  - 
  - THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
  - INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
  - FITNESS  FOR A PARTICULAR  PURPOSE ARE  DISCLAIMED.  IN NO  EVENT SHALL  THE
  - APACHE SOFTWARE  FOUNDATION  OR ITS CONTRIBUTORS  BE LIABLE FOR  ANY DIRECT,
  - INDIRECT, INCIDENTAL, SPECIAL,  EXEMPLARY, OR CONSEQUENTIAL  DAMAGES (INCLU-
  - DING, BUT NOT LIMITED TO, PROCUREMENT  OF SUBSTITUTE GOODS OR SERVICES; LOSS
  - OF USE, DATA, OR  PROFITS; OR BUSINESS  INTERRUPTION)  HOWEVER CAUSED AND ON
  - ANY  THEORY OF LIABILITY,  WHETHER  IN CONTRACT,  STRICT LIABILITY,  OR TORT
  - (INCLUDING  NEGLIGENCE OR  OTHERWISE) ARISING IN  ANY WAY OUT OF THE  USE OF
  - THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  - 
  - This software  consists of voluntary contributions made  by many individuals
  - on  behalf of the Apache Software  Foundation and was  originally created by
  - James Tauber <[EMAIL PROTECTED]>. For more  information on the Apache 
  - Software Foundation, please see .
  - 
  +/* $Id: FopImage.java,v 1.7 2001/06/25 09:01: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.
*/
  +
   //Author:   Eric SCHAEFFER
   //Description:  represent an image object
   
  
  
  

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

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

[keiron]

keiron  01/06/25 02:00:43

  Modified:src/org/apache/fop/image FopImageFactory.java
  Log:
  compiles on jdk1.1
  fixes possible npe when no proptocal specified
  
  Revision  ChangesPath
  1.19  +10 -3 xml-fop/src/org/apache/fop/image/FopImageFactory.java
  
  Index: FopImageFactory.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/image/FopImageFactory.java,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- FopImageFactory.java  2001/06/21 14:21:11 1.18
  +++ FopImageFactory.java  2001/06/25 09:00:42 1.19
  @@ -1,4 +1,4 @@
  -/* $Id: FopImageFactory.java,v 1.18 2001/06/21 14:21:11 keiron Exp $
  +/* $Id: FopImageFactory.java,v 1.19 2001/06/25 09:00:42 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."
  @@ -43,13 +43,20 @@
   URL absoluteURL = null;
   InputStream imgIS = null;
   try {
  -absoluteURL = new URL(href);
  +try {
  +absoluteURL = new URL(href);
  +} catch (MalformedURLException mue) {
  +// if the href contains onl a path then file is assumed
  +absoluteURL = new URL("file:" + href);
  +}
   imgIS = absoluteURL.openStream();
  +} catch (MalformedURLException e_context) {
  +throw new FopImageException("Error with image URL: " + 
e_context.getMessage());
   } catch (Exception e) {
   // maybe relative
   URL context_url = null;
   try {
  -absoluteURL = new URL(Configuration.getStringValue("baseDir") + 
absoluteURL.getPath());
  +absoluteURL = new URL(Configuration.getStringValue("baseDir") + 
absoluteURL.getFile());
   } catch (MalformedURLException e_context) {
   // pb context url
   throw new FopImageException(
  
  
  

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

RE: Mailing Lists (was: Out of Memory Error)

[Ricardo Coutinho]

Regarding the out of memory error.

Some people had posted a replies to my inquiries regarding FOP and fonts.
Are those messages lost? If so then can the relevant persons please
repost???

Thanks

Ricardo

-Original Message-
From: Keiron Liddle [mailto:[EMAIL PROTECTED]]On Behalf
Of Keiron Liddle
Sent: Monday, June 25, 2001 10:28 AM
To: [EMAIL PROTECTED]
Subject: Mailing Lists (was: Out of Memory Error)


Speaking of sending things to mailing lists.

I think we should make the move of getting a fop-user mailing list and
keeping the fop-dev list of development (and someone else suggested it to
me too).

So here's my vote:

+1
for fop-user list.

Keiron.

On Fri, 22 Jun 2001 19:04:17 [EMAIL PROTECTED] wrote:
> I agree, when big patches are involved, for some reasonable definition of
> "big".
>
> I think Alex McLintock's suggestion is best - we have 2 lists, one for
> users and
> the existing one for developers only. Smaller patches, I think, should
> still go
> to the fop-dev list; my reasoning here is that committers are not
> necessarily in
> a position to commit instantly or even in a couple of days. If it's on a
> list
> then at least individual developers can apply it themselves right away if
> they
> wish. We also have better history, archiving support, visibility and
> non-repudiation if it goes to a list vice going to a number of personal
> email
> addresses.


-
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: build fails with jdk1.2 (jdk1.3 needed !?)

[Keiron Liddle]

I'll fix this, teach me for reading the latest api.

I think we probably should think of moving to 1.2 considering the growing
dependancies but not require 1.3.


On Mon, 25 Jun 2001 10:47:12 Christian Geisert wrote:
> Hi,
> 
> I just did a cvs update and got the following errors (with jdk1.2.2):
> 
> [javac]
> D:\tmp\oss\xml-fop\build\src\org\apache\fop\image\FopImageFactory.java:52:
> Method getPath() not found in class java.net.URL.
> [javac] absoluteURL = new
> URL(Configuration.getStringValue("baseDir") + absoluteURL.getPath());
>
> [javac]  
> 
> ^
> [javac]
> D:\tmp\oss\xml-fop\build\src\org\apache\fop\image\FopImageFactory.java:53:
> Exception java.net.MalformedURLException is never thrown in the body of
> the
> corresponding try statement.
> [javac] } catch (MalformedURLException e_context) {
> [javac]   ^
> [javac] 2 errors
> 
> 
> The problem is that URL.getPath() is jdk1.3+ only.
> No problem for me but I think we still have jdk.1.1 as target.
> (Maybe we can think about jdk1.2 as target, even Art talks about
> switching ;-)
> 
> Christian


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

RE: Mailing Lists (was: Out of Memory Error)

[Ricardo Coutinho]

Count me in. I think it is a good idea.

+3

Ricardo

-Original Message-
From: Michiel Verhoef [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 25, 2001 10:39 AM
To: '[EMAIL PROTECTED]'
Subject: RE: Mailing Lists (was: Out of Memory Error)


I second that so 

+2
for fop-user list.

Michiel

$ -Original Message-
$ From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
$ Sent: maandag 25 juni 2001 10:28
$ To: [EMAIL PROTECTED]
$ Subject: Mailing Lists (was: Out of Memory Error)
$ 
$ 
$ Speaking of sending things to mailing lists.
$ 
$ I think we should make the move of getting a fop-user mailing list and
$ keeping the fop-dev list of development (and someone else 
$ suggested it to
$ me too).
$ 
$ So here's my vote:
$ 
$ +1
$ for fop-user list.
$ 
$ Keiron.
$ 
$ On Fri, 22 Jun 2001 19:04:17 [EMAIL PROTECTED] wrote:
$ > I agree, when big patches are involved, for some reasonable 
$ definition of
$ > "big".
$ > 
$ > I think Alex McLintock's suggestion is best - we have 2 
$ lists, one for
$ > users and
$ > the existing one for developers only. Smaller patches, I 
$ think, should
$ > still go
$ > to the fop-dev list; my reasoning here is that committers are not
$ > necessarily in
$ > a position to commit instantly or even in a couple of days. 
$ If it's on a
$ > list
$ > then at least individual developers can apply it themselves 
$ right away if
$ > they
$ > wish. We also have better history, archiving support, visibility and
$ > non-repudiation if it goes to a list vice going to a number 
$ of personal
$ > email
$ > addresses.
$ 
$ 
$ -
$ 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: Mailing Lists (was: Out of Memory Error)

[Michiel Verhoef]

I second that so 

+2
for fop-user list.

Michiel

$ -Original Message-
$ From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
$ Sent: maandag 25 juni 2001 10:28
$ To: [EMAIL PROTECTED]
$ Subject: Mailing Lists (was: Out of Memory Error)
$ 
$ 
$ Speaking of sending things to mailing lists.
$ 
$ I think we should make the move of getting a fop-user mailing list and
$ keeping the fop-dev list of development (and someone else 
$ suggested it to
$ me too).
$ 
$ So here's my vote:
$ 
$ +1
$ for fop-user list.
$ 
$ Keiron.
$ 
$ On Fri, 22 Jun 2001 19:04:17 [EMAIL PROTECTED] wrote:
$ > I agree, when big patches are involved, for some reasonable 
$ definition of
$ > "big".
$ > 
$ > I think Alex McLintock's suggestion is best - we have 2 
$ lists, one for
$ > users and
$ > the existing one for developers only. Smaller patches, I 
$ think, should
$ > still go
$ > to the fop-dev list; my reasoning here is that committers are not
$ > necessarily in
$ > a position to commit instantly or even in a couple of days. 
$ If it's on a
$ > list
$ > then at least individual developers can apply it themselves 
$ right away if
$ > they
$ > wish. We also have better history, archiving support, visibility and
$ > non-repudiation if it goes to a list vice going to a number 
$ of personal
$ > email
$ > addresses.
$ 
$ 
$ -
$ To unsubscribe, e-mail: [EMAIL PROTECTED]
$ For additional commands, email: [EMAIL PROTECTED]
$ 

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

build fails with jdk1.2 (jdk1.3 needed !?)

[Christian Geisert]

Hi,

I just did a cvs update and got the following errors (with jdk1.2.2):

[javac]
D:\tmp\oss\xml-fop\build\src\org\apache\fop\image\FopImageFactory.java:52:
Method getPath() not found in class java.net.URL.
[javac] absoluteURL = new
URL(Configuration.getStringValue("baseDir") + absoluteURL.getPath());
   
[javac]
   
^
[javac]
D:\tmp\oss\xml-fop\build\src\org\apache\fop\image\FopImageFactory.java:53:
Exception java.net.MalformedURLException is never thrown in the body of the
corresponding try statement.
[javac] } catch (MalformedURLException e_context) {
[javac]   ^
[javac] 2 errors


The problem is that URL.getPath() is jdk1.3+ only.
No problem for me but I think we still have jdk.1.1 as target.
(Maybe we can think about jdk1.2 as target, even Art talks about switching ;-)

Christian

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

Mailing Lists (was: Out of Memory Error)

[Keiron Liddle]

Speaking of sending things to mailing lists.

I think we should make the move of getting a fop-user mailing list and
keeping the fop-dev list of development (and someone else suggested it to
me too).

So here's my vote:

+1
for fop-user list.

Keiron.

On Fri, 22 Jun 2001 19:04:17 [EMAIL PROTECTED] wrote:
> I agree, when big patches are involved, for some reasonable definition of
> "big".
> 
> I think Alex McLintock's suggestion is best - we have 2 lists, one for
> users and
> the existing one for developers only. Smaller patches, I think, should
> still go
> to the fop-dev list; my reasoning here is that committers are not
> necessarily in
> a position to commit instantly or even in a couple of days. If it's on a
> list
> then at least individual developers can apply it themselves right away if
> they
> wish. We also have better history, archiving support, visibility and
> non-repudiation if it goes to a list vice going to a number of personal
> email
> addresses.


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