<div dir="ltr"><div class="gmail_extra"><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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Nicolas Cellier wrote<br>
<div class="im">> For embedded morphs/forms created programmaticaly as you did, we have to<br>
> decide something...<br>
<br>
</div>Just reifying and documenting may be enough. For Pharo, I'm proposing (1) an<br>
update to the TextAnchor class comment and (2):<br>
Morph>>#asText<br>
<br>
| anchor embedMorphSignal |<br>
anchor := TextAnchor new anchoredMorph: self.<br>
embedMorphSignal := (Character value: 1) asString. "required by the<br>
scanner"<br>
^ Text string: embedMorphSignal attribute: anchor.<br>
<br>
b.t.w. is "required by the scanner" accurate<br>
<br></blockquote><div>Yep, exactly, that's how the scanner loop works.<br>If you want it, here are a few things I can tell about the scanner and some recent evolutions:<br><br></div><div>The scanner processes run after run (a run is a chunk of text with homogeneous emphasis, like, bold italic, ...).<br>
</div><div>In each run, the font is set according to current emphasis.<br>Inside a run, the scanner then compose/displays string chunks separated by well know special character (space if justified alignment, tab, cr/lf and (Character value: 1)).<br>
</div><div></div><div>A special action associated to the special character is then processed, and this composiiton/display loop continues until end of run.<br></div><div>Those special characters and associated actions are stored in stopConditions which map special character code ->special action (nil if none).<br>
</div><div>Note that currently (heritage of ASCII) the special character code are limited from 0 to 255. There currently cannot be any special wide character.<br></div><div>Two more code are used for two special conditions<br>
- the composition crossed the X boundary (the right margin in latin - we don't yet support arabic or hebrew right to left).<br></div><div>- the endOfRun was reached<br></div><div>In fact, the two external loops (runs and chunks) are (or can be) fused, thanks to the #endOfRun actions linked to these EndOfRun special code.<br>
</div><div><br></div><div>The character by character scanning for stop conditions is performed inside an internal loop which is very simple and can be generated as a primitive.<br></div><div>This provides great speed up for composing/displaying on slow devices, but is unfortunately restricted to StrikeFonts and char codes < 256 currently...<br>
</div><div>This primitive access/mutates some of the scanner states, and thus requires a specific inst. var. layout which was broken quite some times ago (search mantis or this mailing list for reference).<br>It must also have two reserved slots for crossedX and endOfRun conditions which I previously broke (in order to correct a bug: endOfRun was hikacking A-macron char code, perventing its display).<br>
Note that some people (including me) thought that having an indirection stopConditions at: EndOfRun put:#endOfRun was an unecessarily over-engineered feature.<br>This was not the original goal : the original goal was to have a primitive, and indeed the VM cannot easily perform a squeak method, thus the indirection.<br>
Also the VM cannot easily access Symbols by name - unless we reserve additional SpecialObjects (oh no!) - thus the two reserved slots.<br>We restored all these conditions recently with Tim, enabling the primitive to run again in both Squeak and Pharo.<br>
</div><div>Tim added the double dispatch things to properly handle other kind of fonts or WideString by non primitive code.<br></div><div>This should enable using Squeak/Pharo on Pi or other slow devices with smoother user experience (if restricting to latin1 StrikeFont).<br>
</div><div><br></div><div>The old TextAnchor code did not play well this logic. It was a hack added a posteriori, which tried to perform special actions outside the composition/display loop (during setting of the font).<br>
</div><div>Unfortunately, this violates some implicit invariants, because some states are either not yet correctly set, or set twice (like advancing the X position).<br>These are the glitches that you can see when inserting a white space in 'foo *bar'.<br>
</div><div>An unused control Character (value: 1) had been assigned previously for embedded morph/form before this hack, (late 90s ? early 2000s ?), but maybe the hack was older after all (use Bob Arning site for exploring old Squeak changes if you are curious)...<br>
<br></div><div>If we really insist on transforming any character code as an anchor, we can as well try to rewrite the logic to handle TextAnchor specially (as an isolated run ?), but:<br></div><div>1. this is quite involved: I greatly reduced the number of mutated states (inst-var) in my recent reviews, but there are still a bit too many<br>
</div><div>2. this is constrained by the fact that the internal loop must remain simple in order to be generated.<br></div><div>3. if you change the internal loop logic, then you must allocate a new primitive # (or you break the property that the interpreter VM supports old images - we wish to keep it)<br>
</div><div>4. we miss (non regression) tests - I started some unpublished attempts, but given that there are many logics in those composition/display, it's really hard to write good tests. Moreover, I'm not sure that using MethodWrappers on such kind of low level methods in order to measure coverage is an easy thing ;).<br>
</div><div><br></div><div>Another strategy in Pharo is to let things as they are now, and wait for a better (but you must tell versus which criterion) or at least revisited Text model...<br><br></div><div>Last thing, the FreeTypePlugin primitives currently can only compose and display character by character... This is a pity because it's a huge slow down !<br>
</div><div>So if you start Pharo 3.0 on a Pi, please revert to a strike font like dejaVu sans.<br></div><div>Maybe that's something we could address with moderate effort, if there is good will and interest.<br></div><div>
But what are the mid-term Pharo plans about Text composition/redering? Will some new 3rd party libraries be used?<br><br></div><div>Nicolas<br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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-tp4735055p4735207.html" target="_blank">http://forum.world.st/Text-Morph-Embedding-Broken-tp4735055p4735207.html</a><br>
<div class="HOEnZb"><div class="h5">Sent from the Squeak - Dev mailing list archive at Nabble.com.<br>
<br>
</div></div></blockquote></div><br></div></div>