Apache Account Request: New FOP committer
Finn Bock has been voted in as new FOP committer. Please create a new account for him. +1: 6 +0: 0 -1: 0 Vote: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&by=thread&from=563513 Full name: Finn Bock Preferred account name: bckfnn eMail-address: [EMAIL PROTECTED] Karma: xml-fop, xml-site The CLA should arrive by snail mail shortly. Thanks! Jeremias Maerki
Re: Draft discussion of Federation proposal
(I'm CCing batik-dev and fop-dev once to invite everyone to discuss this on [EMAIL PROTECTED] Please repond on general only and do not cross-post unneccessarily.) Concerning the proposed TLPs I'm wondering if FOP and Batik shouldn't go together somehow. Both projects deal with XML to graphics conversions. FOP currently has 2 Batik Transcoder implementations (additional output formats for Batik: PDF, PS/EPS). So there is some kind of overlap which needs to be dealt with sooner or later. One possibility is to move the transcoders over to Batik but parts of them are FOP-specific so both projects should somehow be able to work on the common code. Moving these out of FOP still means a dependency on FOP's PDF, PostScript and font support code. These might need to be separated into "Commons" projects to be accessible to both projects and to ensure compatibility and cooperation. Sorry if this is a bit technical and not entirely on-topic but I thought this may have to be addressed in this discussion. To be fully on-topic again: When the XML project becomes a federation of projects it may make sense to create pointers to other rather XML-oriented projects which live in the Jakarta area (like Jakarta ECS, Jakarta Commons Betwixt, Digester, Jelly, JXPath, there may be others). As for the question about preference for XML Commons. I'd like to see Apache Commons become more live. In this aspect XML Commons should IMO go over to Apache Commons. On the other side, it may well be that Apache Commons will, to a great extent, also be a federation project. And moving too many project over there will create an oversight problem there in time. I guess the decision here depends on the development of Apache Commons and the projects intentions. So in the end I'm unsure what to prefer. In general, I currently don't see any showstoppers in Berin's proposal. On 04.01.2004 12:23:55 Berin Lautenbach wrote: > Have put together a very rough draft of how a federation of projects > around XML might be created. > > Caveat - it really is very draft, and purely there as a discussion > starter. Feel free to either post comments/thoughts back to the list or > to edit the document directly. (Note that this document does not yet > discuss next steps, such as agreements from each sub-project etc.) > > All comments very welcome. The board requested a proposal by the Jan > board meeting (normally around the 20th of the month), so it would be > good to move the discussion forward - whether around this or another > proposal. > > http://nagoya.apache.org/wiki/apachewiki.cgi?XMLProjectPages/FederationProposal Jeremias Maerki
Re: Using Just the Font Metrics Stuff From FOP
The OpenType reader code is in TTFReader. OpenType is an evolution of TrueType. Maybe you could try to use the TTFReader from 0.20.5. The HEAD TTFReader should be at least equal in functionality but I can't be sure we got all fixes for 0.20.5 into HEAD already. Good luck! On 07.01.2004 02:12:38 Eliot Kimber wrote: > I tried the TTFReader on my OpenType font and it died in ReadGlyf() :-( > > I see in a message from Victor Mote from July of 2003 that he had an > OpenType reader working but not committed. Is the OpenType reader code > available or has the OpenType support been pushed to somewhere else? Jeremias Maerki
Re: Non-AWT-based FontMetrics
I'm afraid you got it wrong. Talking about HEAD now: The AWT renderer in HEAD is non-functional ATM. What you need to look at is SingleByteFont (ex. Type 1) and MultiByteFont (ex. TTF) in the org.apache.fop.fonts package. Both classes implement the FontMetrics interface which lets you access glyph widths. FontReader is the class that loads the XML font metrics. The PostScript renderer is not using AWT font metrics. It uses the metrics coming from the Single/MultiByteFonts as does the PDF renderer. I hope this helps. On 08.01.2004 22:13:56 Eliot Kimber wrote: > I was, for some reason, under the impression that there was a > java.awt.FontMetrics implementation that did not delegate to the > built-in Graphics2D AWT font metrics. But now I can't find anything > except the org.apache.fop.render.awt.AWTFontMetrics class. > > I see that the PostScript renderer is using the AWT font metrics. So > does this mean that there is no FontMetrics implementation that uses the > XML font metrics files? Jeremias Maerki
Remember to update the copyright year
Fellow committers We've got a new year. Please remember to update the copyright year on every file you change. Jeremias Maerki
Chris and Andreas: New committers, send your CLAs
Enough time has passed since I cast the three votes for new committers. I'm a bit disappointed that Clay's vote didn't pass but I guess we need to give it some time. Chris passed with 6 +1s, Andreas with 5. No -1s anymore. So, Chris and Andreas, we need your preferred unix usernames and the email address you would like to have @apache.org forwarded to. At least as important is to immedidately sign the Contributors License agreement (CLA) and send (or fax) it to the Apache Software Foundation as fast as possible. I'd send it in paper, even if it takes longer there's a higher chance of immediate success. You only get the account if the CLA has been received. Find the CLA here: http://www.apache.org/licenses#clas As a new committer there are a few things to learn: http://incubator.apache.org/learn/newcommitters.html http://incubator.apache.org/learn/ Jeremias Maerki
Re: multi page-sequence don't work for (XML+XSL) to PDF on the fly
On 09.01.2004 18:29:14 Clóvis Wichoski wrote: > > > disable-output-escaping="yes"> > > > > The problem is that you put some XML code into a CDATA section. On-the-fly processing works with SAX. And in SAX your code will be delivered as text instead of as elements. > I can't understand because on the fly don't woks and from .fo file > generated from xml+xsl transformation work, maybe a bug of FOP, or I > can't generate XML elements using CDATA from this form. The latter. > I post this in dev list because I think that this is a feature or a bug > on FOP then I attached the XSL and XML files that the team can test this > issue, and the code is better to read than my bad English ;) Well, bad luck. Your issue would have been a better fit for fop-user. Jeremias Maerki
Re: Remember to update the copyright year
Yep, to my knowledge only changed files have to be updated. Each source file, in principle, contains its own license, so the year must be updated individually. The downside of this is that we can't use Checkstyle to enforce that. Otherwise, we could have adjusted the checkstyle.header file using regular expressions. On 10.01.2004 03:58:12 Peter B. West wrote: > Andreas L. Delmelle wrote: > > > > If nobody objects, this seems like an ideal pesky task for a freshman... > > > > I mean: would it help if I (or Chris, or Clay ;P ) just checked out all of > > HEAD (to begin with), run a S & R script on all the java and generator > > sources to update the year and enter it as a patch in Bugzilla or something? > > Unless the intention is to only update files that are actually changed. In > > that case I haven't posted anything. > > I'm not sure about this, but I would have thought we only change the > notice in files that are modified. Jeremias Maerki
Apache Account Request: New FOP committer (Chris Bowditch)
Chris Bowditch has been voted in as new FOP committer. Please create a new account for him. +1: 6 +0: 0 -1: 0 Vote: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&by=thread&from=572506 Full name: Chris Bowditch Preferred account name: cbowditch eMail-address: [EMAIL PROTECTED] Karma: xml-fop, xml-site The CLA should be on its way. Thanks! Jeremias Maerki
Apache Account Request: New FOP committer (Andreas L. Delmelle)
Andreas L. Delmelle has been voted in as new FOP committer. Please create a new account for him. +1: 5 +0: 0 -1: 0 (Note: There was a -1 that was later changed to a +1 with no -1s remaining.) Vote: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&by=thread&from=572508 Full name: Andreas L. Delmelle Preferred account name: adelmelle (as "andreas" seems to be taken already) eMail-address: [EMAIL PROTECTED] Karma: xml-fop, xml-site The CLA should be on its way. Thanks! Jeremias Maerki
Re: Chris and Andreas: New committers, send your CLAs
Account requests sent. The accounts will be activated as soon as the CLAs arrive. "andreas" seems to be taken as username so I took the second choice (http://www.apache.org/~jim/committers.html). Finn, Chris and Andreas, welcome aboard! I'm glad to see FOP getting some speed again. Jeremias Maerki
Intersting link for i18n freaks
There was an inquiry by Xerces-J people on the XML PMC yesterday asking for the compatibility of IBM's ICU package with the ASF license. It looks like this package could be interesting for our project, too: http://oss.software.ibm.com/icu/ Jeremias Maerki
Re: DO NOT REPLY [Bug 25873] - [PATCH] abandoning code-generated Property.Maker
Code-completion works for me today as I simply run "ant codegen" and include the build/gensrc directory in the list of source directories in my IDE. That was one of the reasons why I changed the build to generate the gensrc directory and why I moved the sources from src to src/java for HEAD: To make it easier to build FOP within an IDE without the need for running the Ant build every time, thus improving build speed a lot. I'm indifferent whether you go forward with this or not. I personally think it's unnecessary. On 17.01.2004 02:05:05 Glen on bugzilla wrote: > I'd like to have them retained, but put into (1) file, actually, just added to > the Constants interface (as inner interfaces), say adding about 600 lines in > that interface for them all. (I can modify the XSLT code to accomplish that.) > We get rid of those 45 files, and they will be no longer autogenerated with > each build (but, as with the current Constants.java, we retain the XSLT to re- > generate it when we like.) > > Reason why? I *think*, over the long-term, it is much more programmer-friendly > because many/most developers use IDE's with code-complete. I.E., you type in > the property value interface name, hit the ".", and then you automatically see > the 5-7 values relevant for that property. This saves the programmer the > headache of looking at the spec each time for which prop values you need to > code against, or trying to recall from a huge Constants list the actual values > you need, and also making sure all the property options have been coded > against. I think it will be a nice sanity-saver for coders. If not, we can > always excise them later from Constants.java. > > Thoughts on this? Jeremias Maerki
Re: DO NOT REPLY [Bug 25873] - [PATCH] abandoning code-generated Property.Maker
From that perspective, yes, of course. On 17.01.2004 14:55:03 Andreas L. Delmelle wrote: > > -Original Message- > > From: Jeremias Maerki [mailto:[EMAIL PROTECTED] > > > > > > > > > I'm indifferent whether you go forward with this or not. I personally > > think it's unnecessary. > > > > Unnecessary, yes, for those who are familiar enough with the code. I think > however, this proposal would make the sources as a whole a bit easier to > understand for interested developers who want to aid in writing > patches/bugfixes. Perhaps this is more of a key-argument in this case than > mere coding-convenience? Jeremias Maerki
Re: Servlet Examples in HEAD v.s. 0.20.5
Discussion on this can be found here: http://marc.theaimsgroup.com/?t=10383153256&r=1&w=2 http://marc.theaimsgroup.com/?t=10172302692&r=1&w=2 There were pros and cons about the move from examples into the main source tree. I think the triggering point was that the servlet sees real use and doesn't really qualify as an "example". I agree that with today's build it may not be so obvious what is necessary to build the WAR file (the various parts are distributed in the source tree). But the WAR file gets built automatically today. Proposal: I like your ideas. I also think that we have to preserve the simplicity of the servlet as an educational example for people who want to play with it. So what about resurrecting the examples/servlet but keeping it real simple? Just the basics. And the servlet in the main source tree stays where it is but gets your new features. German speaking Swiss people would say you get "de Föifer und's Weggli" (freely translated to english: the 5 cent piece and the donut. Meaning: You get twice as happy. Want to know what a "Weggli" is? Go to http://www.jowa.ch/1776/1846/1847/1865/1867.asp). :-) On 17.01.2004 21:52:06 John Austin wrote: Jeremias Maerki
Re: Newbie committer questions.
Great! Glen will very, very, very glad... :-) On 20.01.2004 13:13:04 Finn Bock wrote: > I've received my account information and everything appears to work > fine. In the guides for setting up CVS there are several ways to set up > tunneling > > http://jakarta.apache.org/site/cvsonwin32.html > > but instead I used the :ext: protocol and set CVS_RSH=ssh with cygwin, > just like I do for sourceforge. Would I get any benefit from using ssh > tunneling? You don't have to establish the SSH connection everytime you do a CVS operation. It's speedier. > When I committed my first modification I got the CVS/Template file > shown, but from browsing around a bit in the archives of commit mails, I > couldn't find an example of anyone using that Template. What is the > policy on this? Usually, you should use the "Submitted by:" prefix when you apply a patch form a developer. > I also guess that we are not yet updating any CHANGES files with the > modification we make? I usually do, but use the XML one. I'd appreciate if everyone did. Not necessarily every little change but the important ones. Jeremias Maerki
Re: cvs commit: xml-fop/src/documentation/content/xdocs team.xml
I agree. Over at Jakarta (especially Commons) this discussion was renewed lately. Bottomline is that it's better (and safer for the ASF) to remove author tags from the sources and credit contributors in changes files, CVS messages and on websites. All source files should probably have one author tag pointing to the developer mailing list of the respective project. Please see: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&by=thread&from=572799 That said I'm in favor for: - removing all author tags (and other such markings) in the source files - adding a "FOP Dev Team" author tag to every source file. - adding each name that is removed somewhere to a list of contributors (hopefully and if possible with a short note about the area of their contribution). - adding contributor names on demand (for those who only have their names in CVS messages) On 20.01.2004 18:37:51 J.Pietschmann wrote: > [EMAIL PROTECTED] wrote: > > removed "former contributor" > > section in favor of going back to giving credit within source files. > > Uh, oh. That's not supposed to be a change anybody can make > on a whim. Jeremias Maerki
Re: Getting rid of JIMI
The ASF does see a problem. Until the FSF has clarified the relationship between "linking" and Java's import concept the ASF's policy is not to allow usage of LGPL packages. There are certain exceptions. For example, if you have a JAI-compatible image codec under the LPGL you could use it because FOP would directly link only with the JAI API, not with the codec that's made available through JAI. See also: http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing I think it's no problem if you modify your copy of FOP to use one of the LGPL packages. The ASF simply cannot publish code that uses these packages at the moment. A possible work-around is to establish a better plug-in concept for our image lib adapters in HEAD (not 0.20.5) so interested parties can create plug-ins outside of the ASF to use LGPL libraries. On 23.01.2004 00:19:28 Dalibor Topic wrote: > While I understand that GPL2 and ASL 1.1 are not compatible, I don't see > a problem with LGPL 2.1 and ASL 1.1. Could you elaborate? Jeremias Maerki
Re: @author tags in source files (Was re:cvs commit....)
On 21.01.2004 15:34:15 Glen Mazza wrote: > --- "Peter B. West" <[EMAIL PROTECTED]> wrote: > > It seems to me that a major motivation for writing > > OSS is precisely the > > recognition. When alt-design is completed, I will > > probably have written > > the bulk of it, as well as designing it, and I have > > no intention of > > removing my @author tags. Why should they be > > removed in favour of a > > mailing-list address? > > > > Of course they shouldn't. Clearly, my English is worse than I thought. I thought I said that credits, after removeing them from the code, go on our website along with a description what a contributor has done for the project. A concentrated hall of fame will allow much better visibility of the contributions to the project. If you leave author tags in the code you have to explicitly search for them or by chance stumble upon them. I have absolutely no intention to lessen anyone's contribution to this project. On the contrary, with my proposal I intended improve the visibility of any contribution. There's another point. Within the ASF a group of people is legally concerned about the attributions in code as they could be exploited by lawyers. It's an unlikely event but the cencerns are there. The ASF simply wants to protect every contributor from lawsuits. Sometimes that means that certain habits need to be avoided. > In my work, I always try to > recognize those people taking FOP to the > dance--something, IMHO, that Jeremias needs to be > better focused on-- Please explain what I've done wrong. I know I forgot to add the "Submitted By" comment in a CVS commit message once or twice but I always added that comment into the changes files. > and put them on a pedestal, making > sure that they're being properly honored. You are > certainly one of them and your credits should not be > removed. > > I also disagree on having the team page be watered > down to that of a phone book where anyone "on demand" > gets listed on it. By "on demand" I don't mean that anyone simply can request to be put there. I simply try to include the case where we forget someone. Please don't interpret any bad intents into my proposal. Jeremias Maerki
Re: Getting rid of JIMI
No apologies required! Image IO (javax.imageio) support is not there, yet, I'm afraid. But if you created an implementation for Image IO then your idea would work. Shouldn't be very hard. Check the org.apache.fop.image package. You wouldn't need to use JIMI. Think of JIMI, JAI and ImageIO as equals. They all provide an API to access bitmap images. On 23.01.2004 16:08:55 Dalibor Topic wrote: > > A possible work-around is to establish a better plug-in concept for our > > image lib adapters in HEAD (not 0.20.5) so interested parties can create > > plug-ins outside of the ASF to use LGPL libraries. > > I'm not very well aware of the differences between all the different > image io APIs, so please excuse me if my next question is a typical > newbie question. If, for example, we had javax.imageio support working > for PNG images in GNU Classpath (and Kaffe), would/could FOP > automatically use that, or would it still need to use JIMI? > > The reasoning behind this being that PNG image support seems to be part > of JDK 1.4 anyway, so it will be implemented in free runtimes eventually > as well. Jeremias Maerki
Re: Getting Rid of Jimi
Damn, you're right. I wonder why we haven't made use of this, yet. BTW, is this code from JAI (like the classes Oleg Tkachenko uses in his TIFF renderer) or is this separately developed code (ASF origin)? You know that there's a number of people who would actually be interested in creating/having a BSD-style image (codec) library? I think that should be one of the packages that should be separated out, when FOP and Batik get closer together. On 24.01.2004 12:21:48 Thomas DeWeese wrote: > It is certainly true that javax.imageio is the direction > to go in the future. > > However, It is probably worth pointing out that you already > include a PNG encoder/decoder with the FOP distribution, > from Batik! > > org.apache.batik.ext.awt.image.codec.PNGImageEncoder > org.apache.batik.ext.awt.image.codec.PNGImageDecoder > > > Let me know if you want/need more info (including pointers > to where FOP does the image loading would be helpful as well). Jeremias Maerki
Changing policy on minimum JDK requirements for HEAD
There was a thread recently which brought up that FOP HEAD currently doesn't compile under JDK 1.3. IMO this is an important point and a change of policy needs a community decision (vote) and a susequent documentation update. Since we should respect our customers a new opinion poll before the vote would be appropriate. Does anyone know of a good and up-to-date list of platforms and the JDK versions they support? I haven't found one. Sun's isn't ready, yet: http://java.sun.com/j2se/1.4.2/ports.html Jeremias Maerki
Re: Getting rid of JIMI
On 25.01.2004 12:46:08 Thomas DeWeese wrote: > Jeremias Maerki <[EMAIL PROTECTED]> wrote: > > > Damn, you're right. I wonder why we haven't made use of this, yet. BTW, > > is this code from JAI (like the classes Oleg Tkachenko uses in his TIFF > > renderer) or is this separately developed code (ASF origin)? > > This was contributed by Sun and is I believe the code came > from JAI (great group of guys). There have been some bug > fixes/improvements since then but it is basically that code. > > > You know that there's a number of people who would actually be > > interested in creating/having a BSD-style image (codec) library? > >Sure, but given imageio does it make sense to put a lot of > effort into an independent codec library? If I were going to > create a codec library I would create one that plugged into > image-io. I agree that the codec library should plug into ImageIO, but this API is only available since JDK 1.4. I'm sure that if there's enough interest in supporting the image library under pre-1.4 JDKs there will be contributions to make that happen. No need to lose too much time if it's not needed at first. > > I think that should be one of the packages that should be separated > > out, when FOP and Batik get closer together. > > This probably makes sense. I will probably have some time next month to write a proposal on how our two projects can move closer together to make the code sharing happen. Jeremias Maerki
Re: Getting rid of JIMI
Noted. I will make it a point in the proposal so the Batik people will be able to comment and we can develop mechnisms to ensure quality. On 25.01.2004 18:42:20 Glen Mazza wrote: > The current (lowered) committer standards on the FOP > team definitely needs to be explained to the Batik > team before we get write access to their > project--something I'm still far from recommending. > Jeremias, being perhaps the leading proponent of the > new committer standards, is probably in the best > position to explain this to Thomas--I still don't > understand it myself. Jeremias Maerki
Re: cvs commit: xml-fop/src/java/org/apache/fop/datastructs Tree.java
Peter, I think it's a bit premature to apply the 2.0 licence already. The board has announced additional information on how the licence should be applied. This is not a veto, I just want to avoid you having to do the whole thing twice. Another thing: Please pay attention to the copyright years. You have to take them over from the old licence. On 27.01.2004 00:07:11 pbwest wrote: > pbwest 2004/01/26 15:07:11 > > Modified:src/java/org/apache/fop/datastructs Tag: > FOP_0-20-0_Alt-Design Tree.java > Log: > Removed references to modCount, used for > ConcurrentModificationException detection. Removed > references to the setting of the containing Tree instance in > Nodes. > Updated license to 2.0. > > Revision ChangesPath > No revision > No revision > 1.1.2.2 +16 -106 xml-fop/src/java/org/apache/fop/datastructs/Attic/Tree.java > > Index: Tree.java > === > RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/datastructs/Attic/Tree.java,v > retrieving revision 1.1.2.1 > retrieving revision 1.1.2.2 > diff -u -r1.1.2.1 -r1.1.2.2 > --- Tree.java 5 Jul 2003 19:06:35 - 1.1.2.1 > +++ Tree.java 26 Jan 2004 23:07:11 - 1.1.2.2 > @@ -1,55 +1,19 @@ >/* > + Copyright 2004 The Apache Software Foundation. > + > + Licensed under the Apache License, Version 2.0 (the "License"); > + you may not use this file except in compliance with the License. > + You may obtain a copy of the License at > + > + http://www.apache.org/licenses/LICENSE-2.0 > + > + Unless required by applicable law or agreed to in writing, software > + distributed under the License is distributed on an "AS IS" BASIS, > + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. > + See the License for the specific language governing permissions and > + limitations under the License. > + > * $Id$ > - * > - * > - * > - * The Apache Software License, Version 1.1 > - * ==== > - * > - * Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved. > - * Jeremias Maerki
Re: Updating licenses
Very cool! I did the whole thing manually back when I exchanged the
"illegal" short licence with the long one.
But I noticed the following:
http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-fop/src/java/org/apache/fop/area/inline/InlineArea.java?rev=1.2.2.1
It looks like the {YEARS} marker seems not to have worked on some files
you checked in yesterday.
On 30.01.2004 00:00:46 Peter B. West wrote:
> Fops,
>
> I have committed the perl script bin/lic_to_2 in FOP_0-20-0_Alt-Design.
> It's function is to substitute license 2.0 for 1.1.
>
> It is called as
>
> $ lic_to_2 --lic2 {file containing license 2.0 text} {file to modify}
>
> The intended usage is something like:
>
> $ find . -name '*java'|while read file;\
> mv $file $file.orig;\
> do lic_to_2 --lic2 {lic2 file} $file.orig > $file;\
> done
>
> I have already committed java and plain text versions of 2.0 to the root
> directory of FOP_0-20-0_Alt-Design. Note that these license files
> contain a {YEARS} marker which is replaced from the actual years in the
> source file copyright notice when the script is run.
>
> When we get the OK, I'll use this to update the licenses in alt-design,
> and, if that works, I can also do the maint and HEAD sources.
Jeremias Maerki
Re: ExampleXML2PDF.java not working
Yes, it's probably got something to do with the getContentHandler(). I can look at it this evening (about 12 hours from now, 20:00 MET). If you find the problem first, even better. Here's the thread (I think) where I brought up the problem: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&by=thread&from=527287 On 02.02.2004 23:12:56 Glen Mazza wrote: > I cannot get the ExampleXML2PDF.java example[1] to > work with CVS HEAD. Jeremias, I believe you were > going to fix something in the Driver class--something > wrong with driver.getContentHandler(), correct? Is > that where the problem is? I can look at it if you > don't have the time right now. > > Thanks, > Glen > > [1] > http://cvs.apache.org/viewcvs.cgi/xml-fop/examples/embedding/java/embedding/ExampleXML2PDF.java?rev=1.3&view=auto Jeremias Maerki
Re: ExampleXML2PDF.java not working
Fixed it...sort of. I've done what I've announced in the thread below. I'm not sure, however, if it will work in every situation as there is still an obscure little code section in render(). Anyway, ExampleXML2PDF produces valid PDF output again. On 03.02.2004 07:40:11 Jeremias Maerki wrote: > Yes, it's probably got something to do with the getContentHandler(). I > can look at it this evening (about 12 hours from now, 20:00 MET). If you > find the problem first, even better. > > Here's the thread (I think) where I brought up the problem: > http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&by=thread&from=527287 > > On 02.02.2004 23:12:56 Glen Mazza wrote: > > I cannot get the ExampleXML2PDF.java example[1] to > > work with CVS HEAD. Jeremias, I believe you were > > going to fix something in the Driver class--something > > wrong with driver.getContentHandler(), correct? Is > > that where the problem is? I can look at it if you > > don't have the time right now. > > > > Thanks, > > Glen > > > > [1] > > http://cvs.apache.org/viewcvs.cgi/xml-fop/examples/embedding/java/embedding/ExampleXML2PDF.java?rev=1.3&view=auto Jeremias Maerki
Re: Adding PPD support when rendering PS
On 04.02.2004 16:22:03 Alex wrote: > I've been looking at this for a couple of days, and figured I'd do best > to post and see what other folks think about this. Good idea. :-) > I have to implement PPD when generating PS for the project (FOP embedded > app) that I'm working on - I need to be able to force printer tray > selection/stapling etc. > > As such, I have "butchered" the version of FOP (0.20.5) that were using > in development here and have managed to get a rough and ready version of > what we need. If anyone is interested or has had a play with area, > please feel free to drop me a line. Being the PS renderer's original author I still have PPD support on my list as a long-term goal. When I was still actively using FOP at work I took another approach however: I've patched the generated PostScript files using home-written Java classes. I also had to add things like OMR marks or embedded fonts so doing the tray selection in the same way was easy. Although I'm not really active in the development right now, I'm certainly keeping an eye on this issue. > I'd be really interested if the group as a whole had any thoughts/ideas > which I could look at implementing and/or contributing back to the > project (if you'll take 'em of course!). Contributions are always welcome. Just keep in mind that patches for FOP 0.20.5 (or the maintenance branch) will have a very high probability of not making it into our codebase since that branch is frozen. We're concentrating on the new codebase (HEAD, redesign). It shouldn't be a big problem to avoid writing all of the code twice if you need PPD support for 0.20.5 (as the 1.0 release is still a few months in the future). It's important to have a good separate PPD parser and then all you need is to include the right sequences in the right places. Well, the latter won't be so easy in the end since you have to have some kind of communication from the XSL-FO file (using custom tags or attributes) to the renderer to map page masters to a tray etc. There's probably an easier way if you provide the mapping information directly to the renderer in Java code but in the long term I believe the mapping should be done in XSL-FO. Anyway, as a long-term investment it would be cool if you wrote the code for the HEAD in parallel with the one for 0.20.5. I'll assist you with (hopefully) good advice and maybe more, as time permits. Jeremias Maerki
Re: [GUMP@lsd]: xml-fop/xml-fop failed
Finally, Gump nags again and Batik builds again under Gump... We've changed a few things lately in Commons IO. Also, an initial release of Commons IO can be expected shortly. I'll do the necessary changes in a few hours and update the IO lib. On 06.02.2004 07:33:51 Sam Ruby wrote: > [javac] > /data/gump/xml-fop/src/java/org/apache/fop/render/rtf/rtflib/rtfdoc/RtfExternalGraphic.java:61: > cannot resolve symbol > [javac] symbol : class IOUtil > [javac] location: package io > [javac] import org.apache.commons.io.IOUtil; Jeremias Maerki
Re: apologies to Nikolai Grigoriev? (was: Just a small question...)
I agree. 100%. Thanks, Bertrand, for speaking my mind. On 06.02.2004 08:26:58 Bertrand Delacretaz wrote: > executive summary: ARE YOU GUYS CRAZY? > > Le Jeudi, 5 fév 2004, à 21:28 Europe/Zurich, Nikolai Grigoriev a écrit : > > > I realize I was wrong when I answered to this forum - I could not > > expect my words to be interpreted this way. Please disregard my > > previous message; I also unsubscribe from the list, to make you feel > > sure I don't induce anyone into wrongdoing. ... > > I'm pissed (not my usual language but cannot find a better word) at the > discussion which caused this to happen. > > People, look at the archives: Nikolai has been kind enough to give > input and share his thoughts here several times, even if it meant > disclosing some information about RenderX at times. Thanks Nikolai. > > Now he's being accused of trying to inject proprietary information into > FOP - this is plain surrealistic. I though RESPECT was a given on these > lists but apparently it is not for everybody. > > In my opinion public apologies are due to Nikolai. Whether he chooses > to stay or go is his choice, but letting him go without a word would be > another lack of respect. > > Nothing personal against anyone - everyone does mistakes at times, the > question is whether you try to fix them (or rather, fix what's left) > and learn from them. > > I tried to refrain from mixing in this as I'm not contributing to FOP > currently, but this is too much. I still care for this project and hate > to see such things happen. > > -Bertrand Jeremias Maerki
Applying the ALv2 (Apache License 2.0)
For those who haven't seen it already: There's new information for applying the new license: http://www.apache.org/dev/apply-license.html Jeremias Maerki
Re: [GUMP@lsd]: xml-fop/xml-fop failed
Changes done. Gump should happily build FOP HEAD again next time. Jeremias Maerki
PMC representation change, still ot ack'ed
I've just noticed that Joerg still hasn't been formally voted in in the XML PMC as a replacement for Peter. Since this was more than 2 months ago I wanted to check if this is still ok. I'll start the vote in the XML PMC on Wednesday if there are no objections until then. Jeremias Maerki
Re: FOP components (and JDK 1.4 requirement)
I'm pleasantly surprised by your proposal. Wasn't it you who wanted the servlet in the main source tree a year ago? On 08.02.2004 00:38:35 J.Pietschmann wrote: > There ought to be a less messy approach. It could be an idea > to move the various packages to different base directories, > making FOP essentially a multi-subproject project similar > to jakarta commons. This way each subpackage has its own > buildfile and lib directory, and dependencies become more > clear. In order to manage the cross package dependencies and > dependencies outside of FOP, Maven seems to be the tool of > choice. Unfortunately, I'm not enough of a Maven wizard to > asses this completely. Is there somebody out there with more > time at hand to look at these issues? > > BTW > 1. I'd like to get rid of the servlet.jar in our CVS. > 2. If we standardize on JDK 1.4 as base (as it currently > is), we could drop the Xerces, Xalan and xml-api jars as > well. Our Jars seem to be somewhat outdated anyway. "If we standardize..." triggers something inside me: I'd like to put on record that I request a vote (by someone who really cares) on the issue of making JDK 1.4 a minimal requirement for FOP. I still don't buy it. For the AWT renderer, any time, but not for the rest. I won't block either, but I want this done properly. I may request that certain parts of FOP (base libraries like PDF and fonts for example) remain compatible with JDK 1.3. Especially the Batik transcoders for PDF and PostScript should remain JDK 1.3 compatible as Batik still has JDK 1.3 (AFAIK) and the transcoders and supporting code should move to a common subproject in the future "XML Graphics" (or whatever) PMC. If the Batik team changes the minimum requirements this could, of course, look different, but that's how it looks today. BTW, Cocoon, an important FOP customer, is also still on JDK 1.3. It me be good prior to taking a decision to ask these two projects about their plans in the regard. Sorry to be a pain. :-) http://xml.apache.org/batik/install.html http://cocoon.apache.org/2.1/installing/requirements.html Jeremias Maerki
Re: FOP components
On 08.02.2004 01:34:16 Glen Mazza wrote: > --- "J.Pietschmann" <[EMAIL PROTECTED]> wrote: > > - avalon and logging for the base library. > > > > The avalon jar is indeed quite small (only 25K or so), > but this dependency I'd like us to eventually get rid > of in favor of what Xalan does with its messaging and > i18n instead. (I suspect AH or RX don't bother with > loggers, they're probably more like Xalan as well.) I don't think logging is the same as providing user-friendly and localized error messages. I'd agree that Xalan's approach is good and we could or even should adopt it but IMO it doesn't replace logging which is primarily for debugging purposes (be it for Java developers or stylesheet producers). It is debatable whether the Avalon Framework's logging approach is the best. I don't think so. There are situations where I should have use Commons Logging instead of Avalon Logging (PDF library for example). Both have their uses. I'll gladly outline if desired. > Xalan appears to route all messages through an > XMLMessages.java [1] (with a couple of subclasses for > XPath and XSLT-specific messages) with the result > going to stdout by default. (I don't know what > happens in embedded usage, whether those messages can > be re-routed to a logger of the user's choosing.) > Also, they use message constant enums so they can get > the messages to appear in multiple languages. [2] The problem I have with Xalan is that they do no logging. Sometimes it would be good to get some feedback on what is going on inside. At the time where I had to do some intensive error searches inside Xalan I encountered a lot of System.outs that where commented out (I don't know if this has changed in the meantime, though). Indicates that they should have used a logging package. And when you have a software live at a customer site you will love the chance to change the debug level to see what's going on inside when you're in trouble. Jeremias Maerki
Re: FOP components
The Preferences API is exactly that: for preferences. IMO this is best for client application (GUIs) that need to save and reload preferences for the application. That's the reason for the distinction between system root and user root [1]. This is cool for our preview application and the "FOP utility" that I promised long ago and never delivered. But for configuring FOP (the engine) I consider the preferences API rather unsuitable. We also need to make sure that FOP can easily be configured from within Cocoon which could be difficult with the Preferences API. [1] http://java.sun.com/j2se/1.4.2/docs/api/java/util/prefs/PreferencesFactory.html On 08.02.2004 04:57:35 Peter B. West wrote: > possibly also the preferences API (java.util.prefs) for > configuration/user agent/user prefs? Jeremias Maerki
Re: FOP components
...and I should probably help since I was the main pusher here. BTW, I've started a little something for testing the SVG transcoder using GhostScript as converter to bitmaps. I've created little Avalon components that can nicely be configured by XML. I hope I can soon upload that for you to see. Another cool place to see Avalon power at work is the Cocoon codebase. On 08.02.2004 12:37:53 J.Pietschmann wrote: > I should probably move a bit faster in order to provide some > working sample code so everybody can see how this could look > like for FOP. Jeremias Maerki
Re: FOP components
It has multiple pluggable datasources (Property files, XML, JNDI) See http://jakarta.apache.org/commons/configuration/ On 09.02.2004 01:06:08 J.Pietschmann wrote: > There's also jakarta commons configuration, which uses property > files (IIRC, may well be wrong). Jeremias Maerki
Re: FOP components
No, the question is: How long will it take for the 1.5 platform to establish itself? 1.4 took quite a long time, less than 1.3 but still... You will have 1.5 on Windows, Solaris and Linux immediately but all the other platforms are not so quick, even MacOSX which was promoted as the "best Java platform". :-) On 09.02.2004 16:11:05 Andreas L. Delmelle wrote: > Besides that, question remains: how many users currently using 1.4 expect to > upgrade to 1.5 as soon as it arrives? Jeremias Maerki
Re: JUnit test failure
I got another one. Probably a Xerces version problem. No good idea for both problems, I'm afraid. org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or change an object in a way which is incorrect with regard to namespaces. at org.apache.xerces.dom.CoreDocumentImpl.checkDOMNSErr(Unknown Source) at org.apache.xerces.dom.AttrNSImpl.setName(Unknown Source) at org.apache.xerces.dom.AttrNSImpl.(Unknown Source) at org.apache.xerces.dom.CoreDocumentImpl.createAttributeNS(Unknown Source) at org.apache.xerces.dom.ElementImpl.setAttributeNS(Unknown Source) at org.apache.xml.utils.DOMBuilder.startElement(DOMBuilder.java:339) at org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1073) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) On 07.02.2004 23:56:40 J.Pietschmann wrote: > Hi all, > I get a nice Junit failure: > Testcase: testFO2PDFWithDOM took 0.23 sec > Caused an ERROR > loader constraints violated when linking org/w3c/dom/Node class > java.lang.LinkageError: loader constraints violated when linking > org/w3c/dom/Node class > at org.apache.xalan.transformer.TransformerIdentityImpl. >createResultContentHandler(TransformerIdentityImpl.java:186) > at org.apache.xalan.transformer.TransformerIdentityImpl. >transform(TransformerIdentityImpl.java:296) > at org.apache.fop.BasicDriverTestCase. >loadDocument(BasicDriverTestCase.java:133) > at org.apache.fop.BasicDriverTestCase. >testFO2PDFWithDOM(BasicDriverTestCase.java:149) > > This seems to have something to do mixing Jars form the JDK and > fop/lib. Does anybody have an idea how this can be avoided? Jeremias Maerki
PMC representation
While we're at it: I think it's about one year since I got voted into the XML PMC. According to the following section of the XML project's mission statement: > 5.4 Every 12 months, (or as required by the Board or PMC) each subproject > of xml.apache.org will nominate 1-2 individuals to represent them on the > PMC. To become a sub-project's representative on the PMC, an individual > must be nominated by a contributor, unanimously approved by all PMC > members, and approved by a two-thirds majority of the sub-project's > active committers. In most cases, developers will have actively > contributed to development for at least six months before being > considered for membership on the PMC. ...it may be time to replace me as well. I have nothing against staying in this role for now (on the contrary) but I'd like to make the post available to Glen, if he desires it. I guess he's the only candidate matching the above criteria right now. Jeremias Maerki
Re: FOP report
On 11.02.2004 22:50:11 Peter B. West wrote: > > Some background: Fact is that the whole FOP team was exchanged during > > the last two years. > > Almost. I've been involved since the beginning of 2001, and a committer > for a little over two years now, I think. Joerg, Jeremias and I became > committers at the same time, so we had varying degrees of prior involvement. You're right, of course. > > None of the old committers is still active though > > one or two are still injecting a comment from time to time. We have a > > heavy decision to carry on taken over two years ago (freezing the old > > maintenance branch and doing a redesign of FOP). I guess the committers > > are only now really getting used to all the code in FOP and getting into > > a position to really bring on the design. > > Amen. > > > Then we've got the problem > > that there are some "strong personalities" among the comitters which > > doesn't make things easier. Take the mailing list as suboptimal > > communication platform into the equation and you got the problems > > together. I myself was pretty close to quitting recently but decided to > > calm down and to concentrate on investing my very little time still > > available to FOP in a productive way because I've already invested so > > much of my free time into FOP that I simply can't let go. > > I'd like to hear more about your thinking on this and your later comment > about the unhealthiness of the team, probably on the fop-dev list, Jeremias. I mean unhealthiness of the team in terms of: - active committer count was at four people at times, all working on FOP outside of the day jobs. I'm grateful this started to change recently, new committers and all. - we've had too much negative energy mixed into our threads lately. - the team switch has cause too much loss of knowledge and awareness of decisions taken earlier. This takes a lot of time to put right again. A positive point is that we finally managed to get the message through that HEAD is the way to go (of course with possible additions from Peter's branch). > > I'm not very good in this sort of thing especially since English ist not > > my primary language and I know that my intentions sometimes don't make > > it 100% to the other side. I hope I haven't put any more oil into the > > fire by writing this. If Peter disagrees with my view of the things I'd > > like him to chime in. For any details I'd like to point to the fop-dev > > mailing list archive (the whole thing happened around 2003-12-17). > > > > So. Peter and the other PMC members, do you think we should change > > anything about my report about FOP? I thought, this was important to > > mention but I don't think this needs any intervention right now as I > > know that some (or at least one) "high-ranking" Apache people are > > listening into the conversions over in FOP-land which I'm grateful for. > > Maybe "infighting" wasn't the best word but I took it as such a few > > times during the last months. I don't consider the FOP developer > > community a healthy one, especially compared to others here at the ASF, > > but I also haven't given up hope. We're all struggling for free time, no > > big companies backing us up anymore. > > > > Perhaps "infighting over technical/design issues" would be more precise. > If you saw it as infighting, it's fair enough to describe it that way. > > I'm interested also in the comment about the lack of backing. What > backing were we receiving previously? Due to his work at Dresdner Bank Keiron was able to work on the redesign for months. I've been able to do some work while I was still at Outline (although this is only a small company but so what) although most of it was in my free time. > As to free time, I'm now working outside the industry, on a > part-time/casual basis, and I like the situation. Working full-time in > IT makes too heavy demands on my concentration to be able to devote the > necessary time to FOP, which, as you point out, is extremely demanding. > The situation I am in now gives me more time the freedom to do my > design and coding the way I want to. That comment has wider application > than FOP. > > On the positive side, the recent increase in activity includes a lot of > cross-fertilization from alt-design to HEAD, which seems to have been > received very well by everyone concerned. Perhaps this should be > mentioned to balance concerns about Victor's departure. I'm glad this happens (not that Victor left however). Jeremias Maerki
Re: PMC representation
Thank you all for your support! I don't think the vote was necessary, though. And sorry for forgetting Christian again. Congratulations on your new family member! On 11.02.2004 23:13:15 Peter B. West wrote: > I have no problem with your continuing. If we need a formal vote, > > Jeremias to remain as one of our PMC representatives: > > +1 Jeremias Maerki
[PMC VOTE] PMC membership change
PMC, As you may be aware, Peter B. West (from the FOP sub-project) wanted to step down from the PMC last November. Somehow this slipped by and we never voted for his replacement: Joerg Pietschmann. The FOP voting results: 4 +1s (Peter B. West, Glen Mazza, Victor Mote and Jeremias Maerki) and no -1s. http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&by=thread&from=526295 (that was all we could get at that time, condition for 2/3 of active committers was met. I've also pinged the list this week to see if anything has changed but no negative comments.) According to the charter (either new or old), we need a unanimous vote from the existing PMC members to accept new members. Please put your votes on [EMAIL PROTECTED] Require votes from : [ ] Scott Boag [ ] Andy Clark [ ] Shane Curcuru [ ] Neil Graham [ ] Kip Hampton [ ] Vincent Hardy [ ] Berin Lautenbach [ ] Ted Leung [+1] Jeremias Maerki [ ] Brian Minchau [ ] Steven Noels [ ] Santiago Pericas-Geertsen [ ] Gareth Reakes [ ] Gianugo Rabellino [ ] Sam Ruby [ ] Matt Sergeant [ ] Kimbro Staken [ ] Jason Stewart [ ] Jeff Turner [ ] Erwin van der Koogh [ ] Dirk-Willem Van Gulik [ ] Peter B. West [ ] PeiYong Zhang (I hope I got the list right) Jeremias Maerki
XML Graphics PMC discussion - Wiki page created
As promised I've started a Wiki page with all the things I collected about the XML Graphics PMC (Batik and FOP moving closer together). This is to move on the discussion that started earlier. Once the board is satisfied with the federation proposal and this XML Graphics idea doesn't face opposition I'd like to create a concrete proposal that will be voted on by the Batik and FOP projects (and probably the XML PMC) and the approved by the board. I'd like again to invite everybody to participate in the discussion. Unless you haven't done so already please subscribe to [EMAIL PROTECTED] as this is the right place to discuss this (it's not so high-volume after all). I'd like the XML PMC to be able to follow the discussion, too. Thanks. If anybody considers this a bad idea, please speak up. There might be issues because this proposal essentially only replicates the XML project down to a smaller scale but I think this can still satisfy the board's wishes. I'm curious to your comments. http://nagoya.apache.org/wiki/apachewiki.cgi?XMLProjectPages/XMLGraphicsPMCDiscussion Jeremias Maerki
Re: ASF Board Summary for February 18, 2004
Ye. ;-) On 23.02.2004 16:06:42 Glen Mazza wrote: > Score (another) one for Jeremias... ;) > > --- Greg Stein <[EMAIL PROTECTED]> wrote: > > > > - author tags are officially discouraged. these > > create difficulties in > > establishing the proper ownership and the > > protection of our > > committers. there are other social issues > > dealing with collaborative > > development, but the Board is concerned about > > the legal ramifications > > around the use of author tags > > > > - it is quite acceptable and encouraged to > > recognize developers' efforts > > in a CHANGES file, or some other descriptive > > file which is associated > > with the overall PMC or release rather than > > individual files. > > Jeremias Maerki
Re: embed images
You're right. The URL protocol handler would have been simple. Probably the easiest way is to modify org.apache.fop.image.FopImageFactory. The "Make" method gets the URL string and tries to get an InputStream. VFS? At one time I suggested using the Source(Resolver) mechanism from Avalon which originally came from the Cocoon project. It provides some sort of VFS which could be used to do the kind of stuff you need. But this is future talk and will take some time to implement. On 22.02.2004 22:27:49 Heiko Barthel wrote: > I've got a special question using FOP 0.20.5: > I want to include GIF and JPEG images in the PDF which are not accessible > neither through HTTP, FTP nor the local file system. They reside only in > memory. I can imagine the following solutions: > 1. URL protocol handler > 2. FO extension > 3. something like a virtual file system > > URL protocol handler implemention is simple but unfortunately does not work > because I had to set the System property "java.protocol.handler.pkgs" which > is write protected in our production environment. > > Is there a possibility to embed the images in the FO file ? So I could > implement an FO extension. What ideas about a VFS ? > Any help and advice is welcome. Jeremias Maerki
Re: PS & PCL: How do I test them?
PS is mostly tested using GhostScript (and Acrobat Distiller). See http://www.ghostscript.com/ Also download GSview which is a viewer frontend for GhostScript. I haven't done any PCL-testing myself, but I guess with PCL you will need two or three different PCL printers if you want to do it seriously. I know there are a couple of good commercial PCL viewers available but maybe GhostPCL does the trick, too. But I don't think the PCL renderer does more than compile right now. We should probably concentrate on PDF, PS, Java2D and SVG outputs first. Another tip: For PDF testing I use GhostScript/GSview, too, because it automatically refreshes the currently displayed file as soon as it's changed. I'll try to allocate time to finish the testing infrastructure thingy I'm working on. Probably I'll simply upload as soon as I have something usable so you can jump in if necessary. That will enable us to view PDF, PS etc. side by side, hopefully with image diffs in the future. On 24.02.2004 01:50:05 Glen Mazza wrote: > Team, simple question: > > I use Adobe Acrobat to test PDF results. Are there any free/open-source > viewers to test PCL and PS results -- on either Windows or Linux? I've > never used PS & PCL before, so I don't know much about them. Jeremias Maerki
Re: [VOTE] Remove Visitor Patterns from AbstractRenderer.java
+0 if you feel this simplifies things. On 22.02.2004 23:41:03 Glen Mazza wrote: > Team, > > To simplify the Area Tree<-->Renderer interaction somewhat, making this > section of the code easier to follow, I'd like to make two changes to > the code: > > 1.) Remove the serveVisitor() methods... > - > > 2.) (This I'm less sure on) After reverting, I'd like to remove the... Jeremias Maerki
Applying the new license
I guess you'all seen the commit messages. I got a headache now, so I'll stop for the moment. Maybe I can do the rest this weekend. Only some manual work is left to do. Help is welcome. That little Java class in the committer CVS module really made this whole thing a piece of cake without me having to set up any script language environments on my Windows box. :-) We still have copyright statements in some of our hyphenation patterns. Seems like I gave up last year before sorting everything out. Sigh. I'll have to sleep over that. If anyone has any ideas or, better, surplus time... Jeremias Maerki
Re: Wiki Migration and other issues
Hehe, you thought the same thing at the same time. See my other post. I really need to sleep over that one. Concerning the Wiki: I see no immediate need right now unless there are plans to shut down the old Wiki. But +0. On 27.02.2004 20:58:29 J.Pietschmann wrote: > Hi all, > now that the ASF has its new Wiki farm up and running, > they pester everyone with moving from UseModWiki > http://nagoya.apache.org/wiki/apachewiki.cgi?HomePage > to the MoinMoinWiki: > http://wiki.apache.org/general > > Should we wait for the Apache XML reorganization to > complete or should we rush ahead and create out own > Wiki already? > > The other issue: The hyphenation files with problematic > licenses are apparently still in the HEAD CVS ready for > checkout. I can't remember any status change here. What > should we doe with them? Jeremias Maerki
Re: cvs commit: xml-fop/src/hyph cs.xml da.xml de.xml de_DR.xml el.xml en_GB.xml en_US.xml fr.xml nl.xml no.xml sk.xml tr.xml
With the help of many people I've done an licensing audit last March. See the Wiki page [1] for the whole protocol. The original Dutch hyphenation file that was used to create nl.xml is published under the LPPL license which includes a restriction that makes it impossible for The Apache Foundation to use and distribute. [1] http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAudits/March2003 On 27.02.2004 21:14:40 Simon Pepping wrote: > On Fri, Feb 27, 2004 at 06:24:38PM -, [EMAIL PROTECTED] wrote: > > jeremias2004/02/27 10:24:38 > > > > Removed: src/hyph cs.xml da.xml de.xml de_DR.xml el.xml en_GB.xml > > en_US.xml fr.xml nl.xml no.xml sk.xml tr.xml > > Log: > > Removed legally problematic files as done for the maintenance branch. > > What are those legal problems? The Dutch file nl.xml is based on the > hyphenation patterns created by the Dutch TeX user group, and are > freely distributed with TeX software. Why cannot FOP distribute them? Jeremias Maerki
Re: Applying the new license
The (documentation) sources all need a license header (docs and src/documentation). That's one part remaining. The other is the rest of the hyphenation files. But there it may not be so simple as to apply the Apache license. We will need to doublecheck the audit results and see where we can apply the ALv2 and where we have to do something else (getting grants, or doing something like we do for the JARs in our repository). BTW, we need to update our site to reflect that new releases and especially new contributions by developers will fall under the new license. The new license contains in implicit copyright grant which makes our life a lot easier when we accept contributions. And what's equally important is that it's a lot easier for contributors, too, because they don't have to send in grants for bigger contributions anymore. See section 5 in the new license. But all that doesn't mean we can neglect our duty to check the origin of contributions. Especially for the hyphenation patterns this may still be problematic because someone who does a hyphenation file conversion may not be entitled to submit it to the ASF because he is not the (only) copyright holder and license restrictions may not allow our distributing the file. On 28.02.2004 00:27:19 Peter B. West wrote: > Apart from the hyphenation problem below, what manual work remains? Jeremias Maerki
Re: Applying the new license
On 28.02.2004 20:16:56 Clay Leeds wrote: > It would also be nice, if there were some sort of "repository" or links > page on the FOP site where people can go to get hyphenation files that > cannot be included in FOP because they do not meet the needs of the > ALv2 (assuming there are no negative legal ramifications). That way, > this valuable information is still accessible, and simplifies the > process of getting the information. It might mean a little more legwork > on our part, but it may end up being 'worth it' in the long run. Well, IMO our website says just about everything there is to know about hypenation patterns. Even a link to the most important source for hypenation patterns is there. One possibility for the community is to create a project at SourceForge (or somewhere else) to put hyphenation patterns which cannot be distributed by the ASF. > Also, I don't know how I can be of use, but if there's anything I can > do in this regard (e.g., take a text blurb and 'apply' it to a set of > files), I'd be happy to help. I just need a little direction on how to > contribute. You could try to get a few people together to create that place where people can download additional hyphenation patterns. Also, simply send in patches for the documentation as you see possibilities for improvement. I don't think you have to care about the relicensing issues. We can handle that. Just continue doing what you do. That way you already help a lot. If you want to do even more, you could buy yourself a good beginners guide to Java. Jeremias Maerki
Re: [VOTE] Clay Leeds for Committer
+1, again, for Clay. Thanks, Glen, for doing a better job at formulating a new committer proposal than I did. Would you please enlighten me what the words below mean? On 29.02.2004 22:10:42 Glen Mazza wrote: > Waxing chutzpaic, Jeremias Maerki
Re: Newbie Commiter Questions
I've had my problems with using SSH2. I finally tried SSH1 and it worked. I suggest you create a SSH1 key pair and retry with this. There are two ways you can work with putty. Either you create a tunnel for CVS which has the benefit that the connection is always there as soon as you have connected to the server. The other way is to use plink which has to build a connection everytime you access CVS. Select SSH authentication in WinCVS and specify the full path to plink.exe as SSH client. You need to have Putty Password agent running for that. Tell me if you need more info. Good luck! On 01.03.2004 10:32:28 Chris Bowditch wrote: > I know this subject has come up before, but I still cant quite get > things working after trawling through the archives. > > I'm using WinCVS 1.3 and Putty to connect to the cvs.apache.org. My > understanding was that using SSH keys was optional but strongly > encouraged. So I had a go at creating the private/public key pairs, and > put the public key into .ssh directory on my apache home, and specified > the private key file to Putty, but when I click "open" in Putty and > enter userid/password I get a message saying > > Trying public key authentication. > Key is of wrong type (PuTTY SSH2 private key) > > Any ideas, what this means? I specified SSH2 (RSA) when I generated my > keys. I noticed in the archives that some people have authorized_keys > and others have authorized_keys2 file, which do I need? I tried both, > but I still got the same message. > > Thinking that SSH is not strictly required for write access, I had a go > at updating my description on the Team page, but WinCVS says: > > cvs [server aborted]: "commit" requires write access to the repository Jeremias Maerki
Re: Thanks Jeremias
You guys are welcome. Thanks for the cheering. So what's left? Basically your special branch if you haven't converted everything, yet (I didn't check). It's probably ok to leave the maintenance branch in the fridge. And I guess I can give the hyphenation stuff a few minutes on Friday. One thing, though: If I've see correctly there's a growing number of files that have CVS keyword substitution disabled. We may want to address that eventually. On 03.03.2004 00:53:51 Peter B. West wrote: > Thanks again, Jeremias, for all of the licensing housekeeping. I'm > sorry I didn't get around to giving you a hand with this. Does anything > (apart from the hyphenation mess) remain to be done? Jeremias Maerki
Implicit grants (FOP hyphenation)
(ccing fop-dev and XML PMC) Last year I've invested hours after hours doing a license audit on the XML FOP project mainly because of problems with the hyphenation pattern files. These files have been converted to XML by FOP contributors but almost all files are coming from TeX software repositories where licenses are diverse or non-existent. Some problems were resolved, more than half of the files removed in the process. For one of the files I have been able to get the original author of the hyphenation pattern file to submit a grant form by fax to the ASF. That grant has never been confirmed although I've pinged Jim twice (in April last year). Following that I gave up hunting for grants. I understand that dealing with this is annoying but it brings up the question about on one side requiring grant forms and on the other side having a good infrastructure not depending on one person alone to handle it all. But that's not the reason I write this. I've done the relicensing on the XML FOP project and was again confronted with our hyphenation files. Two of them now have the ALv2 header because for these two files all legal problems have been dealt with (although we don't have any copyright grants on file for them. See big question below). The other files carry copyright statements (or just a file history with names) but appear to be distributable by the ASF. I still have to figure out what to do with them. Most of them appear to be in the public domain (although this is usually not explicitly state as such) so I will probably simply add the ALv2 header if nobody sees any reason why I couldn't do so. I'm real tired of the problem. My big question: The ALv2 specifies implicit grants, right? (Section 5) Can I apply this section to contributions done before the ALv2 was here? Example: For the file (da.xml, Dansk hyphenation patterns, currently not in CVS) mentioned above, I know that a grant was sent to the ASF by the original author of the file (although there's no confirmation of the receipt). And the person who converted the file to XML intentionally submitted it to the FOP mailing list for inclusion in the project. It would appear that I am now able add the ALv2 header to the file and add it to CVS again. Any reason I can't do that? As a related question: The implicit grant works for original works only. Derived works still need a written permission by the original author(s). I'd imagine a written permission is enough. No grant form necessary. Correct? But then, where's the border between not needing a grant and needing one (for example for the new projects coming to the ASF)? Just wondering. A slightly out-of-date log of the FOP audit is here: http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAudits/March2003 I apologize if this post may carry a somewhat bitter undertone. It took a lot of time already and I'm still not finished. I wanted to do it right but that's very difficult. So thanks in advance for any insight and good ideas. Jeremias Maerki FOP committer, XML PMC representative for FOP
Re: Implicit grants (FOP hyphenation)
I agree. But if we don't put them under the ALv2 we need to clearly mark the files as such. Like we do for the JARs in the lib directory. But before we do anything I'd like to see if there's any answer to my questions. On 05.03.2004 21:29:39 J.Pietschmann wrote: > Jeremias Maerki wrote: > > But that's not the reason I write this. I've done the relicensing on the > > XML FOP project and was again confronted with our hyphenation files. Two > > of them now have the ALv2 header because for these two files all legal > > problems have been dealt with > > I don't think it is necessary to put *all* files under APL. If we can > assume the content had been granted, and there is no infformation to > the contrary and no incompatible license already in the file, we can > just leave it as it is, or perhaps add something to the effect > "... has been contributed to FOP and is assumed to be licensed > for all purposes FOP can be used. Contact the authors stated above > for further details." > (unless license@ says otherwise, of course) > Tracking down the original committer from CVS might help too, but > in general I wouldn't loose much further sleep on the whole issue. > > Of course, newly contributed files should be put under APL which > means all issues have to be resolved before the file is committed to > CVS. Jeremias Maerki
Fw: Re: Federation Proposal
Forgot to CC. Please follow up on [EMAIL PROTECTED] Forwarded by Jeremias Maerki <[EMAIL PROTECTED]> --- Original Message --- From:Jeremias Maerki <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Date:Fri, 05 Mar 2004 20:45:45 +0100 Subject: Re: Federation Proposal I've posted an initial draft for the XML Graphics PMC (provided this name is ok for everybody). I've basically copied it from the one from the Logging Services project and changed it from there. http://nagoya.apache.org/wiki/apachewiki.cgi?XMLProjectPages/XMLGraphicsPMCDraftResolution Help in any form (Changes to the Wiki page, comments and ideas...) is welcome. I hope I'm going in the right direction. BTW, I find the mission statement and bylaws of Logging Services project very clear and a good template for our new PMCs. See http://logging.apache.org/ On 23.02.2004 12:50:59 Berin Lautenbach wrote: > Berin Lautenbach wrote: > > > For the next (or subsequent) board meeting, we need to have identified > > the new TLPs, together with proposed initial PMCs. Finally we need to > > have a draft motion for the board to vote on. (The last part is the > > easy part.) > > To be clear - we need a number of draft motions - one for each proposed TLP. Jeremias Maerki ----- Original Message Ends Jeremias Maerki
Apache Account Request: New FOP committer (Clay Leeds)
Clay Leeds has been voted in as new FOP committer. Please create a new account for him as soon as the CLA has been received. +1: 9 +0: 0 -1: 0 Vote: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&by=thread&from=660266 Full name: Clay Leeds Preferred account name: clay (alternative choices: webmaestro, cleeds) eMail-address: [EMAIL PROTECTED] Karma: xml-fop, xml-site The CLA should be on its way. Thanks! Jeremias Maerki
Re: Fonts and Document
The font subsystem is still far from finished. It's still quite complex to understand, unnecessarily so IMO. My font source idea still need to be implemented... Let's see if I can pull together some connectors. As you've seen the Document class is a central class in font handling. It currently (not in my ideas) provides direct access to font metric information and to the list of fonts actually used in a rendering run (we don't always want to embedd them all). The setup of all fonts is done in the FontSetup class where the base 14 fonts are defined. Additionally, custom fonts are added there. But the custom fonts are mostly renderer-dependant, so at the moment, some font setup also takes place in PDFRenderer for example. See PDFRenderer.configure (which can build custom font information using an Avalon Configuration object using a helper method from FontSetup) and PrintRenderer.setupFontInfo which actually triggers the font setup. The fonts get registered with the Document object and subsequently is available to the layout engine. Most font classes in the fonts package deal with the different font formats (single byte und unicode, base und custom...). There's also a difference in audience: The layout needs different information (metrics in particular) than the renderers (primarily information for using and embedding the font in the target format. Just a quick write-up, but I hope it still helps a bit. On 15.03.2004 00:27:35 Peter B. West wrote: > Fops, > > What is the current situation with font information? I notice that the > Document class now contains a lot of Font setup information, whilst a > comprehensive set of font classes exists in ...fonts. I want to > introduce font information into alt-design as compatibly as possible > with HEAD. What do I need? Jeremias Maerki
Re: Antwort: Web Start
I also don't think WebStart can help us here. I'd like to add a comment here. Considerations like this are currently running hot within the ASF. We need to divide two problems: 1. The ASF is restricted in what it can distribute. There's a policy forming. I hope all FOP committers are subscribed to [EMAIL PROTECTED] 2. Our users who download FOP expect FOP to be available under the Apache license (v1 or v2). If we include non-Apache licensed works or if we download such works from other places (for example using Maven) the user also has to comply with the licenses under which the other works are distributed. The user needs to be made aware of that. So it may not be done with simply downloading files from other locations. AFAICT people will start (or already have started) to discuss this problem is it is not only FOP's problem. I hope the above is understandable. I'm not sure I've understood everything myself. Just summing up what I read on community@ and [EMAIL PROTECTED] On 19.03.2004 03:15:32 Peter B. West wrote: > Let's say, for example, that we approach a TeX distribution with a > request that we be allowed to download the TeX hyphenation files, as > modified for use with Fop. If they are OK with that, we generate a jar > file with the hyphenation files, including the original copyright (and > possibly notes about the conversion being done under the auspices of > Apache) and drop it on the CTAN servers. Alternatively, we simply jar > up the original TeX files, and include a conversion process in the > installation. > > The files are not coming from an Apache server, and they do not carry > the Apache license (except for perhaps a "Parts copyright..." notice). > It is a convenience to our users that we download such files > transparently from another source on installation. Jeremias Maerki
Re: Another licensing issue
Well, the list may not be complete as the Unicode standard in always in flux. At any rate, I think the character name list is used to map the names to unicode character, so you can map unicode characters to a font's glyph index. So it's primarily a matter for custom multibyte fonts like TrueType fonts. I can't see right now, where we need a wider set of character names. Maybe when people need to use fonts that have the latest and newest Unicode characters in them they could run into problems. Not sure. On 19.03.2004 06:07:04 Peter B. West wrote: > Jeremias, > > The penny just dropped about the names of the Unicode characters; they > are the Adobe Glyph List and the Zapf Dingbats Glyph List names of a > subset of Unicode characters. > > Won't we at some stage need to generalise support for a wider set of > glyphs? Or is that entirely a matter for user-defined fonts? Looks as > though I'll have to look at user fonts. > > Peter > > Peter B. West wrote: > > Jeremias et al, > > > > I would like ti use the Unicode Character Database as a source for names > > of characters. At the moment, ...fonts.Glyphs contains a static table > > of String pairs containing the Unicode character and its name, > > respectively. > -- > Peter B. West <http://www.powerup.com.au/~pbwest/resume.html> Jeremias Maerki
Re: Fonts and Document
ons). However, I still don't buy the idea, yet, as the way to go. With separate PDF and PS renderers I have everything under control. More code, granted. It would certainly be interesting to have both models and compare them more closely. I have once looked at Hansuli's code which seemed to me a modified copy of the AWT renderer which is not such a good thing to do. It should be possible to reuse code as much as possible even if it means changing the original AWT, sorry, Java2D renderer. But that's already many months in the past. Now we can start on the green field. Maybe Hansuli chimes in again and helps us go into this direction. > Btw, what search keys should I use to recover details of your font model > from the archive, assuming there are differences between your model and > the wiki? Interesting threads: http://marc.theaimsgroup.com/?t=10420983741&r=1&w=2 http://marc.theaimsgroup.com/?t=9809918463&r=1&w=2 I think the Wiki holds most of my view of things. Victor added a lot of additional content I was unfortunately never able to completely follow-up on. http://nagoya.apache.org/wiki/apachewiki.cgi?FOPFontSubsystemDesign Jeremias Maerki
Re: [VOTE] Switch from Avalon to Commons-Logging
y accept JDK 1.4 logging. > Another huge advantage I see for FOP in particular is > exceptional integration with Struts applications. For > Struts developers, the same commons-logging instance > that they presently use for their application coding > can be passed into FOP during PDF generation. No more > needing to create a separate Avalon logging instance > in their code, or (possibly) needing to have two > different output logging files, one for each logging > instance. This will look very nice architecturally > for both FOP and Struts. Same is true for integration with Cocoon which is Avalon-based. Cocoon's logger can simply be passed to FOP. (And we don't know, yet, how Cocoon will look like later. For now it's Avalon-based.) > I'll be more than happy to take care of the conversion > for us--I'll make the change via a patch for us to > review before committing. Before Avalon is removed I request a plan be made on how to handle the configuration aspects in FOP. Avalon provides a very good infrastructure to handle this. I've even used it in my Barcode4J project (which is a lot smaller than FOP) because it makes configuring a component using XML a no-brainer. I must say, however, that the Avalon-integration will probably become optional (implemented in special subclasses) as Barcode4J is reasonably simple to work with Bean-style configuration. But still I have absolutely no plans the remove this small dependecy to Avalon Framework. Has anybody here already taken a look at Hivemind (found in Jakarta Commons)? Jeremias Maerki
Re: [VOTE] Switch from Avalon to Commons-Logging
I'm not sticking to Avalon. All I can say is that I've successfully used Avalon to build a flexible server for document processing using the ECM container (same that Cocoon is currently using). I loved to work with it, especially after I was able to rewire the whole application at a customer's site by only changing the XML configuration files. I didn't have to change one line of Java to adapt the application to the unsupected requirements found there. I'm open to investigate other possibilities, even to simply try to work without any outside help. What I find important is to have a way to configure FOP using XML in a flexible manner, to have something that helps us split up FOP into the right set of components, to have exchangable components, to have FOP easily integrate with other packages such as Cocoon. I'm still thinking that we can do without a sophisticated container such as Merlin, even ECM. The basic Avalon patterns established my Avalon Framework already provide an interesting environment. I'm sure that even Stefano and Pier would agree to that. They simply see different requirements specifically targeted at Cocoon. FOP is surely something different. But if we find something better, I will fully support it. Well, let's have an eye on what's going on in Cocoon-land, but let's also not blindly follow what they're doing. On 28.03.2004 18:07:15 Glen Mazza wrote: > Jeremias, I reached your conclusion yesterday in doing the logging > conversion (I'm only 2/3rds there right now): namely, to keep Avalon > for the time being for the non-logging components, but just to replace > its logging component with Commons-Logging. It was just in doing the > conversion yesterday that I first noticed that we were using Avalon for > other things (even after switching to C-L, it will still be in about > 10-15 classes over a few packages), namely the configuration that you > mention. I also agree in not switching away from the Avalon > configuration unless there is something better in Commons--*** or > something better we can do ourselves. I haven't studied configuration > (hence am not very knowledgeable about it), and it is not among my > priorities--other team members have thankfully been taking the lead on > configuration. > > Also, if there's another feature you like from Avalon, we can always use > it. To me, Avalon is now just another library, like the Commons--*** > libraries. It's just that FOP won't be living and breathing Avalon 24/7 > anymore--we'll use certain parts of it where it's better than > Commons--*** libraries, but not just blindly using it "because it's > Avalon". The entire 30-40 email Cocoon thread on "building on stone" > was not much of a confidence builder in adopting the latter > philosophy--email after email, the team had little good to say about > Avalon as an application framework, and is now considering painful > contortions [1] to liberate themselves from it. > > Thanks, > Glen > > [1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108016162526312&w=2 > Jeremias Maerki
Re: DO NOT REPLY [Bug 28044] - Patch, Avalon Logging to Commons Logging Conversion.
I got home late today, so I didn't manage to finish everything. I will do that tomorrow morning. Todos: - Figure out how best to configure the SimpleLog when using static loggers in command line apps. - Fix examples in examples/embedding - Fix tests - Update Gump descriptor to include the new dependency on JCL. We're lucky that we don't get nagged as Batik has a compilation problem ATM. On 31.03.2004 08:34:13 Jeremias wrote: > I'm busy today but I'll try to do the whole thing for the PDF and library code > on Thursday evening (CET). Jeremias Maerki
How to work with Commons Logging in FOP
As promised, I've changed the way the logger is fetched in the PDF library and the font code. Instead of passing a Log instance from parent to child (IoC, like with Avalon), logging-enabled classes fetch their own logger via JCL's LogFactory. The code gets easier. I'm quite happy with this. As you may have seen I added a cvsignore file in the src directory. The idea is to put a simplelog.properties (or other such configuration file) in the src/private-resources directory so you can configure the SimpleLog logger from Commons Logging. My current simplelog.properties looks like this: org.apache.commons.logging.simplelog.showShortLogname=false org.apache.commons.logging.simplelog.defaultlog=info org.apache.commons.logging.simplelog.log.org.apache.fop.pdf=trace Info about simplelog.properties can be found at [1]. One additional thing is to add a system property to each startup configuration in your IDE where you need to configure logging. Working with Eclipse I've added... -Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog ...to the "VM arguments" in the run configuration. This ensures that Commons Logging will not use JDK 1.4 logging (see [2]), but directly choose the SimpleLog implementation which is sufficient while developing. Of course, you can use JDK 1.4 loggging or Log4J, as you wish. See the javadocs for LogFactoryImpl [2] for further information. The whole documentation on Commons Logging is available at it homepage [3]. [1] http://jakarta.apache.org/commons/logging/api/org/apache/commons/logging/impl/SimpleLog.html [2] http://jakarta.apache.org/commons/logging/api/org/apache/commons/logging/impl/LogFactoryImpl.html [3] http://jakarta.apache.org/commons/logging/ For setting up Commons Logging for a command-line application, please see PFMReader and TTFReader for how I think it should be done. I'm not entirely comfortable, yet, as SimpleLog logs everything to System.err. For Barcode4J I wrote a special ConsoleLogger (for Avalon Logging) [4] that logs only WARN, ERROR and FATAL levels to System.err while sending the rest to System.out. Also, there's no possibility to get rid of the log level prefix in SimpleLog. In the end, it would probably be best to create a special CommandLineLog class which is tailored to this use case. [4] http://cvs.sourceforge.net/viewcvs.py/barcode4j/barcode4j/src/java/org/krysalis/barcode4j/cli/AdvancedConsoleLogger.java?rev=1.1&view=auto Jeremias Maerki
Re: DO NOT REPLY [Bug 28044] - Patch, Avalon Logging to Commons Logging Conversion.
On 02.04.2004 03:47:16 Glen Mazza wrote: > > --- Jeremias Maerki <[EMAIL PROTECTED]> wrote: > > I got home late today, so I didn't manage to finish > > everything. I will > > do that tomorrow morning. > > > > Todos: Actually, these todos were rather targeted at myself but I'm glad you jumped in. THANKS! > > - Figure out how best to configure the SimpleLog > > when using static > > loggers in command line apps. > > I'll let you start the cogitation here. ;) See my other post. > > - Fix examples in examples/embedding > > Just done, as well as updated some of the > documentation. Also tested them. Feel free of course > to make adjustments as you wish. Look fine, thanks! > > - Fix tests > > Done--only one file (BasicDriverTestSuite) needed > changing. BTW, the subsequent test fails as follows > for this file (the other test files are all OK)--but > it appears unrelated to the logger switch (it may be > something with my machine): > > Testcase: testFO2PDFWithConstructorSetupTestcase: > testFO2PDFWithInputSource took 0 sec > Caused an ERROR > loader constraints violated when linking > org/xml/sax/XMLReader class > java.lang.LinkageError: loader constraints violated > when linking org/xml/sax/XMLReader class > at > org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown > Source) > at > org.apache.fop.apps.FOFileHandler.createParser(FOFileHandler.java:91) > at org.apache.fop.apps.Driver.run(Driver.java:655) > at > org.apache.fop.BasicDriverTestCase.testFO2PDFWithInputSource(BasicDriverTestCase.java:89) > at > sun.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > > > (over and over again for each test within this file) Have you got two different versions of Xerces or JAXP in your classpath maybe? I've got another one: org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or change an object in a way which is incorrect with regard to namespaces. at org.apache.xerces.dom.CoreDocumentImpl.checkDOMNSErr(Unknown Source) I haven't taken the time, though, to track it down, yet. > > - Update Gump descriptor to include the new > > dependency on JCL. We're > > lucky that we don't get nagged as Batik has a > > compilation problem ATM. > > > > I don't know where this file is. Right here: http://cvs.apache.org/viewcvs.cgi/gump/project/xml-fop.xml http://cvs.apache.org/viewcvs.cgi/gump/project/xml-fop-maintenance.xml I'll change them in a few minutes. Jeremias Maerki
Re: DO NOT REPLY [Bug 28044] - Patch, Avalon Logging to Commons Logging Conversion.
Yes, Axis uses JCL just as I wanted. Concerning the discovery things, they are using Commons Discovery [1]. I'm not sure myself what the intent/benefit is behind it but I'm pretty sure we don't have to do the same. For the moment, I think the current approach is quite satisfying. Anyone else want to comment? [1] http://jakarta.apache.org/commons/discovery/ On 02.04.2004 04:57:45 Glen Mazza wrote: > Actually, what the Axis team did in their code may be > a good example for us. > > They created their own LogFactory class [1], and in > 167 files, such as here [2] and [3], they activate > that LogFactory class with the name of the class where > the logging is occur. > > It appears that they created their own LogFactory to > centralize in one place the exact type of logger that > will be created. Also, they're doing something > security- and "singleton discovery"-related, I'm > unsure of its relevance for us, however--Axis has > requirements quite different from us, of course. Jeremias Maerki
Re: [VOTE] Simon Pepping for Committer
Jeremias says: +1 On 02.04.2004 02:38:11 Glen Mazza wrote: > I'd like us to go ahead and make Simon Pepping our > newest FOP team member. He has provided steady ML > help and numerous patch contributions for the past few > months, and with the many layout patches that have > been coming in recently, we could certainly use his > continued help on our team. Jeremias Maerki
Re: eoXXXXXXXXXtm files
Hello Heiko, to my knowledge, there's no code in FOP that creates these files and I have never come across files named like this. Does your own protocol handler generate these files? If yes, you're responsible to remove them. Please follow up on the fop-user mailing list as it's the better place for questions like this. Thanks! On 02.04.2004 10:04:55 Heiko Barthel wrote: > I saw these files when I referenced images via my own protocol handler. > How can i avoid that FOP creates these files ? Jeremias Maerki
Re: New version of LaTeX Project Public License
I agree with Christian. Are there hyphenation files available under LPPL 1.3 already? I'd like to have a look at the packaging. Before including files under LPPL 1.3 in FOP we should clear it with [EMAIL PROTECTED] I don't know who of you is also listening into [EMAIL PROTECTED] (I know Peter does). There are still discussions about details on how to apply the new ALv2 and how to deal with other licenses. We probably still need to wait a bit. On 02.04.2004 09:27:31 Christian Geisert wrote: > Simon Pepping wrote: > > Rainer Schöpf of the CTAN team pointed out that there is a new version > > of the LaTeX Project Public License, version 1.3, > > http://www.latex-project.org/lppl/lppl-1-3.html. He stated that this > > version is DSFG compliant, although I could not find this statement on > > the web site. > > > > The clauses relevant to FOP's ability to distribute hyphenation > > patterns derived from files under the LPPL seem to be: > > [..] > > > > 2. Information that is sufficient to obtain a complete, > > unmodified copy of the Work. > > [..] > > > Clause 6.d.2 is a bit tricky I guess. The rest seems OK. > > IMHO it should be ok to add this to the NOTICE file > (See http://www.apache.org/licenses/example-NOTICE.txt) > > -- > Christian Jeremias Maerki
Re: Applying patches
Hi Chris, I'm applying the patches directly in Eclipse which provides graphical helpers to resolve problems like this. Patches can even be copy/pasted. I've had problem with the patch.exe myself in the past, but since I'm using Eclipse I've had almost no problems anymore. On 02.04.2004 12:26:20 Chris Bowditch wrote: > Team, > > sorry but another newbie committer question: > > I downloaded a patch program from the internet. Not sure if there is a > specific one I need, or whether they all conform to a standard. When I try to > run the patch program with unified patch file in the xml-fop directory, it > cant figure out the locations of the files its supposed to be patching. I > thought it would just read the following line: > > RCS file: > /home/cvspublic/xml-fop/src/java/org/apache/fop/layoutmgr/TextLayoutManager.java,v > > I tried telling it to strip the first 2 components of the path, but no difference. > > I need a patch program for windows. Can anyone offer advice? I ended up > applying the patch manually. > > Chris > Jeremias Maerki
Fw: cvs commit: gump/project xml-fop.xml
FYI Forwarded by Jeremias Maerki <[EMAIL PROTECTED]> --- Original Message --- From:[EMAIL PROTECTED] To: [EMAIL PROTECTED] Date:2 Apr 2004 12:50:43 - Subject: cvs commit: gump/project xml-fop.xml jeremias2004/04/02 04:50:42 Modified:project xml-fop.xml Log: Added commons-logging to dependencies. Revision ChangesPath 1.28 +1 -0 gump/project/xml-fop.xml Index: xml-fop.xml === RCS file: /home/cvs/gump/project/xml-fop.xml,v retrieving revision 1.27 retrieving revision 1.28 diff -u -r1.27 -r1.28 --- xml-fop.xml 27 Feb 2004 09:22:57 - 1.27 +++ xml-fop.xml 2 Apr 2004 12:50:42 - 1.28 @@ -36,6 +36,7 @@ + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Original Message Ends ---- Jeremias Maerki
Re: How to work with Commons Logging in FOP
On 02.04.2004 12:59:00 Chris Bowditch wrote: > Jeremias Maerki wrote: > > > > > As you may have seen I added a cvsignore file in the src directory. The > > idea is to put a simplelog.properties (or other such configuration file) in > > the src/private-resources directory so you can configure the SimpleLog > > logger from Commons Logging. > > > > My current simplelog.properties looks like this: > > org.apache.commons.logging.simplelog.showShortLogname=false > > org.apache.commons.logging.simplelog.defaultlog=info > > org.apache.commons.logging.simplelog.log.org.apache.fop.pdf=trace > > > > Info about simplelog.properties can be found at [1]. > > Well Ive created the file on my hard disk as you suggest. But shouldnt this > really be kept in CVS, with default settings. Obviously users will be expected > to change the defaults. If a sample file is not kept in CVS, then every user > is going to have to look in archives in order to find out how to get logging > turned on. I know we dont have many users of HEAD yet, but I want us to > consider what is going to happen longer term . Well, JCL provides some reasonable default without any additional configuration. I added the directory to cvsignore because I don't want to accidently upload my private modifications to my log configuration. If you think there should be a default configuration we can provide such a file, but hopefully in a different directory. > > > > One additional thing is to add a system property to each startup > > configuration in your IDE where you need to configure logging. Working > > with Eclipse I've added... > > > > -Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog > > We would need to add this to FOP.sh or FOP.bat in CVS We could. But I expect a command-line application to write all its output to System.out/err exclusively. See PFMReader and TTFReader where I explicitely set up Commons Logging to write to the console. The system property above is only necessary for embedded use. > > > > For setting up Commons Logging for a command-line application, please > > see PFMReader and TTFReader for how I think it should be done. I'm not > > entirely comfortable, yet, as SimpleLog logs everything to System.err. > > For Barcode4J I wrote a special ConsoleLogger (for Avalon Logging) [4] that > > logs only WARN, ERROR and FATAL levels to System.err while sending the > > rest to System.out. Also, there's no possibility to get rid of the log > > level prefix in SimpleLog. In the end, it would probably be best to > > create a special CommandLineLog class which is tailored to this use case. > > Will embedded users be able to write a Logger that overrides the default > SimpleLog, and captures the output to file, rather than System.err? Sure, they can use Log4J, LogKit, JDK 1.4 logging to write to any file, email, SNMP or whatever. They don't even have to write a logger because Log4J, for example, can already do everything. Just have a look at the JCL documentation. Jeremias Maerki
Re: Fontconfig
On 11.04.2004 01:55:48 Peter B. West wrote: > In connection with our recent discussions concerning font handling, I > looked at the contentious fontconfig system driven by Keith Packard. > I have also, as I noted previously, looked briefly at the way fonts are > defined in Java. Would I be correct in surmising that the current > manner of defining fonts is derived from Adobe's methods for PDF and PS? Correct. At the beginning, there was PDF. The whole thing was pretty much derived from the PDF-way of handling fonts. PostScript is quite similar. > If that is the case (a big if) might we not be better to move to a more > generic form, with translation into each particular form of font > specification? I can't tell. I don't see much benefit because the current system already provides most of what FOP needs. A total rewrite may provide more flexibility on the long run but will mean a lot of work which is problematic in FOPs current state. It should be fairly simple to add the two most important missing features to FOP font handling: on-the-fly font discovery and font aliases. On the other side, Keith Packard's system, I guess, would have to be reimplemented in Java for use to be able to use it. Jeremias Maerki
Re: Fontconfig
on-the-fly font discovery: Specify a directory and FOP finds all the compatible fonts in there without the need for manual font metrics creation. So this is something else. font aliases: Mapping Arial to Helvetica, for example. Mapping font characteristics is somewhat hardcoded already into FOP, though on a very primitive level only. See FontUtil. On 12.04.2004 14:55:35 Peter B. West wrote: > It seems to me that, at some point, we have to map from this set of > properties to the font characteristics of the renderer in question. > > Is this what you mean by on-the-fly font discovery and font aliases? Jeremias Maerki
Re: More on font properties
On 13.04.2004 14:47:02 Peter B. West wrote: > Fop-dev font-devs, > > My reading of the Javadocs for both 1.4.2 and 1.3.1 has turned up some > interesting questions. Since 1.3.1 (at least), java.awt.Font has > defined constants for CENTER_BASELINE, HANGING_BASELINE and > ROMAN_BASELINE. These correspond to the Central, Hanging and Alphabetic > baselines of the Rec at 7.8.1 Fonts and Font Data, which includes: > > XSL assumes that the font tables will provide at least three font > characteristics: an ascent, a descent and a set of baseline-tables. > > > The Rec actually aligns ideographic text on the Ideographic baseline, > but this seems to have a fixed relationship to the Central. > > Does the baseline discussion in the Rec have any echo in FOP? Are > baseline tables implemented? No idea and I don't think so. Up to date we are lucky to have non-ISO-8859-1 characters display at all. I think Keiron started working on BIDI, and Karen had quite some knowledge, too. But I don't think it got any farther than that. We've got the ascender, the descender, the X/Cap-height and that's the three values that determine the placement of characters right now. See FontMetrics.java. > Mind you, I don't yet know whether the baseline constants from Java are > actually used anywhere. Neither do I, but trusting Eclipse's reference search, the answer is: no, they aren't in use, not even in JDK 1.4. Sorry for being of no use here. Jeremias Maerki
Apache Account Request: New FOP committer (Simon Pepping)
Simon Pepping has been voted in as new FOP committer. Please create a new account for him as soon as the CLA has been received. +1 [9]: Peter, Finn, Jeremias, Glen, Oleg, Chris Bowditch, Christian Geisert, Andreas, Clay +0 [0] -0 [0] -1 [0] Vote: http://marc.theaimsgroup.com/?t=10808663048&r=1&w=2 Full name: Simon Pepping Preferred account name: spepping eMail-address: [EMAIL PROTECTED] Karma: xml-fop, xml-site The CLA should be on its way. Thanks! Jeremias Maerki
Batik and FOP - how to proceed
Hi everyone I'd like to make another attempt to push the XML Graphics idea a bit. We're at a stage where we'd have to gather the candidates for the new PMC. That's where it gets complicated. Obviously, Batik is practically in a stand-still. Both Vincent and Thomas are practically unavailable right now. How do we handle the Batik side for new PMC? Any idea, Thomas, when and if you can get back to the project? I know Vincent will try to help out on the transition of Batik into the XML Graphics umbrella, but it feels like a dump right now. The FOP team will most likely not be able to maintain the project. I'd personally have as many people on the new PMC as possible even if it means having more FOP people on it than Batik people. But having only two (or less) on the PMC from the Batik side seems not to be a good thing. Any ideas how to proceed? Opinions? I'm out of ideas right now. After all, we have to finish reorganizing the XML project sooner or later, right? Jeremias Maerki
Image library adapter package
Team, Abey Mullassery, committer in Jakarta taglibs, recently wrote a proposal for an image wrapper package. I answered to show him some pointers where code such as this is used/needed. We already have a solution although it probably needs an overhaul. If anyone of you is interested to work with him on this, please get in touch with him (he's cc'ed). I would but you know Here's the thread: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&by=thread&from=762095 Thanks, Jeremias Maerki
Re: Batik and FOP - how to proceed
Hi Vincent On 13.05.2004 10:14:11 Vincent Hardy wrote: > Hi Jeremias, > > Jeremias Maerki wrote: > > >Hi everyone > > > >I'd like to make another attempt to push the XML Graphics idea a bit. > >We're at a stage where we'd have to gather the candidates for the new > >PMC. That's where it gets complicated. Obviously, Batik is practically > >in a stand-still. Both Vincent and Thomas are practically unavailable > >right now. How do we handle the Batik side for new PMC? Any idea, Thomas, > >when and if you can get back to the project? I know Vincent will try to > >help out on the transition of Batik into the XML Graphics umbrella, but > >it feels like a dump right now. > > > Sorry to see you interpret things this way. I'll do my best to help out. > I have spent enough of my life on Batik that I would not just dump it > :-), but there are only so many hours in a day. I know how you feel. I'm in a similar position. I'm simply trying to deal with the facts as they present themselves. > I hope someone else can > step up and represent Batik on the XML Graphics PMC. > > >The FOP team will most likely not be > >able to maintain the project. > > > > > Yes, I agree we need someone who is more dedicated to Batik. > > >I'd personally have as many people on the new PMC as possible even if it > >means having more FOP people on it than Batik people. But having only > >two (or less) on the PMC from the Batik side seems not to be a good > >thing. > > > > > Do people on the PMC need to be commiters? If so, then the options for > Batik are going to be pretty limited. No, I don't think so, but Batik needs active committers to stay alive. > >Any ideas how to proceed? Opinions? I'm out of ideas right now. After > >all, we have to finish reorganizing the XML project sooner or later, > >right? > > > > > What do you think needs to happen for the formation of the new PMC > (apart from finding volunteers)? The board resolution is pretty much finished, we just need to fill in names. When the resolution is approved by us and passes in the board meeting, we need to write a charter. We could already start with the charter now. That's pretty much it. > What will people need to do: set up a > new project repositiory? No. We will still use the XML project's infrastructure. If the XML Graphics PMC is realized we might one day create an additional repository for joint operations. > set-up/moderate mailing lists? Nothing changes. We might choose to create an additional mailing list for common discussions (much like [EMAIL PROTECTED]). > And what do you > expect the changes to be for FOP and Batik, for commiters, developers > and users? For example, will there be web site changes, release changes > etc..? No changes for developers and users. Only minor changes for committers: Releases need to be approved by the PMC. Website remain where they are. You see. There are no big changes. The board simply wants the XML project to reestablish proper oversight over the projects. That's why we need to break down the XML project into smaller parts. The XML project transforms into a federation of XML-related projects at the ASF, basically a link collection, but also providing the old infrastructure so we don't disrupt our "customer's" view of our projects. If a project desires to become a full top-level project, that will be no problem, but that's not the issue here. -- Jeremias Maerki <[EMAIL PROTECTED]>
Re: AW: [Patch Proposal] Integrate FOP with Cocoon/Excalibur Source Resolving
Can we take a step back? Let's look at the possibilities: 1. URI resolver: Processes a URI String, returning either the same URI or a modified/different one. Corresponds to JAXP's URIResolver and SAX's EntityResolver. Generally usable whereever we use URIs to access external resources. 2. URI to InputStream resolver: Takes a URI and returns an InputStream from where a resource (font, image etc.) can be loaded. Such a resolver could mak use of the URI resolver above before actually resolving to an InputStream. 3. URI to FopImage resolver: Basically corresponds to our FopImageFactory today. Takes an URI and provides a FopImage instance, making use of at least a (1) and optionally (2). (3) could, for example, also provide the ability to create an image on the fly (charts, barcodes, static progress indicators, whatever...). All three could be expressed as plain Java interfaces. Each for its own level of responsibility. From top to bottom the responsibilities narrow down. Wouldn't it solve any possible requirement to provide a central registry in FOP where implementations of these interfaces (all three) are provided? By default, FOP provides its own basic implementations and our customers (Cocoon for example) could plug in their SourceResolver and CatalogResolver as necessary. Actually, that was what I originally planned to do by introducing Avalon (Framework). Its Serviceable/ServiceManager pair would have provided this infrastructure (allowing easy interfacing with Cocoon). I don't think it's a big problem to write some basic infrastructure to provide this (extending FOUserAgent or writing some FOPEnvironment class). Avalon would provide that already, as would probably other frameworks (such as Hivemind). In the end it depends on how much we will want to write ourselves and not depend on other libraries. Given the recent events in Avalon-land (and around it), I don't have a problem with going our own way although it doesn't sound ideal to me. Batik has done the same. Just a few thoughts... On 30.04.2004 23:29:19 Stefan Seifert wrote: > > > What about interface javax.xml.transform.URIResolver with > > > > javax.xml.transform.Source resolve(String href, String base) ? > > > > Note that org.apache.xml.resolver.tools.CatalogResolver is an > > implementation of this interface using various sorts of catalogs. > > Well, i'm not sure if thats helping us here, because the different > resolving/source concepts seem primarly to target resolving one string > url into another string. My aim is to resolve a string source uri and > get an input stream (like it is done by excalibur source resolving or - > in a more simple way - by the > java.net.URL/URLStreamHandler/URLConnection connection classes used by > FOP 0.20.5 in the current implementation). Jeremias Maerki
Re: User configuration for hyphenation
On 08.05.2004 23:04:40 Simon Pepping wrote: > I am trying to enable user configuration of the directory of > hyphenation files, like in the maintenance code. Configuration of the > renderers is easy, because they are instantiated in Fop.main(). But > hyphenation is done deep down in the process, where any reference to > the start-up objects is lost. How can I configure it? > > If I am correct, in the maintenance code the user configuration could > be accessed by a static method, anywhere in the process, just like a > log file in commons logging. I suppose that is not the preferred > way of accessing configuration in HEAD? Indeed. Logging is a special case where static lookup is in order. For the other cases lookup via references is preferred (IMO). > This is the stack frame: > > [1] org.apache.fop.layout.hyphenation.Hyphenator.getHyphenationTree > (Hyphenator.java:67) > [2] org.apache.fop.layout.hyphenation.Hyphenator.hyphenate (Hyphenator.java:232) > [3] org.apache.fop.layoutmgr.LineLayoutManager.getHyphenContext > (LineLayoutManager.java:479) > [4] org.apache.fop.layoutmgr.LineLayoutManager.getNextBreakPoss > (LineLayoutManager.java:228) > [5] org.apache.fop.layoutmgr.BlockLayoutManager.getNextBreakPoss > (BlockLayoutManager.java:204) > [6] org.apache.fop.layoutmgr.FlowLayoutManager.getNextBreakPoss > (FlowLayoutManager.java:79) > [7] org.apache.fop.layoutmgr.PageLayoutManager.getNextBreakPoss > (PageLayoutManager.java:229) > [8] org.apache.fop.layoutmgr.PageLayoutManager.doLayout > (PageLayoutManager.java:194) > > The first two frames are in static context. The LMs share a reference > to a user agent object, of type > layoutmgr.AbstractLayoutManager.userAgent. Would this be the right > object to hold a reference to the user configuration? On first thought, yes. But I feel the scope of the FOUserAgent is still somewhat undefined. Maybe we need to finally settle this issue. Until this is done I consider it safe to hold the user configuration in there. We can change that easily later. Jeremias Maerki
Just do it (was: Re: Borders on Blocks)
Guys, my comment on this is: Commit it if you think it's an improvement. It may be a bit different if it concerned design questions, but with small fixed and improvements I'd rather you guys "just did it". If it turns out to be a mistake it can easily be corrected. That's why we have peer review here. You guys block yourselves with this strategy and Arnd gets even more of a head-start. :-) On 18.05.2004 12:40:07 Chris Bowditch wrote: > It fixes my problem, but I'll wait for any comments before committing this change. Jeremias Maerki (shutting up again)
Re: Applying Large Patches (was Re: Justification and line breaking)
Chris, I've just upgraded my sources and tried to apply the same patch within Eclipse to see what happens. I get two parts of the patch that Eclipse claims to be unable to apply correctly. But this only makes up a few lines in all. Maybe if Luca would send you the whole LineLayoutManager.java, too, you could sort out the rest manually. Eclipse IMO has a very good patch facility. You'd probably get farther that way. On the other side, I've got no idea why the patch doesn't work 100%. Luca seems to have used the latest sources when doing the patch. On 21.05.2004 14:05:29 Chris Bowditch wrote: > FOP Devs, > > I'm trying to apply Luca's patch and running into problems. The hunks in the > first 9/10 files get applied okay, but when the patch program gets to > LineLayoutManager, it only reconises 6 hunks, the seventh is very big and for > some reason the patch program thinks it has found the start of another file > and errors with "File not found. Skip this file [n]: " > > Has anyone else got any experience of working with such large and patches? Any > advice on how to proceed would be appreciated. Jeremias Maerki
Re: Java text handling
There might be a problem: UTA uses JGraphT which is LGPL. FOP cannot depend on LGPL software (Apache licence policy). There is a "graph" subproject inside Jakarta Commons. Maybe this could be used instead of JGraphT. Anyway, how does UTA relate to Luca's recent patch on line breaking? On 21.05.2004 17:27:35 Christian Z. wrote: > My advice: Use UTA and provide a wrapper around the Java font class in > form of a Script [1]. ;-) Jeremias Maerki
Re: ASL 2.0
Clay, our current version 0.20.5 was released under the Apache licence 1.1, so I think the AL 1.1 should stay. (a) would be best but adding a short paragraph at the top of the page explaining the applicability of each licence would be great. Thank you! On 21.05.2004 16:39:04 Clay Leeds wrote: > Howdy folks, > > When doing a minute of research, I noticed that the FOP License page[1] > still references ASL 1.1. Is there anything special we need to do with > that page, or should I just replace it with the contents of ASL 2.0? In > other words, should I: > > a. pre-pend ASL 2.0 (put it at the top) and leave ASL 1.1 to follow? > b. replace ASL 1.1 with ASL 2.0 (ASL 1.1 would no longer be accessible > from that page) > c. rename license.html => license1.1.html and have a new license.html w > ASL 2.0 > d. something else? > > Thanks! > > Web Maestro Clay > > [1] > http://xml.apache.org/fop/license.html Jeremias Maerki
missing karma (was: Re: [Bug 29124] New: - New line breaking algorithm)
Simon, I've just sent a note about that. I hope you (and Clay) will have karma soon. It seems to have been forgotten. I don't think I have the necessary powers to add karma myself. Even if I had I wouldn't know what to do. By now I know a lot about Subversion, but still almost nothing about CVS (on the server). I'm sorry that it went wrong. On 23.05.2004 21:15:12 Simon Pepping wrote: > I would have applied them (as amended by myself) if I would have had > karma. Jeremias Maerki
Re: Fonts
One big problem: As soon as you use SVG, you're running Batik code which makes heavy use of AWT. I think with three different approaches to solve the headless problem this shouldn't be a big issue, even on AIX, right? On 24.05.2004 07:20:05 Clay Leeds wrote: > On the subject of running headless, my experience has been to pass it > off to POSTSCRIPT--which, again in my experience--runs fine headless. > Perhaps something can be 'learned' from that interaction? Maybe instead > of basing the implementation on AWT, it might make sense to base it > instead off of POSTSCRIPT. Alternatively, perhaps Type1 might 'require' > postscript? Dunno... just a thought... Jeremias Maerki
CVS Karma for Simon and Clay...
...should be in place now, thanks to Ted Leung. Jeremias Maerki
Re: SVG Generator
We have it already (to a certain extent)unless I fail to see the point. We have: org.apache.fop.svg.PDFDocumentGraphics2D org.apache.fop.render.ps.PSDocumentGraphics2D org.apache.fop.render.ps.EPSDocumentGraphics2D Of course, it will take some more time to mature but the most important parts are there. I have even added support for multi-page generation in AbstractPSDocumentGraphics2D. Will be easy to add to PDFDocumentGraphics2D. At one point I did a proof-of-concept (not committed) to use the three classes above to create additional output formats for JPS (Java Printing System). One downside I see by using the Graphics2D exclusively is that you will (probably) lose the ability to pass through in-stream objects (JPEGs and SVGs) as-is to the target format. A JPEG will be decoded into a BufferedImage, an SVG will be rendered to a Graphics2D and reencoded as SVG, EPS might not make it into a PS file as-is anymore unless we create a PostScript interpreter (still on my very-long-term wish-list). You guys might want to talk to Hansueli Anderegg who's a fan of the exclusive Java2D approach AFAICS. I'd personally prefer to leave the PDF and PS renderer intact in HEAD for now. No problem with creating a second path and then seeing which is best. On 12.06.2004 13:52:14 Glen Mazza wrote: > > It so happens that the availability of such a > > substitution would be of > > great use to me, because I am constructing the > > layout in Java 2D terms, > > so that I can get it working with minimum agony. > > Yes, but a PDFGraphics2D will take some time to > develop. I'm still with FO objects and layout. We > can keep this open as an idea, at least. Jeremias Maerki
Re: [Fwd: CVS and Subversion]
I use SVN at home and at work. With great success. Command line works great and is very easy and intuitive. TortoiseSVN (Explorer Plug-In for Windows) is also quite nice although on some not quite ordinary operations the thingy seems to do a few things wrong messing up the local working copy from time to time. But that's easily fixed. Even branching is not scary anymore. :-) On 12.06.2004 00:28:58 Clay Leeds wrote: > A very interesting read! Looks like a really nice tool. We may consider > it ourselves in-house, as the infrastructure has some really nice > features! Jeremias Maerki
Re: cvs commit: xml-fop/src/java/org/apache/fop/render/pdf PDFRenderer.java
Chris, please check the settings of your IDE not to allow tab characters. Thanks! On 16.06.2004 23:29:33 jeremias wrote: > jeremias2004/06/16 14:29:33 > > Modified:src/java/org/apache/fop/render/pdf PDFRenderer.java > Log: > Removed illegal tab character > Removed some of the checkstyle warnings while at it. Jeremias Maerki
Re: cvs commit: xml-fop/src/java/org/apache/fop/render/pdf PDFRenderer.java
I see. So please upgrade the files to the lastest version and we others shall upgrade our checkstyle plugins. On 17.06.2004 12:10:52 Chris Bowditch wrote: > Jeremias Maerki wrote: > > > Chris, please check the settings of your IDE not to allow tab characters. > > Thanks! > > Hi Jeremias, > > I cant simply turn off Tabs as I need them for my paid work! I would like to > be able to run checkstyle to check for this sort of mistake, but have run into > some problems with it. > > It seems our config files were originally written for 2.4, with a > checkstyle-3.1.1-Head file being provided in CVS for 3.x versions. However, I > could only find 3.4 available for download anywhere, and the config file > layout seems to have changed again since 3.1. > > If no one knows where I can download either 2.4 or 3.1, then I will have to > read up and find a way to convert our config file to the new XML format. Jeremias Maerki
Re: Offline
Peter, same wishes from warm and sunny Lucerne, Switzerland! Have a good time! On 17.06.2004 15:53:29 Clay Leeds wrote: > Mr. West, > > On Jun 17, 2004, at 6:06 AM, Peter B. West wrote: > > Fopfellows, > > > > I will be offline for the next week. I'm marrying Jenni tomorrow, and > > honeymooning in the frozen south of the South Island of New Zealand for > > a week. I'll post some photos to my web site when I get back. > > > > Peter > > -- > > Peter B. West <http://www.powerup.com.au/~pbwest/resume.html> > > Many happy congratulations to you and Jenni! Going to the frozen south, > huh!? Sounds like a good place to get cozy! Looking forward to pics > when you return... > > Web Maestro Clay Jeremias Maerki
[PROPOSAL] Finally creating the XML Graphics PMC....
Hi everyone, Berin thankfully pushed again and I'm taking the time for another round. Considering what I think is the general opinion, here's what I propose: 1. We create that XML Graphics PMC taking Batik and FOP under the new umbrella. I hope I don't have to explain again that nothing will change for our users. We will still use the XML project's infrastructure. 2. We will take Batik in even though the patient is in a suboptimal condition ATM. The PMC to-be-formed agrees to keep an eye on the project and help if any potential new committer bubbles up. When Batik's life energies come up to healthy levels again it shall be more strongly represented in the PMC as people come available. 3. I propose the following FOP people for the minimal initial PMC: Peter B. West, Jörg Pietschmann, Glen Mazza. I'd also propose at least some of the more junior committers but I don't know how anyone feels about that. Please propose any additional candidates as you see fit. I don't propose myself but I'm available if anyone proposes me. 4. I propose both Vincent Hardy and Thomas DeWeese from the Batik project as PMC members. I'd appreciate if at least one of the two accepted even if you can't actively participate in the development. You know it isn't much to do but it's important to have at least someone on board. I'll update the board resolution draft and set up a charter draft during the next few days (also peeking at the other works). The proposed PMC members are kindly invited to indicate whether they would be available for the post. Votes of support are requested for the nominations. If anyone is against this proposal (or parts of it) please speak up. We need to get this done. I appreciate any kind of help I can get. Jeremias Maerki
