Re: Remove Useless Comments
Dear Fop-devs, as always, I have no say in this, but what I usually do is to use /** [EMAIL PROTECTED] */ This works really well, if the method inherits from a class / interface which is also present in the same codebase: Checkstyle is happy, and so is JavaDoc. Also, JavaDoc gives a warning if a method uses inheritDoc, but does not implement / override a method (a way of detecting renames in superclasses) For some more discussion on this matter, see [1] [1] http://mail-archives.apache.org/mod_mbox/jackrabbit-dev/200503.mbox/[EMAIL PROTECTED] hth Max Vincent Hennebert schrieb: > Hi, > > Nothing related with (and against) the original change, but I take this > one as an opportunity to launch the discussion. I've been having this in > my head for a while. > >> - /** @see org.apache.fop.layoutmgr.LayoutManager#initialize() */ >> +/** @see org.apache.fop.layoutmgr.LayoutManager#initialize() */ > > I'd like to suggest to remove such comments every time there's an > opportunity. They are useless for javadoc which is able to retrieve the > comment from the redefined method. They are painful when discovering > code in Eclipse because when we hover a method call, we get that comment > instead of the real one, which Eclipse also is able to retrieve. > > The only reason I can think of for such a comment is to make checkstyle > happy. But I don't think this is a solution. Checkstyle should be aware > that in Java redefined methods inherit their javadoc from the original > one, and shouldn't complain in this case. So here it's checkstyle that > is wrong. > > Anyway, there are already zillions of checkstyle warnings in the current > codebase, so I guess we can live with a few more. > > > WDYT? > Vincent signature.asc Description: OpenPGP digital signature
Plan for the 0.94 release
Hi all, I'll soon start the release process for XML Graphics Commons. There's not much to do there, apart from updating the website content. Meanwhile I'd like to enter some kind of freezing phase in the FOP area. That is, mainly, avoid to perform too big changes which might introduce instabilities in the code. I propose the following plan: - make a list of patches/bugs that we would like to apply/fix before releasing. Here everyone can help, even non-committers ;-) Once the list is done we will see how many of them we can handle. - refactor the website according to Chris' recent suggestions. That requires some writing skills and a minimal knowledge of Cocoon/Forrest and I'd be /very/ grateful for any help in this area... - once Commons is released we can start the process for FOP I'll create the branch very soon, as it's probably best to perform the website refactoring in it. Once it's done we will have to be careful when committing changes. I suggest to perform code changes on Trunk only and merge in the 0.94 branch if applicable; and make website changes in the branch only, that I'll merge back into Trunk once the release is out. Speaking of branches, I noticed that there are many (very) old branches on Subversion. What about removing them? Some cleanup wouldn't hurt, they won't be completely lost anyway as it will still be possible to retrieve them from earlier revisions, and the corresponding tags would remain. The candidates for removal are: - FOP_0-20-0_Alt-Design/ - FOP_0-20-4Pre_BuildExp_pbw/ - Temp_API_Finalization/ - Temp_KnuthStylePageBreaking/ - Temp_SpaceResolution/ - dirkx/ < what is this one?? - fop-0_14_0/ - fop-0_14_0_regions/ - fop-0_17_0_batikSVG/ - fop-0_20_2-maintain/ - fop-0_90/ - fop-0_91/ - fop-0_92/ - fop-0_93/ - foray-font/ - release-0-13-0/ Some time ago we discussed about abandoning support for Java 1.3. Since then I forgot to launch the poll on fop-user. I guess this will have to be postponed and 1.3 archives will be provided for 0.94. I think that's all for now. Thanks, Vincent
Re: Remove Useless Comments
Yes, inheritDoc would be the right way, as long as we're on Java 1.4.2 and later (feature not available in 1.3, severly buggy in 1.4.0/1.4.1. I would have switched a long time ago if we weren't still on 1.3. On 13.07.2007 15:49:58 Max Berger wrote: > Dear Fop-devs, > > as always, I have no say in this, but what I usually do is to use > > /** [EMAIL PROTECTED] */ > > This works really well, if the method inherits from a class / interface > which is also present in the same codebase: Checkstyle is happy, and so > is JavaDoc. Also, JavaDoc gives a warning if a method uses inheritDoc, > but does not implement / override a method (a way of detecting renames > in superclasses) > > For some more discussion on this matter, see [1] > > [1] > http://mail-archives.apache.org/mod_mbox/jackrabbit-dev/200503.mbox/[EMAIL > PROTECTED] > > hth > > Max > > Vincent Hennebert schrieb: > > Hi, > > > > Nothing related with (and against) the original change, but I take this > > one as an opportunity to launch the discussion. I've been having this in > > my head for a while. > > > >> - /** @see org.apache.fop.layoutmgr.LayoutManager#initialize() */ > >> +/** @see org.apache.fop.layoutmgr.LayoutManager#initialize() */ > > > > I'd like to suggest to remove such comments every time there's an > > opportunity. They are useless for javadoc which is able to retrieve the > > comment from the redefined method. They are painful when discovering > > code in Eclipse because when we hover a method call, we get that comment > > instead of the real one, which Eclipse also is able to retrieve. > > > > The only reason I can think of for such a comment is to make checkstyle > > happy. But I don't think this is a solution. Checkstyle should be aware > > that in Java redefined methods inherit their javadoc from the original > > one, and shouldn't complain in this case. So here it's checkstyle that > > is wrong. > > > > Anyway, there are already zillions of checkstyle warnings in the current > > codebase, so I guess we can live with a few more. > > > > > > WDYT? > > Vincent > > > Jeremias Maerki
Re: Plan for the 0.94 release
On 13.07.2007 15:45:01 Vincent Hennebert wrote: > Speaking of branches, I noticed that there are many (very) old branches > on Subversion. What about removing them? -1. If you want to clean up, please create a subdirectory "old-tags" (or similar) and move the old tags there. If you just delete them, it is too difficult to access them anymore (provided you still know at which point in time they existed). Sorry for just a short message. Optimizing available time... Jeremias Maerki
Re: Severe : Exception. Cannot Load Font. No font URI's available.
Andreas L Delmelle wrote: As far as I can judge, /if/ the names of embedded fonts forcibly need to be altered because they would be overridden by local fonts in the PDF viewer, then it could turn out to be pretty simple --for someone who knows what he's doing :/ Leave the font-family name alone, and modify related classes in org.apache.fop.pdf to skip the step of actually embedding the font, if the configuration did not specify an embed-uri. I envisage a minor problem with omitting the embed-url. Currently FOP uses that to generate metrics on the fly. So it seems Font Referencing and auto metrics generation are mutually exclusive :-/ What we need is to be able to change the attributes on font element, so that there is an explicit attribute that specifies whether embedding is on/off instead of overloading embed-url to do 2 functions. Something like this: Although changing configuration files in a backwards incompatible way is not likely to be popular with the users! Chris
Remove Useless Comments [Re: svn commit: r555684 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/LineLayoutManager.java]
Hi, Nothing related with (and against) the original change, but I take this one as an opportunity to launch the discussion. I've been having this in my head for a while. > Modified: > > xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/LineLayoutManager.java > > Modified: > xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/LineLayoutManager.java > URL: > http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/LineLayoutManager.java?view=diff&rev=555684&r1=555683&r2=555684 > == > --- > xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/LineLayoutManager.java > (original) > +++ > xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/LineLayoutManager.java > Thu Jul 12 09:24:27 2007 > @@ -84,7 +84,7 @@ > private Block fobj; > private boolean isFirstInBlock; > > - /** @see org.apache.fop.layoutmgr.LayoutManager#initialize() */ > +/** @see org.apache.fop.layoutmgr.LayoutManager#initialize() */ I'd like to suggest to remove such comments every time there's an opportunity. They are useless for javadoc which is able to retrieve the comment from the redefined method. They are painful when discovering code in Eclipse because when we hover a method call, we get that comment instead of the real one, which Eclipse also is able to retrieve. The only reason I can think of for such a comment is to make checkstyle happy. But I don't think this is a solution. Checkstyle should be aware that in Java redefined methods inherit their javadoc from the original one, and shouldn't complain in this case. So here it's checkstyle that is wrong. Anyway, there are already zillions of checkstyle warnings in the current codebase, so I guess we can live with a few more. WDYT? Vincent
Re: Severe : Exception. Cannot Load Font. No font URI's available.
Just some details on what is currently possible and what not (for PDF output): Type 1: embedded or referenced, WinAnsi only TrueType: - embedded subset, CID (default mode) - embedded WinAnsi (full font is embedded 1:1, no subset) - referenced WinAnsi (works, but is restricted to WinAnsi) - referenced subset, CID (no errors by FOP, but Acrobat throws errors) One thing that might be worth investigating is referencing a font and using Unicode characters directly (i.e. not the subset mode). I think that should be possible. I think the embed="false" setting could be interesting, especially for PostScript output where you usually have the fonts installed on the target printer so you can make smaller print files. For PDF, this is only interesting for closed environments where you have full control over the installed fonts on every system. I don't think we need to change embed-url just now. If there's a better name for specifying the main font file (not all fonts have just one font file), then we can always support both for a longer period, right? On 13.07.2007 16:04:59 Chris Bowditch wrote: > Andreas L Delmelle wrote: > > > > > As far as I can judge, /if/ the names of embedded fonts forcibly need > > to be altered because they would be overridden by local fonts in the > > PDF viewer, then it could turn out to be pretty simple --for someone > > who knows what he's doing :/ > > Leave the font-family name alone, and modify related classes in > > org.apache.fop.pdf to skip the step of actually embedding the font, if > > the configuration did not specify an embed-uri. > > I envisage a minor problem with omitting the embed-url. Currently FOP > uses that to generate metrics on the fly. So it seems Font Referencing > and auto metrics generation are mutually exclusive :-/ > > What we need is to be able to change the attributes on font element, so > that there is an explicit attribute that specifies whether embedding is > on/off instead of overloading embed-url to do 2 functions. Something > like this: > > > > Although changing configuration files in a backwards incompatible way is > not likely to be popular with the users! > > Chris > Jeremias Maerki
Re: Plan for the 0.94 release
Jeremias Maerki a écrit : > On 13.07.2007 15:45:01 Vincent Hennebert wrote: > >> Speaking of branches, I noticed that there are many (very) old branches >> on Subversion. What about removing them? > > -1. If you want to clean up, please create a subdirectory "old-tags" (or > similar) and move the old tags there. If you just delete them, it is too > difficult to access them anymore (provided you still know at which point > in time they existed). Well I was talking of branches and not tags. I can understand that this may be a pain to retrieve old tags, but old branches really seem to not be useful anymore. Moreover most of them can be retrieved from their corresponding tags. Vincent
Re: Remove Useless Comments [Re: svn commit: r555684 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/LineLayoutManager.java]
On Jul 13, 2007, at 12:09, Vincent Hennebert wrote: Nothing related with (and against) the original change, but I take this one as an opportunity to launch the discussion. I've been having this in my head for a while. Yes, I seem to remember the point being raised earlier... and to be honest, I don't really see the use either. It's just (very understandable ;)) laziness, I guess: add one * to Eclipse's default comment when adding an override, and you get precisely that pseudo- javadoc. Cheers Andreas
Incrementing a number using XSL-FOP
Hi Guys, This is a newbie question. I have an XSL which reads in some of value from xml using Document() function and some some . I'm using to display the content in a block. Simply what I want to do is create a counter that will increment for my each i.e. etc. Please help? - I've tried the below code but it doesn't work: - this return 1 instead of 2 -- View this message in context: http://www.nabble.com/Incrementing-a-number-using-XSL-FOP-tf4075497.html#a11582915 Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: Plan for the 0.94 release
On Jul 13, 2007, at 15:45, Vincent Hennebert wrote: Hi Vincent I'll soon start the release process for XML Graphics Commons. There's not much to do there, apart from updating the website content. Meanwhile I'd like to enter some kind of freezing phase in the FOP area. That is, mainly, avoid to perform too big changes which might introduce instabilities in the code. Agreed. I propose the following plan: - make a list of patches/bugs that we would like to apply/fix before releasing. Here everyone can help, even non-committers ;-) Once the list is done we will see how many of them we can handle. Shall I post a little survey mail on fop-users? Maybe it's good to know for them as well about the upcoming release... - refactor the website according to Chris' recent suggestions. That requires some writing skills and a minimal knowledge of Cocoon/ Forrest and I'd be /very/ grateful for any help in this area... - once Commons is released we can start the process for FOP I'll create the branch very soon, as it's probably best to perform the website refactoring in it. Once it's done we will have to be careful when committing changes. I suggest to perform code changes on Trunk only and merge in the 0.94 branch if applicable; and make website changes in the branch only, that I'll merge back into Trunk once the release is out. +1 Speaking of branches, I noticed that there are many (very) old branches on Subversion. What about removing them? Some cleanup wouldn't hurt, No explicit opinion here. Some time ago we discussed about abandoning support for Java 1.3. Since then I forgot to launch the poll on fop-user. I guess this will have to be postponed and 1.3 archives will be provided for 0.94. Not necessarily, IMO. Now may just be a good time to start dropping support for 1.3, precisely by not releasing new binaries anymore. Users will be warned that with the sources, a 1.3 build is still possible, but they would have to do it on their own. After the release, we can then gradually start dropping support for 1.3 in the code as well, and clean up some there too. For you, this means less work with building the release-binaries :-) Only a few extra lines of caution in the announce mail. Cheers Andreas
Re: Severe : Exception. Cannot Load Font. No font URI's available.
Chris Bowditch wrote: Although changing configuration files in a backwards incompatible way is not likely to be popular with the users! Given that not embedding fonts never really worked (except for fonts specifically installed using the Acrobat font manager), there is not really an incompatibility. J.Pietschmann
Re: Remove Useless Comments
Jeremias Maerki wrote: Yes, inheritDoc would be the right way, as long as we're on Java 1.4.2 and later (feature not available in 1.3, severly buggy in 1.4.0/1.4.1. I would have switched a long time ago if we weren't still on 1.3. I think of JavaDoc as a sort of compile time feature. I don't think there's still a reason to generate the JavaDocs with a JDK version older than 1.5. It's the byte code which should run in an 1.3 environment, not the HTML'd docs. J.Pietschmann
