Smalltalk › Squeak › Squeak - Dev

fonts, characterscanners and dead primitive 103

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

66 messages Options

1234

timrowledge

Re: fonts, characterscanners and dead primitive 103

I've now finished looking at users of the assorted scanner classes and senders of related messages and boy, what a mix.

Odd bits that I could really do with answers to -

RemoteCanvas>paragraph:bounds:color: - should it be using MultiCanvasCharacterScanner ?
The only other reference to CanvasCharacterScanner is from Canvas>paragraph2:bound:color: which is unsent, so I propose to remove it.

Paragraph>composeAll refers to MultiTextComposer - why? seems like a mixup with NewParagraph to me.
Similarly, Paragraph>displayLines:affectedRectangle: refers to MultiDisplayScanner when I'd anticipate DisplayScanner

GrafPort>displayScannerForMulti:foreground:background: ignoreColorChanges: ( only sent by

FormCanvas>paragraph3:bounds:colour: (refers to DisplayScanner) is only sent by TextMorph>drawOnTest: which is unsent, so I propose to remove the whole lot.

The choice between CharacterBlockScanner & MultiCBS in NewParagraph>characterBlock… is based on #isWideString. The choice between DisplayScanner and MultiDS in GrafPort>displayScannerFor…. is based on para isMemberOf: MultiNewParagraph) or: [para text string isByteString] and I can't currently see why the difference.

In NewParagraph>composeAll, the choice between a plain compose and multi-compose message is based not on whether the string is byte or wide, but whether it *could* be be byte even if actually wide. That seems like it might dangerously skip over an encoding issue?

Answers on these could be quite useful in trying to work out the intention of some of the code, which is important because <b>lack of comments</b>

One of the suggestions when I started on this stuff was that the multi-stuff was associated with NewParagraph and was for Morphic text handling whereas the old scanners and Paragraph was kept for MVC. It really isn't looking much like that at the moment.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Compatible: Gracefully accepts erroneous data from any source.

Nicolas Cellier

Re: fonts, characterscanners and dead primitive 103

I have done one part of this job independently, removed all senders of getPresentation getPresentationLines

This covers FormCanvas>paragraph3:bounds:colour: and TextMorph>drawOnTest: and a bunch of other (see attached change set)

This then enables removing presentation presentationLines and numOfComposition from MultiCharacterScanner and get the two hierarchies a bit closer...

As i said in another mail, rendering CombinedChar and transforming WideString to precomposed or not are two orthogonal matters, there is no reason to fuse the two notions, so my feeling is that we must redo this part.

And the font should be responsible of displaying the CombinedChar...

I wanted to publish in inbox, unfortunately I messed up Morphic-nice.683.mcz in trunk (two versions with exactly same name...)

I'll try to restore the original Morphic-nice.683.mcz tomorrow morning, and I think that it is important because the original is the one pointed by the mcm update (they retain the UUID). So please don't publish a Morphic in trunk until then...

2013/9/24 tim Rowledge <[hidden email]>

I've now finished looking at users of the assorted scanner classes and senders of related messages and boy, what a mix.

Odd bits that I could really do with answers to -

RemoteCanvas>paragraph:bounds:color: - should it be using MultiCanvasCharacterScanner ?
The only other reference to CanvasCharacterScanner is from Canvas>paragraph2:bound:color: which is unsent, so I propose to remove it.

Paragraph>composeAll refers to MultiTextComposer - why? seems like a mixup with NewParagraph to me.
Similarly, Paragraph>displayLines:affectedRectangle: refers to MultiDisplayScanner when I'd anticipate DisplayScanner

GrafPort>displayScannerForMulti:foreground:background: ignoreColorChanges: ( only sent by

FormCanvas>paragraph3:bounds:colour: (refers to DisplayScanner) is only sent by TextMorph>drawOnTest: which is unsent, so I propose to remove the whole lot.

The choice between CharacterBlockScanner & MultiCBS in NewParagraph>characterBlock… is based on #isWideString. The choice between DisplayScanner and MultiDS in GrafPort>displayScannerFor…. is based on para isMemberOf: MultiNewParagraph) or: [para text string isByteString] and I can't currently see why the difference.

In NewParagraph>composeAll, the choice between a plain compose and multi-compose message is based not on whether the string is byte or wide, but whether it *could* be be byte even if actually wide. That seems like it might dangerously skip over an encoding issue?

Answers on these could be quite useful in trying to work out the intention of some of the code, which is important because <b>lack of comments</b>

One of the suggestions when I started on this stuff was that the multi-stuff was associated with NewParagraph and was for Morphic text handling whereas the old scanners and Paragraph was kept for MVC. It really isn't looking much like that at the moment.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim

Compatible: Gracefully accepts erroneous data from any source.

methods.st (7K) Download Attachment

timrowledge

Re: fonts, characterscanners and dead primitive 103

In reply to this post by timrowledge

Another odd bit to consider -
MultiNewParagraph is, so far as I can tell, dead, defunct, unrequired and should be removed. It only adds presentationText/Lines and no usage is made of them.

Make your bid soon to preserve this unloved class, or say sayonara.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
No one is listening until you make a mistake

Nicolas Cellier

Re: fonts, characterscanners and dead primitive 103

Yes, after removal of presentation*, it is mostly un-needed
But beware, I have MultiNewParagraph allInstances size -> 85, because of TextMorph>>paragraphClass.

So something special might be required in update process to hook opened windows...

2013/9/24 tim Rowledge <[hidden email]>

Another odd bit to consider -
MultiNewParagraph is, so far as I can tell, dead, defunct, unrequired and should be removed. It only adds presentationText/Lines and no usage is made of them.

Make your bid soon to preserve this unloved class, or say sayonara.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim

No one is listening until you make a mistake

timrowledge

Re: fonts, characterscanners and dead primitive 103

In reply to this post by Nicolas Cellier

On 23-09-2013, at 5:29 PM, Nicolas Cellier <[hidden email]> wrote:

> I have done one part of this job independently, removed all senders of getPresentation getPresentationLines
> This covers FormCanvas>paragraph3:bounds:colour: and TextMorph>drawOnTest: and a bunch of other (see attached change set)
> This then enables removing presentation presentationLines and numOfComposition from MultiCharacterScanner and get the two hierarchies a bit closer...
> As i said in another mail, rendering CombinedChar and transforming WideString to precomposed or not are two orthogonal matters, there is no reason to fuse the two notions, so my feeling is that we must redo this part.
> And the font should be responsible of displaying the CombinedChar…
>
OK, we need to be careful to not stomp on each other's feet here.

wrt your changeset -

GrafPort>displayScannerForMulti… can't see any change but it should be completely deleted anyway
MultiNewParagraph stuff should all go away

I'll remove some of the pointless nasties and submit the package(s), you make sure to update before starting work tomorrow ;-)

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Time to start the War on Errorism before stupidity finally gets us.

timrowledge

Re: fonts, characterscanners and dead primitive 103

In reply to this post by Nicolas Cellier

On 23-09-2013, at 5:38 PM, Nicolas Cellier <[hidden email]> wrote:

> Yes, after removal of presentation*, it is mostly un-needed
> But beware, I have MultiNewParagraph allInstances size -> 85, because of TextMorph>>paragraphClass.
> So something special might be required in update process to hook opened windows…
Ah yes, the joy of live programming...

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
If it was easy, the hardware people would take care of it.

timrowledge

Re: fonts, characterscanners and dead primitive 103

Good news is that getting rid of all references to MultiNewParagraph doesn't seem to break anything and all the tests that used to refer to it still work when referring to plain old NewParagraph instead.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: IO: Illogical Or

Nicolas Cellier

Re: fonts, characterscanners and dead primitive 103

Another one for tim:

MultiTextComposer multiComposeLinesFrom: etc... differs from TextComposer by two lines:

1) it uses a MultiCompositionScanner instead of a CompositionScanner

2) it does not have the workaround (scanner canComputeDefaultLineHeight)
the fix is implemented only in CompositionScanner (introduced in 2010 by cmm)

Name: Morphic-cmm.440

Fix for composing Text's with TextAnchors as first character.

2013/9/24 tim Rowledge <[hidden email]>

Good news is that getting rid of all references to MultiNewParagraph doesn't seem to break anything and all the tests that used to refer to it still work when referring to plain old NewParagraph instead.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim

Strange OpCodes: IO: Illogical Or

timrowledge

Re: fonts, characterscanners and dead primitive 103

In reply to this post by timrowledge

On 23-09-2013, at 6:12 PM, tim Rowledge <[hidden email]> wrote:

> Good news is that getting rid of all references to MultiNewParagraph doesn't seem to break anything and all the tests that used to refer to it still work when referring to plain old NewParagraph instead.

More good news; a nice simple and obvious
MultiNewParagraph allInstancesDo:[:mnp|
mnp become: (mnp as: NewParagraph)]
followed by a gc is enough to get rid of all instances without so far as I can tell causing any issues. So the obvious question is how to make a package with that and the class deletion; never done any sort of preamble script for MC stuff before so all advice welcomed.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Oxymorons: Living dead

cbc

Re: fonts, characterscanners and dead primitive 103

Could you add a MultiNewParagraph class>>initialize that does your snippit (change all instances to NewParagraph).

Include that MCZ in a new configuration map with that version (to ensure it loads for everyone else).

Then commit a new version of the package without MultiNeweParagraph.

This works, right? you'd think I'd want to be updating Trunk at some point, too, wouldn't you?

-cbc

On Tue, Sep 24, 2013 at 11:18 AM, tim Rowledge <[hidden email]> wrote:

On 23-09-2013, at 6:12 PM, tim Rowledge <[hidden email]> wrote:

> Good news is that getting rid of all references to MultiNewParagraph doesn't seem to break anything and all the tests that used to refer to it still work when referring to plain old NewParagraph instead.

More good news; a nice simple and obvious
MultiNewParagraph allInstancesDo:[:mnp|
mnp become: (mnp as: NewParagraph)]
followed by a gc is enough to get rid of all instances without so far as I can tell causing any issues. So the obvious question is how to make a package with that and the class deletion; never done any sort of preamble script for MC stuff before so all advice welcomed.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim

Oxymorons: Living dead

Nicolas Cellier

Re: fonts, characterscanners and dead primitive 103

Done, give it a try if not faint hearted ;)

2013/9/24 Chris Cunningham <[hidden email]>

Could you add a MultiNewParagraph class>>initialize that does your snippit (change all instances to NewParagraph).
Include that MCZ in a new configuration map with that version (to ensure it loads for everyone else).

Then commit a new version of the package without MultiNeweParagraph.

This works, right? you'd think I'd want to be updating Trunk at some point, too, wouldn't you?

-cbc

On Tue, Sep 24, 2013 at 11:18 AM, tim Rowledge <[hidden email]> wrote:

On 23-09-2013, at 6:12 PM, tim Rowledge <[hidden email]> wrote:

> Good news is that getting rid of all references to MultiNewParagraph doesn't seem to break anything and all the tests that used to refer to it still work when referring to plain old NewParagraph instead.

More good news; a nice simple and obvious
MultiNewParagraph allInstancesDo:[:mnp|
mnp become: (mnp as: NewParagraph)]
followed by a gc is enough to get rid of all instances without so far as I can tell causing any issues. So the obvious question is how to make a package with that and the class deletion; never done any sort of preamble script for MC stuff before so all advice welcomed.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim

Oxymorons: Living dead

timrowledge

Re: fonts, characterscanners and dead primitive 103

In reply to this post by cbc

On 24-09-2013, at 1:32 PM, Chris Cunningham <[hidden email]> wrote:

> Could you add a MultiNewParagraph class>>initialize that does your snippit (change all instances to NewParagraph).
> Include that MCZ in a new configuration map with that version (to ensure it loads for everyone else).
> Then commit a new version of the package without MultiNeweParagraph.
>
> This works, right? you'd think I'd want to be updating Trunk at some point, too, wouldn't you?

I don't actually know if that is the right thing to do; does loading package-chthulhu.5 when you currently have .2 result in .3 then .4 and finally .5 being loaded? If it only loads .5 then the intermediate and temporary existence of the method isn't noticed.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
As far as we know, our computer has never had an undetected error.

Nicolas Cellier

Re: fonts, characterscanners and dead primitive 103

The packages listed in the next update-*.mcm are required intermediates.

If:

chthulhu.tpr.3 is specified in update-tpr.248.mcz
chthulhu.tpr.7 is specified in update-tpr.249.mcz
chthulhu.tpr.10 is highest version in Trunk

then these 3 packages will be loaded/merged in that order, and intermediate packages will be ignored...

I've specified Morphic-nice.688 in update-tpr.247.mcz, so the initialize method will be invoked for sure...

2013/9/25 tim Rowledge <[hidden email]>

On 24-09-2013, at 1:32 PM, Chris Cunningham <[hidden email]> wrote:

> Could you add a MultiNewParagraph class>>initialize that does your snippit (change all instances to NewParagraph).
> Include that MCZ in a new configuration map with that version (to ensure it loads for everyone else).
> Then commit a new version of the package without MultiNeweParagraph.
>
> This works, right? you'd think I'd want to be updating Trunk at some point, too, wouldn't you?

I don't actually know if that is the right thing to do; does loading package-chthulhu.5 when you currently have .2 result in .3 then .4 and finally .5 being loaded? If it only loads .5 then the intermediate and temporary existence of the method isn't noticed.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim

As far as we know, our computer has never had an undetected error.

timrowledge

Re: fonts, characterscanners and dead primitive 103

On 24-09-2013, at 3:18 PM, Nicolas Cellier <[hidden email]> wrote:

> The packages listed in the next update-*.mcm are required intermediates.
>
> If:
> chthulhu.tpr.3 is specified in update-tpr.248.mcz
> chthulhu.tpr.7 is specified in update-tpr.249.mcz
> chthulhu.tpr.10 is highest version in Trunk
>
> then these 3 packages will be loaded/merged in that order, and intermediate packages will be ignored...
> I've specified Morphic-nice.688 in update-tpr.247.mcz, so the initialize method will be invoked for sure…

OK, so that is some other part of MC about which I am blissfully ignorant. As long as it all integrates in with the updating menu item in the top-of-screen dock then we're all ok.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Noli me vocare, ego te vocabo = Don't call me, I'll call you.

timrowledge

Re: fonts, characterscanners and dead primitive 103

The next step - I have changes that remove the need for MultiTextComposer and clean up a variety of usages. BUT the order of making the changes is (as you have to expect when changing the tools that change the tools) crucially important.
I'd really appreciate it if one you that already knows the MC magic to ensure correct ordering could leap to my assistance for this; it would be nice to avoid the fun we had the other day.

The load order needs to be
Multilingual-tpr.174 on top of Multilingual-nice.173
Graphics-tpr.229 on top of Graphics-tpr.228
only then can Graphics-tpr.230 be added (method ordering seems an issue)
finally Morphic-tpr.689 makes use of the changes.

Gradually, bit by bit, little curlicues of ugliness are being abraded away….

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Vescere bracis meis. = Eat my shorts.

Nicolas Cellier

Re: fonts, characterscanners and dead primitive 103

Ah, the tool for you is MC Configuration Browser.

Here is how to use:

1) open MC browser

2) open repository browser on trunk

3) select (pseudo) package named update and latest update version (update-nice.247.mcm)

4) click Browse button

At this stage you have a MC Configuration Browser armed for the massacre of text composition.

5) Arrange to load in your image all the packages that you want to figure in the map
(Multilingual-tpr.174 and Graphics-tpr.229)

6) Select the Multilingual package in the configuration browser list (Multilingual-nice.171)

7) pop up menu and 'update this dependency from image'

8) redo with Graphics

9) click Store button and accept update-tpr.248, publish in trunk

At this stage, you gained a MC configuration publisher skill.

Now if Graphics-tpr.230 is really an intermediate requirement, you could make a second update-tpr.249

Note that you can also mess with the package load order in last resort (the top most in the list is loaded/merged first).

Since currently Graphics is loaded before Multilingual, I don't think that the second update is necessary...

If you do that, you'll get the MC configuration hacker skill, and it's not recommended to get two MC skills in a single evening.

2013/9/25 tim Rowledge <[hidden email]>

The next step - I have changes that remove the need for MultiTextComposer and clean up a variety of usages. BUT the order of making the changes is (as you have to expect when changing the tools that change the tools) crucially important.
I'd really appreciate it if one you that already knows the MC magic to ensure correct ordering could leap to my assistance for this; it would be nice to avoid the fun we had the other day.

The load order needs to be
Multilingual-tpr.174 on top of Multilingual-nice.173
Graphics-tpr.229 on top of Graphics-tpr.228
only then can Graphics-tpr.230 be added (method ordering seems an issue)
finally Morphic-tpr.689 makes use of the changes.

Gradually, bit by bit, little curlicues of ugliness are being abraded away….

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim

Useful Latin Phrases:- Vescere bracis meis. = Eat my shorts.

David T. Lewis

Re: fonts, characterscanners and dead primitive 103

On Thu, Sep 26, 2013 at 12:32:08AM +0200, Nicolas Cellier wrote:
>
> If you do that, you'll get the MC configuration hacker skill, and it's not
> recommended to get two MC skills in a single evening.
>

Ha! :)

The accumulation of excessive MC skills is a rare but serious condition. A reported
cure is to release some of the excess mental pressure in the form of a new class comment
for some undocumented MC class.

Dave

timrowledge

Re: fonts, characterscanners and dead primitive 103

In reply to this post by Nicolas Cellier

On 25-09-2013, at 3:32 PM, Nicolas Cellier <[hidden email]> wrote:

> Ah, the tool for you is MC Configuration Browser.
> Here is how to use:

Right, that appears to have worked from my end, so hopefully I followed the recipe correctly and it works for the rest of you out there!

Thanks for the clear explanation. Now, let;s see if I can collapse CompositionScanner & MultiCompositionScanner.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: CCC: Crash if Carry Clear

timrowledge

Re: fonts, characterscanners and dead primitive 103

In reply to this post by David T. Lewis

On 25-09-2013, at 5:00 PM, "David T. Lewis" <[hidden email]> wrote:
>
> The accumulation of excessive MC skills is a rare but serious condition. A reported
> cure is to release some of the excess mental pressure in the form of a new class comment
> for some undocumented MC class.

What? There are classes without proper comments? Unpossible!

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Oxymorons: Resident alien

timrowledge

Re: fonts, characterscanners and dead primitive 103

In reply to this post by timrowledge

I note that there seems to be no attempt in #scanJapaneseCharactersFrom… to handle kerning. Is this because Japanese character glyphs don't get kerned, or is it a bug that should be addressed at some point?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- One flower short of an arrangement.

1234