RE: Cocoon 2.1 + Encryption

2004-06-07 Thread Andreas L. Delmelle 
> -Original Message-
> From: Martin Mauri [mailto:[EMAIL PROTECTED]
>

Hi,

> I've installed everything like appars in
> http://wiki.cocoondev.org/Wiki.jsp?page=FOPPDFEncryption but I
> can't get it working, could it be a problem with the API?

Nope. It's most probably related to the fact that the FOP 0.20.5
distribution jar was compiled without encryption support...

> Can anybody tell me what jar should be placed and where?

Try downloading the source, rebuild the jar from scratch on a system having
JCE present, and replace the jar that gets distributed with Cocoon by the
new one.

IIC, that should be all there is to it (however, there *should* be some
logging message somewhere telling you that encryption is unavailable... is
there?)

HTH!

Greetz,

Andreas


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

Re: Image Size Calculations

2004-06-07 Thread Christian Hattemer 
Clay Leeds wrote:

> If it's true that graphics measurements specified in INCHES yields 
> better results than PX, that certainly is news, and would (if 
> reproducible) warrant special mention on the FOP Graphics page. Can you 
> also do a test to see if the results are similar if you specify mm and 
> cm (millimeters & centimeters of course ;-)) as well?

I just found out that xpdf has fooled me. The default magnification level is
125%. It's clear that the images don't look good because they have been
scaled up for display. The images are fine when selecting 100%. Argh!

The images are too large in relation to the text, but that should be easy to
fix.

Another interesting thing is that another PDF of the same site, which was
built a few years ago using Windows tools (AFAIK MS Word and Adobe
Distiller), looks best at a magnification level of 150%. At 125% it still looks
better than the one I produced, but a close look with xmag reveals that it
is scaled. At 100% it's even more scaled. Dunno why this happens,
Windows is always strange.
 
> BTW, I don't know if this is related, but GIF images do not scale well, 
> as they are a form of a INDEXED BITMAP image. JPG images scale much 
> better. This could be part of the problem. If you're working with line 
> drawings, perhaps SVG might be a better format to use in your 
> documents.

Have a look at my previous mail if you want to see the images I'm working with.

Bye, Chris






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

Re: Image Size Calculations

2004-06-07 Thread Peter B. West 
Clay Leeds wrote:
On Jun 7, 2004, at 2:13 AM, Chris Bowditch wrote:
Christian Hattemer wrote:
If it's true that graphics measurements specified in INCHES yields 
better results than PX, that certainly is news, and would (if 
reproducible) warrant special mention on the FOP Graphics page. Can you 
also do a test to see if the results are similar if you specify mm and 
cm (millimeters & centimeters of course ;-)) as well?
I think the problem is that pixels are not well-defined.  In general, a 
pixel is an output-dependent unit.  On a printer, a pixel might be 
1/2400 inch, on the screen, 1/96".  The Recommendation warns about this 
in 5.9.13.1 Pixels.  I suggest that anyone tempted to define lengths in 
"px" read that section of the Recommendation.  It's not so bad if the 
units are completely "internal", that is, that it only affects text, 
tables and the like.  But when you import an image constructed 
externally, and defined in pixels for God knows what output device, you 
are asking for trouble.

Consider the lengths that Gimp goes to on installation to make sure that 
images are reliably sized.  You must effectively tell Gimp exactly what 
the size of a screen pixel is on your monitor.  Incidentally, if you 
want to find out about the dimensions of images, install Gimp and load 
the image.  Because of Gimp's awareness of your monitor size, you should 
be able to get reliable translations of image sizes into stable units.

Bottom line - don't define *anything* in px.
BTW, I don't know if this is related, but GIF images do not scale well, 
as they are a form of a INDEXED BITMAP image. JPG images scale much 
better. This could be part of the problem. If you're working with line 
drawings, perhaps SVG might be a better format to use in your documents.

This leads to the question: How can I find out the actual resolution 
of my
images and calculate the dimensions in inches? Do I have to modify the
generated fo afterwards to include the calculated dimensions?

Dont you know the resolution of the images? It is difficult for me to 
answer this question as I dont know where you get the images from. In 
my environment, the system responsible for generating the images 
stores the measurements in cm/mm/inches along with the resolution and 
the image itself.

Chris

Can't you just load the image directly into a web browser:
images/NetworkModel/Basics/BachmanDiagram.GIF
--
Peter B. West 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Image Size Calculations

2004-06-07 Thread Clay Leeds 
On Jun 7, 2004, at 2:13 AM, Chris Bowditch wrote:
Christian Hattemer wrote:

The images are a bunch of line drawings and other illustrations from a
website I converted into DocBook.
The DocBook stylesheets include the images like this:

So the image dimensions are specified. But it seems the unit "px" 
isn't
enough to make the images look nice. Looking at the "Graphics 
Resolution"
section it seems that the dimensions should be specified in inches to
stop using the default 72 dpi.
Thats right pixel measurements are not enough information for FOP to 
scale the image to a fixed size. FOP would need to know a resolution 
as well, but that isnt implemented right now. The only way FOP will 
scale the image to a particular size is if you tell FOP the 
measurement.
If it's true that graphics measurements specified in INCHES yields 
better results than PX, that certainly is news, and would (if 
reproducible) warrant special mention on the FOP Graphics page. Can you 
also do a test to see if the results are similar if you specify mm and 
cm (millimeters & centimeters of course ;-)) as well?

BTW, I don't know if this is related, but GIF images do not scale well, 
as they are a form of a INDEXED BITMAP image. JPG images scale much 
better. This could be part of the problem. If you're working with line 
drawings, perhaps SVG might be a better format to use in your 
documents.

This leads to the question: How can I find out the actual resolution 
of my
images and calculate the dimensions in inches? Do I have to modify the
generated fo afterwards to include the calculated dimensions?
Dont you know the resolution of the images? It is difficult for me to 
answer this question as I dont know where you get the images from. In 
my environment, the system responsible for generating the images 
stores the measurements in cm/mm/inches along with the resolution and 
the image itself.

Chris
Can't you just load the image directly into a web browser:
images/NetworkModel/Basics/BachmanDiagram.GIF
Web Maestro Clay
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Cocoon 2.1 + Encryption

2004-06-07 Thread Martin Mauri 
Hi users,
I've installed everything like appars in
http://wiki.cocoondev.org/Wiki.jsp?page=FOPPDFEncryption but I can't get it
working, could it be a problem with the API? Can anybody tell me what jar
should be placed and where?
I've tried putting bcprov-jdk14-123.jar in the jre/lib directory of my JDK
as well as jboss' lib directory (I'm running jboss/tomcat/cocoon), and I've
also configured the serializer thing in the sitemap file. I can get the app
running though, but my PDF still allows printing and saving...any idea?

thanks!>


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

Re: Image Size Calculations

2004-06-07 Thread Christian Hattemer 
Chris Bowditch wrote:

> > I was able to work around the object-too-large bug by using a larger page
> > size. In the PDF the images have the wrong resolutions and look
> > ugly. (Read on, it's a slightly different question than usual)
> 
> Hidding objects that are too large is not necessarily a bug. The XSL-FO spec

It does not hide them, it goes into an endless loop trying to fit the object on
the next page. It only stops when the memory is full. This is described in the
FAQ. (This is with fop 0.20.5, since I wasn't able to compile the current
version.)

> Dont you know the resolution of the images? It is difficult for me to answer
> this question as I dont know where you get the images from. In my
> environment, 
> the system responsible for generating the images stores the measurements in
> cm/mm/inches along with the resolution and the image itself.

I didn't make the images myself. I have converted a website into DocBook and
want to create a PDF from that now. It basically works, but the images are ugly.

You can see the page with the image I mentioned in my previous mail here:
http://www.fbi.fh-darmstadt.de/~erbs/Databases/NetworkModel/Basics/index.html

The same applies to all other images on that site. All images are processed by 
fop
as they are online on that page.

Bye, Chris






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

How to print directly

2004-06-07 Thread Rudy RENTSCH 
Hi everybody,
I need help please, to manage to print something directly in the 
application.
I have an application in Java, with frames (JFrame exactly), and a 
button "print" is dedicated to the print of the contents of the window. 
I use FOP to format the content. Currently, i manage to create a PDF 
file as output, but i'd like to set the output to the printer, but i 
don't know how to do this, since it's impossible to use 
"Driver.RENDER_PRINT" when I set the renderer of the driver (see the 
following method "printMyJPanelC", the second...). Here is the code I 
use to "print" a window.

   /**
 * Impression du contenu de la fenetre
 */
   public void imprimeToi(){
  try {
   //System.out.println("FOP MyJPanel to printer\n");
   //System.out.println("Preparing...");
   
   //Reglages des dossiers
   File baseDir = new File(".");
   File tempDir = new File(baseDir, MyJPanel.TEMP_REP);
   tempDir.mkdirs();

   tempDir.deleteOnExit();
   //Reglages des fichiers xslt(depend du type de la fenetre) 
et de sortie
  String t = getType();
  System.out.println("\nType de test a imprimer : "+t+"\n");

  File xsltfile;
  if(t.equals("gz"))
 xsltfile = new File(baseDir, XSLT_GZ);
  else if(t.equals("ivp"))
 xsltfile = new File(baseDir, XSLT_IVP);
  else if(t.equals("kuder"))
 xsltfile = new File(baseDir, XSLT_KUD);
  else if(t.equals("mbti"))
 xsltfile = new File(baseDir, XSLT_MBTI);
  else if(t.equals("papi"))
 xsltfile = new File(baseDir, XSLT_PAPI);
  else if(t.equals("dat"))
 xsltfile = new File(baseDir, XSLT_DAT);
  else
 throw new MyException("Mauvais type de test : \nImpression 
impossible!");

   File pdffile = new File(tempDir, "Result.pdf");
   System.out.println("\nInput: Test object");
   System.out.println("Stylesheet: " + xsltfile);
   System.out.println("Output: PDF (" + pdffile + ")");
   System.out.println();
   System.out.println("Transforming...\n");
  printMyJPanelC(this, xsltfile, pdffile);
   
   System.out.println("\nSuccess!");
   } catch (Exception e) {
   //System.err.println(ExceptionUtil.printStackTrace(e));
   e.printStackTrace();
   System.exit(-1);
   }
   }   


   private void printMyJPanelC(MyJPanelCollection c, File xslt, File 
pdf) throws IOException, FOPException, TransformerException {
   
   //Construct driver
   Driver driver = new Driver();
 
   //Setup logger
   Logger logger = new ConsoleLogger(ConsoleLogger.LEVEL_INFO);
   driver.setLogger(logger);
   MessageHandler.setScreenLogger(logger);
   
   //Setup Renderer (output format)
   driver.setRenderer(Driver.RENDER_PDF);

   //Setup output
   OutputStream out = new java.io.FileOutputStream(pdf);
   try {
   driver.setOutputStream(out);
  
   //Setup input for XSLT transformation
   Source src = c.getSourceForMyJPanelC();

   //Resulting SAX events (the generated FO) must be piped 
through to FOP
   Result res = new SAXResult(driver.getContentHandler());

   //Setup XSLT
   TransformerFactory factory = TransformerFactory.newInstance();
   Transformer transformer = factory.newTransformer(new 
StreamSource(xslt));

   //Start XSLT transformation and FOP processing
   transformer.transform(src, res);
   } catch (Exception e) {
e.printStackTrace();
   } finally {
out.close();
   }
   }

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

Re: Image Size Calculations

2004-06-07 Thread Chris Bowditch 
Christian Hattemer wrote:
Hi,
I was able to work around the object-too-large bug by using a larger page
size. In the PDF the images have the wrong resolutions and look
ugly. (Read on, it's a slightly different question than usual)
Hidding objects that are too large is not necessarily a bug. The XSL-FO spec 
has several options for dealing with objects that are too large in the 
overflow property. FOP defaults to "hidden" and doesnt implement the other 
overflow options.

The images are a bunch of line drawings and other illustrations from a
website I converted into DocBook.
The DocBook stylesheets include the images like this:

So the image dimensions are specified. But it seems the unit "px" isn't
enough to make the images look nice. Looking at the "Graphics Resolution"
section it seems that the dimensions should be specified in inches to
stop using the default 72 dpi.
Thats right pixel measurements are not enough information for FOP to scale the 
image to a fixed size. FOP would need to know a resolution as well, but that 
isnt implemented right now. The only way FOP will scale the image to a 
particular size is if you tell FOP the measurement.

This leads to the question: How can I find out the actual resolution of my
images and calculate the dimensions in inches? Do I have to modify the
generated fo afterwards to include the calculated dimensions?
Dont you know the resolution of the images? It is difficult for me to answer 
this question as I dont know where you get the images from. In my environment, 
the system responsible for generating the images stores the measurements in 
cm/mm/inches along with the resolution and the image itself.

Chris

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

Re: table-layout="fixed" (xslfo / css difference)

2004-06-07 Thread Chris Bowditch 
Philippe PITHON wrote:
I noted a difference in operation between the xslfo/fop and css/ie of 
function table-layout=”fixed”
What makes you think they should be the same? XSL-FO is based on CSS, but 
there are differences.


With FOP, the width of contents of a table has priority
I'm not quite sure what you mean?
In CSS, the width of a table is really fixed (even if the contents have 
an important table)
Sorry I dont understand what you mean.
Chris

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

Re: Text disappearing in the PDF generated from a FO

2004-06-07 Thread Chris Bowditch 
Abhijit Junnare wrote:
Hello,
I do not get any warnings such as "content doesn't fit
in area" or similar. I have attached two FO files that
I use to generate PDF. Both FO are exactly the same
except for the margins on the page sequence I am
using. However, one generates correct PDF while in the
other one some text is lost. I have also attached the
PDF generated from the FO that gives the PDF with
problem. I generated the PDFs using FOP-0.20.5 Any
help is appreciated..
I tried both samples you sent and all the text is present. I have attached the 
PDF to prove it. Perhaps this is a JVM/OS issue. I am running Windows XP with 
Sun JDK 1.4.1 build 2

Chris


problem.pdf
Description: Adobe PDF document
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

table-layout="fixed" (xslfo / css difference)

2004-06-07 Thread Philippe PITHON 








Hello !

 

I noted a difference in operation between the
xslfo/fop and css/ie of function table-layout=”fixed”

 

XSLFO :



 

CSS :



 

 

With FOP, the width of contents of a table has
priority

 

In CSS, the width of a table is really fixed (even if
the contents have an important table)

 

 

It’s normal?