Weird text composition when tab happens at large destX

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Weird text composition when tab happens at large destX

Nicolas Cellier
Hi,
the (attached) text composition bugs me:
When a tab occurs after some column, the composition creates a new line, even when there is room for more text...
I tried to create a test case in CharacterScannerTest

testCrossedXWithManyTabs
| p text chunkWidth expectedChunkStartX expectedWidth |
text := (String new: 59 streamContents: [:str | (String new: 14 withAll: $m) do: [:m | 5 timesRepeat: [str nextPut: m]] separatedBy: [str tab]]) asText.
chunkWidth := 5*mWidth.
expectedChunkStartX := Array new: 14 streamContents:
[:str |
(1 to: 14) inject: 1 into:
[:destX :rank |
str nextPut: destX.
(style nextTabXFrom: destX + chunkWidth leftMargin: 0 rightMargin: 0)]].
expectedWidth := expectedChunkStartX last + chunkWidth.
p := NewParagraph new.
p
compose: text
style: style
from: 1
in: (0 @ 0 corner: expectedWidth+10 @ (style lineGrid * 2)).
self assert: p lines size = 1 description: 'There is enough composition width for this text'.

but the test pass (it composes in single line). Any idea where to look at?




WeirdComposition.png (14K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Weird text composition when tab happens at large destX

Nicolas Cellier
Ah found it, the tabsArray stops at 720 currently in default TextStyle...
Now that our screen are so wide, maybe it's not enough.
And the test does not pass and does not work like I thought it should.

Le mer. 15 mai 2019 à 21:36, Nicolas Cellier <[hidden email]> a écrit :
Hi,
the (attached) text composition bugs me:
When a tab occurs after some column, the composition creates a new line, even when there is room for more text...
I tried to create a test case in CharacterScannerTest

testCrossedXWithManyTabs
| p text chunkWidth expectedChunkStartX expectedWidth |
text := (String new: 59 streamContents: [:str | (String new: 14 withAll: $m) do: [:m | 5 timesRepeat: [str nextPut: m]] separatedBy: [str tab]]) asText.
chunkWidth := 5*mWidth.
expectedChunkStartX := Array new: 14 streamContents:
[:str |
(1 to: 14) inject: 1 into:
[:destX :rank |
str nextPut: destX.
(style nextTabXFrom: destX + chunkWidth leftMargin: 0 rightMargin: 0)]].
expectedWidth := expectedChunkStartX last + chunkWidth.
p := NewParagraph new.
p
compose: text
style: style
from: 1
in: (0 @ 0 corner: expectedWidth+10 @ (style lineGrid * 2)).
self assert: p lines size = 1 description: 'There is enough composition width for this text'.

but the test pass (it composes in single line). Any idea where to look at?



Reply | Threaded
Open this post in threaded view
|

Re: Weird text composition when tab happens at large destX

Nicolas Cellier
The test did not work because rightMargin should have been further toward east, in the indies (1e6 is a good start).
The tabsArray are never adapted to character width, and so might be a bit small for large fonts!
They always take the DefaultTabsArray from TextConstants.

I see this:
(TextStyle default defaultFont widthOf: Character space) = 4
(TextStyle default defaultFont widthOf: $m) = 12
DefaultTabsArray is every 24 pixels (6 space width but only 2 m!)

I won't fix the un-adaptative stops by now.
I don't know what to provide as default and those pixels bug me.
Fonts should never be defined in pixels, they should be defined in points
(a unit of length use in printing, which is about 1/72 inch, 1/72.27 more exactly).
In the eighties, a Screen resolution of 72 dpi (dot per inch) was somehow typical, but not nowadays...
Today the resolution of many screens is super high (200 dpi or more).
Fortunately (???) we draw hideous big squares for what we pretend to be a pixel.

In the meantime, I suggest a quick and dirty fix.
TextConstants is a global, for which we long lost the recipe of making of...
So I'd suggest some post-script like this for doubling the number of tabs:

    (TextConstants at: #DefaultTabsArray) becomeForward: (24 to: 1440 by: 24) asArray.
    (TextConstants at: #DefaultMarginTabsArray) becomeForward: ((24 to: 720 by: 24) collect: [:i | {i. i}]).

Unless we also grow the stops to 32 (8 spaces, 2/3+2 m...)?

Le mer. 15 mai 2019 à 21:51, Nicolas Cellier <[hidden email]> a écrit :
Ah found it, the tabsArray stops at 720 currently in default TextStyle...
Now that our screen are so wide, maybe it's not enough.
And the test does not pass and does not work like I thought it should.

Le mer. 15 mai 2019 à 21:36, Nicolas Cellier <[hidden email]> a écrit :
Hi,
the (attached) text composition bugs me:
When a tab occurs after some column, the composition creates a new line, even when there is room for more text...
I tried to create a test case in CharacterScannerTest

testCrossedXWithManyTabs
| p text chunkWidth expectedChunkStartX expectedWidth |
text := (String new: 59 streamContents: [:str | (String new: 14 withAll: $m) do: [:m | 5 timesRepeat: [str nextPut: m]] separatedBy: [str tab]]) asText.
chunkWidth := 5*mWidth.
expectedChunkStartX := Array new: 14 streamContents:
[:str |
(1 to: 14) inject: 1 into:
[:destX :rank |
str nextPut: destX.
(style nextTabXFrom: destX + chunkWidth leftMargin: 0 rightMargin: 0)]].
expectedWidth := expectedChunkStartX last + chunkWidth.
p := NewParagraph new.
p
compose: text
style: style
from: 1
in: (0 @ 0 corner: expectedWidth+10 @ (style lineGrid * 2)).
self assert: p lines size = 1 description: 'There is enough composition width for this text'.

but the test pass (it composes in single line). Any idea where to look at?



Reply | Threaded
Open this post in threaded view
|

Re: Weird text composition when tab happens at large destX

Squeak - Dev mailing list
+1


/*—————————————————-*/

On May 15, 2019, at 13:56, Nicolas Cellier <[hidden email]> wrote:

The test did not work because rightMargin should have been further toward east, in the indies (1e6 is a good start).
The tabsArray are never adapted to character width, and so might be a bit small for large fonts!
They always take the DefaultTabsArray from TextConstants.

I see this:
(TextStyle default defaultFont widthOf: Character space) = 4
(TextStyle default defaultFont widthOf: $m) = 12
DefaultTabsArray is every 24 pixels (6 space width but only 2 m!)

I won't fix the un-adaptative stops by now.
I don't know what to provide as default and those pixels bug me.
Fonts should never be defined in pixels, they should be defined in points
(a unit of length use in printing, which is about 1/72 inch, 1/72.27 more exactly).
In the eighties, a Screen resolution of 72 dpi (dot per inch) was somehow typical, but not nowadays...
Today the resolution of many screens is super high (200 dpi or more).
Fortunately (???) we draw hideous big squares for what we pretend to be a pixel.

In the meantime, I suggest a quick and dirty fix.
TextConstants is a global, for which we long lost the recipe of making of...
So I'd suggest some post-script like this for doubling the number of tabs:

    (TextConstants at: #DefaultTabsArray) becomeForward: (24 to: 1440 by: 24) asArray.
    (TextConstants at: #DefaultMarginTabsArray) becomeForward: ((24 to: 720 by: 24) collect: [:i | {i. i}]).

Unless we also grow the stops to 32 (8 spaces, 2/3+2 m...)?

Le mer. 15 mai 2019 à 21:51, Nicolas Cellier <[hidden email]> a écrit :
Ah found it, the tabsArray stops at 720 currently in default TextStyle...
Now that our screen are so wide, maybe it's not enough.
And the test does not pass and does not work like I thought it should.

Le mer. 15 mai 2019 à 21:36, Nicolas Cellier <[hidden email]> a écrit :
Hi,
the (attached) text composition bugs me:
When a tab occurs after some column, the composition creates a new line, even when there is room for more text...
I tried to create a test case in CharacterScannerTest

testCrossedXWithManyTabs
| p text chunkWidth expectedChunkStartX expectedWidth |
text := (String new: 59 streamContents: [:str | (String new: 14 withAll: $m) do: [:m | 5 timesRepeat: [str nextPut: m]] separatedBy: [str tab]]) asText.
chunkWidth := 5*mWidth.
expectedChunkStartX := Array new: 14 streamContents:
[:str |
(1 to: 14) inject: 1 into:
[:destX :rank |
str nextPut: destX.
(style nextTabXFrom: destX + chunkWidth leftMargin: 0 rightMargin: 0)]].
expectedWidth := expectedChunkStartX last + chunkWidth.
p := NewParagraph new.
p
compose: text
style: style
from: 1
in: (0 @ 0 corner: expectedWidth+10 @ (style lineGrid * 2)).
self assert: p lines size = 1 description: 'There is enough composition width for this text'.

but the test pass (it composes in single line). Any idea where to look at?




Reply | Threaded
Open this post in threaded view
|

Re: Weird text composition when tab happens at large destX

marcel.taeumel
In reply to this post by Nicolas Cellier
Hi Nicolas,

I think it is related to the DefaultTabsArray in TextStyle, which does only specify [tab] positions up to 720 px. Thus, it is also related to the font (size) you are currently using. The mechanism in TextStyle >> #nextTabFrom:... has an upper bound and works on (unscaled) pixels. 

We might want to ...
1) use RealEstateAgent class >> #scaleFactor as a workaround
2) Increase DefaultTabs beyond 720 px.


Best,
Marcel

Am 15.05.2019 21:36:53 schrieb Nicolas Cellier <[hidden email]>:

Hi,
the (attached) text composition bugs me:
When a tab occurs after some column, the composition creates a new line, even when there is room for more text...
I tried to create a test case in CharacterScannerTest

testCrossedXWithManyTabs
| p text chunkWidth expectedChunkStartX expectedWidth |
text := (String new: 59 streamContents: [:str | (String new: 14 withAll: $m) do: [:m | 5 timesRepeat: [str nextPut: m]] separatedBy: [str tab]]) asText.
chunkWidth := 5*mWidth.
expectedChunkStartX := Array new: 14 streamContents:
[:str |
(1 to: 14) inject: 1 into:
[:destX :rank |
str nextPut: destX.
(style nextTabXFrom: destX + chunkWidth leftMargin: 0 rightMargin: 0)]].
expectedWidth := expectedChunkStartX last + chunkWidth.
p := NewParagraph new.
p
compose: text
style: style
from: 1
in: (0 @ 0 corner: expectedWidth+10 @ (style lineGrid * 2)).
self assert: p lines size = 1 description: 'There is enough composition width for this text'.

but the test pass (it composes in single line). Any idea where to look at?



Reply | Threaded
Open this post in threaded view
|

Re: Weird text composition when tab happens at large destX

marcel.taeumel
In reply to this post by Squeak - Dev mailing list
+1

Am 16.05.2019 01:59:04 schrieb John Pfersich via Squeak-dev <[hidden email]>:

+1


/*—————————————————-*/

On May 15, 2019, at 13:56, Nicolas Cellier <[hidden email]> wrote:

The test did not work because rightMargin should have been further toward east, in the indies (1e6 is a good start).
The tabsArray are never adapted to character width, and so might be a bit small for large fonts!
They always take the DefaultTabsArray from TextConstants.

I see this:
(TextStyle default defaultFont widthOf: Character space) = 4
(TextStyle default defaultFont widthOf: $m) = 12
DefaultTabsArray is every 24 pixels (6 space width but only 2 m!)

I won't fix the un-adaptative stops by now.
I don't know what to provide as default and those pixels bug me.
Fonts should never be defined in pixels, they should be defined in points
(a unit of length use in printing, which is about 1/72 inch, 1/72.27 more exactly).
In the eighties, a Screen resolution of 72 dpi (dot per inch) was somehow typical, but not nowadays...
Today the resolution of many screens is super high (200 dpi or more).
Fortunately (???) we draw hideous big squares for what we pretend to be a pixel.

In the meantime, I suggest a quick and dirty fix.
TextConstants is a global, for which we long lost the recipe of making of...
So I'd suggest some post-script like this for doubling the number of tabs:

    (TextConstants at: #DefaultTabsArray) becomeForward: (24 to: 1440 by: 24) asArray.
    (TextConstants at: #DefaultMarginTabsArray) becomeForward: ((24 to: 720 by: 24) collect: [:i | {i. i}]).

Unless we also grow the stops to 32 (8 spaces, 2/3+2 m...)?

Le mer. 15 mai 2019 à 21:51, Nicolas Cellier <[hidden email]> a écrit :
Ah found it, the tabsArray stops at 720 currently in default TextStyle...
Now that our screen are so wide, maybe it's not enough.
And the test does not pass and does not work like I thought it should.

Le mer. 15 mai 2019 à 21:36, Nicolas Cellier <[hidden email]> a écrit :
Hi,
the (attached) text composition bugs me:
When a tab occurs after some column, the composition creates a new line, even when there is room for more text...
I tried to create a test case in CharacterScannerTest

testCrossedXWithManyTabs
| p text chunkWidth expectedChunkStartX expectedWidth |
text := (String new: 59 streamContents: [:str | (String new: 14 withAll: $m) do: [:m | 5 timesRepeat: [str nextPut: m]] separatedBy: [str tab]]) asText.
chunkWidth := 5*mWidth.
expectedChunkStartX := Array new: 14 streamContents:
[:str |
(1 to: 14) inject: 1 into:
[:destX :rank |
str nextPut: destX.
(style nextTabXFrom: destX + chunkWidth leftMargin: 0 rightMargin: 0)]].
expectedWidth := expectedChunkStartX last + chunkWidth.
p := NewParagraph new.
p
compose: text
style: style
from: 1
in: (0 @ 0 corner: expectedWidth+10 @ (style lineGrid * 2)).
self assert: p lines size = 1 description: 'There is enough composition width for this text'.

but the test pass (it composes in single line). Any idea where to look at?