"Description: Binary data
You wrote: > Apologies. I was in a hurry - a screenshot was due in half an hour and > the code was rendering very screwily. I was basically going AAARGGHH and > flying from file to file ;) And I was just waking up and didn't feel very good. Sorry for having been grumpy :o) > > In the case of SceneFlobs, note that boxed flobs have a needsBox() > > method. You can override it to return false. > > Ah, right. The problem there is that I haven't really touched the old > code in a while so I didn't know this. I just committed the code to > do it your way. > > Hmm... the name is a bit odd: I'm not saying that a RotatedSceneFlob > doesn't need a box, I'm saying that it *mustn't* be boxed... Hm, the original logic was "normally we don't render boxes at all; we only do if a flob NEEDS them." Note that needsBox is in Flob, not BoxedFlob, for a reason I don't readily remember. So here we assume that normal flobs don't need a box. > > In the case of FTextLayouter, why not add a structparam (which can be > > set through the constructor, see firstCap) which decides whether to clip > > or not? i.e. doClip or some such. > > Sure. OTOH, the single text strings should never be clipped - that's > woefully inefficient. Instead, the code using the ftext should place e.g. > a sceneflob outside which would do the clipping. Not committing a change > yet. Remember that for an average VanishingView with a linebreaking cell view, that means some hundred flobsets because a sceneflob contains a flobset. *That's* woefully inefficient. (An earler version of FTextCellView did that and I changed it because it was too slow.) Also note that the code *only* clips if a line is too long for the box. The hope is that usually they will not be, at least in long blocks of text (which is where the sceneflob would be an efficient alternative). -b. -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
"
Description: Binary data