Using the attached ppt, I am reading it in and then writing it back out as a different file. The following message is displayed =========================== Couldn't find the new location of the "slide" with id 299 that used to be at 13418 Not updating the position of it, you probably won't be able to find it any more (if you ever could!) =========================== To read file in. SlideShow ppt = null; ppt = new SlideShow(new HSLFSlideShow("c:\\files\nh.ppt")); To write file back out. FileOutputStream fos = new FileOutputStream("c:\\files\\njh.ppt"); ppt.write(fos); fos.close(); The ppt that is being read in (nh.ppt), use to be a much larger ppt which I have trimmed down for the purposes of development and testing. The subsegment file cannot be opened in Powerpoint. The ppt has a single master slide (with title master) and three presentation slides. Is it likely that there are references to some of the deleted slides in the presentation hanging around. I am using a version of POI that I compiled myself from source downloaded from the subversion repository. Nick.
The URL to a ppt file with this issue is http://www.nickhavard.talktalk.net/broken.ppt Tried to upload it, but it was too large.
Fixed. It was another issue with org.apache.poi.ddf.EscherArrayProperty. (We already had issues with it, see Bug 39800). In PPT it is legal to have empty complex part of an array property. When reading such a property, remember it and write back the same empty data. Although the fix is simple I spent a lot of time trying to cover all sorts of special cases in xls and ppt. Truly, the Escher arrays are the most weird constructions ever intended :). P.S. I moved the warning messages to POILogger. If users want verbose output they should enable it through -Dorg.apache.poi.util.POILogger option. For example to use System.out set it as follows: -Dorg.apache.poi.util.POILogger=org.apache.poi.util.SystemOutLogger Regards, Yegor
Hi The bug that you referenced appears to be some 9 months old and fixed back then. However I was getting the issue with a set of self compiled jars. Has any fix been made to solve the issue that I was having? I don't understand the bit about the logger. Withinh my application I am using log4j. Can I set the POI logger to write its output to that? If so how? Thanks for your help with this. Nick.
Hi, >The bug that you referenced appears to be some 9 months old and fixed back then. >>However I was getting the issue with a set of self compiled jars. >Has any fix been made to solve the issue that I was having? Drawing properties are full of special cases. Nick fixed one in bug 39800. Your issue is another special case, the fix in 39800 does not work for it. Hopefully I fixed it. >I don't understand the bit about the logger. Withinh my application I am using >log4j. Can I set the POI logger to write its output to that? If so how? If you want to still see messages in System.out just set -Dorg.apache.poi.util.POILogger as described. If you want to redirect it to Log4j you need to write an adapter. See org.apache.poi.util.CommonsLogger for an example. I think it would be nice to have ready-to-use log4j adapter in POI, if you wish to contribute it - welcome! Regards, Yegor
Hi I've just download a fresh copy of source and recompiled. I am now able to append sheets to the original documents that were giving me a problem. Many thanks for sorting this out. I'm marking the bug as closed. Nick. P.S. Would love to do the log4j piece, but I wouldn't even know where to start.
>Many thanks for sorting this out. I'm marking the bug as closed. Welcome :) >P.S. Would love to do the log4j piece, but I wouldn't even know where to start. I think you just need to follow the pattern in org.apache.poi.util.CommonsLogger. This class redirects log calls to the apache commons logging framework. You need the same but log4j instead of commons. P.S. I think I rushed a bit with the idea to add log4j adapter to POI. It would mean adding log4j.jar to the compilation process and it another dependency, etc. Yegor
Hi In the version of the code that I have downloaded to recompile the classes, it appears that the issue I reported a couple of weeks ago about the 133% scaling has been "unfixed". See this link for a reminder. http://www.nabble.com/HSLF---Adding-Picture-is-133--of-actual-size-tf3492107.html As you fixed that for me, can you check if something has been reversed out. Thanks for your help. Nick.