Apache OpenOffice (AOO) Bugzilla – Issue 34326
Fail to show word doc's bullet properly
Last modified: 2013-08-07 14:38:26 UTC
Looking at the attached file using Word docs, all the bullets have a same size. Open with OpenOffice and some is small, some is larger. Generally larger than the word docs (2003) picture. It even introduce extra bullet.
Created attachment 17779 [details] Test document show test bug
confirmed in src680_m51 but this ist already fixed in src680_m54
closing
The bullets still have a wrong size (some big and some small). Please check the attached document. View using MS word 2003 and OpenOffice m54. Note that when using OpenOffice to save this doc, and reopen, they'll all have the same size.
Created attachment 17887 [details] Test show bullets diff size.
Also, after clicking on the link: Created an attachment (id=17887) below, then open using OpenOffice m54 (Windows XP). Then click on File menu->Properties. Then thing crashes. If you want, I'll report this as another bug.
I already report this at: http://www.openoffice.org/issues/show_bug.cgi?id=34571
MRU->FME: Can you please have a look, why the bullets look slightly different? All the attributes seem identical, but the upper ones look a bit larger when imported in OO Writer...
Please look into this. This is a crucial fix for 2.0. Bullets are used all over places. With this bug, OOo does not look serious for any thing at all. Here is why I said so: one of the people I tried to get to switch over to OOo from MS word open a resume in OOo, and the bullets just don't look right. Immediately, that person switched back to MS Word, and I was speechless. The action was all justified, and I see no reason to support my case. For OOo to be a serious Office contender, it must display all usual features of a word processing MS Word doc correctly and perfectly. Bullets, tables, drawings, margins, fonts are the most basic stuffs that have to work right.
That's how we obtain the font size for the bullets: 1. The size of the bullets is the size of the paragraph font, obtained from the paragraph style. 2. If there is a hard font size attribute set at the paragraph, we take the font size from this attribute. 3. If the character attribute associated with the numbering (WW8Num38z0 in this case) has the font size set, this will be taken. Analysis: In the test3.doc document, all the paragraphs with bullets have a paragraph font of size 12pt. The last three paragraphs have a hard font size attribute of size 11 set at the paragraph, therefore rule 2 applies and the bullet gets the size 11pt. The first three paragraphs do not have a hard font size attribute set at the paragraph, instead they have a hard font size attribute set to all the characters in the paragraph, which makes the difference. Therefore rule 2 does not apply and the font size remains 12pt.
Thank you for the analysis and the clear explaination. I have this curious question though: Open the test file, then save as OOo file (test3.oot for example). Open the new file in OOo. The bullets look good (same size). The question is this: why not making any modification to the files, and save, and open, and things changed? Is this another/different bug? Can we investigate this bug, and see if we can copy the bug's "idea" and fix this one?
FME->VYHO: I think the xml export does not distinguish between attributes set at the paragraph and attributes set at all characters of the paragraph, but I'm not sure about this. After the xml import, the attributes which have been set at all characters will go to the special attribute set denoted for paragraph attributes. Except from the bullet/numering code I cannot imagine any other scenario that depends on this difference. So the easiest way to address this issue is enhance the font size calculation algorithm by this: 2.5. If there is a hard font size attribute set at all characters of the paragraph, we take the font size from this attribute.
One strange point I see is that the first 3 bullets are big, while the last 3 are small. From MS Word, they're all small like the last 3. So when you change to rule, make sure that somehow all of them get the size of 11, not 12.