In some cases RichTextRun returns wrong style attributes. Run the following fragment against the attached file and see that the font size is wrong. RichTextRun says the size is 7 and it is wrong. Slide[] slide = ppt.getSlides(); for (int i = 0; i < slide.length; i++) { TextRun[] txrun = slide[i].getTextRuns(); for (int j = 0; j < txrun.length; j++) { TextRun run = txrun[j]; RichTextRun[] rtf = run.getRichTextRuns(); for (int k = 0; k < rtf.length; k++) { System.out.println(rtf[k].getRawText() + ": " + rtf[k].getFontSize()); } } }
Created attachment 18664 [details] file for testing
Fixed. There are three bugs I had to fix: (1) Bug in StyleTextPropAtom. The rule is that sum(length) for paragraph and character style runs must be text.length + 1. It was true only for character styles. I had to add the symmetrical code to the paragraph block. See the change in StyleTextPropAtom.setParentTextSize I added a warning if this rule is broken and it helped me to discover two more bugs: (2) The data setup for data_a and data_c in TestStyleTextPropAtom was wrong. What we had for data_a: /** From a real file: a paragraph with 4 different styles */ private byte[] data_a = new byte[] { 0, 0, 0xA1-256, 0x0F, 0x2A, 0, 0, 0, 0x36, 00, 00, 00, // paragraph is 54 long 00, 00, // (paragraph reserved field) 00, 00, 00, 00, // it doesn't have any styles 0x15, 00, 00, 00, // first char run is 21 long 00, 00, 00, 00, // it doesn't have any styles 0x11, 00, 00, 00, // second char run is 17 long 00, 00, 0x04, 00, // font.color only 00, 00, 00, 0x05, // blue 0x10, 00, 00, 00, // third char run is 16 long 00, 00, 0x04, 00, // font.color only 0xFF-256, 0x33, 00, 0xFE-256 // red }; private int data_a_text_len = 54; The value passed to StyleTextPropAtom.setParentTextSize is the text length. If we read the corresponding style record we should get text.length + 1 chars covered. It means that actual text length is 54-1. The same stuff is with data_c. The text length is 123-1. (3) When we construct a new style record we need to pass text.length+1 to the constructor. See the change in TextRun.ensureStyleAtomPresent. With these changes everything works fine. Regards, Yegor
Created attachment 19385 [details] the patch
I hope we don't have any more bugs with the style record. I would like to refactor the code as we discussed some time ago: move TextPropCollection and TextProp out of StyleTextPropAtom, try to integrate it with TxMasterStyleAtom, etc. Yegor
Created attachment 19393 [details] returns 0 for the font.size I applied the patch with the fix of this bug, but the same problem still happens. The font.size value returned is wrong (almost always, it returns 0). I tested the file test2 and this I'm uploading and I have more two files with the same problem.
Bah, that code hurt my head enough when it was written the first time... I've committed your code (hopefully infra will do your account soon!). Glad you managed to track the bug down :) I agree we should split out the TextPropCollection and TextProp stuff, probably into model. I suspect we'll want two sub classes, one for the slide style definitions, and one for the master definitions. Should be cleaner code then.
Tales - could you let us know which data you would expect from your test file, so we can turn it into a (failing) test to work against?
The file I attached (returns 0 for the font.size) has one text box with font size 20. This is the value I expected, but RichTextRun.getFontSize() returns 0. Running with the file previously attached, the values returned were correct.
Created attachment 19398 [details] the patch which fixed the order of properties in StyleTextPropAtom I think it is the final touch. The order in which properties are read in StyleTextPropAtom is NOT defined by the property mask value. I had suspects it is so but coudn't confirm it. Tales, thank you for the attached ppt. What I changed: - The order of property definitions in StyleTextPropAtom - added StyleTextPropAtom.toStirng() . It's handy for debugging. - Included the test data into TestStyleTextPropAtom. Yegor
Patch applied, cheers for that Yegor Did you find some method to the madness of the ordering of the TextProps, or was it just trial and error? Tales - Hopefully this fixes your problem, but shout if there's still more we need to sort.
>>Did you find some method to the madness of the ordering of the TextProps, or was >>it just trial and error? No, I gave up searching for intelligence in style records :). I found the fix mostly by trial and error - debugged and saw that the font size resides in a wrong property. Made more tests , swapped some props and voila! Yegor