Testing some code I wrote in Squeak-3.10.2-Closures (and works ok), in
the trunk I find some text truncation. Example code is: font1 := (TextFontReference toFont: (StrikeFont familyName: 'Atlanta' size: 24)). msg := (3.83 asString, ' RPS (', 3 asString, ' pts), Vavg=', 2.35 asString) asText addAttribute: font1. nota:=TextMorph new. nota contents: msg. nota openInWorld Screen shot 2009-09-21 at 14.33.png (26K) Download Attachment |
Hi Javier -
[cc: Juan for questions regarding AA fonts below] Thanks for pointing this out. This appears to be a problem caused by the new fonts; for some reason the code computes an incorrect base kern, i.e., (StrikeFont familyName: 'Atlanta' pointSize: 22) baseKern This results in -2 (should be zero I think). Juan, I'm wondering why we don't just store the base kern in the font and do something along the lines of: baseKern ^baseKern ifNil:[0] to leave the previous fonts alone. Alternatively, we can leave the computation in and just set the base kern for the fonts we care about. There is a remaining question which is why the text isn't resizing itself to the proper width (with or without wrong kerning) but I think that's a separate question to consider. Cheers, - Andreas Javier Diaz-Reinoso wrote: > Testing some code I wrote in Squeak-3.10.2-Closures (and works ok), in > the trunk I find some text truncation. > Example code is: > > font1 := (TextFontReference toFont: (StrikeFont familyName: > 'Atlanta' size: 24)). > msg := (3.83 asString, ' RPS (', 3 asString, ' pts), Vavg=', 2.35 > asString) > asText addAttribute: font1. > nota:=TextMorph new. > nota contents: msg. > nota openInWorld > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > |
Hi Folks,
Andreas Raab wrote: > Hi Javier - > > [cc: Juan for questions regarding AA fonts below] > > Thanks for pointing this out. This appears to be a problem caused by > the new fonts; for some reason the code computes an incorrect base > kern, i.e., > > (StrikeFont familyName: 'Atlanta' pointSize: 22) baseKern > > This results in -2 (should be zero I think). Juan, I'm wondering why > we don't just store the base kern in the font and do something along > the lines of: > > baseKern > ^baseKern ifNil:[0] > > to leave the previous fonts alone. Alternatively, we can leave the > computation in and just set the base kern for the fonts we care about. Just did that. Trunk updated. The only non-zero base kern is for the small pda font, where it is really needed. > There is a remaining question which is why the text isn't resizing > itself to the proper width (with or without wrong kerning) but I think > that's a separate question to consider. Tried to dive a bit in the deep waters of CharacterScanner, and the handling of fractional kerning, etc. I believe that StrikeFont>>widthOf: should substract the base kern in the last line (as it does in Cuis), but doing this brings yet more artifacts... Cheers, Juan Vuletich > Cheers, > - Andreas > > Javier Diaz-Reinoso wrote: >> Testing some code I wrote in Squeak-3.10.2-Closures (and works ok), >> in the trunk I find some text truncation. >> Example code is: >> >> font1 := (TextFontReference toFont: (StrikeFont familyName: >> 'Atlanta' size: 24)). >> msg := (3.83 asString, ' RPS (', 3 asString, ' pts), Vavg=', 2.35 >> asString) >> asText addAttribute: font1. >> nota:=TextMorph new. >> nota contents: msg. >> nota openInWorld >> >> ------------------------------------------------------------------------ >> >> >> ------------------------------------------------------------------------ >> >> > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.409 / Virus Database: 270.13.112/2388 - Release Date: 09/22/09 05:51:00 > > |
Juan Vuletich wrote:
> Just did that. Trunk updated. The only non-zero base kern is for the > small pda font, where it is really needed. Great! Thanks so much. >> There is a remaining question which is why the text isn't resizing >> itself to the proper width (with or without wrong kerning) but I think >> that's a separate question to consider. > > Tried to dive a bit in the deep waters of CharacterScanner, and the > handling of fractional kerning, etc. I believe that StrikeFont>>widthOf: > should substract the base kern in the last line (as it does in Cuis), > but doing this brings yet more artifacts... I'm not sure, but it looks as if after your fix the text morph is exactly the right size and not clipped any longer. So I think we're good. Cheers, - Andreas |
Free forum by Nabble | Edit this page |