Re: Apache FOP on .NET
Jeremias Maerki wrote: I think having the opportunity to provide a .NET version of FOP would widen the number of potential users considerably especially since to my knowledge there's no usable open source .NET FO implementation out there. Depending on the license situation (IKVM is BSD but GNU Classpath is LGPL) we could even think about distributing .NET binaries. I think that's a good move and definitely would be well accepted in the .NET community. I could help you on that. And besides IKVM what do yo uthink about other options - using J# or even porting to C#? -- Oleg
Re: Apache FOP on .NET
Hi Oleg, I see you're still a lurker. :-) J#: I don't know. It looks like you need a Visual Studio .NET license which I don't have. Was this what nfop was done with? I didn't look. C#: I don't have time to help with such an endeavour in the near future. That's a huge task. And the Java version takes effort enough at the moment. I know people who would be very interested to run FOP on .NET but for the moment I'm only going to take the easy road via IKVM so see where I get. But I guess one could think about creating additional source code in C# or any other .NET language to provide additional features that might be difficult with IKVM. Since IKVM has problems with AWT it might make sense to write a renderer in C# to do direct printing, for example. But my priorities are with PDF and PS at the moment. On 22.11.2005 10:27:09 Oleg Tkachenko wrote: Jeremias Maerki wrote: I think having the opportunity to provide a .NET version of FOP would widen the number of potential users considerably especially since to my knowledge there's no usable open source .NET FO implementation out there. Depending on the license situation (IKVM is BSD but GNU Classpath is LGPL) we could even think about distributing .NET binaries. I think that's a good move and definitely would be well accepted in the .NET community. I could help you on that. And besides IKVM what do yo uthink about other options - using J# or even porting to C#? -- Oleg Jeremias Maerki
DO NOT REPLY [Bug 37579] - footnotes within table-cell get lost
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37579. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37579 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2005-11-22 11:02 --- Two test cases added to our test suite: http://svn.apache.org/viewcvs?rev=348138view=rev The same problem exists with lists. The problem is the following: In table and list layout Knuth element lists are combined to a single element list. The footnotes contained in KnuthBlockBoxes in the original element lists currently don't get propagated to the combined element lists and that's why the footnotes get ignored. It shouldn't be too hard to fix. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 37589] New: - iText, Bookmarks and Document Info
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37589. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37589 Summary: iText, Bookmarks and Document Info Product: Fop Version: 0.20.5 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: documentation AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] On the website, it is stated that iText swallows bookmarks. If you instead of using PDFWriter, uses PDFStamper then itext does not swallow bookmarks. The PDFInfo class mentioned her is the one enclosed in FOP, but with creatation date predefined and an number of other methods defined to set the different parameters. PDFInfo info = new PDFInfo(); PdfReader reader = new PdfReader(fi); info.setTitle(title); info.setSubject(A subject); info.setCreator(A Creator + ver); info.setAuthor(This Working Group); PdfStamper stamp = new PdfStamper(reader, new FileOutputStream(fo)); stamp.setMoreInfo(info.toMap()); stamp.close(); BTW. How come you have not created a fop extension for the document properties. Eg.you should enable elements such as fox:author, fox:title etc. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 37589] - iText, Bookmarks and Document Info
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37589. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37589 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2005-11-22 11:08 --- (In reply to comment #0) On the website, it is stated that iText swallows bookmarks. If you instead of using PDFWriter, uses PDFStamper then itext does not swallow bookmarks. The PDFInfo class mentioned her is the one enclosed in FOP, but with creatation date predefined and an number of other methods defined to set the different parameters. PDFInfo info = new PDFInfo(); PdfReader reader = new PdfReader(fi); info.setTitle(title); info.setSubject(A subject); info.setCreator(A Creator + ver); info.setAuthor(This Working Group); PdfStamper stamp = new PdfStamper(reader, new FileOutputStream(fo)); stamp.setMoreInfo(info.toMap()); stamp.close(); Thanks for the info. I'll integrate it into the website. BTW. How come you have not created a fop extension for the document properties. Eg.you should enable elements such as fox:author, fox:title etc. We could do a lot of things. But someone has to have the time and motivation to actually do it. You've got access to the source code. Patches are welcome!!! :-) BTW, FOP Trunk/0.90alpha1 supports setting all the above through the FOUserAgent. Granted, it's not the same as setting these values through the FO input and we don't support XMP metadata, yet. But everyone is invited to help improve. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: Apache FOP on .NET
Jeremias Maerki wrote: J#: I don't know. It looks like you need a Visual Studio .NET license which I don't have. Was this what nfop was done with? I didn't look. afair J# command line compiler is a part of .NET SDK. I'll check it out anyway. The main problem I think is that J# supports only Java 1.1.4 subset... C#: I don't have time to help with such an endeavour in the near future. That's a huge task. And the Java version takes effort enough at the moment. Ok, forget it. -- Oleg
Re: Apache FOP on .NET
On Tue, Nov 22, 2005 at 10:51:40AM +0100, Jeremias Maerki wrote: Hi Oleg, I see you're still a lurker. :-) J#: I don't know. It looks like you need a Visual Studio .NET license which I don't have. Was this what nfop was done with? I didn't look. C#: I don't have time to help with such an endeavour in the near future. That's a huge task. And the Java version takes effort enough at the moment. I know people who would be very interested to run FOP on .NET but for the moment I'm only going to take the easy road via IKVM so see where I get. But I guess one could think about creating additional source code in C# or any other .NET language to provide additional features that might be difficult with IKVM. Since IKVM has problems with AWT it might make sense to write a renderer in C# to do direct printing, for example. But my priorities are with PDF and PS at the moment. On a side note, an interesting way to get the AWT going on Win32 could be to use the Qt4 peers in GNU Classpath with a Qt4 build on Win32. You may want to see if Jeroen or someone on the IKVM list has looked that way. I've got the Qt4 peers working with Kaffe on Linux and OS X, but didn't have much time to play with Kaffe on Cygwin recently. cheers, dalibor topic On 22.11.2005 10:27:09 Oleg Tkachenko wrote: Jeremias Maerki wrote: I think having the opportunity to provide a .NET version of FOP would widen the number of potential users considerably especially since to my knowledge there's no usable open source .NET FO implementation out there. Depending on the license situation (IKVM is BSD but GNU Classpath is LGPL) we could even think about distributing .NET binaries. I think that's a good move and definitely would be well accepted in the .NET community. I could help you on that. And besides IKVM what do yo uthink about other options - using J# or even porting to C#? -- Oleg Jeremias Maerki
Re: Apache FOP on .NET
On Tue, Nov 22, 2005 at 09:12:05AM +0100, Jeremias Maerki wrote: Hi Dalibor Good thing you're still lurking! :-) Well, FOP is very interesting for me in terms of having a free DocBook toolchain on free runtimes that's well maintained. If you are around at FOSDEM, it'd be great to have a small talk about FOP, Batik, XML graphics and free runtimes, what works, what we still need, which areas would need more work, etc. On 21.11.2005 23:48:37 Dalibor Topic wrote: On Mon, Nov 21, 2005 at 10:29:18AM +0100, Jeremias Maerki wrote: Hi gang, as you know we've have several inquiries in the past about compiling FOP with GNU Classpath for use in VMs such as Kaffe or natively on Unixes (using GCC/GCJ) and about running Apache FOP under .NET. I've done some experiments last week in this direction and here's what I found out: After removing Batik as a dependency for FOP allows FOP to run and compile under IKVM [1]. So far, I've managed to run FOP from the command-line as an EXE file on Windows to create PDF files. No fancy tests, yet. I'll try to see what needs to be done to call FOP from a C# application by compiling FOP and its dependency into DLLs. Yay! Congrats all over! :-) Batik has the problem that it relies on com.sun.* classes which has been brought up on batik-dev. (Thomas, just so you know, I'm working on that one. I'll drop a note on batik-dev about that shortly.) Given this problem it's currently not possible to compile Batik for use in Kaffe or IKVM (both use GNU Classpath). Furthermore, it seems that the AWT implementation of IKVM is unfinished and results in runtime errors (which have nothing to do with the com.sun.* classes) when forcing IKVM to run a precompiled Batik JAR. Yup. I was under the impression that the XML graphics project would help work around the most dire problems, though. Right? As much as we can, anyway. I'm working on that. I don't think I'll be able to help improving IKVM. GNU Classpath might be easier to help with, but then I still don't have a clue how to work with GNU Classpath on Windows (Cygwin only coming with GCC 3.x, not 4.0). I haven't had the time to help myself to a true Unix environment, yet. I've got access to two Unix systems, both of which don't have GCC/GCJ installed and I have limited knowledge on unixish systems to simply know how to install additional software (if I'm allowed at all). And then I hate C/C++ and having to apply patches before I can compile some software. :-) So this means that it takes a lot of nerves to go after this. Heh, I know, I know ... I can't build Kaffe on Cygwin without a patched up jikes, with Davanum's patches from CVS, etc... I need to pickup my conversation with Cygwin packagers to see if we can get Kaffe packaged in there. With the recent CVS head it's possible to use Kaffe with GNU Classpath like with JamVM, and other runtimes, but it's still some time to go until I release 1.1.7. I'll play around a bit with gcjx on cygwin, to see if it works better than jikes. Since we've also heard several voices who would like the Batik-dependency to be optional for FOP (to reduce JAR size), I'd like to propose making it so by extracting the SVG support from the main codebase. Some of this will be done anyway, as we're going to move stuff out to XML Graphics Commons. I'm not sure about the placement of the sources, yet. There are several possibilities: (1) Move optional FOP extensions (SVG and MathML) to src/extensions/name/java (where name is svg or mathml). (2) Move optional FOP extensions to src/optional/java along with code for JAI, JIMI and similar things. +1 (3) Move FOP extensions under src/java/org/apache/fop/extensions/name where all the various sources will be concentrated. ATM, the SVG support classes are scattered over the whole codebase which I don't like so much. I'm open for additional suggestions. Generally, I don't like having all the code in one tree but in XML Graphics Commons this approach has won, too. I think having the opportunity to provide a .NET version of FOP would widen the number of potential users considerably especially since to my knowledge there's no usable open source .NET FO implementation out there. Depending on the license situation (IKVM is BSD but GNU Classpath is LGPL) we could even think about distributing .NET binaries. GNU Classpath is more liberally licensed than LGPL, actually ;) It's the GPL with a big fat linking exception, that puts no restrictions on the license of the linking code. Oops, sorry, looks like I had the wrong idea in mind. There was so much talk within the ASF about LGPL that I assumed Harmony's problem was with the LGPL. LGPL is mopstly important because of Hibernate, afaik. But it'd be an interesting milestone in terms of how much copyleft is acceptable in what sort of dependencies.
Re: Illegal property values
On Nov 16, 2005, at 19:24, Andreas L Delmelle wrote:
On Nov 16, 2005, at 11:51, Luca Furini wrote:
snip /
There are other properties with a validity range and a fallback
value: column-count, initial-page-number, column-number, number-
columns-repeated, number-columns-spanned, number-rows-spanned,
hyphenation-{push, remain}-character-count; only hyphenation-
ladder-count does not have a fallback value in 1.0, so maybe this
was just an oversight.
Note that the fallback value is different, in general, from the
default value, as it is derived from the illegal value by rounding.
I guess we'll have to have a look at all these properties to see
how the fallbacks are dealt with.
snip/
I'll look into this as soon as I find some spare time.
I took another look, and none of the mentioned properties (with the
exception of column-number) perform a validity check/provide a
fallback. Haven't checked all applicable FObj's yet to see if the
errors are reported there...
On another note, there are a few other number-properties for which
bogus-values are currently allowed:
- orphans / widows: from the definition, one would say positive
integer (?); any value allowed
- reference-orientation: only 7 possible values; any value is allowed.
- grouping-size: zero-or-positive; negatives are allowed
- maximum-repeats: zero-or-positive; negatives are allowed
Since grouping-size and maximum-repeats are applicable to only one or
two types of FO, the fallback could easily be provided when the
property is bound.
For reference-orientation, I'm still doubting... The values are
numeric, but supposed to be treated as a sort of enum. Probably best
off with a tiny custom Maker to avoid code duplication, and catch the
error as early as possible.
For orphans and widows, the Rec doesn't explicitly state what to do
with zero-or-negative values (neither does CSS) --maybe we could
suffice with a warning message here (and a common-sense substitution
with the initial value?)
Cheers,
Andreas
DO NOT REPLY [Bug 37589] - iText, Bookmarks and Document Info
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37589. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37589 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-11-22 20:04 --- I've added your tip to the website sources. Thanks! http://svn.apache.org/viewcvs?rev=348211view=rev -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: Release
OK, except that I could not verify your signature: gpg --verify fop-0.90alpha1-src.tar.gz.asc fop-0.90alpha1-src.tar.gz gpg: Signature made Mon 21 Nov 2005 23:05:36 CET using DSA key ID 8408F755 gpg: BAD signature from Christian Geisert [EMAIL PROTECTED] gpg --verify fop-0.90alpha1-bin-jdk1.4.tar.gz.asc fop-0.90alpha1-bin-jdk1.4.tar.gz.asc gpg: Signature made Mon 21 Nov 2005 23:05:12 CET using DSA key ID 8408F755 gpg: BAD signature from Christian Geisert [EMAIL PROTECTED] Simon On Mon, Nov 21, 2005 at 10:36:13PM +0100, Christian Geisert wrote: Hi, as you've probably noticed I've tagged the 0.90alpha1 release. It would be nice if someone else could have a look at the builds (available at http://people.apache.org/~chrisg/fop-0.90alpha1-test/) for a quick test. If no showstoppers are reported within the next hours I'll move this to the distribution area (and wait 24 hours for the mirrors to catch up). Christian -- Simon Pepping home page: http://www.leverkruid.nl
Re: Release
Simon Pepping schrieb: OK, except that I could not verify your signature: Yes, I screwed it up - fixed now. Thanks for checking Christian
[ANNOUNCEMENT] Apache FOP 0.90 alpha 1 released
The Apache FOP team is excited to announce the release of Apache FOP 0.90 alpha 1, the first preview release after over three years of redesign and after two and a half years without a new release. Apache FOP is the Apache Software Foundation's XSL-FO implementation written in Java with support for several output formats like PDF, PostScript, Plain Text, RTF etc. This new release brings you long-awaited features like keeps on all implemented FO elements, support for reference-orientation, better indent behaviour, various improvements on inline elements like baseline-shift and improved leaders and image handling, improved border painting etc. Please check out the compliance page to view the differences between 0.20.5 and 0.90 alpha 1: http://xmlgraphics.apache.org/fop/compliance.html IMPORTANT! This release is the first after a big redesign effort on the whole FOP codebase. This release is to be considered ALPHA quality and it is intended as a preview release encouraging people to take a look at the new version and to provide feedback to the developers. Please not only report to us problems you might experience but also tell us if it works for you. If you find out that this version works fine for you, you're welcome to use it but please test it thoroughly as we don't consider this release ready for every production environment. Please read the following page for more detailed information: http://xmlgraphics.apache.org/fop/0.90/upgrading.html Download: http://www.apache.org/dyn/closer.cgi/xml/fop Source and binary distributions are available. Two binary distributions exist, one for JDK 1.3.x and one for JDK 1.4 and later. Release Notes: http://xmlgraphics.apache.org/fop/relnotes.html#FOP+0.90+alpha+1 Documentation: http://xmlgraphics.apache.org/fop/0.90/ Important information if you upgrade from version 0.20.5: http://xmlgraphics.apache.org/fop/0.90/upgrading.html Compliance documentation which allows you to compare 0.20.5 and 0.90.x: http://xmlgraphics.apache.org/fop/compliance.html General Information about Apache FOP: http://xmlgraphics.apache.org/fop/ Enjoy, Jeremias Maerki for the Apache FOP team pgplR8coRDqpG.pgp Description: PGP signature
