<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 11/1/24 10:03 AM, Behdad Esfahbod
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAF63+7UaGNJo7JesKYKmvgrMXzr+dnV=mGpLv1K-59ipUaH=YA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">Hi Skef,
<div><br>
</div>
<div>Thanks for the prompt reply. The two proposals look good
to me. One comment below:</div>
<div><br>
</div>
</div>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Nov 1, 2024 at
3:59 AM Skef Iterum via mpeg-otspec <<a
href="mailto:mpeg-otspec@lists.aau.at" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">mpeg-otspec@lists.aau.at</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>
<ul>
<li>The proposal to allow multiple vsindex operators in
a CharString is a very significant change that will
need further discussion both within Adobe and probably
outside of it. It will probably require bumping the
CFF2 major version number (to 3, alas).</li>
</ul>
</div>
</blockquote>
<div>Not the minor version? What things would trigger a
minor-version bump?</div>
</div>
</div>
</blockquote>
It's a good question, and probably something we should talk about
when the<br>
time comes. I think, in general, minor version bumps at the top
level make the<br>
most sense when there is fine-grained versioning available lower
down, but<br>
the operator-based approach that CFF has always taken makes that
tricky.
<p>I was originally thinking of a minor version bump for this sort
of thing, but<br>
if there is no opportunity to version the individual CharStrings,
what would<br>
the minor bump accomplish? There's no systematic way for an
existing<br>
implementation to skip over the new semantic.<br>
</p>
<blockquote type="cite"
cite="mid:CAF63+7UaGNJo7JesKYKmvgrMXzr+dnV=mGpLv1K-59ipUaH=YA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<ul>
<li>We will need to consider whether to allow the change
in the PrivateDict as well, and what that means for
fallback (what the first proposal clarifies). All of
this means that this is not the time to be discussing
that change.</li>
</ul>
</div>
</blockquote>
<div>I think multiple vsindex'es are already permitted in
PrivateDict. At least, there's no text saying otherwise. The
relevant text in the spec is:</div>
<div><br>
</div>
<div>"The vsindex operator may be used only once in a
CharString and must precede the first use of the blend
operator."</div>
<div><br>
</div>
</div>
</div>
</blockquote>
I suspect many if not all existing implementations would break if
you tried it<br>
in a PrivateDICT, and it's just something the authors didn't
imagine. There are<br>
a lot of operators that can only be used once to reasonable effect
that don't<br>
make that explicit.<br>
<br>
Note that if multiple operators were allowed, you'd need some
language to<br>
sort out which one applied to the CharStrings (e.g. the first one or
the last<br>
one). The language that talks about that relationship is generally
singular.
<p>Skef<br>
</p>
<blockquote type="cite"
cite="mid:CAF63+7UaGNJo7JesKYKmvgrMXzr+dnV=mGpLv1K-59ipUaH=YA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div>Thanks,</div>
<div>behdad</div>
<div> </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<ul>
</ul>
<p>Perhaps we can discuss the two editorial(esque) changes
at our next meeting.</p>
<p>Thanks,<br>
</p>
<div>Skef Iterum<br>
Adobe, Inc.<br>
</div>
<div><br>
</div>
<div>On 10/22/24 3:17 PM, Behdad Esfahbod via mpeg-otspec
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Hi everyone,</div>
<div><br>
</div>
CFF2 has a file size advantage over TrueType-flavored
variable fonts, specially if one doesn't care about
hinting (Android, Apple platforms, etc) but does care
about (uncompressed) size.<br>
<br>
CFF2 also alleviates some other limitations of
variable-fonts built against the gvar table.
Unfortunately, it imposes its own limitations. These
are among the issues I'm going to raise.<br>
<br>
Please see:
<div><br>
</div>
<div> <a
href="https://github.com/harfbuzz/boring-expansion-spec/issues/155"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://github.com/harfbuzz/boring-expansion-spec/issues/155</a></div>
<div><br>
</div>
<div>for details of the changes I am proposing.
Ideally, Adobe folks choose to turn these ideas into
proposals and push it through the OFF
standardization / OpenType integration process.
Failing that, we might want to go ahead and do it at
Google</div>
<div><br>
</div>
<div>Thanks,<br>
<div><br clear="all">
<div>
<div dir="ltr" class="gmail_signature">behdad<br>
<a href="http://behdad.org/" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">http://behdad.org/</a></div>
</div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
mpeg-otspec mailing list
<a href="mailto:mpeg-otspec@lists.aau.at" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">mpeg-otspec@lists.aau.at</a>
<a href="https://lists.aau.at/mailman/listinfo/mpeg-otspec"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
mpeg-otspec mailing list<br>
<a href="mailto:mpeg-otspec@lists.aau.at" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">mpeg-otspec@lists.aau.at</a><br>
<a href="https://lists.aau.at/mailman/listinfo/mpeg-otspec"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a><br>
</blockquote>
</div>
</div>
</blockquote>
</body>
</html>