2017-10-01 12:57 GMT+02:00 Tobias Pape <Das.Linux at gmx.de>:

>
> > On 01.10.2017, at 11:38, Marcel Weiher <marcel.weiher at gmail.com> wrote:
> >
> >
> >
> >> On Sep 29, 2017, at 19:09 , Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> wrote:
> >>
> >> The canvas other than PostscriptCanvas don't use the target, they are
> sinks.
> >
> > 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’.
> >
> > And having filter-canvases would be really cool :-)
>
> You mean like ColorMappingCanvas, AlphaBlendingCanvas, and
> ShadowDrawingCanvas?
> (Which, by your account, should not have an own myCanvas but rather reuse
> target…)?
>
> Best regards
>         -Tobias
>
>
Hi Marcel, Tobias,
I perfectly understand what an Encoder is. OK I said it transforms stream
instead of filters stream because I'm not academic enough ;).
I agree that the pattern has a lot of potential, though parallelism still
is a problem in Smalltalk processing model.

But:
In a sense, the canvas did handle a stream of graphics instructions (draw a
line, a circle, fill a rectangle etc...).
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.
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).
This is a metonymy.

I will repeat why it does not sound legitimate to me:
First, a metonymy is obscuring responsibilities.
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.
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).
So we have to give greater responsabilities to the dumb canvas for this
composition to happen.

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...).

If we really want to keep the Encoder pattern, then yes, we must use the
target where possible. But I'm not convinced.

--------

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.
I fail to see where those PostScript font metrics are in Squeak?

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.

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.
It has to cooperate with a GraphicsContext (the quivalent of our Canvas)
for transforming fonts to nearest PostScript equivalent, measuring, etc...
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?).
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).

>
> > Marcel
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20171001/47a0d7de/attachment.html>