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





-------------- next part --------------
A non-text attachment was scrubbed...
Name: CenteredTextFix-Bg.zip
Type: application/octet-stream
Size: 2292 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030531/04d39288/CenteredTextFix-Bg.obj