<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-size: 13px;color: rgb(0, 0, 0);font-family: arial, sans-serif;">As my memory kicks in, I think "overwhelm certain processors" may not have been a good characterization. IIRC most environments fail to deal gracefully with subroutines that have an index value greater than two bytes (which isn't a real shock). This made the pan-CJK fonts bigger than they could have been, but they still got the majority of compression value due to the "biggest first" algorithm noted before.<div>thanks,</div><div>David L<br><br><blockquote style="padding-left: 5px; margin-left: 0px; border-left: #0000ff 2px solid; font-weight: normal; font-style: normal; text-decoration: none; font-size: 10pt; font-family: arial,sans-serif; color: black;">-----Original Message-----
<br>From: David Lemon <typenerd@mindspring.com>
<br>Sent: Sep 11, 2020 8:36 PM
<br>To: "Adam Twardoch (Lists)" <list.adam@twardoch.com>, Renzhi Li <renzhi.li@microsoft.com>
<br>Cc: mpeg-otspec <mpeg-otspec@lists.aau.at>
<br>Subject: Re: [MPEG-OTSPEC] [EXTERNAL] Re: Co-existence of glyph rendering source types 2
<br><br><style type="text/css"><!-- DIV {margin:0px;} --></style><div style="font-size: 13px;color: rgb(0, 0, 0);font-family: arial, sans-serif;"><style>body{font-size:10pt;font-family:arial,sans-serif;background-color:#ffffff;color:black;}p{margin:0px;}</style>Adam Twardoch wrote:<br><blockquote style="padding-left: 5px; margin-left: 0px; border-left-width: 2px; border-left-style: solid; border-left-color: rgb(0, 0, 255); font-size: 10pt;"><list.adam@twardoch.com><renzhi.li@microsoft.com><mpeg-otspec@lists.aau.at><div class="gmail_quote"><div dir="auto">...</div><div dir="auto">CFF subroutine compression has been around for a long time, so it could be used as a metric. In real life, what's the current size benefit of subroutinized vs. non-subroutinized? </div></div></mpeg-otspec@lists.aau.at></renzhi.li@microsoft.com></list.adam@twardoch.com></blockquote>The amount of compression delivered by CFF2 subroutinization varies significantly by design; some fonts are vastly more subroutinizable than others. In some cases it was as little as about 2%; in other cases well over 30%. The algorithm is also adjustable. By default it starts with the biggest "bang for the buck" and keeps goin until it reaches the point where storing a subroutine uses as much space as the subroutine saves, but some environments require setting a threshold on the number of subroutines so as not to overwhelm certain processors. (This was the case in the Adobe/Google pan-CJK fonts.)<div><br></div><div>The appropriate benchmark is the size benefit of subroutinized v non-subroutinized versions of a given target font, and how those would compare to the proposed new mechanism.</div><div>thanks,</div><div>David L<br><div><br></div></div></div>
</mpeg-otspec@lists.aau.at></renzhi.li@microsoft.com></list.adam@twardoch.com></typenerd@mindspring.com></blockquote></div></div></body></html>