<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-10-01 12:57 GMT+02:00 Tobias Pape <span dir="ltr"><<a href="mailto:Das.Linux@gmx.de" target="_blank">Das.Linux@gmx.de</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"><span><br>
> On 01.10.2017, at 11:38, Marcel Weiher <<a href="mailto:marcel.weiher@gmail.com" target="_blank">marcel.weiher@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
>> On Sep 29, 2017, at 19:09 , Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmai<wbr>l.com</a>> wrote:<br>
>><br>
>> The canvas other than PostscriptCanvas don't use the target, they are sinks.<br>
><br>
> That’s only technically true, and really an oversight.  All canvases write their output somewhere, be it a bitmap, native display surface or other ‘DisplayMedium'.  A canvas is a filter for converting morphs to this target ‘DisplayMedium’.<br>
><br>
> And having filter-canvases would be really cool :-)<br>
<br>
</span>You mean like ColorMappingCanvas, AlphaBlendingCanvas, and ShadowDrawingCanvas?<br>
(Which, by your account, should not have an own myCanvas but rather reuse target…)?<br>
<br>
Best regards<br>
        -Tobias<br>
<br></blockquote><div><br></div><div>Hi Marcel, Tobias,</div><div>I perfectly understand what an Encoder is. OK I said it transforms stream instead of filters stream because I'm not academic enough ;).</div><div>I agree that the pattern has a lot of potential, though parallelism still is a problem in Smalltalk processing model.<br></div><div><br></div><div>But:<br></div><div>In a sense, the canvas did handle a stream of graphics instructions (draw a line, a circle, fill a rectangle etc...).</div><div>Even, if we don't really reify those instructions, and tell (canvas write: (Line from: ... to: ....)) but rather use a more direct (canvas drawLineFrom:to:...) send.<br></div><div>By making it an Encoder, it now handles both a stream of graphics instructions and a stream of objects (that can appropriately convert themselves to a stream of graphic instructions thru double dispatching).</div><div>This is a metonymy.</div><div><br></div><div>I will repeat why it does not sound legitimate to me:</div><div>First, a metonymy is obscuring responsibilities.<br></div><div>Either that's an un-necessary indirection, because objects already know how to draw themselves, and it composes well already, because an object will ask the objects that it is composed of to render themselves.</div><div>Or once we want to use it as a filter for a stream of arbitrary objects, we get a problem of composability (understand composing as giving a specific layout to the objects we want to render).</div><div>So we have to give greater responsabilities to the dumb canvas for this composition to happen.</div><div><br></div><div>I showed that the only place where we make use of the double dispatching technic exhibit this problem of composability (we can't render in PostScript a Morph composed of BookMorph, because we can't put several pages into a page...).<br></div><div><br></div><div>If we really want to keep the Encoder pattern, then yes, we must use the target where possible. But I'm not convinced.</div><div><br></div><div>--------</div><div><br></div><div>Note about text rendering: we generally have to recompose the layout for different target (for example, if we want to render a BookMorph on A4 paper with specific margins...). For this composition to take place, we need to know the font metrics, and use some specific rules for margins, alignment, tab stops, etc... That's what a CompositionScanner does.</div><div>I fail to see where those PostScript font metrics are in Squeak?</div><div><br></div><div>Rendering on PostScript is not an exception. If we are able to share some fonts then we can omit the composition step for most simple cases (like generating an EPS figure). But if we start with a bitmap font, rendering in PostScript will be very rough indeed. <br></div><div><br></div><div>For this reason, generating the PostScript in VW smalltalk goes thru a higher level indirection, the Document, which is somehow responsible for composing the layout for an arbitrary input stream of objects.</div><div>It has to cooperate with a GraphicsContext (the quivalent of our Canvas) for transforming fonts to nearest PostScript equivalent, measuring, etc...<br></div><div>VW has a PostScriptContext which is a specific GraphicsContext for low level rendering instructions, but that's not where everything takes place. The Document would handle the DSC for example (that sounds quite logical no?).<br></div><div>Also note that a Document is not conceptually bound to a Postscript target, it could be anything, even LaTeX or Word backend, in which case it could eventually delegate the composition phase (which could work for a flow of text and small graphics, but would be more delicate for math expressions, tables and figures though).<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">
><br>
> Marcel<br>
><br>
><br>
<br>
<br>
</blockquote></div><br></div></div>