Re: New year - update copyright years
Glen Mazza wrote:
{Sigh.} Jeremias, you are so particular--anyway,
Peter, will you please give Jeremias said greeting so
he can proceed?
Thanks,
Glen
--- Jeremias Maerki [EMAIL PROTECTED] wrote:
I've
got a script from Thomas to do that but I need a
good day to do that. :-)
Wish list:
G'day Jeremias.
I hope it works.
Peter
Re: New year - update copyright years
I've updated the copyright years for http://xml.apache.org/fop/ but I noticed a different glitch in my xmlgraphics logo. It says xmlgraphics, but it shows xml.apache.org/ (ahem! now who can I blame this on? ;-)). Anyway, I'll fix that little one soon... Also, the Group link is still to Apache XML Project and I need to change that to Apache XML Graphics Project. Speaking of which I think it makes sense that links to http://xmlgraphics.apache.org/fop/ be re-directed to http://xml.apache.org/fop/ (and the same for /batik/). Are there any objections to my making this *low* priority request to [EMAIL PROTECTED] On Jan 4, 2005, at 9:57 AM, Web Maestro Clay wrote: I'll take care of the web pages when I upload the site... On Jan 4, 2005, at 12:44 AM, Jeremias Maerki wrote: People, we have a new year again, so don't forget to update the copyright years if you change a file. snip Jeremias Maerki Web Maestro Clay -- [EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet
Re: New year - update copyright years
At Jeremias' suggestion, I've added .htaccess files at http://xmlgraphics.apache.org/fop/ http://xmlgraphics.apache.org/batik/ so they re-direct to http://xml.apache.org/fop http://xml.apache.org/batik/ (thanks for the suggestion, Jeremias! It's always nice to save a bit of work for the infr@ folks! I'll get on the graphic issue shortly. Web Maestro Clay On Wed, 5 Jan 2005 07:54:57 -0800, The Web Maestro [EMAIL PROTECTED] wrote: I've updated the copyright years for http://xml.apache.org/fop/ but I noticed a different glitch in my xmlgraphics logo. It says xmlgraphics, but it shows xml.apache.org/ (ahem! now who can I blame this on? ;-)). Anyway, I'll fix that little one soon... Also, the Group link is still to Apache XML Project and I need to change that to Apache XML Graphics Project. Speaking of which I think it makes sense that links to http://xmlgraphics.apache.org/fop/ be re-directed to http://xml.apache.org/fop/ (and the same for /batik/). Are there any objections to my making this *low* priority request to [EMAIL PROTECTED] On Jan 4, 2005, at 9:57 AM, Web Maestro Clay wrote: I'll take care of the web pages when I upload the site... On Jan 4, 2005, at 12:44 AM, Jeremias Maerki wrote: People, we have a new year again, so don't forget to update the copyright years if you change a file. snip Jeremias Maerki Web Maestro Clay -- [EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet
Re: cvs commit: xml-fop/src/java/org/apache/fop/datatypes LengthBase.java
On Mon, Jan 03, 2005 at 02:20:25PM +0100, Jeremias Maerki wrote: I'm trying to understand what's going on here. One thing that strikes me as odd is that PropertyList.convertAttributeToProperty() always contructs Properties based on the parentFO. Normally, this is probably ok since most calculation bases are the parent FOs but in the case of content-width/height it's the context FO itself that provides the base (the intrinsic image size). PropertyList.convertAttributeToProperty() calls prop = propertyMaker.make(this, attributeValue, parentFO). If I remember correctly, the parentFO is only used if the attribute value is 'inherit'. Otherwise it converts the attribute value into a property value object. See my description in http://www.leverkruid.nl/FOP/html/ch09s02.html. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: fo.InlineLevel -- make abstract?
I agree as well. Regards, Simon On Tue, Jan 04, 2005 at 09:39:14AM +0100, Jeremias Maerki wrote: I think, you are right. They should be abstract. On 04.01.2005 00:47:29 Glen Mazza wrote: Any problem with making fo.InlineLevel an abstract class? Any reason why you made it instantiable--or was this just an oversight? (Actually, anyone know why we're not making FObj and FObjMixed abstract as well? I might be missing something here...) Jeremias Maerki -- Simon Pepping home page: http://www.leverkruid.nl
[RT] FOP RTF edition
(RT means random thought and this is something the Cocoon people do a lot.) FOP's layout engine is clearly not ready to be released, yet. We're working on that. Another part is the RTF output (formerly JFOR) which is practically independant of the layout engine. Over the past few months there were smaller improvements in that part and I'd say, that it's ready to be unleashed to the public so people can experiment. It's not that it's beta quality or feature-complete or anything. I simply think that part is usable and only takes little improvement until people can produce simple documents in RTF format. I'd like to test the waters and see what you guys think about separately releasing the RTF part, or in other words: FOP RTF edition. It might be a good sign to our users that our project's not dead. I understand that it would take some manpower to prepare such a release. I also understand that it may send false signals that may make people think that they can expect PDF output, too. So I'm not sure if I should push this just yet, but I'd like to hear what you guys think. Things that would need to be done: - What API for that part? Are we comfortable with our current API? - Clearly define the parts which make a FOP RTF edition. - Extend the build accordingly. - Some more tests. - Documentation update. - Release process. Jeremias Maerki
Re: [RT] FOP RTF edition
--- Jeremias Maerki [EMAIL PROTECTED] wrote: I'd like to test the waters and see what you guys think about separately releasing the RTF part, or in other words: FOP RTF edition. My $0.02: Looks like busywork--I don't see how this would help you or any other committer. I would be concerned about burdening current committers with this work, as well as scaring away prospective ones. The deep thinkers that are needed to get layout et al done are generally not attracted to the mundane tasks that a FOP RTF would require. It might be a good sign to our users that our project's not dead. Even if some think that way now, they'll come back when it's done. Glen
Re: Implementing text-decoration
I looked at the code and I can't see anything wrong with your suggestion. Unfortunately I'm far from an expert in this area of the code. Glen --- Jeremias Maerki [EMAIL PROTECTED] wrote: I'm currently looking at implementing text-decoration. ATM it's specified as an EnumProperty but should be more like a set of enums with certain validation rules applied. I'm unsure about the approach. If anyone already has an idea how it should look like I'd appreciate any insight. My first idea was to implement a special property class (TextDecorationProperty) that handles the conversion of a ListProperty of NCNames to an internal set of variables while at the same time validating the enum combinations. I think my approach would work even if it look a bit awkward. But I wanted to check first so I didn't implement something really ugly. Jeremias Maerki
Re: fo.InlineLevel -- make abstract?
Done. Thanks both for the quick response. Glen --- Simon Pepping [EMAIL PROTECTED] wrote: I agree as well. Regards, Simon On Tue, Jan 04, 2005 at 09:39:14AM +0100, Jeremias Maerki wrote: I think, you are right. They should be abstract. On 04.01.2005 00:47:29 Glen Mazza wrote: Any problem with making fo.InlineLevel an abstract class? Any reason why you made it instantiable--or was this just an oversight? (Actually, anyone know why we're not making FObj and FObjMixed abstract as well? I might be missing something here...) Jeremias Maerki -- Simon Pepping home page: http://www.leverkruid.nl
DO NOT REPLY [Bug 5221] - Image loading can hang forever
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=5221. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=5221 --- Additional Comments From [EMAIL PROTECTED] 2003-08-27 01:22 --- [new account, please ignore] -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
