Re: Scrollable region in generated PDF

[paul womack]

GK wrote:

I'm using Apache FOP to generate a PDF through XML and XSL-FO. I have a cell
in my generated PDF that I need to be able to scroll through if the content
overflows it. XSL-FO has an overflow="scroll" feature, but based on my
research on the topic it seems that Apache FOP does not support this option.


Since FO is a multi-target language, not all feature can be implemented
in all targets.

Since PDF itself does not (AFAIK) support scrollable regions, FOP
cannot honour this XSL-FO feature when generating PDF.

 BugBear


-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org

Re: Table of Content

[paul womack]

Anastasia wrote:

Good Day!

We are interested in using the FOP Apache application. But we require the 
function of making Table of Contents and Index in the document. Could you 
please tell us, is there a way to create a table of contents and index in your 
program? As the only way to implement it, that we see, is to create a simple 
table. Thank you for your answer!


There's a chapter called "Indexing and Table of Contents" in the O'Reilly
Book "XSL-FO" by Dave Pearson, from 2002!

It's also covered in XSLT by Toug Tidwell.

  BugBear

-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org

Re: Improving FOP Performance

[paul womack]

Gonzalo Vasquez wrote:

I'm into that, but I guess there might be some first parts to look before I dig 
thaaat deep ;)



Nah, profiling ain't digging deep, it's by far the quickest and easiest way
to find unexpected performance hogs.

 BugBear


-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org

Re: Improving FOP Performance

[Paul Womack]

Gonzalo Vasquez wrote:

Hi everybody,

We've been doing some performance tests using several output formats (PDF, 
PostScript and AFP), and they al give us about the same time results, which are 
far from what we expected. I'm aware that there are several bits of Apache FOP 
which might me tweaked, but any suggestions would be appreciated for improving 
performance.


Use a profiling tool? Or is that too obvious?

 BugBear


-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org

Re: performance of PNG output vs PDF

[paul womack]

Frank B wrote:

I'm working on an application that creates labels. For PNG at 300 dpi, cpu 
usage is 2x higher than PDF output. The application can expect high volumes so 
performance is important.

Is the relatively poor performance of image output normal? Is there a setting 
that can improve the png renderer performance?


One would always expect rendering to have a higher CPU usage than
outputting a vector format.

Otherwise, one would have to assume a zero CPU load when running ghostscript!

 BugBear

-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org

Re: FOP memory growing with a lot of

[paul womack]

Kerry, Richard wrote:

Yes I did understand what you wrote, and the earlier correspondent.

I was attempting to ask why.

It seems illogical to treat many small documents as one large one.  Especially 
if the large one is so large that it is hard to process.


That case sounds (to me) like many "documents" in one large "print job".

I suppose one might consider turning a whole wiki (they can get big, I'm told)
into a single hyperlinked PDF. That would be a legitimate, and fairly useful
massive PDF.

 BugBear


-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org

Re: FOP memory growing with a lot of

[Paul Womack]

aemitic wrote:

Thanks for the suggestion.

This /workaround/ (it's not a solution) cannot be applied. Why:
  - internal pdf links would not work
  - pdf bookmarks would not work
  - page numbering would not be correct
  - creating over 15 PDFs and then merging them with an external tool is
unacceptable from a performance point of view


I cannot imagine a (useful) PDF with 150,000 pages.

This may well be a limitation of my imagination :-)

Can you tell me a little about this?

 BugBear


-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org

page property page-height=indefinite

[paul womack]

I note (google!) that subsequent to my questions on this
(in 2008), this feature remains unimplemented,
and has been asked about a few times.

In the interests of repaying the community,
I offer this perl script (written for my own purposes)
which generates output of the "right" height,
by performing an initial pass, and parsing the resulting
area tree.

The information from the area tree is used to generate
a custom XSL based on the desired XSL, with the
height "dropped in".

My script happens to generate EPS, which means there's
a small piece of FILTHY perl search-and-replace
on FOP's generated postscript, which is a print stream.

This script is based heavily on information and advice
from Jeremias Maerki and Andreas Delmelle, to whom
my thanks are due.

   BugBear

#!/usr/bin/perl

use strict;
use warnings;

use Data::Dumper;
use Carp;
use XML::LibXML;

my $fop = "../fop-1.0/fop";

my $main_mime = "application/postscript";
my $main_format = "-ps";

# preliminary H+J to get dimensions
sub measure_pass {
my ($style, $data) = @_;
my $atfile = "measure.xml";
my $cmd = "${fop} -xsl ${style} -xml ${data} -at ${main_mime} ${atfile}";
system($cmd);
return $atfile;
}

sub find_depth_mm {
my ($atfile) = @_;
my $parser = XML::LibXML->new(recover=>1, validation=>0, no_network => 1);
my $doc = $parser->parse_file ($atfile);
my @page = $doc->findnodes("//page");
my $page = $page[0];
my @span = $page->findnodes("regionViewport/regionBody/mainReference/span");
my $depth;
foreach my $s (@span) {
$depth += $s->getAttribute("bpd");
}
# units are 1000th pts.
return $depth / 1000 / 72 * 25.4;
}

sub new_style {
my ($style, $depth) = @_;
my ($os, $ns);
my $new_xsl_file = "right_height.xsl";
open $os, "<", $style;
open $ns, ">", $new_xsl_file;
while(<$os>) {
s/page-height="[^"]+"/page-height="${depth}mm"/g;
print $ns $_;
}
close($ns);
close($os);
return $new_xsl_file;
}

sub final_pass {
my ($style, $data) = @_;
my $ps = "output.ps";
my $cmd = "${fop} -xsl ${style} -xml ${data} ${main_format} ${ps}";
system($cmd);
return $ps;
}

sub make_epsf {
my ($psfile, $epsf) = @_;

local $/; # slurp!
my $pstream;
open $pstream, "<", $psfile || die "cannot open $psfile $!";
my $ps = <$pstream>;
close($pstream);
# call it EPSF
$ps =~ s/^(%!PS-Adobe-[\d.]+)$/$1-EPSF/m;
# pick up the bounding box from where it's been put
$ps =~ m/^(%%PageBoundingBox:\s+[\d\s]+)$/m;
my $bb = $1;
$bb =~ s/PageBoundingBox/BoundingBox/g;
# insert it where we want it
$ps =~ s/(%%LanguageLevel:\s+\d+)$/$1\n$bb/m;
$ps =~ s/>> setpagedevice/>> pop/g;
# disable the nasty setpagedevice call

my $ostream;
open $ostream, ">$epsf" || die "cannot open $epsf $!";
print $ostream $ps;
close($ostream);
}

sub usage {
croak <  "
EOF
}

unless(scalar(@ARGV) == 3) {
usage();
}

my ($style, $data, $eps) = @ARGV;

my $at = measure_pass($style, $data);
my $depth = find_depth_mm($at);
my $ns = new_style($style, $depth);
my $ps = final_pass ($ns, $data);
make_epsf($ps, $eps);

-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org

Re: Invalid PDF Created

[paul womack]

Eric Douglas wrote:

I'm not sure what this quickdraw thing is you're referring to, but if
I'm understanding it right, it's not like you can alter the PDF heading
after the transform.  The PDF is already mostly written to the file at
this point.  It just left out the last block.  I don't know the size of
that block, if it's always one complete section, if it's possible to
insert something to the file before that.  Obviously you can't write
anything after the end of that stream before closing the stream because
it's a PDF which has to end with the %EOF.


All agreed - for PDF.

That's why I used a quickdraw example; a quickdraw
"drawing" file could actually support more than one (embedded) jpeg
image, and FOP can (as you know) generate JPEG images.
Hence the undesirability of FOP closing its output stream.

In this example, an induividual JPEG may be finished,
but the quickdraw isn't.

  BugBear

-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org

Re: Invalid PDF Created

[paul womack]

Eric Douglas wrote:

Surely this is a longer explanation than you're asking for. 


Certainly was ;-)


The short
answer is I'm well aware of how the output streams work, but I thought
if the transform was writing to it which should be a complete process
that it would close it when it's done.


It was your expressed surprise that an open BufferedOutputStream
isn't flushed that I was commenting on.

As in:


Eric Douglas wrote:
I resolved this.  After the transform I didn't close the output stream.  

Apparently that left some bytes hanging.


It appears that the (real) surprise is that the execution
doesn't close its destination OutputStream.

I would be surprised if it *did*.

Consider, for example, that for reasons all-my-own I want to create an old
style quickdraw version from fop input. If I had a quickdraw
writing library, I could generate a quickdraw image header (*),
let FOP write a (rendered) jpeg to the still-open OutputStream
of the quickdraw, and then generate any required quickdraw trailer.

It would be most inconvenient if the FOP staged closed my outputstream.

  BugBear

(* this isn't how the quickdraw really works, but it's near enough for this 
example)

-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org

Re: Invalid PDF Created

[paul womack]

Eric Douglas wrote:
I resolved this.  After the transform I didn't close the output stream.  
Apparently that left some bytes hanging.


Apparently?

You said:
> If I try to create a PDF directly from the transform with FOP 1.0, by
> passing a BufferedOutputStream created from a FileOutputStream into the
> FopFactory.newFop, it's creating an incomplete PDF.  Am I missing
> something or where should this come from?

You might want to review your understanding of what BufferedOutputStream
and FileOutputStream do.

   BugBear

-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org

Re: Text rendering with FOP

[paul womack]

Vincent Hennebert wrote:

Hi,

I think the way to go about that is to use a PDF post-processor that
would convert the PDF into plain text.


Does this mean there's (implicitly) no way of using FOP
to emulate tex/nroff, at least directly ?

   BugBear

-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org

Re: Transparent Text

[paul womack]

Duncan McGregor wrote:

Hi

I'm trying to work out how to write transparent text to overlay OCR data 
on top of its source image.


I've seen it done in PDFs, but cannot find how to represent transparency 
in xsl:fo


Thanks in anticipation


Text is set in the foreground colour, and has no background colour
per se.

What might be loosely termed "opaque text" is merely text upon (and in)
a coloured box (which has a colour, which we might term background colour)

If the text you wish to be "transparent" is in a box, it is the box's
colour you need to suppress - so if you've been looking
in the text control parameters, you may well have missed it.

  BugBear

-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org

Re: 0.95 & Acrobat Performance Problems

[paul womack]

egibler wrote:

Hi,

I receive lots and lots of small (1-3 page) PDFs each day, combine them
using Acrobat Professional, and print and mail them for clients.  One client
recently upgraded from FOP .2x to FOP 0.95, and the combining of his files
has become nearly impossible.  It'll put the first 10 pages together fairly
quickly, but gets incrementally slower with subsequent additions until the
process grinds to a halt before page 150 or so.  He tends to send me batches
of between 1500 and 3500 pages, so I'm well shy of what I need to
accomplish.  The process worked great with the earlier version, and works
fine with my other clients' PDFs that are created with various other tools.

These files are invoices.  Batches of which regularly represent several
millions of dollars, so they really have to be right, timely, and without
duplicates or omissions.

I'm not at all familiar with FOP - please forgive my ignorance.  I hadn't
heard of it until the problem occurred and I started doing a bit of
research.  From what I've read, there seems to be a fair amount of
discussion related to memory issues and large PDFs.  I'm wondering if anyone
else has a situation similar to mine, and / or might be able to suggest what
I might be able to do to get my production back on track.



I'm a little confused. While FOP does indeed have some known
performance issues with multi page documents,
isn't the performance issue YOU'RE talking about
inside Acrobat?

  BugBear

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

Re: AW: FO writing

[paul womack]

Georg Datterl wrote:

Hi Erwan,


Since several months, i'm creating FOP documents, always with gedit or some 
text editor. The only feature they give me is a syntax coloration.
So what are you using : which program or plugin ?


XmlSpy works fine, but basically any program which displays XML nicely can also display Fo-files nicely. 



Don't like the price of XMLSpy, and I won't steal.

Any other suggestions?

  BugBear

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

Re: FOP to PDF using PHP

[paul womack]

Al Dancer wrote:

Hello,

I've installed PHP-Java-Bridge 5.2.2
and would like to create a PDF file using FOP and PHP.
OS: Solaris 10
FOP: version 0.95
PHP: version 5.2.6
Java: jdk1.6.0
Apache: Server Version: Apache/2.2.9

when I run fop from the command line, the PDF file was created.
./fop test.fo  test.pdf

But when I created a PHP file, let's say mytest.php as following:
---
tmpdir = "/tmp";
$pdf->run("/tmp/simple.fo", "/tmp/simple.pdf");
$pdf->printPDF();
$pdf->deletePDF();
?>
---

I could not see any PDF file in my browser after checking the PHP page
http://my-server/mytest.php

The script exited after executing $pdf->run("/tmp/simple.fo", 
"/tmp/simple.pdf");
without any errors or warning (I've checked the apache log file, 
php-java-bridge.log file,phperror logfile)


I have tried the runFromFile and runFromString (in fo2pdf.php) methods 
they behave the same way.


My question is : is FOP 0.95 working with PHP-Java-Bridge 5.2.2 and PHP 
5.2.6, Java_1.6.0 ?

Any help would be appreciated.

BTW, the same script (PHP) is working with:
FOP: 0.20.4, PHP-Java-Bridge-4.0.8a, Java jdk1.5.0_06 (I mean the PDF 
file has been created).


Permissions, file paths, or $PATH errors would be the usual
suspects.

  BugBear

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

Re: Page Layout - Spreads, Bleed etc.

[paul womack]

Jeremias Maerki wrote:

That was discussed some time ago. You might want to read up on the
status here: http://fop.markmail.org/search/?q=trimbox

I've prepared FOP so TrimBox, BleedBox and MediaBox can all be set [1].
But the wiring into an extension hasn't been completed, yet.

[1] http://svn.apache.org/viewvc?rev=618626&view=rev


I would regard support of bleed, trim and media sizes
as desirable "general" layout features, despite the fact
the present motivation is to get them set in a PDF output file.

  BugBear

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

Re: How to add space between words

[paul womack]

Ashish Kulkarni wrote:

Hi

I need to print text like "My Name is  ABC"

.
.
.


How can i add space between words


What are trying to DO with this space?
Are you trying to line up a table, express columns,
a list of pairs?

In almost all cases, you should be working at a higher
design level (in terms of layout) that "adding spaces"

  BugBear



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

large scale users?

[paul womack]

I'm trying to convince someone that fop
is a good choice for generating (large)
pdf's from structured input.

Should be easy :-)

Can anyone tell me of fop being used in this way and
has a website where the output (and/or input)
is publicly visible?

  BugBear

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

Re: FOP Newbie

[paul womack]

moorzee wrote:

Hi

I have a requirement to output, what I hope, is going to be a very simple
PDF document. I'll be building up an xml domdocument in VB. My question is
can I output my PDF without the need to save the xml as a file, i.e pass the
xml directly into fop with my style sheet and output my PFD?


At the risk of reverse engineering instead of reading documents,
I just grepped the source tree, and System.in
(Java's version of STDIN)
does not appear very often - so I suspect fop cannot
be piped to (on the command line) which is what you appear
to require.

  BugBear

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

Re: How to use glyphs from the Symbol font ?

[paul womack]

Daniel Noll wrote:

Andreas Delmelle wrote:
IIC, this is a FOP limitation for all versions up to and including 
0.95. FOP Trunk should now use another font than Symbol for a 'q'. Max 
implemented basic support for character-by-character font-selection, 
which is probably what Firefox does too.


Something to look forward to. :-)


This is extremely good news.  No more requiring a massive third party 
font like Arial Unicode in order to render documents with mixed 
languages! :-)


Indeed. In an academic paper in the sphere of philosophy
or literature (surely a target demographic for FOP) multiple
languages and hence a wide range of glyphs are most likely.

  BugBear

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

Re: PDF full screen mode...

[paul womack]

Jeremias Maerki wrote:

Ah well, my afternoon's almost over anyway...

Here's a proposal:
http://wiki.apache.org/xmlgraphics-fop/ExtensionsForPdf

Feel free to improve/comment/fix.

In FO that would look like this:
http://www.w3.org/1999/XSL/Format";>
  

  

  
  
http://xmlgraphics.apache.org/fop/pdf";
   page-mode="full-screen"/>
  
  

  Hello World!

  



At the risk of creating the ultimate "back door"

   
 http://xmlgraphics.apache.org/fop/pdf";>
 
 

i.e. a pdf-setting element, with "open" scope.
It's more forward extensible/open to abuse (*)

   BugBear

(*) delete according to taste

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

Re: Fop source-resolution

[paul womack]

Jeremias Maerki wrote:

My suggestion: Use 0.95beta and
inline-progression-dimension.maximum="100%"
content-width="scale-down-to-fit" to restrict the images to a maximum
size.

FOP always uses the image's resolution to determine the intrinsic size.
Only if an image has now explicit resolution, the source-resolution
setting in the configuration is used. There's currently no way to
override the resolution for single images in FO.


This seems reasonable - if neccessary the OP
can use a tool e.g. ImageMagick to SET the resolution
on an image.

If the OP is using a format which does not support
resolution fields (e.g. GIF), this would also
need some kind of conversion.

  BugBear

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

Re: Editing Text in the Intermediate Format

[paul womack]

Martin Edge wrote:

Hey Guys,
The file definitely is XML parsable.. and it’s output using XmlDocument in c# 
.NET.


XML parseable is a low hurdle! It also needs to represent the
correct semantics for FOP...

  BugBear

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

Re: Generating TIFF G4 files

[paul womack]

Jeremias Maerki wrote:

On 19.05.2008 17:41:49 paul womack wrote:

Platekatel wrote:

Hello *,

I’m using FOP embedded, to generate PS files for printing, everything works
fine.
Now I have the new task to create TIFF files. 
Well, easy to get tiffs with FOP but I have the special requirement the

generated TIIF have to be a TIFF G4.

Does anybody know how to setup FOP to create such a TIFF?

Fop output possibilities are quite constrained.


Careful with statements like that!

See here:
http://xmlgraphics.apache.org/fop/0.95/output.html#tiff-configuration



I stand corrected; I was over interpreting the number
of command line options, and not looking elsewhere

  BugBear

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

Re: Getting hyphenation to work

[paul womack]

Kamal Bhatt wrote:
Thanks. Works a treat. One more question, where can I get these 
hyphenation files for asian languages (such as japanese).


I'm far from sure hyphenation is even a valid concept
in Japanese.

  BugBear

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

Re: tif images appearing distorted in PDFs

[paul womack]

Woodhouse, Graeme wrote:

How would I find out if the tif that is going wrong has non-squared pixels?


xresolution != yresolution. They're independent parameters
in the TIFF spec.

Try tiffdump.

  BugBear

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

Re: tif images appearing distorted in PDFs

[paul womack]

Woodhouse, Graeme wrote:

Hello all,

 


I'm trying to get tif images working in PDF’s I'm creating –

 

The problem is some of them are coming out with the image height having 
been resized (by around 50%).


 


Other tif images are being displayed correctly with no incorrect resizing.

 


Does anyone have any idea’s why this might be?


Possibly a tiff file with non-square pixels (which is valid,
but unusual) ?

  BugBear

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

Re: Handeling tradional orphans.

[paul womack]

paul womack wrote:

Michael Halpin wrote:
I realize that orphans according to fop are the first line of a 
paragraph at the bottom of a page where the rest of the paragraph 
breaks onto the next page.  


I'd call that a "widow", a term also used for headings
which have "lost" their body text.

 > In traditional editing an orphan is a lone
word at the end of a paragraph.  Does anyone know if there is a way to 
tell fop to either suck up the word to the previous line or to bump a 
word down automatically as to avoid orphans at the end of a paragraph.


I work in the print/prepress trade, and the term orphan
is generic (in my experience); "any trailing isolated thing".

The worst case I've ever seen was where the second half
of a hyphenated word at the end of a paragraph
wrapped onto the next page... !


Further context; in OpenOffice (v2.3 if it matters)
the options you're talking of are in "paragraph style",
"text flow", options. One of the options is "keep paragraph together"
If this is NOT checked, the options "widow control" and "orphan control"
can be used, both expressed as a number of lines.

   BugBear

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

Re: Handeling tradional orphans.

[paul womack]

Michael Halpin wrote:
I realize that orphans according to fop are the first line of a 
paragraph at the bottom of a page where the rest of the paragraph 
breaks onto the next page.  


I'd call that a "widow", a term also used for headings
which have "lost" their body text.

> In traditional editing an orphan is a lone
word at the end of a paragraph.  Does anyone know if there is a way to 
tell fop to either suck up the word to the previous line or to bump a 
word down automatically as to avoid orphans at the end of a paragraph.


I work in the print/prepress trade, and the term orphan
is generic (in my experience); "any trailing isolated thing".

The worst case I've ever seen was where the second half
of a hyphenated word at the end of a paragraph
wrapped onto the next page... !

  BugBear

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

Re: Generating TIFF G4 files

[paul womack]

Platekatel wrote:

Hello *,

I’m using FOP embedded, to generate PS files for printing, everything works
fine.
Now I have the new task to create TIFF files. 
Well, easy to get tiffs with FOP but I have the special requirement the

generated TIIF have to be a TIFF G4.

Does anybody know how to setup FOP to create such a TIFF?


Fop output possibilities are quite constrained.
I would use fop to create "something" and then
use a graphics utility package to convert.

imagemagick, netpbm, and gimp could all be used.

 BugBear

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

Re: Help Needed in XSL:FO

[paul womack]

Rakesh Kumar S wrote:

Hi

I am using XSL:FO to render PDF documents from XML File.

Now i have a requirement where i have to exactly replicate a PDf file for which 
i dont have the XSL:FO.

I had given them a version using my XSL:FO that is close but they want 100%.

They are looking for 100% replication, I am a fresher in this arena of XSL:FO 
and i am not confident if i would be able to replicate it to 100%.

Could somebody give me some ideas as to how it can be done.


It can't be done; if the target PDF exhibits features
that fop (or xsl-fo) doesn't support, you're dead in the water.

e.g. a PDF from a specialist GIS package.

   BugBear

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

formatting stricture differing from data structure?

[paul womack]

I've succeeded (hearty thanks to all who have helped)
in making EPSF files.

Preview TIFFS are made using ghostscript (via imagemagick),
the fop postscript is turned into EPSF via some viciously
unsubtle edits using perl, and the tiff put onto the EPSF
with a suitable header via a little more perl.

Up until this point I've put little emphasis
on the sophistication of my stylesheet programming
(xslt) or formatting (fo).

My present data exactly matches (in structure)
my styling.

I can thus put one fo element on each data element,
and I'm good to go.

Even I can get the XSLT right for this...

A couple of questions have now occurred to me,
which a reading the Tidwell book
hasn't answered (easily).

If my feed xml (in DTD form) were:



How could I (best) get a single fo element around
any summary (if present) and all the paragraphs?

Or in



How could I get the first verse to be formatted
differently to the rest?

In both cases I want a fo element where
there isn't an exactly analogous element in
the feed xml.

I feel I'm missing something obvious;
I assume XSLT can easily handle this, given
that it can do cross referencing and sorting and stuff,
but I can't see how.

Can somebody point out the obvious to me?

  BugBear

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

Re: generating EPSF (with preview)?

[paul womack]

Jeremias Maerki wrote:
Which is why I wrote "closely resembling output". 


Ah! Damn this English language; one man's "closely"
is another man's "not close enough" :-)

> There's no (efficient) way

we can do any better with the current design. If it's a problem in your
case, you're out of luck, I'm afraid.


That's OK - I was just attempting to confirm
facts before wasting effort.


I may have to use ghostscript to render the postscript to get
a preview, sadly. I'd rather have stayed in one "world".


So help us improve FOP. Some time ago we started investigating a new
intermediate format. What we've started outlining there would allow
exact character placing:
http://wiki.apache.org/xmlgraphics-fop/AreaTreeIntermediateXml/NewDesign


With my "general experience" hat on;

Sadly, this exchanges one problem for another. "proper" strings
are rather desirable when generating PDF and/or postscript,
since they facilitate compact (even elegant) representations,
*and* text searching or extraction later (should that be relevant).

It would (I freely admit) help my case greatly ;-)

   BugBear

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

Re: generating EPSF (with preview)?

[paul womack]

Jeremias Maerki wrote:


q2) Is it possible to (somehow) use the same layout
for two renderers? in my particular circumstances
induividual character appearance is a moderately low
priority; whiat I do require is that line wrapping
and general layout is the same between the EPSF and
the preview.

If the AT file specified the exact placement of each character
my purpose would be well served.


The AT does that. Not with absolute coordinates for each glyph but the
renderers will produce closely resembling output.


I'm afraid not; since "whole lines" are commonly passed to  the renderers
small changes in the character width can accumulate; this is
(sadly) more than enough to drive words (or at least parts of words)
off the right hand edge, or conversely to make justified
text extremely (intolerably) ragged.

I may have to use ghostscript to render the postscript to get
a preview, sadly. I'd rather have stayed in one "world".

  BugBear

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

generating EPSF (with preview)?

[paul womack]

I note that fop can generate printable PostScript
(the -ps flag in the command line version).

My requirment is to generate EPSF; I am making
"fragments" for makeup into a large page
by an external (interactive) application.

The postscript generated is most definitely
NOT epsf, or even close. In particular there *IS*
is a call to a global device operator - setpagedevice.

q1) are there any plans to generate EPSF?
I suspect I know enough to use perl (or similar) to transform
the present PostScript into EPSF, but I'd rather not...

An epsf file, to be useful in an interactive environment
needs a rendered preview. Given that fop can also
generate a number of raster formats, I was hoping
to use this facility to generate EPSF and a raster
preview from the same xsl/data. However, given
some helpful advice from Andreas, it appears
that choice of renderer influences layout decisions.

q2) Is it possible to (somehow) use the same layout
for two renderers? in my particular circumstances
induividual character appearance is a moderately low
priority; whiat I do require is that line wrapping
and general layout is the same between the EPSF and
the preview.

If the AT file specified the exact placement of each character
my purpose would be well served.

  BugBear

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

Re: variable size output (pages)?

[paul womack]

Andreas Delmelle wrote:


I think the problem is that you have to specify the eventual renderer to 
mimic.


Try
../fop -xsl lineage.xsl -xml lineage_eg.xml -at image/tiff lineage.at.xml;


Yes; that worked (in the standard sense of did what I wanted!)

Thank you very much, for all your help.

   BugBear

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

Re: variable size output (pages)?

[paul womack]

Andreas Delmelle wrote:

On May 8, 2008, at 14:17, paul womack wrote:


O.K.

I've found this documentation on the "area tree" internal modelling:

http://xmlgraphics.apache.org/fop/dev/design/areas.html

I think this page:
http://xmlgraphics.apache.org/fop/0.94/intermediate.html

says that the XML format is "subject to change".

q1) May I assume that any particular version of FOP would be able
to consume an area tree (XML) that it had itself generated?


That's a reasonable assumption, I think.


(I have noted your other information; thank you)

This assumption may be reasonable, but it just failed
a test (I think)

generating tiff directly:

 ../fop -dpi 288 -xsl lineage.xsl -xml lineage_eg.xml -tiff a.tif

gives me different line breaks to going via an "at" file:

 ../fop -xsl lineage.xsl -xml lineage_eg.xml -at lineage.at.xml; ../fop -atin 
lineage.at.xml -dpi 288  -tiff b.tif

Unless these are different for a "valid" reason that I am ignorant of?

The "b.tif" files has lines going beyond the right hand side of
the raster; the lines appears to have been wrapped for a large
page width than I (actually) have.

   BugBear

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

Re: variable size output (pages)?

[paul womack]

Andreas Delmelle wrote:


On May 6, 2008, at 14:16, paul womack wrote:

Hi


In effect I want to generate "galleys" of text,
where the formatting width is known, but the depth
of the final output is determined by the amount
of text formatted, in effect fitting the page
to the content.


What you would need:
http://www.w3.org/TR/xsl/#page-height

See the defined possible value of "indefinite"

FOP does not implement this yet, unfortunately (while the compliance 
page /does/ indicate full compliance; correction/note needed)


For the moment, your area tree idea is probably your best bet, unless 
you feel like joining us, and diving into the code yourself... ;-)


O.K.

I've found this documentation on the "area tree" internal modelling:

http://xmlgraphics.apache.org/fop/dev/design/areas.html

I think this page:
http://xmlgraphics.apache.org/fop/0.94/intermediate.html

says that the XML format is "subject to change".

q1) May I assume that any particular version of FOP would be able
to consume an area tree (XML) that it had itself generated?

q2) And, a detail question, which I have not been (easily)
able to find an answer to: in the area tree, what are the units?

(I could reverse engineer, but I'd rather not)

My present plan is to identify the lower bound of the last text line
from the area tree, then use that to perform a second fop pass (all
the way from the start) with a "carefully contrived" page-height.

  BugBear

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

Re: multiple outputs

[paul womack]

Andreas Delmelle wrote:


If you would use FOP multiple times in a row, without restarting the 
JVM, then over a few runs that will save you minutes...
The very first run is always a lot slower due to static initialization, 
class loading etc. Once the VM is warmed up, the average runtime for a 
formatting run will drastically reduce. To see what I mean, you could 
already make the comparison: try 50 isolated runs from the command-line, 
and afterwards, perform the same 50 runs, but then looped in a single 
small class.


Hmm. As a compromise, I may be able to create a java class
that accepts multiple "commandlines" from stdin.

This could be driven either via a pipe from a script
(a sort of fop daemon) or via a command file, as per
egrep --file (etc)

I would prefer to avoid too much close-coupling with java
in my particular environment (system intgration,
coded in perl).

In conjunction with my requirment to have variable size
output, and 2 output formats, I think I need 3 runs
in total, so reducing startup overhead seems a useful
goal.

   BugBear

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

multiple outputs

[paul womack]

If I want a TIFF and a PDF from the same input (xml + xsl), what's
my best course?

Clearly, running fop from the command line twice would work,
but can I get a performance "win" by converting to an intermediate fo
file, then doing a render run?

Or even making (and then using) a AT file?

Or can I reduce the fop startup overhead by running two
commands (how?) in the same instance?

 BugBear

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

Re: variable size output (pages)?

[paul womack]

Andreas Delmelle wrote:


On May 6, 2008, at 14:16, paul womack wrote:

Hi


In effect I want to generate "galleys" of text,
where the formatting width is known, but the depth
of the final output is determined by the amount
of text formatted, in effect fitting the page
to the content.


What you would need:
http://www.w3.org/TR/xsl/#page-height

See the defined possible value of "indefinite"

FOP does not implement this yet, unfortunately (while the compliance 
page /does/ indicate full compliance; correction/note needed)


For the moment, your area tree idea is probably your best bet, unless 
you feel like joining us, and diving into the code yourself... ;-)


FWIW: It has been discussed a couple of times on fop-dev@, so there are 
already ideas floating around.


A perfect, if disappointing answer :-(

Thank you.

 BugBear

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

Re: variable size output (pages)?

[paul womack]

Peter Coppens wrote:
Ic...so there is no way to know what the page size will have to be until 
the layout has been completed?


No, that's rather the heart of my problem.

Consider, if you like, a different example.

I wish to make rendered images of quotations
for placement on a web site.

Of course, quotations vary in length...

I know I want the images to be 350 pixels wide,
to fit my web site design.

So...

The depth of these images will need to vary
in order to accomodate the words, but I don't
know *how* deep until I've laid out the text, with
line wrapping, hyphenation etc.

   BugBear

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

Re: variable size output (pages)?

[paul womack]

Peter Coppens wrote:
Can't you use different page masters and select the one that is 
appropriate using some (XSLT) pre-processing?


I'd need an almost infinite range of
masters - the line count could vary from 5-350,
and even line spacing could vary due to superscripts,
subscripts, emboldening etc.

So I think the answers no; in anycase, a two pass
solution (via the area tree) is already
my fall back option, but it feels
like a dirty hack.

  BugBear

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

variable size output (pages)?

[paul womack]

I need to generate output (PDF) where the page
size (actually just page depth) varies
with the content.

In effect I want to generate "galleys" of text,
where the formatting width is known, but the depth
of the final output is determined by the amount
of text formatted, in effect fitting the page
to the content.

I have tried to search the documentation,
but am greatly hampered by not knowing
the terminology well enough to search effectively.

It appears that I can "fake" what I want by
either using imageprocessing to "autocrop"
the output, or (possibly) by doing
"something" to the XML area tree, and performing
a second pass, but if there's a proper
way to achieve my goal, that'd be great.

I would welcome either advice, or simply
a pointer to any relevant parts of the
specification(s) or documentation.

  BugBear

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