Re: FOP CLI

[J.Pietschmann]

Jeremias Maerki wrote:

commons-cli is quite nice. I use it in Barcode4J. It could simplify the
cli package a bit but would add a new dependency. Not sure if it's worth
it.


I find it more worrisome that there there are a commons-cli v1
and a commons-cli v2 which are incompatible, and I'm not sure
whether v2 will make it to release this time (although it looks
better now than the last try).

J.Pietschmann

Re: svn commit: r674484 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/render/xml/AbstractXMLRenderer.java

[Andreas Delmelle]

On Jul 11, 2008, at 10:55, Jeremias Maerki wrote:

... So the IFRenderer actually doesn't generate any XML itself.  
That will be the job of the

IFSerializer. So IFRenderer will not subclass AbstractXMLRenderer.


Apart from that, I also completely forgot about the SVGRenderer  
(currently still in the sandbox).
Not sure, but that one could be considered an AbstractXMLRenderer as  
well.


And yes, I agree that it's not really a bad thing to have lots of  
abstractions, as long as they're actually useful.
If you have only one class that extends it, and there's no immediate  
benefit, it's worth to stop and think for a second...


Considering the above: even if not useful for the new IF, there does  
seem to be potential benefit for rendering to XML formats.



Cheers

Andreas

Re: Embedding fonts from JAR: Problem in FOURIResolver.resolve()

[Thomas S.]

Max Berger wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> this may not help, but here's a different approach:
> 
> Fop (Trunk) supports fonts in jar-files directly, without the need of
> font-metrik files. It also adds general support for fonts described with
> an URI rather than a file path, which probably solved the problems you
> described.
> 
> You will need to add  to your fop config file, and prepare
> special font jars, as described in:
> 
> http://xmlgraphics.apache.org/fop/trunk/fonts.html
> 
> This feature is still little tested, so I would be happy to receive any
> feedback, especially in the case of a web application, where classloader
> issues surface frequently.
> 

I would prefer the option to configure custom fonts explicitly, cause I use
several different, independent 
layouts in one JAR file, each of them brings it's own configuration, images
and fonts. Autodetection of fonts
will bring the same custom fonts for all layouts.
So it would be great, if someone can take a look at my comments for
FOURIResolver.resolve().

Although I'm trying your suggestion right now, but I cannot understand the
description of the configuration
format found on
http://xmlgraphics.apache.org/fop/trunk/fonts.html#autodetect for
MANIFEST.MF: What format
must the MANIFEST.MF file have to make (for example) the two font files
fontdir/foo.ttf and fontdir/blah.ttf
known to FOP?

-- 
View this message in context: 
http://www.nabble.com/Embedding-fonts-from-JAR%3A-Problem-in-FOURIResolver.resolve%28%29-tp18399841p18406661.html
Sent from the FOP - Dev mailing list archive at Nabble.com.

Re: svn commit: r675698 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/cli: CommandLineOptions.java InputHandler.java Main.java

[Peter B. West]

I can recommend it.

Max Berger wrote:

Vincent,

it may (or may not) make sense to move to commons-cli:

http://commons.apache.org/cli/introduction.html

which addresses this (and other problems) very well, but this would mean
a lot more work.

Max



--
Peter B. West 
Folio 

Re: svn commit: r675698 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/cli: CommandLineOptions.java InputHandler.java Main.java

[Jeremias Maerki]

commons-cli is quite nice. I use it in Barcode4J. It could simplify the
cli package a bit but would add a new dependency. Not sure if it's worth
it.

On 11.07.2008 13:29:43 Max Berger wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Vincent,
> 
> it may (or may not) make sense to move to commons-cli:
> 
> http://commons.apache.org/cli/introduction.html
> 
> which addresses this (and other problems) very well, but this would mean
> a lot more work.
> 
> Max
> 
> Jeremias Maerki schrieb:
> > Hi Vincent
> > 
> > Certainly not, but you'll probably have to do a few more changes to the
> > command-line parser to be able to use the "-". You'll see. ;-)
> > 
> > On 11.07.2008 12:01:24 Vincent Hennebert wrote:
> >> Hi Jeremias,
> >>
> >>> Author: jeremias
> >>> Date: Thu Jul 10 12:47:12 2008
> >>> New Revision: 675698
> >>>
> >>> URL: http://svn.apache.org/viewvc?rev=675698&view=rev
> >>> Log:
> >>> Added support for piping:
> >>> - input from stdin (-imagein not supported)
> >>> - output to stdout
> >>>
> >>> Syntax: fop -xml # -xsl mystylesheet.xsl -pdf #
> >>> (reads the XML from stdin and sends the generated PDF to stdout)
> >> The de facto standard in the Unix world is to use ‘-’ to specify stdin
> >> or stdout:
> >> fop -xml - -xsl mystylesheet.xsl -pdf -
> >>
> >> No objection if I change the code accordingly?
> >>
> >> Thanks,
> >> Vincent
> > 
> > 
> > 
> > 
> > Jeremias Maerki
> > 
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkh3RCUACgkQ+Gr+4pk71JyASACfc9j+U87JiPH36L8ApBWvn9p2
> myUAnR3Ac7DXQqXPIy6xrrwEKnkkVQAh
> =eiDz
> -END PGP SIGNATURE-




Jeremias Maerki

Re: svn commit: r675698 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/cli: CommandLineOptions.java InputHandler.java Main.java

[Max Berger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Vincent,

it may (or may not) make sense to move to commons-cli:

http://commons.apache.org/cli/introduction.html

which addresses this (and other problems) very well, but this would mean
a lot more work.

Max

Jeremias Maerki schrieb:
> Hi Vincent
> 
> Certainly not, but you'll probably have to do a few more changes to the
> command-line parser to be able to use the "-". You'll see. ;-)
> 
> On 11.07.2008 12:01:24 Vincent Hennebert wrote:
>> Hi Jeremias,
>>
>>> Author: jeremias
>>> Date: Thu Jul 10 12:47:12 2008
>>> New Revision: 675698
>>>
>>> URL: http://svn.apache.org/viewvc?rev=675698&view=rev
>>> Log:
>>> Added support for piping:
>>> - input from stdin (-imagein not supported)
>>> - output to stdout
>>>
>>> Syntax: fop -xml # -xsl mystylesheet.xsl -pdf #
>>> (reads the XML from stdin and sends the generated PDF to stdout)
>> The de facto standard in the Unix world is to use ‘-’ to specify stdin
>> or stdout:
>> fop -xml - -xsl mystylesheet.xsl -pdf -
>>
>> No objection if I change the code accordingly?
>>
>> Thanks,
>> Vincent
> 
> 
> 
> 
> Jeremias Maerki
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkh3RCUACgkQ+Gr+4pk71JyASACfc9j+U87JiPH36L8ApBWvn9p2
myUAnR3Ac7DXQqXPIy6xrrwEKnkkVQAh
=eiDz
-END PGP SIGNATURE-

Re: Building FOP Trunk with Any - BUILD FAILED

[Jeremias Maerki]

Bonekrusher and I had an exchange off-list. He did a few tests for me
and my recent change didn't help either.

Basically, we established the following:
- He's also running WinXP
- He's running the same JDK as I do.
- The XSLT processor used in the context of the error is a normal Apache
Xalan, just like on my machine.

I think Adrian's comment (about the file URL) could be a good hint at
what's wrong but I have no idea where this is coming from. Short of
debugging the code on Bonekrusher's machine I have no idea how to fix
this problem.

On 09.07.2008 19:58:20 bonekrusher wrote:
> 
> Hi  Jeremias - I set you an email. Let me know if you received it. thx
> 
> 
> Jeremias Maerki-2 wrote:
> > 
> > Not really. Please do "ant clean package >out.txt" and send me the
> > "out.txt" file (off-list).
> > 
> > On 09.07.2008 16:45:48 bonekrusher wrote:
> >> 
> >> I spoke to soon. I am getting the same error after the clean.
> >> 
> >> I am using Java 1.6
> >> 
> >> Any ideas?
> >> 
> >> thx
> >> 
> >> 
> >> Jeremias Maerki-2 wrote:
> >> > 
> >> > Yes. Works fine for me, BTW. An "ant clean" prior to the build can work
> >> > wonders sometimes. Also, make sure you're using a Sun JVM to avoid any
> >> > unexpected side-effects.
> >> > 
> >> > On 09.07.2008 16:15:54 bonekrusher wrote:
> >> >> 
> >> >> I downloaded the latest Trunk this morning, which should be the
> >> latest.
> >> >> Correct?
> >> >  
> >> > 
> >> > 
> >> > 
> >> > Jeremias Maerki
> >> > 
> >> > 
> >> > 
> >> 
> >> -- 
> >> View this message in context:
> >> http://www.nabble.com/Building-FOP-Trunk-with-Ant---BUILD-FAILED-tp18359419p18363253.html
> >> Sent from the FOP - Dev mailing list archive at Nabble.com.
> > 
> > 
> > 
> > 
> > Jeremias Maerki
> > 
> > 
> > 
> 
> -- 
> View this message in context: 
> http://www.nabble.com/Building-FOP-Trunk-with-Ant---BUILD-FAILED-tp18359419p18367327.html
> Sent from the FOP - Dev mailing list archive at Nabble.com.




Jeremias Maerki

Re: svn commit: r675698 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/cli: CommandLineOptions.java InputHandler.java Main.java

[Jeremias Maerki]

Hi Vincent

Certainly not, but you'll probably have to do a few more changes to the
command-line parser to be able to use the "-". You'll see. ;-)

On 11.07.2008 12:01:24 Vincent Hennebert wrote:
> Hi Jeremias,
> 
> > Author: jeremias
> > Date: Thu Jul 10 12:47:12 2008
> > New Revision: 675698
> > 
> > URL: http://svn.apache.org/viewvc?rev=675698&view=rev
> > Log:
> > Added support for piping:
> > - input from stdin (-imagein not supported)
> > - output to stdout
> > 
> > Syntax: fop -xml # -xsl mystylesheet.xsl -pdf #
> > (reads the XML from stdin and sends the generated PDF to stdout)
> 
> The de facto standard in the Unix world is to use ‘-’ to specify stdin
> or stdout:
> fop -xml - -xsl mystylesheet.xsl -pdf -
> 
> No objection if I change the code accordingly?
> 
> Thanks,
> Vincent




Jeremias Maerki

Re: svn commit: r675698 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/cli: CommandLineOptions.java InputHandler.java Main.java

[Vincent Hennebert]

Hi Jeremias,

> Author: jeremias
> Date: Thu Jul 10 12:47:12 2008
> New Revision: 675698
> 
> URL: http://svn.apache.org/viewvc?rev=675698&view=rev
> Log:
> Added support for piping:
> - input from stdin (-imagein not supported)
> - output to stdout
> 
> Syntax: fop -xml # -xsl mystylesheet.xsl -pdf #
> (reads the XML from stdin and sends the generated PDF to stdout)

The de facto standard in the Unix world is to use ‘-’ to specify stdin
or stdout:
fop -xml - -xsl mystylesheet.xsl -pdf -

No objection if I change the code accordingly?

Thanks,
Vincent

Re: Embedding fonts from JAR: Problem in FOURIResolver.resolve()

[Max Berger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thomas,

this may not help, but here's a different approach:

Fop (Trunk) supports fonts in jar-files directly, without the need of
font-metrik files. It also adds general support for fonts described with
an URI rather than a file path, which probably solved the problems you
described.

You will need to add  to your fop config file, and prepare
special font jars, as described in:

http://xmlgraphics.apache.org/fop/trunk/fonts.html

This feature is still little tested, so I would be happy to receive any
feedback, especially in the case of a web application, where classloader
issues surface frequently.

Max

Thomas S. schrieb:
> I already posted this message in the fop-user list, but I think it's better
> placed here, cause now
> I think it's not a usage problem.
> 
> I use Apache FOP 0.94 to include Truetype-fonts into PDFs, which works
> perfectly, if the needed
> configuration and  font description files are placed in a directory within
> file system, but for usage
> within a web application I pack these files into a JAR file, and this causes
> problems, which I
> suppose to be in method 
> public Source org.apache.fop.apps.FOURIResolver.resolve(String href, String
> base).
> Reading the configuration and including images from the JAR still works, but
> loading the font metric
> unfortunately not.
> 
> I also tried 0.95beta with same result, and the implementation of the
> relevant code in trunk seems
> to be unchanged between rev. 567305 (tag for 0.94) and trunk, so this
> applies also for trunk
> version. All mentioned line numbers refer to 0.94 / rev. 567305. Now for the
> details...
> 
> The configuration and image-inclusion works with relative URLs, an example
> is:
> href:   image/header.png
> base: jar:file:/path_to_jar/file.jar!/path_within_jar/
> 
> This works without a problem!
> 
> But when a font within the XSL-FO processing has to be loaded, the method
> FOURIResolver.resolve(String href, String base) is indirectly called from
> LazyFont.load() line: 79, now href is an absolute URL to the font metrics
> file.
> 
> So the two argument in FOURIResolver.resolve(String href, String base) are:
> href:  
> jar:file:/path_to_jar/file.jar!/path_within_jar/fonts/ttfnewsgothic.xml
> base: jar:file:/path_to_jar/file.jar!/path_within_jar/
> 
> The problem is, that lines 194-196 remove "jar:" from href, and we run into
> the problem,
> that in line 208 the constructor new URL(URL basURL, String href) is called
> with a href still containing a protocol (file:), which is different from the
> protocol of the
> baseURL (jar:), so absoluteURL = new URL(baseURL, href) sets
> absoluteURL to
> file:/path_to_file/file.jar!/path_within_jar/fonts/ttfnewsgothic.xml.
> This URL doesn't work, cause it's missing the proper protocol specification
> (jar:).
> 
> I have to admit, that I don't understand, what lines 197-203 should do (Ok,
> we prepend a slash to
> the url, if there is a colon and a slash in the url, and the colon is places
> before the slash, but why?),
> so I cannot give a proper solution for that problem.
> 
> But if it's not needed to remove the scheme from the url, if scheme isn't
> "file:" (cause only for this
> scheme, the slash is prepended), this diff whould help:
> 
> 195c236
> < if (href.startsWith(scheme)) {
> ---
>> if (href.startsWith(scheme) && "file:".equals(scheme))
>> {
> 197d237
> < if ("file:".equals(scheme)) {
> 206d245
> < }
> 
> What do you think?

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkh3Kl4ACgkQ+Gr+4pk71Jwo0gCggJNl/G3+3N9YpKFEVIbupkd6
tt0An19wI65V4wa7Ajv0axn6xonQYMpN
=cyfL
-END PGP SIGNATURE-

Re: Building FOP Trunk with Ant - BUILD FAILED

[Leeloo5E-FOP]

Hi,

got the same problem when trying to build FOP from Trunk with the
pre-installed version 1.6.5 of ant on a linux maschine. Using version 1.7.0
instead, the build runs fine. I do not try the newest version 1.7.1 of ant
yet (I comes out on june 28th). For building FOP from Trunk I used the
pre-installed jre 1.4.2 or 1.5.0 from SUN on my linux maschines.

Thats my suggestions.

Best Regards,
Lee


bonekrusher wrote:
> 
> Hi,
> 
> I am trying to build the FOP trunk (checked out with svn) with Ant and get
> the following error:
> 
> va:231: warning: [deprecation] toURL() in java.io.File has been deprecated
> [javac] urls.add(libFiles[i].toURL());
> [javac] ^
> [javac] 26 warnings
> [mkdir] Created dir: C:\fop_trunk\trunk\build\sandbox-classes
> [javac] Compiling 11 source files to
> C:\fop_trunk\trunk\build\sandbox-classe
> s
> 
> resourcegen:
> [mkdir] Created dir: C:\fop_trunk\trunk\build\codegen-classes
> [javac] Compiling 3 source files to
> C:\fop_trunk\trunk\build\codegen-classes
> 
>  [copy] Copying 2 files to C:\fop_trunk\trunk\build\codegen-classes
> 
> BUILD FAILED
> C:\fop_trunk\trunk\build.xml:353: java.io.IOException:
> java.io.FileNotFoundExcep
> tion:
> file:\C:\fop_trunk\trunk\build\gensrc\org\apache\fop\events\event-model.xm
> l (The filename, directory name, or volume label syntax is incorrect)
> 
> Total time: 33 seconds
> 
> ***
> 
> The C:\fop_trunk\trunk\build\gensrc\org\apache\fop\events folder is empty.
> 
> Any thoughts:?
> 

-- 
View this message in context: 
http://www.nabble.com/Building-FOP-Trunk-with-Ant---BUILD-FAILED-tp18359419p1849.html
Sent from the FOP - Dev mailing list archive at Nabble.com.

Embedding fonts from JAR: Problem in FOURIResolver.resolve()

[Thomas S.]

I already posted this message in the fop-user list, but I think it's better
placed here, cause now
I think it's not a usage problem.

I use Apache FOP 0.94 to include Truetype-fonts into PDFs, which works
perfectly, if the needed
configuration and  font description files are placed in a directory within
file system, but for usage
within a web application I pack these files into a JAR file, and this causes
problems, which I
suppose to be in method 
public Source org.apache.fop.apps.FOURIResolver.resolve(String href, String
base).
Reading the configuration and including images from the JAR still works, but
loading the font metric
unfortunately not.

I also tried 0.95beta with same result, and the implementation of the
relevant code in trunk seems
to be unchanged between rev. 567305 (tag for 0.94) and trunk, so this
applies also for trunk
version. All mentioned line numbers refer to 0.94 / rev. 567305. Now for the
details...

The configuration and image-inclusion works with relative URLs, an example
is:
href:   image/header.png
base: jar:file:/path_to_jar/file.jar!/path_within_jar/

This works without a problem!

But when a font within the XSL-FO processing has to be loaded, the method
FOURIResolver.resolve(String href, String base) is indirectly called from
LazyFont.load() line: 79, now href is an absolute URL to the font metrics
file.

So the two argument in FOURIResolver.resolve(String href, String base) are:
href:  
jar:file:/path_to_jar/file.jar!/path_within_jar/fonts/ttfnewsgothic.xml
base: jar:file:/path_to_jar/file.jar!/path_within_jar/

The problem is, that lines 194-196 remove "jar:" from href, and we run into
the problem,
that in line 208 the constructor new URL(URL basURL, String href) is called
with a href still containing a protocol (file:), which is different from the
protocol of the
baseURL (jar:), so absoluteURL = new URL(baseURL, href) sets
absoluteURL to
file:/path_to_file/file.jar!/path_within_jar/fonts/ttfnewsgothic.xml.
This URL doesn't work, cause it's missing the proper protocol specification
(jar:).

I have to admit, that I don't understand, what lines 197-203 should do (Ok,
we prepend a slash to
the url, if there is a colon and a slash in the url, and the colon is places
before the slash, but why?),
so I cannot give a proper solution for that problem.

But if it's not needed to remove the scheme from the url, if scheme isn't
"file:" (cause only for this
scheme, the slash is prepended), this diff whould help:

195c236
< if (href.startsWith(scheme)) {
---
> if (href.startsWith(scheme) && "file:".equals(scheme))
> {
197d237
< if ("file:".equals(scheme)) {
206d245
< }

What do you think?
-- 
View this message in context: 
http://www.nabble.com/Embedding-fonts-from-JAR%3A-Problem-in-FOURIResolver.resolve%28%29-tp18399841p18399841.html
Sent from the FOP - Dev mailing list archive at Nabble.com.

Re: svn commit: r674484 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/render/xml/AbstractXMLRenderer.java

[Jeremias Maerki]

Adrian,

thanks for uploading your changes to the Temp_AreaTreeRedesign branch.
I made a mistake which sent you off in the wrong direction. The text was
describing a different design than was shown in the graphic [1]. I've
now updated the graphic. The clue here is to avoid going through the SAX
ContentHandler when painting without serialization to the intermediate
format. That would have caused a performance penalty. So the IFRenderer
actually doesn't generate any XML itself. That will be the job of the
IFSerializer. So IFRenderer will not subclass AbstractXMLRenderer. Sorry
for the confusion.

[1] http://wiki.apache.org/xmlgraphics-fop/AreaTreeIntermediateXml/NewDesign

On 08.07.2008 11:25:31 Adrian Cumiskey wrote:
> As it is, I have a class in the Temp_AreaTreeRedesign branch that extends 
> AbstractXMLRenderer.  I 
> thought it useful to provide the class in trunk for anyone else who may wish 
> to create their own XML 
> based renderer for whatever purposes.
> 
> However, IMO you can never have enough abstract classes, helps to hide/break 
> up some of the 
> complexity and remove some unnecessary code dependencies and give yourself 
> options to extend the class.
> 
> Adrian.
> 
> Andreas Delmelle wrote:
> > On Jul 7, 2008, at 15:39, Jeremias Maerki wrote:
> > 
> >>> On 07.07.2008 15:28:26 acumiskey wrote:
>  Author: acumiskey
>  Date: Mon Jul  7 06:28:26 2008
>  New Revision: 674484
> 
>  URL: http://svn.apache.org/viewvc?rev=674484&view=rev
>  Log:
>  Added new AbstractXMLRenderer base class.
> 
>  Added:
>  
>  xmlgraphics/fop/trunk/src/java/org/apache/fop/render/xml/AbstractXMLRenderer.java
> 
>  (with props)
> 
> > 
> >> What for? Just curious.
> > 
> > Me too... Just abstracting to abstract seems to make little sense. :-/
> > 
> > 
> > Cheers
> > 
> > Andreas
> > 
> > 




Jeremias Maerki