<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2014/1/8 Sean P. DeNigris <span dir="ltr"><<a href="mailto:sean@clipperadams.com" target="_blank">sean@clipperadams.com</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Nicolas Cellier wrote<br>
<div class="im">> Ah yes, that's true.<br>
> Try with Character value: 1 instead of *:<br>
<br>
</div>Yes, that works. So is it a bug or not?<br>
<br></blockquote><div><br></div><div>I don't know.<br>See the comment of Morphic-nice.695 which explains why this change was made.<br></div><div>The old code (lr 2006) was buggy and wrong: it did cause glitches.<br><br>
</div><div>For example, just insert a space between foo and the icon after opening the morph and see how it hurts.<br></div><div>And note how differently weird it behaved when you replaced * with Character value: 1...<br>
</div><div><br></div><div>Embedded morphs/forms created interactively will be over (Character value: 1) and work OK.<br></div><div>For embedded morphs/forms created programmaticaly as you did, we have to decide something...<br>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Another thing… There is noise around the embedded form. It seems that<br>
BitBltDisplayScanner>>#displayEmbeddedForm: should be changed to:<br>
aForm<br>
displayOn: bitBlt destForm<br>
at: destX @ (lineY + line baseline - aForm height)<br>
clippingBox: bitBlt clipRect<br>
rule: Form blend<br>
fillColor: Color white<br>
<br>
<br></blockquote><div>Yes I saw that too.<br>If we change it, it should use BitBltDisplayScanner backgroundColor inst. var. (transparent) rather than white in any case.<br><br></div><div>But I'd like to understand first.<br>
</div><div>What is strange is that old code in DisplayScanner>>placeEmbeddedObject: did just <br> anchoredMorph <br> displayOn: bitBlt destForm <br> at: destX - anchoredMorph width @ destY<br>
clippingBox: bitBlt clipRect<br></div><div>Exactly as the new code do in BitBltDisplayScanner>>displayEmbeddedForm:<br><br></div><div>But this was probably happening in a different order - as soon as setFont (mutated graphics context in action).<br>
</div><div>I instrumented, and it seems that the new version is using combinationRule 37 (rgbMul) at time of Form display...<br></div><div>This is one rule used by StrikeFont subpixel rendering:<br>(SystemNavigation default browseAllCallsOn: 37) -> rgbMul -> installStrikeFont:foregroundColor:backgroundColor:.<br>
<br>It might be those lines in new DisplayScanner>>displayLine:offset:leftInRun:<br> stopConditionsMustBeReset<br> ifTrue:[self setStopConditions].<br></div><br></div><div class="gmail_quote">Lazyness + stateful mutations might lead to modified side effects...<br>
</div><div class="gmail_quote"><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-----<br>
Cheers,<br>
Sean<br>
--<br>
View this message in context: <a href="http://forum.world.st/Text-Morph-Embedding-Broken-tp4735055p4735059.html" target="_blank">http://forum.world.st/Text-Morph-Embedding-Broken-tp4735055p4735059.html</a><br>
<div class=""><div class="h5">Sent from the Squeak - Dev mailing list archive at Nabble.com.<br>
<br>
</div></div></blockquote></div><br></div></div>