date:20080508

I have an Ubuntu 8.04 in a VM to play with. So I copied over the Bodoni
fonts from that ZIP file you indicated. However, the ZIP does not
contain any AFM files for the Bodoni font, just the PFB and PFM. Looking
at these fonts, BTW, gives me a strong impression that these are illegal
and altered copies (Some of the fonts give a BBS phone number). Anyway,
I had no problems auto-detecting and using the fonts with FOP 0.95beta.
If you've installed the fonts in a location other than the directory
mentioned in the following Java class:
http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/autodetect/UnixFontDirFinder.java
you'll have to use the directory element in the font configuration.

It looks like /usr/local/share/fonts is another place where fonts can be
on Unixes but that's not used by FOP, yet. Can a Unix Guru confirm that
it would be correct to add this directory to the other ones in
UnitFontDirFinder?

On 07.05.2008 22:16:06 John Brown wrote:
Andreas Delmelle andreas.delmelle at telenet.be writes:

On May 7, 2008, at 10:30, Andreas Delmelle wrote:
snip /

Can you try to checkout and build FOP 0.95 (*), and see if that
helps already?

snip/

If you still need it, the URL to use with SVN for 0.95 head:
http://svn.apache.org/repos/asf/xmlgraphics/fop/branches/fop-0_95

Cheers

Andreas

I am on Linux (Kubuntu Gutsy Gibbon (7.10?)). Auto-detection of
fonts does not work most of the time. For example, I cannot use
Bodoni (Type 1 font - the download page says that it is shareware,
but neither the site nor the ZIP file says who should be paid).
I downloaded the font at
http://www.winsite.com/bin/Info?50017011.

Scribus lets me embed this font in a PDF, and Scribus itself
says that it is strict about the fonts that it allows to be
embedded, so I assume that nothing is wrong with the font.

'fc-list Bodoni' gives:
Bodoni:style=Bold
Bodoni:style=Normal-Italic
Bodoni:style=Normal

'ls /usr/local/share/fonts/bodoni*' gives:
/usr/local/share/fonts/bodoni.afm /usr/local/share/fonts/bodonii.pfb
/usr/local/share/fonts/bodonib.afm /usr/local/share/fonts/bodonii.pfm
/usr/local/share/fonts/bodonib.pfb /usr/local/share/fonts/bodoni.pfb
/usr/local/share/fonts/bodonib.pfm /usr/local/share/fonts/bodoni.pfm
/usr/local/share/fonts/bodonii.afm

AFM, PFM and PFB files are all present.

However fop-trunk svn (653186, 2008-05-03) and fop-0.95beta svn
(653537, 2008-05-05) both say:
WARNING: Font 'Bodoni,normal,400' not found. Substituting
with 'any,normal,400'.

I used the same FO and fop.xconf that was posted.

I noticed that fop printed a lot of warnings like:

May 7, 2008 2:05:22 PM org.apache.fop.fonts.truetype.TTFFile determineAscDesc
WARNING: Ascender and descender together are larger than the em box. This
could lead to a wrong baseline placement in Apache FOP.

and

May 7, 2008 2:05:35 PM org.apache.fop.fonts.truetype.TTFFile
guessVerticalMetricsFromGlyphBBox
WARNING: xHeight value could not be determined. The font may not work as
expected.
May 7, 2008 2:05:35 PM org.apache.fop.fonts.type1.PFMFile loadExtMetrics
WARNING: Size of extension block was expected to be 52 bytes, but was 0 bytes.

The messages do not say which fonts cause the warnings. I do
not know if it matters.

By the way, I have found a few Type 1 fonts that fop
recognises, but no TrueType fonts so far.

Jeremias Maerki

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

Re: Memory issue (was: Re: Major issue with image loading in FOP 0.95beta)

I've done extensive tests about memory allocation with FOP when
implementing the new image loading framework and in my case the memory
was always released. So, some results from a profiler would be helpful.

Anyway, what I meant with my hint was that the iText step might not be
necessary anymore and that you should be able to safely reduce -Xmx on
the JVM (provided your document doesn't contain to much non-image
content). But if you release FopFactory and the memory is still not
reclaimed something's wrong somewhere and I have a somewhat hard time
believing that FOP itself somehow still holds on to it. Please make sure
you don't hold on to the FOUserAgent and other FOP-related objects
because they might have a reference to the FopFactory.

On 08.05.2008 08:40:55 Jean-François El Fouly wrote:
 Jeremias Maerki a écrit :
  And my next problem is to find a way to force memory recycling after 
  this long and hefty FOP processing, but until further investigated this 
  is OT ;-)
  
 
  You probably didn't get my hint earlier but with the new image loading
  framework you should actually get away with lower memory settings. In my
  tests I have been able to produce PDF with little text and many images
  with 40MB of VM memory which wasn't possible with 0.94 and earlier.

 
 Well, I got the hint, but it seems in contradiction with what I read.
 So to take the picture from a bit higher:
 - all XSL-FO transformation + FOP generation now work OK.
 - this generates 20-30 documents (chapters) for a grand total of about 
 150 Mb, to be bound together by iText.
 - source XML is 1.5 Mb
 - 1011 PNG images for a total of 151 Mb, the largest image is 715 kb.
 
 Now the figures:
 - XML - XSL-FO transformation + FOP generation take 15 minutes on a 
 pretty decent DELL Server (running Debian 4.0) having all the physical 
 RAM possible (staging server for several customers)
 - JVM has 2000 Mb (which is BTW the grand max on this 
 processor/server/OS/JVM architecture)
 - only one instance of FOP launched (one document generation)
 - the second next step in the publication process (opening the 150 Mb 
 with iText to add the bookmarks) fails immediately (at file open) saying 
 it cannot allocate memory
 
 If I try to investigate memory usage using 
 Runtime.getRuntime().getFreeMemory() and logging the figures with log4j, 
 these are the figures I get:
 - before XSLT + FOP: 1900 Mb free/2000 Mb
 - end of XSLT + FOP: 241 Mb free
 - set FopFactory instance to null as a desperate hint to the GC that FOP 
 objects could be/should be recycled
 - I force garbage collection using System.gc()[OK, in an application 
 server this is a brute force approach, but could not see a more clever 
 maneuver ATM]
 - 350 Mb free/2000 Mb total
 - Bind all chapters with iText
 - 250 Mb free
 - Force another GC
 - 350 Mb free again (so the binding operation has no effect on the 
 available memory).
 - the next iText step still fails.
 
 Now I don't take runtime.getXXXMemory() for bible word but at least it 
 looks like the Xalan + FOP subsystem hogs 1500 Mb of RAM which I 
 cannot recover.
 So I hired the team member who's competent in profiler usage next week 
 but I must say at the moment I'm still stuck :-(
 
 Of course I've made my homework and read the f...riendly manual before 
 daring to ask.
 Did I miss any important indication ?
 




Jeremias Maerki


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

Re: Memory issue (was: Re: Major issue with image loading in FOP 0.95beta)


On May 8, 2008, at 08:40, Jean-François El Fouly wrote:

Hi


Jeremias Maerki a écrit :


And my next problem is to find a way to force memory recycling  
after this long and hefty FOP processing, but until further  
investigated this is OT ;-)
You probably didn't get my hint earlier but with the new image  
loading framework you should actually get away with lower memory  
settings. In my tests I have been able to produce PDF with little  
text and many images with 40MB of VM memory which wasn't possible  
with 0.94 and earlier.


Well, I got the hint, but it seems in contradiction with what I read.


There are, of course, other factors to take into account than simply  
document/image sizes.


Which Java VM are you using? Practically every time someone tells us  
about memory/GC issues, it appears they are using an implementation  
other than Sun (IBM, GNU...)
Up to now, we still have to find out why precisely non-Sun VMs have  
difficulties with FOP...


What options does the Java VM offer to tweak the GC? What options  
does it use by default?



So to take the picture from a bit higher:
- all XSL-FO transformation + FOP generation now work OK.
- this generates 20-30 documents (chapters) for a grand total of  
about 150 Mb, to be bound together by iText.

- source XML is 1.5 Mb
- 1011 PNG images for a total of 151 Mb, the largest image is 715 kb.

Now the figures:
- XML - XSL-FO transformation + FOP generation take 15 minutes on  
a pretty decent DELL Server (running Debian 4.0) having all the  
physical RAM possible (staging server for several customers)


How large would the resulting FO-files be if you dump them to the  
filesystem? The XML by itself says very little. From a 1.5MB XML, you  
could get a FO of a few KB or one of 26MB, depending on the stylesheet.


Does the stylesheet adhere to XSLT best practices? Does it generate a  
lot of redundant fo:blocks, fo:inlines?


- JVM has 2000 Mb (which is BTW the grand max on this processor/ 
server/OS/JVM architecture)

snip /

On my end, that has proven to be more than enough to generate one  
page-sequence with a table of 15 columns, spanning 500+ pages. (Note:  
only text-content, no images; more a test to check the memory usage  
without doing anything special, just a whole lot of FOs)


If I try to investigate memory usage using Runtime.getRuntime 
().getFreeMemory() and logging the figures with log4j, these are  
the figures I get:

- before XSLT + FOP: 1900 Mb free/2000 Mb
- end of XSLT + FOP: 241 Mb free


Yikes! That looks troublesome indeed... :/

- set FopFactory instance to null as a desperate hint to the GC  
that FOP objects could be/should be recycled
- I force garbage collection using System.gc()[OK, in an  
application server this is a brute force approach, but could not  
see a more clever maneuver ATM]


A nit, for the record: There is no such thing as 'forcing garbage  
collection'. The most you can do with System.gc() is indicate to the  
VM that it should run the GC as soon as possible. Admitted, most  
implementations do run the algorithm virtually immediately upon  
execution of the statement, but the Java spec does not mandate such  
behavior. In theory, if the VM is too busy, it could still postpone  
the actual GC-run, until it acquires the necessary resources...



snip /
Now I don't take runtime.getXXXMemory() for bible word but at least  
it looks like the Xalan + FOP subsystem hogs 1500 Mb of RAM which  
I cannot recover.
So I hired the team member who's competent in profiler usage next  
week but I must say at the moment I'm still stuck :-(


If you're not on a Sun VM, then I have a very vague feeling that he's  
going to discover the issue to be related to arrays, a special type  
of object, but I could be wrong about this. Someone once reported  
that the VM seemed to hold on to a lot of arrays. When profiling, he  
discovered that the arrays were referenced nowhere, but still the GC  
did not clean them up.


Of course I've made my homework and read the f...riendly manual  
before daring to ask.

Did I miss any important indication ?



I don't think so, but it seems we might do well by putting some of  
the info concerning JVM/GC implementation we have gathered so far, on  
the website or a Wiki.



Cheers

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

Resolve image url

2008-05-08 Thread mjatromp


Hi,

I am trying to resolve url's that point to local image files (svg). As the
location varies per document, I am trying to use catalogs, but can't get it
to work.

What is the recommended way to do this?

Thanks,

Marcel
--
-- 
View this message in context: 
http://www.nabble.com/Resolve-image-url-tp17122107p17122107.html
Sent from the FOP - Users mailing list archive at Nabble.com.


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

Re: Resolve image url

If you're talking about SVG you have to look into Batik. AFAIK, it
doesn't support URI resolution with a catalog. FOP just passes Batik a
base URI which Batik can use for relative URIs but advanced URI
resolution may not be possible. Better ask on
[EMAIL PROTECTED]

On 08.05.2008 09:48:18 mjatromp wrote:
 
 Hi,
 
 I am trying to resolve url's that point to local image files (svg). As the
 location varies per document, I am trying to use catalogs, but can't get it
 to work.
 
 What is the recommended way to do this?
 
 Thanks,
 
 Marcel
 --
 -- 
 View this message in context: 
 http://www.nabble.com/Resolve-image-url-tp17122107p17122107.html
 Sent from the FOP - Users mailing list archive at Nabble.com.



Jeremias Maerki


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

multiple outputs


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: multiple outputs

That has come up a number of times. To a certain degree, this is
possible, but PDF and TIFF(Java2D) use different font sources with
different font metrics which can lead to small differences between the
two output formats. See:
http://fop-users.markmail.org/message/n3myr6scq6afh7uz?q=tiff+pdf+outputpage=2

The above example does the whole thing from the command-line but of
course, it's possible to do this in one JVM instance. 

See here for more information about the intermediate format (AT):
http://xmlgraphics.apache.org/fop/0.94/intermediate.html
From this information you should be able to derive how you can render
the same intermediate file twice to two different renderers.

On 08.05.2008 10:22:31 paul womack wrote:
 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



Jeremias Maerki


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

Re: multiple outputs


On May 8, 2008, at 10:22, paul womack wrote:

Hi

I see Jeremias has already given info about the AT, so I'll restrict  
myself to some other pointers that may be of use.



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


One very convenient way to generate multiple outputs is to use FOP's  
Ant task.

That would not require much intervention or Java knowledge.


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?


We can't really say, without knowing more about the XSL transform. It  
depends on whether performing the same transform two times in a row  
weighs up to writing the fo to disk and reading it back again.
Note that you can optimize multiple identical transforms by using a  
cached javax.xml.transform.Templates based on the same stylesheet.  
That at least saves you from having to parse the stylesheet twice (or  
more?)



snip /

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


Have a look at the embedding examples:
http://xmlgraphics.apache.org/fop/0.95/embedding.html#examples

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.



HTH!

Cheers

Andreas


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

Re: Problem using Lucida Console font

2008-05-08 Thread John Brown

Jeremias Maerki dev at jeremias-maerki.ch writes:

You are right. The timestamp was different for the AFM files (2007 as
opposed to 1990), so I looked inside one and saw:

Comment AFM Generated by Ghostscript/pf2afm

Looking
at these fonts, BTW, gives me a strong impression that these are illegal
and altered copies (Some of the fonts give a BBS phone number). Anyway,
I had no problems

Oh well...

auto-detecting and using the fonts with FOP 0.95beta.

fop-trunk also works.

If you've installed the fonts in a location other than the directory
mentioned in the following Java class:

http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/autodetect/UnixFontDirFinder.java
you'll have to use the directory element in the font configuration.

It worked. All fonts that I have tried so far (TT and Type1) can now
be used. By the way, the FOP-trunk online documentation says:

Font registration via XML font metrics file is still supported and is still
necessary if you want to use a TrueType Collection (*.ttc). Direct support for
TrueType collections may be added later.

This should be updated, as I can use such fonts. Cambria is an MS font that
comes with Office 2007, but, for whatever reason, it is included in the
latest PowerPoint viewer, the installer of which runs on Linux. Cambria.ttf
contains Cambria and Cambria Math (which I know only because FOP
told me) and I can select either one.

Thanks.

snip/

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

Re: Problem using Lucida Console font


On May 8, 2008, at 09:06, Jeremias Maerki wrote:

snip /
It looks like /usr/local/share/fonts is another place where fonts  
can be
on Unixes but that's not used by FOP, yet. Can a Unix Guru confirm  
that

it would be correct to add this directory to the other ones in
UnitFontDirFinder?


FWIW, no Guru over here, but anyway:
I think this can be safely added. If the directory does not exist, I  
assume IOCommons' DirectoryHandler simply adds nothing to the result  
list (see FontInfoFinder.find())? Only if the DirectoryWalker would  
not handle non-existing directories, we'd have to take care of that  
on our side as well, but checking the Javadocs, DirectoryWalker.walk 
() only throws an IOException if you pass null as the starting-point.



Cheers

Andreas

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

Re: Memory issue

2008-05-08 Thread Jean-François El Fouly


Andreas Delmelle a écrit :


Which Java VM are you using? Practically every time someone tells us 
about memory/GC issues, it appears they are using an implementation 
other than Sun (IBM, GNU...)
Up to now, we still have to find out why precisely non-Sun VMs have 
difficulties with FOP...


Nope. I'll double check but I'm pretty sure it's a genuine Sun JVM 
1.5.0_11, or maybe the very minor build after.
How large would the resulting FO-files be if you dump them to the 
filesystem? The XML by itself says very little. From a 1.5MB XML, you 
could get a FO of a few KB or one of 26MB, depending on the stylesheet.



5.08 Mb.
Does the stylesheet adhere to XSLT best practices? Does it generate a 
lot of redundant fo:blocks, fo:inlines?


I hope not. It has been a complicated thing generated by StyleVision in 
the very beginning but it has been simplified and tweaked a lot.


A nit, for the record: There is no such thing as 'forcing garbage 
collection'. The most you can do with System.gc() is indicate to the 
VM that it should run the GC as soon as possible. Admitted, most 
implementations do run the algorithm virtually immediately upon 
execution of the statement, but the Java spec does not mandate such 
behavior. In theory, if the VM is too busy, it could still postpone 
the actual GC-run, until it acquires the necessary resources...


Indeed, but the log4j log has timestamps and they show that 20 seconds 
are spent around System.gc() so my guess is that something really 
happens at that time.



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

Re: Memory issue


On May 8, 2008, at 11:38, Jean-François El Fouly wrote:

Andreas Delmelle a écrit :


Which Java VM are you using? Practically every time someone tells  
us about memory/GC issues, it appears they are using an  
implementation other than Sun (IBM, GNU...)
Up to now, we still have to find out why precisely non-Sun VMs  
have difficulties with FOP...


Nope. I'll double check but I'm pretty sure it's a genuine Sun JVM  
1.5.0_11, or maybe the very minor build after.


OK. Just curious: Any chance you could test it on another build or  
maybe even Java 6?


How large would the resulting FO-files be if you dump them to the  
filesystem? The XML by itself says very little. From a 1.5MB XML,  
you could get a FO of a few KB or one of 26MB, depending on the  
stylesheet.



5.08 Mb.


That's not what I would call a large FO, so this should be no problem.

Does the stylesheet adhere to XSLT best practices? Does it  
generate a lot of redundant fo:blocks, fo:inlines?


I hope not. It has been a complicated thing generated by  
StyleVision in the very beginning but it has been simplified and  
tweaked a lot.


In my personal experience, optimizing the stylesheet code usually  
does not offer much improvement in terms of global memory usage, but  
it could have a noticeable impact on the processing time. One of the  
things I've learned about generated XSL-FO stylesheets by Altova is  
that they add a lot of fo:inlines to specify, for example, font- 
properties on the lowest levels in the generated FO while, when  
comparing to the font-properties of the fo:inlines' parents nothing  
really changes, except for the size, style or weight. From FOP's  
point of view, that's somewhat of a waste. Much better to specify a  
global font-size on the page-sequence, and override on the lower  
levels only what is really necessary. After adapting the stylesheet  
manually, and removing the redundant fo:inlines, the stylesheet and  
the generated FO were reduced to not even half the original size.


Something else that bothered me, but I don't know if that was also  
generated by Altova, is that in one of the stylesheets I saw, the  
entire transformation was contained in one giant template... AFAIU,  
this gives little opportunity for the XSLT processor to clean up  
anything. Java 1.5 uses Xalan XSLTC by default, which converts  
templates into Java objects. One giant template would then mean one  
very long-living object that may reference numerous others for the  
whole duration of the processing run. If you look at the chain, when  
using XML+XSLT input, FOP is always the first one to finish, then the  
XSLT processor, then the XML parser.
If the XSLT processor cannot reclaim anything, this will give FOP  
less room to work with, so it ultimately runs slower. As the heap  
increases to reach the maximum, the points where the JVM will launch  
the GC by itself, will also increase. Since it cannot expand the heap  
anymore, it will try to clean up more frequently.



Cheers

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

Re: Identify list in subject line

ezmlm adds the List-Post header entry. You can use that for filtering
(assuming that was the cause for this message).

On 08.05.2008 12:01:51 John Brown wrote:
 Hello all,
 
 I think that messages on the fop-users mailing list should identify
 themselves in the subject line, like most mailing lists. For example:
 
 [fop-users] Problem using Lucida Console font




Jeremias Maerki


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

ClassCastException while loading image

2008-05-08 Thread Michael Glass

Hello all,

I just ran into rather strange problems during FO processing, causing the 
exception shown below. My research (web searching, FAQ  mail archive etc.) 
turned up blank.



Started: D:\Java\jre1.6.0_06\bin\java
... lengthy OxygenXML 9.0.0 eclipse plugin commandline ... 
org.apache.fop.cli.Main -fo D:\Tools\e33\xml-test\figures.xml_xslt -pdf 
D:\Tools\e33\xml-test\figures.pdf
08.05.2008 09:30:01 org.apache.fop.image.ImageIOImage loadBitmap
SCHWERWIEGEND: Error while loading image: [B cannot be cast to [S
java.lang.ClassCastException: [B cannot be cast to [S
at sun.awt.image.ShortInterleavedRaster.getDataElements(Unknown Source)
at org.apache.fop.image.ImageIOImage.loadBitmap(ImageIOImage.java:174)
at 
org.apache.fop.image.ImageIOImage.loadDimensions(ImageIOImage.java:68)
at org.apache.fop.image.AbstractFopImage.load(AbstractFopImage.java:161)
at org.apache.fop.fo.flow.ExternalGraphic.bind(ExternalGraphic.java:75)
at org.apache.fop.fo.FObj.processNode(FObj.java:125)
at 
org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:320)
at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:185)
at 
net.sf.saxon.event.ContentHandlerProxy.startContent(ContentHandlerProxy.java:343)
...
---

What I did and what happened:

Two png images are to be included into a pdf. Exceptions occur, finally 
resulting in a null image. PDF is generated, can be viewed, but one image is 
missing. There's just empty space of correct dimensions in the document.

Circumstances:

Both images are fetched from a web server. Both are available by URL in a 
browser and both can be opened by an image editor program, meaning the files 
themselves seem to be ok. Loading the images from remote by a small java awt 
test application (using ImageIO) works fine. Both images were created by 
conversion to png (ImageMagick), one using a wmf as source the other having an 
emf as source. Both images share the same filename but are from different 
paths/URLs.

Java 1.6.0_06
fop.jar: Implementation-Version: 0.94 (OxygenXML 9.0.0 eclipse plugin)

fop.jar: Implementation-Version: 0.20.4 works just fine (XMLmind FO converter 
3.1 without VM))

What happened? Any ideas? Upon request I'll gladly provide both images, the 
minimal fo source and the pdf result.

Best regards and thanks in advance,

Michael Glass
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

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

Re: Problem using Lucida Console font

On 08.05.2008 10:48:33 John Brown wrote:
Jeremias Maerki dev at jeremias-maerki.ch writes:

You are right. The timestamp was different for the AFM files (2007 as
opposed to 1990), so I looked inside one and saw:

Comment AFM Generated by Ghostscript/pf2afm

Looking
at these fonts, BTW, gives me a strong impression that these are illegal
and altered copies (Some of the fonts give a BBS phone number). Anyway,
I had no problems

Oh well...

auto-detecting and using the fonts with FOP 0.95beta.

fop-trunk also works.

If you've installed the fonts in a location other than the directory
mentioned in the following Java class:

http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/autodetect/UnixFontDirFinder.java
you'll have to use the directory element in the font configuration.

It worked. All fonts that I have tried so far (TT and Type1) can now
be used.

Great. Thanks for the feedback. BTW, I've added the additional Unix font
directory: http://svn.apache.org/viewvc?rev=654453view=rev

By the way, the FOP-trunk online documentation says:

Font registration via XML font metrics file is still supported and is still
necessary if you want to use a TrueType Collection (*.ttc). Direct support for
TrueType collections may be added later.

I've updated the documentation in SVN. It will go live the next time the
website is published. Thanks for the hint.

Thanks.

snip/

Jeremias Maerki

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

Identify list in subject line

2008-05-08 Thread John Brown

Hello all,

I think that messages on the fop-users mailing list should identify
themselves in the subject line, like most mailing lists. For example:

[fop-users] Problem using Lucida Console font



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

Re: ClassCastException while loading image

Smells like some class obfuscation gone wrong. Please run FOP outside of
OxygenXML with FOP's own command-line to see if the same thing occurs
there. Otherwise, no better idea, yet.

On 08.05.2008 12:02:05 Michael Glass wrote:
 Hello all,
 
 I just ran into rather strange problems during FO processing, causing the 
 exception shown below. My research (web searching, FAQ  mail archive etc.) 
 turned up blank.
 
 
 
 Started: D:\Java\jre1.6.0_06\bin\java
 ... lengthy OxygenXML 9.0.0 eclipse plugin commandline ... 
 org.apache.fop.cli.Main -fo D:\Tools\e33\xml-test\figures.xml_xslt -pdf 
 D:\Tools\e33\xml-test\figures.pdf
 08.05.2008 09:30:01 org.apache.fop.image.ImageIOImage loadBitmap
 SCHWERWIEGEND: Error while loading image: [B cannot be cast to [S
 java.lang.ClassCastException: [B cannot be cast to [S
   at sun.awt.image.ShortInterleavedRaster.getDataElements(Unknown Source)
   at org.apache.fop.image.ImageIOImage.loadBitmap(ImageIOImage.java:174)
   at 
 org.apache.fop.image.ImageIOImage.loadDimensions(ImageIOImage.java:68)
   at org.apache.fop.image.AbstractFopImage.load(AbstractFopImage.java:161)
   at org.apache.fop.fo.flow.ExternalGraphic.bind(ExternalGraphic.java:75)
   at org.apache.fop.fo.FObj.processNode(FObj.java:125)
   at 
 org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:320)
   at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:185)
   at 
 net.sf.saxon.event.ContentHandlerProxy.startContent(ContentHandlerProxy.java:343)
 ...
 ---
 
 What I did and what happened:
 
 Two png images are to be included into a pdf. Exceptions occur, finally 
 resulting in a null image. PDF is generated, can be viewed, but one image is 
 missing. There's just empty space of correct dimensions in the document.
 
 Circumstances:
 
 Both images are fetched from a web server. Both are available by URL in a 
 browser and both can be opened by an image editor program, meaning the files 
 themselves seem to be ok. Loading the images from remote by a small java awt 
 test application (using ImageIO) works fine. Both images were created by 
 conversion to png (ImageMagick), one using a wmf as source the other having 
 an emf as source. Both images share the same filename but are from different 
 paths/URLs.
 
 Java 1.6.0_06
 fop.jar: Implementation-Version: 0.94 (OxygenXML 9.0.0 eclipse plugin)
 
 fop.jar: Implementation-Version: 0.20.4 works just fine (XMLmind FO converter 
 3.1 without VM))
 
 What happened? Any ideas? Upon request I'll gladly provide both images, the 
 minimal fo source and the pdf result.
 
 Best regards and thanks in advance,
 
 Michael Glass



Jeremias Maerki


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

Re: Memory issue

2008-05-08 Thread Jean-François El Fouly


Andreas Delmelle a écrit :
OK. Just curious: Any chance you could test it on another build or 
maybe even Java 6?



Probably, if required or useful. Our sys admins are very cooperative ;-)


In my personal experience, optimizing the stylesheet code usually does 
not offer much improvement in terms of global memory usage, but it 
could have a noticeable impact on the processing time. One of the 
things I've learned about generated XSL-FO stylesheets by Altova is 
that they add a lot of fo:inlines to specify, for example, 
font-properties on the lowest levels in the generated FO while, when 
comparing to the font-properties of the fo:inlines' parents nothing 
really changes, except for the size, style or weight. From FOP's point 
of view, that's somewhat of a waste. Much better to specify a global 
font-size on the page-sequence, and override on the lower levels only 
what is really necessary. After adapting the stylesheet manually, and 
removing the redundant fo:inlines, the stylesheet and the generated FO 
were reduced to not even half the original size.


Yes. That is exactly what happened to the stylesheet we use. I've 
reduced it drastically.
One issue with stylesheets generated by StyleVision is that you must be 
careful when you tweak them to avoid certain [fo-block inside fo:inline] 
combinations that make FOP crash with a stack trace and no really useful 
information about what's happening or where. This bug is mentioned in 
the FOP bug tracker, though in a rather raw, loose manner. I removed all 
such constructs and that made the XSLT much simpler and cleaner.
Something else that bothered me, but I don't know if that was also 
generated by Altova, is that in one of the stylesheets I saw, the 
entire transformation was contained in one giant template...

With the last version, or our XSLT ? this was no longer the case.
AFAIU, this gives little opportunity for the XSLT processor to clean 
up anything. Java 1.5 uses Xalan XSLTC by default, which converts 
templates into Java objects. One giant template would then mean one 
very long-living object that may reference numerous others for the 
whole duration of the processing run. If you look at the chain, when 
using XML+XSLT input, FOP is always the first one to finish, then the 
XSLT processor, then the XML parser.
If the XSLT processor cannot reclaim anything, this will give FOP less 
room to work with, so it ultimately runs slower. As the heap increases 
to reach the maximum, the points where the JVM will launch the GC by 
itself, will also increase. Since it cannot expand the heap anymore, 
it will try to clean up more frequently.

Yep, that is why I've tried to be cautious not to accuse FOP publicly ;-)
The problem is in the (Xalan + FOP) subsystem and the profiling could 
well show that the issue is Xalan-related.
BTW, we've made the Xalan-FOP coupling a parameter so that we can use 
tight coupling (with Sax events) or loose coupling (writing the 
intermediate FO files on disk). We usually use the second option, since 
the possibility to read the FO intermediate code is helpful when you 
debug. And I guess without being really sure that not to have Xalan and 
FOP working at the same time should use less memory. This separation 
probably accounts for the long execution time, but that is not an issue 
since document generation does not occur often in the target system (you 
can generate chapters for proofreading but you generate the whole 
document once-twice a day).



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

Re: Memory issue


On May 8, 2008, at 12:03, Andreas Delmelle wrote:

Hi Jean-François,


On May 8, 2008, at 12:57, Jean-François El Fouly wrote:


Andreas Delmelle a écrit :
OK. Just curious: Any chance you could test it on another build  
or maybe even Java 6?


Probably, if required or useful. Our sys admins are very  
cooperative ;-)





For the moment, that would be more a nice-to-know. Chances are that,  
if it's not JVM-related, this won't help a thing, so no need to go  
out of your way to do that


snip /
Yes. That is exactly what happened to the stylesheet we use. I've  
reduced it drastically.
One issue with stylesheets generated by StyleVision is that you  
must be careful when you tweak them to avoid certain [fo-block  
inside fo:inline] combinations that make FOP crash with a stack  
trace and no really useful information about what's happening or  
where. This bug is mentioned in the FOP bug tracker, though in a  
rather raw, loose manner. I removed all such constructs and that  
made the XSLT much simpler and cleaner.




OK, so we can exclude that as well.

snip /
AFAIU, this gives little opportunity for the XSLT processor to  
clean up anything. Java 1.5 uses Xalan XSLTC by default, which  
converts templates into Java objects. One giant template would  
then mean one very long-living object that may reference numerous  
others for the whole duration of the processing run. If you look  
at the chain, when using XML+XSLT input, FOP is always the first  
one to finish, then the XSLT processor, then the XML parser.
If the XSLT processor cannot reclaim anything, this will give FOP  
less room to work with, so it ultimately runs slower. As the heap  
increases to reach the maximum, the points where the JVM will  
launch the GC by itself, will also increase. Since it cannot  
expand the heap anymore, it will try to clean up more frequently.


Yep, that is why I've tried to be cautious not to accuse FOP  
publicly ;-)


... which is also why /we/ are so cooperative/responsive. ;-)

BTW: If all users would have the time and motivation to be as  
thorough as yourself, the traffic on this list would probably drop  
significantly.


The problem is in the (Xalan + FOP) subsystem and the profiling  
could well show that the issue is Xalan-related.


Or maybe even Xerces...? Xerces is a very feature-complete parser,  
but reports in the past have shown that all those nice features come  
with a price-tag. For FOP this holds as well, of course, and to be  
honest, FOP can be a pretty memory-hungry beast if you're not careful  
(but you definitely seem to be).


A relatively easy way to find out whether it's XSLT-related, would be  
to try out Saxon instead. I don't know if you have any experience  
with plugging in a different XSLT processor, but this is pretty  
straightforward (but might require re-starting the JBoss service,  
depending on how you go about it; for testing purposes, you could  
ultimately also change the app-code to reference Saxon directly  
instead of letting the JVM choose the  
javax.xml.transform.TransformerFactory implementation, and then  
redeploy).




Cheers

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

Re: multiple outputs


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]

Re: variable size output (pages)?


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


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

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.


A possible option: I once wrote a very small 'FOP server program'. No  
servlet container needed or anything, just a simple program that  
opens a socket, and listens for simple string requests in a form that  
suited me. A modified version of the example files, surrounded by an  
infinite loop.
If you know just a bit of Java, this should take only very little  
time. Programming threads and sockets in Java is a piece of cake,  
when compared to C.


Something like that suffices to keep the Java VM running until a  
forced shutdown, and avoid any startup overhead on all but the very  
first run.


I have only very little experience with Perl, but IIC, it should be  
equally straightforward to send the client request from within a script.


Maybe an idea for you.


HTH!

Cheers

Andreas

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

ClassCastException while loading image

2008-05-08 Thread Michael Glass

Hello all,

I just ran into rather strange problems during FO processing, causing the 
exception shown below. My research (web searching, FAQ  mail archive etc.) 
turned up blank.



Started: D:\Java\jre1.6.0_06\bin\java
... lengthy OxygenXML 9.0.0 eclipse plugin commandline ... 
org.apache.fop.cli.Main -fo D:\Tools\e33\xml-test\figures.xml_xslt -pdf 
D:\Tools\e33\xml-test\figures.pdf
08.05.2008 09:30:01 org.apache.fop.image.ImageIOImage loadBitmap
SCHWERWIEGEND: Error while loading image: [B cannot be cast to [S
java.lang.ClassCastException: [B cannot be cast to [S
at sun.awt.image.ShortInterleavedRaster.getDataElements(Unknown Source)
at org.apache.fop.image.ImageIOImage.loadBitmap(ImageIOImage.java:174)
at 
org.apache.fop.image.ImageIOImage.loadDimensions(ImageIOImage.java:68)
at org.apache.fop.image.AbstractFopImage.load(AbstractFopImage.java:161)
at org.apache.fop.fo.flow.ExternalGraphic.bind(ExternalGraphic.java:75)
at org.apache.fop.fo.FObj.processNode(FObj.java:125)
at 
org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:320)
at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:185)
at 
net.sf.saxon.event.ContentHandlerProxy.startContent(ContentHandlerProxy.java:343)
...
---

What I did and what happened:

Two png images are to be included into a pdf. Exceptions occur, finally 
resulting in a null image. PDF is generated, can be viewed, but one image is 
missing. There's just empty space of correct dimensions in the document.

Circumstances:

Both images are fetched from a web server. Both are available by URL in a 
browser and both can be opened by an image editor program, meaning the files 
themselves seem to be ok. Loading the images from remote by a small java awt 
test application (using ImageIO) works fine. Both images were created by 
conversion to png (ImageMagick), one using a wmf as source the other having an 
emf as source. Both images share the same filename but are from different 
paths/URLs.

Java 1.6.0_06
fop.jar: Implementation-Version: 0.94 (OxygenXML 9.0.0 eclipse plugin)

fop.jar: Implementation-Version: 0.20.4 works just fine (XMLmind FO converter 
3.1 without VM))

What happened? Any ideas? Upon request I'll gladly provide both images, the 
minimal fo source, and the pdf result.

Best regards and thanks in advance,

Michael Glass
-- 
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

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

Re: variable size output (pages)?


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.


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?


1/1000 of a point (= non-standard 'millipoints'), or 1/72000 inches.


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.


What I think would be the easiest approach:
- generate an area tree using a relatively large page-height (enough  
to fit the largest content)
- use forced breaks (break-before=page) in the FO to trigger the  
page-breaks
- if you look at the area tree, you will then see regionViewport /  
elements generated for the region-body of each page; if the initial  
used page-size is large enough, these should have the exact same  
dimensions on every page


Finally, run the area tree through an XSLT transform, that simply  
copies the input, but adds special processing for those  
regionViewports: check the childnodes' accumulated 'bpd' attribute,  
and shrink the regionViewport's bounds so it will fit nicely around  
the content.


This is all a bit speculative, but this seems the most efficient way  
I can come up with FTM, and it does presuppose some knowledge/ 
understanding of XSLT.



Cheers

Andreas


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

Re: variable size output (pages)?


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


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?


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;

^^

HTH!

Andreas

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

Re: Identify list in subject line



On May 8, 2008, at 12:08, Jeremias Maerki wrote:


On 08.05.2008 12:01:51 John Brown wrote:

Hello all,

I think that messages on the fop-users mailing list should identify
themselves in the subject line, like most mailing lists. For example:

[fop-users] Problem using Lucida Console font

ezmlm adds the List-Post header entry. You can use that for  
filtering

(assuming that was the cause for this message).


The recipient would also be a reasonable choice, no?

Only fails for those still posting to the old address --but that's a  
matter of tweaking the condition--, or people who do not use the 'To'  
header...



Cheers,

Andreas

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

Re: variable size output (pages)?