ttf-parser 0.5 - TrueType فونٽس سان ڪم ڪرڻ لاءِ نئين لائبريري

ttf-parser TrueType/OpenType فونٽس کي پارس ڪرڻ لاءِ لائبريري آهي.
نئين ورزن ۾ متغير فونٽس لاءِ مڪمل سپورٽ آهي
(متغير فونٽ) ۽ سي اي پي آئي، جنهن جي نتيجي ۾ مون فيصلو ڪيو ته ان کي لوڪ ۾ اشتهار ڏيو.

تازو تائين، جيڪڏهن TrueType فونٽس سان ڪم ڪرڻ جي ضرورت هئي، اتي ٻه آپشن هئا: FreeType ۽ stb_truetype. پهريون هڪ تمام وڏو گڏيل آهي، ٻيو ڪمن جي ڪافي ننڍڙي تعداد کي سپورٽ ڪري ٿو.

ttf-parser وچ ۾ ڪٿي آهي. اهو سڀني ساڳين TrueType جدولن کي سپورٽ ڪري ٿو (TrueType فارميٽ ڪيترن ئي الڳ بائنري جدولن تي مشتمل آهي) جيئن FreeType، پر پاڻ گليفس نه ڪڍندو آهي.

ساڳئي وقت، ttf-parser ڪيترن ئي ٻين اهم اختلافن تي مشتمل آهي:

1. ttf-parser غير محفوظ استعمال ڪرڻ کان سواء Rust ۾ لکيل آهي. FreeType ۽ stb_truetype سي ۾ لکيل آهن.
2. ttf-parser صرف ميموري-محفوظ عمل آهي. بي ترتيب ياداشت پڙهڻ ممڪن ناهي. FreeType ۾ ڪمزورين کي مسلسل طئي ڪيو پيو وڃي، ۽ stb_truetype اصولي طور تي، غير ارادي فونٽ پڙهڻ لاءِ ٺهيل نه آهي.
3. ttf-parser واحد ٿريڊ-محفوظ عمل آهي. سڀ تجزيي جا طريقا مستقل آهن. صرف استثنا متغير فونٽس لاءِ همراهن کي ترتيب ڏيڻ آهي، پر هي فنڪشن ٻيهر آهي. FreeType بنيادي طور تي واحد موضوع آهي. stb_truetype - ٻيهر داخل ڪرڻ وارو (توهان انفرادي ڪاپيون مختلف موضوعن ۾ استعمال ڪري سگهو ٿا، پر گهڻن مان هڪ نه).
4. ttf-parser اهو واحد عمل آهي جيڪو هيپ مختص استعمال نٿو ڪري. اهو توهان کي تيز ڪرڻ جي اجازت ڏئي ٿو پارسنگ کي تيز ڪرڻ ۽ OOM سان مسئلن کان بچڻ.
5. انهي سان گڏ، لڳ ڀڳ سڀ رياضياتي عملن ۽ عددي قسمن جي تبديلين جي چڪاس ڪئي وئي آهي (بشمول جامد طور تي).
6. بدترين صورت ۾، لائبريري هڪ استثنا اڇلائي سگھي ٿي. انهي صورت ۾، C API ۾، استثنا پڪڙجي ويندا ۽ فنڪشن هڪ غلطي واپس ڪندو، پر حادثي نه ٿيندو.

۽ سڀني حفاظتي ضمانتن جي باوجود، ttf-parser پڻ تيز ترين عمل درآمد آهي. مثال طور، CFF2 parsing FreeType کان 3.5 دفعا تيز آھي. Glyf، ساڳئي وقت ۾، stb_truetype جي ڀيٽ ۾ 10٪ سست آهي، پر اهو ان حقيقت جي ڪري آهي ته اهو متغير فونٽس کي سپورٽ نٿو ڪري، جنهن تي عمل ڪرڻ لاء اضافي اسٽوريج جي ضرورت آهي. ڄاڻ. وڌيڪ تفصيل ۾ ريڊيو.

جو ذريعو: linux.org.ru