This bug report refers to Squeak 3.4 latest update: #5170. The bug is also present in Squeak 3.3alpha latest update: #4981. It is not present in Squeak 3.2 alpha latest update: #4599
In an MVC project, centered text is sometimes not displayed centered. In Morphic this bug does not appear.
I will first explain what works in Morphic: 1. In aMorphic project, open a workspace. 2. Type in a displayable character and select it. 3. In the context menu, select the item 'more...' and (in the following menue) 'set alignment...'. select the alignment 'centered'. The character jumps into the middle of the workspace. When you type in additional characters, the text line is extended both to the left and to the right.
After some typing, you see a beautifully centered multiline text. (When you resize the workspace to a small size, you will get this result with less typing :-) )
Now that you know that this works in Morphic, create an MVC project and enter it. Open a workspace and do the same thing that you did with Morphic. You will see:
1. The text is not displayed centered. 2. As soon as you have at least two lines, the text will be displayed centered (but only from the second line) when you move the workspace on the screen. However the cursor rep. the current selection is displayed as for leftFlush text. 3. As soon as as you tpye in an additional character, the the line that received that character is again displayed left flush.
The first change set after #4599 that has significant chenges to the display machinery is #4614 (titled: 'TextAndFonts-ar' from Dec 17, 2001). Later followed: #4631 (MVCFixes-ar) without preamble, #4717 (CharBlockScannerFix-slg from Jan 10, 2002) #4723 (initMorphicOffsets-ls from Jan 19, 2002) #4727 (initLeftMArgin-ls from Jan 14, 2002) #4730 (FixUpdateGliches-di from Jan 30, 2002)
I think that the bug is simply a glitch that came in with #4614 and was never seen. (I work a lot with MVC but usually I feel no need to center text. Today I tested an editor and saw this problem.)
The point is - in my opinion - that in two methods (CharacterBlockScanner>>buildCharacterBlockIn: and !DisplayScanner displayLinesin:clippedBy:) the scanner is not completely initialized when the essential work is performed. In these methods the statement alignment ifNil:[textStyle alignment] is executed when the instance variable alignment is still nil and this causes the use of the default. (Place a 'self beep.' into the block to verify this!) The assignment to 'alignment' is triggered in CharacterScanner>>setFont. In the presenece of an TextAlignment atribute, the 'att emphasiseScanner: self' is sent to the TextAlignment instance which in turn calls CharacterScanner>>setAlignment.
CharacterScanner>>setFont is called by CharacterScanner>> setStopConditions and I think that it is sufficient to send this method before the first call of leftMarginForDisplayForLine:alignment: to the paragraph.
Attached you find a change set that is a proposal to fix this glitch. It is deliberately not labelled as a FIX. I want first to hear the opinions of others on this mailing list. Afterall, a careless change to methods in CharacterScanner can easily ruin an image.
Greetings Boris
squeak-dev@lists.squeakfoundation.org