<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>There are two aspects to the question of documentation for
PostScript-style hinting:</p>
<ol>
<li>What the different parameters are (per-glyph stems, blue
values, the additional blue parameters, counter hints) and
conceptually what these parameters encode and how they interact.</li>
<li>How to implement a rasterizer that hints using these
parameters.</li>
</ol>
<p>As far as 1 goes, the current documentation may not be ideal but
I don't think it's terrible. It's always nice, of course, to know
more about the specifics of how things will work, but (for good or
bad) one idea of this model was that different implementations
might work differently, hence "hints" as opposed to
"instructions".</p>
<p>As far as 2 goes, yes, that would be nice, but there are many
systems that haven't been codified in this way, and we all
struggle along. I've been told there are ongoing complaints that
Adobe is keeping some documentation private for competitive
reasons, but if that's true the company is keeping it from me too
-- it would have been very handy when I was porting the autohinter
to Python. It appears that the technology started with an
implementation rather than a spec and has just evolved that way.<br>
</p>
<p>All I have to look at is a set of past implementations, differing
slightly from each other as bugs are fixed or new contexts are
supported. Before 10 years ago this was itself, at least arguably,
pretty unfair, at least for the world at large. But once CFF
hinting was contributed to FreeType, I'm not sure the additional
things that I can refer to really changes much. And of course,
Apple has their own CFF stack and I can't look at that.</p>
<p><br>
</p>
<p>Anyway, to answer your specific question: The way I would
document the hinting model for variable composites is by
describing how the existing parameters, per-component-glyph, are
affected (changed or eliminated) by composition. So in the end
you'd be left with a per-glyph list of stems, blue values, and
additional blue parameters, which you would need to rasterize
together as a unit. That's not 100% identical to the current case
of multiple contours within a glyph using identical blue values,
but it's not that far off.</p>
<p>Skef<br>
</p>
<div class="moz-cite-prefix">On 8/23/23 13:53, Dave Crossland wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAOgqPYe1zbiFu9mJPP-W-ZxNWF9M+pD0xwYx5tWsO8PUdRju7Q@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Aug 23, 2023 at
1:48 PM Skef Iterum <<a href="mailto:skef@skef.org"
moz-do-not-send="true" class="moz-txt-link-freetext">skef@skef.org</a>>
wrote:</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div> There does seem to be a viable compositing model for
PostScript-style hinting. <br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>But is there a viable path for documenting the
PostScript-style hinting model sufficiently to standardize
it? </div>
<div><br>
</div>
<div>AFAIK this is big hole in the spec</div>
</div>
</div>
</blockquote>
</body>
</html>