Pen protocol: scope?

[madig]

The docs say:

[...] it is an abstraction for drawing outlines, making sure that outline objects don’t need to know the details about how and where they’re being drawn, and that drawings don’t need to know the details of how outlines are stored

I was wondering if there have been thoughts about extending the protocol to include e.g. anchors? How about a more extensive protocol that can also transport codepoints, guidelines, advance height and width and image?

Is there a specific reason to focus solely on the outline?

[justvanrossum]

In a very early iteration of pens, they included advance width, and perhaps even anchors, I forgot. It made everything messy and focussing on outlines alone was a huge improvement.

[madig]

Can you give some examples of messiness?

I'm asking because I am thinking about how to add pen-like processors to Norad to transform glyphs.

[justvanrossum]

But pens can do so much more than transforming. Look at all the pens in the fonttools/ufo world, which ones could be meaningfully expanded for the items you mention? What is the bounding box of a code point? :)

The way I see it, is that

1. it's hard to agree on a universal object model for outlines
2. even when agreeing, an object model for outlines is relatively complex

The pen-model already existed (PostScript), and I see more or less the same API in every 2D canvas library. It's a natural fit for piecewise bezier paths.

The non-outline things you mention can be represented easily with a shallow object tree (like in defcon/fontparts/ufolib2) and will not benefit as much from a transfer protocol. For example, setting an advance width is not sequential in the way that moveTo/lineTo/curveTo/closePath are.

Anyway, perhaps I'm wrong, and glyphs can benefit from a transfer protocol in a similar way that outlines do. But then let "pen" be a "child protocol" within it, to have a clear separation of concern. "Has-a" vs. "Is-a".

The lack of separation of concern is probably why I took it out: it's too much unrelated stuff in one protocol. Most pens (eg. bounds pen, point-inside-pen, filter pens, area pen, draw-to-2d-API-of-choice-pen, the list goes on) are just outline processors, and would not benefit at all from being expanded with glyph-level data.

For your entertainment (but it won't prove much), here is a precursor for CocoaPen from 2003, using an earlier version of the pen protocol:

class BezierPathPen:

    def __init__(self, glyphSet, path=None):
        self.glyphSet = glyphSet
        if path is None:
            path = NSBezierPath.bezierPath()
        self.path = path
    
    def moveTo(self, pt, smooth=False):
        self.path.moveToPoint_(pt)
    
    def lineTo(self, pt, smooth=False):
        self.path.lineToPoint_(pt)
    
    def curveTo(self, pt1, pt2, pt3, smooth=False):
        self.path.curveToPoint_controlPoint1_controlPoint2_(pt3, pt1, pt2)
    
    # XXX qCurveTo(...)
    
    def closePath(self):
        self.path.closePath()
    def endPath(self):
        self.path.closePath()
    def addComponent(self, baseName, offset, scale):
        pen = BezierPathPen(self.glyphSet)
        self.glyphSet.drawGlyph(baseName, pen)
        t = NSAffineTransform.transform()
        t.scaleXBy_yBy_(*scale)
        t.translateXBy_yBy_(*offset)
        compoBez = pen.path
        compoBez.transformUsingAffineTransform_(t)
        self.path.appendBezierPath_(compoBez)
    
    def addAnchor(self, *args):
        pass
    
    def setWidth(self, width):
        self.width = width
    
    def setNote(self, note):
        pass

    def doneDrawing(self):
        pass