0006715: An issue to collect font tests and font test knowledge

Notes
(0011270 - 1631 - 1790 - 1790 - 1790 - 1790 - 1790) wiz 10-09-07 19:59	Currently (as of sq 7149) font tests are scattered into several suites and packages. StandardSystemFontsTest only tests restoreStandardFonts but has the crucial helper wrapping method. LangEnvBugs in Test-bugs which tests a fix to #isFontAvailable by invoking some smalland font changes. The fix which makes this test work actually breaks the correct working of #isFontAvailable and leaves the font state in a changed state. Which makes it an even better test probe. It uncovers a lot of problems in fonts because the state it leaves things in causes system crashes when other tests are run. MultiLingual-Display>FontTest which tests fonts w/o insuring any particular font state to begin with. Several of these tests are in need of rewriting. LocaleTest this tests language locales. To go by the SBE books suggestion some of these tests are more acceptance tests (they rely on the internet to seek out and install the japanese font which creates a directory and downloads 2Meg worth of fonts) . An sunit test would need a mock locale or something like that. This also tests #isFontAvailable. There are not a good suite of tests for smalland themes but those are the ones that extensively change fonts and such. They are also the trigger for finding many of the bugs such as infinite recursion in the TTCFont font methods. The importance of the TTCFont code is that is works well enough to provide squeakland and oplc with a basis for i18n. The difficulty is that it is much in need of repair and before that can happen in documentation so that those other that the creator can repair it.

(0011271 - 1857 - 2440 - 2440 - 2440 - 2440 - 2440) wiz 10-09-07 20:11	------ Other thoughts on font tests... In addition to a state preserving method we need a way to temporarily set font state during tests. >>#setFontStateTo: [ font setting block ] during: [ font testing block ] . which would allow the running of tests under many variants of font state and then restore the starting state. The other thing I wonder about is that both the Preference class var Parameters and the global dictionary TextConstants hold changable font state. TextConstant currently holds these texts defaults: #DefaultBaseline: 12 #DefaultEditMenu: a PopUpMenu #DefaultEditMenuMessages: #(#again #copySelection #cut #paste #undo #save #cancel #align #fit) #DefaultFixedTextStyle: a TextStyle Atlanta #DefaultFontFamilySize: 3 #DefaultLineGrid: 16 #DefaultMarginTabsArray: #(#(24 24) #(48 48) #(72 72) #(96 96) #(120 120) #(144 144) #(168 168) #(192 192) #(216 216) #(240 240) #(264 264) #(288 288) #(312 312) #(336 336) #(360 360)) #DefaultMask: Color black #DefaultMultiStyle: a TextStyle Accuny11(FontSet) #DefaultRule: 3 #DefaultSpace: 4 #DefaultTab: 24 #DefaultTabsArray: #(24 48 72 96 120 144 168 192 216 240 264 288 312 336 360 384 408 432 456 480 504 528 552 576 600 624 648 672 696 720) #DefaultTextStyle: a TextStyle Accuny12(FontSet) and in Parameters #eToysFont->TTCFont(BitstreamVeraSans 9 Bold) #haloLabelFont->a StrikeFontSet(Accuny12 12) #paintBoxButtonFont->TTCFont(BitstreamVeraSansMono 9 Roman) #standardButtonFont->TTCFont(BitstreamVeraSansMono 9 Roman) #standardCodeFont->a StrikeFontSet(Accuny12 12) #standardFlapFont->a StrikeFont(Accushi12 15) #standardListFont->a StrikeFontSet(Accuny12 12) #standardMenuFont->a StrikeFontSet(Accuny12 12) #windowTitleFont->TTCFont(BitstreamVeraSans 12 Bold) ) I may have missed some relevant state but thats most of it.

Issue History
Date Modified	Username	Field	Change
10-09-07 16:39	wiz	New Issue
10-09-07 16:39	wiz	Status	new => assigned
10-09-07 16:39	wiz	Assigned To	=> andreas
10-09-07 16:39	wiz	File Added: StandardSystemFontsTest.st
10-09-07 16:41	wiz	Relationship added	child of 0006570
10-09-07 16:43	wiz	Relationship added	related to 0006571
10-09-07 19:59	wiz	Note Added: 0011270
10-09-07 20:11	wiz	Note Added: 0011271