Created attachment 192268 [details] bestFitVertical.xlsx: MSO bestFit inconsistency demo Slices near the Y-axis are best suited for well-wrapped text. Unfortunately, LO's algorithm has no ability to look for the "best width". So it cannot place as many labels inside the slice as needed for compatibility documents. However, there are other cases where LO's algorithm is able to bestFit content where MSO fails, and as this document shows, MSO isn't very predictable in determining whether content should bestFit or not. Fixing this will require adding a significant amount of intelligence to the bestFit algorithm. It will need to loop and try three or four different widths. Due to 3D manipulation, simple tricks like comparing the slice area to the text area will not work - unless your area formula takes into account the 3D rotation.
Created attachment 192269 [details] bestFitVertical_mso2010.pdf: how it looks in the program that created the file
Created attachment 192270 [details] insideWrapping.xlsx: text attempts to fit into slice also with center placement The bestFit shrinking algorithm should also be applied to center/inside-edge placements.
Created attachment 192271 [details] insideWrapping_mso2010.pdf: how it looks in the program that created it Granted, this is not a "nice" example. It was designed to show how MS handles a somewhat bizarre situation, compared to how LO does it. LO ends up looking somewhat OK in this example because it ALWAYS limits the width to 80% of the radius. For a very large pie, LO wouldn't wrap which might cause it to spill out of the slice if it doesn't bestFit. As can be seen here, MSO can sometimes not bother to bestFit and just spill outside of the pie chart too.
(In reply to Justin L from comment #2) > The bestFit shrinking algorithm should also be applied to center/inside-edge I'd like to retract this statement. A bit more playing around suggests this is not actually true. I'm not sure what is going on here...
I think in the ideal case that ALL inside placements should also try to bestFit the text content into the slice, regardless of what MSO does. (I mean, how bad could it be if we DO NOT spill out of the slice - just less aesthetic hyphen-splits in specific contexts?) IIUC, our current bestFit algorithm simply tries to find the best POSITION for the text: center or edge basically. In order to do that, it does some brilliant calculations, which I would HOPE could be fairly easily adapted to compare to the area of the current text bounding box. // get label b.b. width and height basegfx::B2IRectangle aBb( lcl_getRect( rPieLabelInfo.xLabelGroupShape ) ); If the guessed best width doesn't fit, [but the area fits into the slices' available text area,] then reduce the maximum width to this width and check if the new height is OK. [Area isn't a great predictive test though, since almost half of it could be empty space.] rPieLabelInfo.xTextShape->SvxShape::setPropertyValue("TextMaximumFrameWidth", nMaxBestFitWidth); That is an expensive task, so don't want to do that flippantly. However, the only way to actually know if it fits is to force the text to re-layout with a new width.
Ok, let's set to NEW.