Hi, I am generating a ppt from an existing template ppt file using XSLF. Here, I have a table and I update cells with the content dynamically and add/delete rows accordingly. I was trying to find the height of a cell/row so that I can find out how many rows can be accommodated in the table without overflowing the slide area. So if a row cannot be accommodated, a new slide will be created. But when I was trying to access cell.getTextHeight() or cell.getLineWidth(), I am getting the below exception. java.lang.IllegalStateException: CTShapeProperties was not found. at org.apache.poi.xslf.usermodel.XSLFShape.getSpPr(XSLFShape.java:240) at org.apache.poi.xslf.usermodel.XSLFSimpleShape$1.fetch(XSLFSimpleShape.java:113) at org.apache.poi.xslf.usermodel.XSLFShape.fetchShapeProperty(XSLFShape.java:320) at org.apache.poi.xslf.usermodel.XSLFSimpleShape.getXfrm(XSLFSimpleShape.java:121) at org.apache.poi.xslf.usermodel.XSLFSimpleShape.getAnchor(XSLFSimpleShape.java:128) at org.apache.poi.sl.draw.DrawShape.getAnchor(DrawShape.java:142) at org.apache.poi.sl.draw.DrawTextParagraph.getWrappingWidth(DrawTextParagraph.java:399) at org.apache.poi.sl.draw.DrawTextParagraph.breakText(DrawTextParagraph.java:240) at org.apache.poi.sl.draw.DrawTextShape.drawParagraphs(DrawTextShape.java:134) at org.apache.poi.sl.draw.DrawTextShape.getTextHeight(DrawTextShape.java:195) at org.apache.poi.sl.draw.DrawTextShape.getTextHeight(DrawTextShape.java:177) at org.apache.poi.xslf.usermodel.XSLFTextShape.getTextHeight(XSLFTextShape.java:536) ...... Please let me know if this is a bug or is implemented like that. And how can we find the dynamic height of a cell/row. Thanks, Preetam
Thanks for bringing this up - fixed with r1747605 So getTextHeight() didn't crash on my test, but getLineWidth() did. Just recently I've implemented the rendering of xslf tables. One of the methods where were necessary is XSLFTable.updateCellAnchor() which calculates the positions of the cells and their anchors. This method is triggered, when you call XSLFTableCell.getAnchor() the first time ... maybe this info is useful to you.
(In reply to Andreas Beeker from comment #1) > Thanks for bringing this up - fixed with r1747605 > > So getTextHeight() didn't crash on my test, but getLineWidth() did. > Just recently I've implemented the rendering of xslf tables. > One of the methods where were necessary is XSLFTable.updateCellAnchor() > which calculates the positions of the cells and their anchors. > This method is triggered, when you call XSLFTableCell.getAnchor() the first > time ... maybe this info is useful to you. The unit test TestXSLFTable.checkTextHeight() fails when run from the build.xml test target on Windows - the height returned on my system was 91.890625, not 88 as the test expects. There are many factors that could be at play when calculating rendering measurements, especially on Windows. For example, I typically use a non-standard system font and scaling factor (I like my default text small). Could this test instead check that the method returns a value in a reasonable range, or doesn't throw an exception? This spurious failure makes it hard to test changes before I submit patches. Yes, I'm stuck using Windows. Talk to my boss if you want about getting me a Mac :)
> Could this test instead check that the method returns a value in a reasonable range, or doesn't throw an exception? This spurious failure makes it hard to test changes before I submit patches. I have to admit that I haven't payed attention about the font issue, only that getTextHeight() worked at all and after it ran on my Windows machine and the ubuntu Jenkins instances I didn't care about it ... (well actually this is not completely true, as I did a lot of test while developing the table rendering. It is still not perfect, i.e. the fonts are to big, but I couldn't yet nail the error ...) So if you work on XSLFTables handling - patch it and submit your patch. If you work on something else - add @Ignore I'll change it to your suggestion soon anyways. Andi
> If you work on something else - add @Ignore > I'll change it to your suggestion soon anyways. > > Andi Thanks. "Soon" is good enough for my purposes. I'm working on XSSF stuff now, I can ignore this test for now. Every now and then Java isn't completely cross-platorm, and fonts are one of those areas.
fixed font issue via r1747803