Bug 40143 - HSLF: RichTextRun returns wrong style attributes
Summary: HSLF: RichTextRun returns wrong style attributes
Alias: None
Product: POI
Classification: Unclassified
Component: HSLF (show other bugs)
Version: unspecified
Hardware: Other other
: P2 normal with 1 vote (vote)
Target Milestone: ---
Assignee: POI Developers List
Depends on:
Reported: 2006-07-31 14:03 UTC by Yegor Kozlov
Modified: 2007-01-16 05:12 UTC (History)
0 users

file for testing (12.50 KB, application/vnd.ms-powerpoint)
2006-07-31 14:03 UTC, Yegor Kozlov
the patch (3.42 KB, patch)
2007-01-10 06:10 UTC, Yegor Kozlov
Details | Diff
returns 0 for the font.size (228.50 KB, application/vnd.ms-powerpoint)
2007-01-11 08:07 UTC, Tales Paiva
the patch which fixed the order of properties in StyleTextPropAtom (6.25 KB, patch)
2007-01-12 01:24 UTC, Yegor Kozlov
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Yegor Kozlov 2006-07-31 14:03:12 UTC
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() + ": " +

Comment 1 Yegor Kozlov 2006-07-31 14:03:39 UTC
Created attachment 18664 [details]
file for testing
Comment 2 Yegor Kozlov 2007-01-10 06:09:05 UTC

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
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
See the change in TextRun.ensureStyleAtomPresent. 

With these changes everything works fine.

Comment 3 Yegor Kozlov 2007-01-10 06:10:45 UTC
Created attachment 19385 [details]
the patch
Comment 4 Yegor Kozlov 2007-01-10 06:14:04 UTC
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.

Comment 5 Tales Paiva 2007-01-11 08:07:25 UTC
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.
Comment 6 Nick Burch 2007-01-11 08:21:23 UTC
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.
Comment 7 Nick Burch 2007-01-11 08:22:43 UTC
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?
Comment 8 Tales Paiva 2007-01-11 08:36:21 UTC
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.
Comment 9 Yegor Kozlov 2007-01-12 01:24:22 UTC
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.

Comment 10 Nick Burch 2007-01-15 07:24:57 UTC
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.
Comment 11 Yegor Kozlov 2007-01-16 05:12:16 UTC
>>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!