
<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;"><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><br>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></body></html>