I committed those changes.
Next:
should TextStyle class >> pixelsPerInch be moved to
DisplayScreen >> pixelsPerInch ?
If so: TextPrinter >> defaultResolution is probably wrong, and should
probably just answer some constant like 300dpi...?
;;--
If, after loading the recent changes to pixelsPerInch: etc., you want to
see their effect, try this:
1.
| s |
s := TextStyle named: #BitstreamVeraSans.
UserInterfaceTheme current properties associationsDo: [:a |
(a value isKindOf: StrikeFont) ifTrue: [
s addNewFontSize: a value pointSize.
a value: (s fontOfPointSize: a value pointSize)]].
2. Close and reopen all your widgets (sigh), including running
TheWorldMainDockingBar initialize
3. Open a few windows
4. Alternate between the following:
TextStyle pixelsPerInch: 163
TextStyle pixelsPerInch: 96
Cheers,
Tony
On 8/26/20 4:20 PM, Tony Garnock-Jones wrote:
> Hi all,
>
> I'm looking at the image-side DPI-change code, namely TextStyle >>
> pixelsPerInch:.
>
> The broadcast of the change is fine. But the handler in TTCFont is
> subtly wrong, I think.
>
> - I believe instance variables height, ascent, descent have to be nil'd
> as part of pixelsPerInchChanged. Is that right? Without nil'ing them,
> my TTCFonts don't resize properly.
>
> - This suggests flushCachedValues, which has NO SENDERS (!), should be
> folded into flushCache. Does that sound right?
>
> - Finally, if both the above hold, then pixelsPerInchChanged should be
> calling flushCache instead of recreateCache. Does that sound right?
>
> I'll be running for a few days with these changes in my image, to see if
> there are any obvious problems with them.
>
> But, before I push a commit out to Trunk, if I could get a thumbs-up
> from someone who knows a bit about the font subsystem, that'd be great!
>
> Regards,
> Tony
>
Locked
